Last week I suggested that all commercial distributions adopt Debian as the foundation for their Linux distribution and build added value upon it. Gauging from the responses I received regarding last week's column, most of my readers misunderstood my rationale for choosing Debian as a prime candidate for a Linux distribution standard. I'll gladly take the blame for that. I obviously spent too much energy raving about the Debian approach to upgrading software and neglected to reconnect the dots on the other issues I had raised in past columns.
Despite how I waxed rhapsodic over Debian's apt-get program last week, this is not about RPM package format versus Debian package format, the dpkg program versus the RPM program, the apt-get program versus the various RPM update programs available, or about an octopus trapped in a chicken's body. The issue is about getting all major commercial Linux distributions to agree to start with a common, comprehensive, standard Linux distribution and add value beyond that foundation.
Here are the requirements, as I see them, for the above plan to have maximum benefit to customers and developers:
- The Linux distribution standard must be broad enough to eliminate kernel, application, and package incompatibilities across all commercial distributors that adopt the standard.
- It must document strict installation and maintenance policies by which all Linux software must be developed and packaged.
- An independent group must maintain the standard distribution and provide the software to the public so that no single commercial entity can manipulate the standard to its exclusive advantage.
- The independent Linux distribution standard group should divide its work into several levels. The group should maintain and improve the current version, develop the next version, and experiment with ideas for future versions. In addition, the group should maintain a repository of security fixes. Customers should have maximum flexibility on how and what they update within their individual Linux installations. For example, customers should -- at their discretion and with minimum effort -- be able to update everything or only security fixes.
- All levels of development must be updated regularly and be freely available to both customers and developers. Customers and developers must be able to update or upgrade their base Linux distributions easily and without cost, regardless of their commercial Linux distribution. All software package dependencies should be resolved automatically when updating any of the software.
- The software installation and upgrade process must be safe, flexible, and reliable. By safe, I mean it should attempt to guarantee that the software is free of Trojans or other malicious changes to the original code. By flexible, I mean the installation software should allow you to install some upgrades by other means, such as compiling the code yourself without confusing the installation or upgrade process for other packaged software. Reliability is rather self-explanatory.
|
The issue of update utilities
Readers pointed out many alternatives to Debian's approach to updating and upgrading Linux systems. In particular, they mentioned that Conectiva has modified Debian's apt programs to work with RPM, so that you can update Conectiva the same way as Debian. At least one reader claims to be using Conectiva's version of apt to update his Mandrake distribution. I haven't tried that yet but, after browsing through the Conectiva apt package, it certainly seems possible. Bravo to Conectiva for the port of apt. Click here for the full text.
|
I'm sure I've neglected some important factors, but I'm equally sure you understand that good standards are never created by a single person. The list above is a starting point, and I happen to believe Debian GNU/Linux currently fits the description best. I also believe Debian would be the easiest distribution to tweak to comply with my requirements or to make it compare well with other distributions.
But please don't fixate on Debian or packaging issues. Of course, Debian has many weaknesses, including even its packaging format, as many readers aptly pointed out. If it is Debian itself that offends you, forget about it. The point is that all commercial distributions should adopt a standard distribution such as the one I describe above, whatever its origin.
Look at the advantages. If all commercial Linux distributors agreed on a standard Linux distribution and built from there, they would no longer needlessly duplicate the effort of maintaining several base distributions. They could easily redirect a portion of their development staff to improving the standard distribution, and devote the rest of their talent toward building the kind of unique added value that would bust the Linux market wide open.
If all commercial Linux distributors adopted a Linux distribution standard, it would eliminate the need for multiple packages for any single software product, free or proprietary. There would be no Mandrake version, Red Hat version or Debian version of the Apache Web server. There would simply be Apache for Linux.
If all commercial Linux distributors adopted a Linux distribution standard, we would eliminate the needless duplication of effort that now exists between distributions. Why are all the distros wasting time solving the same problems in different ways? Who other than obsessive-compulsive geeks really cares whether Linux init files exist in /etc/init.d or /etc/rc.d/init.d? Who really cares if the default init level for a multiuser graphical desktop is init 2 or init 3? And aren't we past the point of caring whether or not the initialization process is graphical or character mode?
Why not, for example, simply create a way to initialize Linux that all distros can live with, freeing them to innovate something much more important? Those distributors that are completely anal about such things can always customize their own installations to break conformance to the init standard. The point is that because so much of a Linux distribution is basically irrelevant to customers, it's just plain idiocy for distributors to devote time to such common issues in parallel only to produce products that give software developers and users headaches due to the differences.
If all commercial Linux distributors adopted a Linux distribution standard, they would create unmatched consumer confidence in Linux as a choice operating system. If you became unsatisfied with your commercial distribution or if your commercial distributor went out of business, you could still update and upgrade the most important part of your Linux installation indefinitely. Since the base distribution would be the same, you could even switch to another commercial distribution and take advantage of its added-value software without having to reinstall an entirely new Linux distribution. All you would have to install is the software unique to that new distribution. And all you would stand to lose by switching is any proprietary added value that had been offered by your previous commercial distribution. Your investment in Linux itself would be protected.
About now it should become obvious that if they followed my advice, commercial Linux distributors would no longer be Linux distributors at all. They would be distributors of added-value software and support. It should be equally obvious that the introduction of a distribution standard is not only a good thing but also inevitable.
I am optimistic about the future of commercial distributions, partly because I have already heard rumblings about the possibility of many of them collaborating on a single distribution standard. But for the sake of argument, let's assume Linux distributors ignored the need for a standard and continued to differentiate at too low a level for adequate cross-distribution compatibility. Sooner or later, one Linux distributor would have to become the de facto standard. The problem for other distributors would be that the dominant one alone would have sufficient resources to add unique value and support its distribution. The others would waste too much time maintaining their own base distributions, which are largely invisible to the customer. The nondominant players would duplicate effort to only gain a fraction of the revenue generated by the de facto standard. The little guys would essentially throw away the very money that they could have used to make their offerings more worthy of purchase than the de facto standard. In the end, the only way they could avoid that problem would be to adopt the de facto standard and build upon it.
Perhaps that is how it will play out. Maybe Caldera, Conectiva, Mandrake, Red Hat, SuSE, TurboLinux, or some other distribution will become the de facto standard, and the rest will eventually build on that standard. But I don't see how that could happen without a bloodbath in the Linux market. And that would have two serious consequences. First, it would undermine the perception that Linux is a good investment. Second, it would shift dominance from one player to another without solving the problem. Almost every commercial Linux distributor sees Red Hat as the enemy. If they collaborated on a standard to beat Red Hat and won, a dominant player would by necessity emerge from the collaborators. That dominant player would then become the enemy, and the cycle would start again.
The only way to avoid that situation is for everyone to adopt a comprehensive open standard maintained by people who are not driven by commercial interests. Lo and behold, there lies Debian waiting to be plucked up and honed to the task. Which is one of the many reasons I picked Debian as a starting point. But it's certainly not the only possibility. If you have a better idea, go for it.
Resources
The issue of update utilities
Readers pointed out many alternatives to Debian's approach to updating and upgrading Linux systems. In particular, they mentioned that Conectiva has modified Debian's apt programs to work with RPM, so that you can update Conectiva the same way as Debian. At least one reader claims to be using Conectiva's version of apt to update his Mandrake distribution. I haven't tried that yet but, after browsing through the Conectiva apt package, it certainly seems possible. Bravo to Conectiva for the port of apt.
People use other programs to update their systems, and many of them automatically resolve dependencies. Among them are Autoupdate, autorpm, up2date, YUP, and many others. A quick search on http://freshmeat.net will turn up some possibilities. I received one message from the maintainer of a new utility called MandrakeUpdateRobot (see Resources for a link).
I tried installing it on Mandrake 7.2, but it sent me digging for a cascading list of dependencies just to get it to work properly (it needs curl and lib-curl, at least one of which had other unmet dependencies on my system, such as glibc 2.2, which in turn needed other packages to be upgraded). That seemed rather ironic to me, since the utility is meant to solve such problems automatically.
It was probably just my unfamiliarity with the software, but I couldn't seem to use Mandrake's rpmdrake program to ease the pain of getting MandrakeUpdateRobot and all its dependencies resolved. The rpmdrake program is supposed to automatically resolve dependencies, so I should have been able to install something such as glibc2.2 and let rpmdrake do the work of resolving other needs. But for the life of me, I couldn't even find glibc2.2 on the Mandrake Cooker site using rpmdrake. That makes no sense, so I'm almost certain I was at fault. Regardless, I eventually got everything installed and made MandrakeUpdateRobot work, although I couldn't get it to work with my squid proxy (so I told it there was no proxy).
MandrakeUpdateRobot is very cool, and I'm sure I'll use it on my Mandrake partition. But it entirely misses the point I was trying to make about updating from a standard distribution. MandrakeUpdateRobot is great, but it doesn't update a base distribution upon which Mandrake Linux rests. It updates Mandrake. If Mandrake went bankrupt tomorrow, I couldn't point MandrakeUpdateRobot to a Red Hat or Caldera server and expect it to continue upgrading my system properly. And if I were running Red Hat, for example, I couldn't point to a Caldera or Mandrake server and expect updates to work properly. That's because those distributions' use of RPM is essentially meaningless when it comes to compatibility across distributions.
But when Stormix went bankrupt, I could point my Storm 2000 system to Debian servers and continue upgrading with only a few minor adjustments. That's because Stormix came very close to complying with my suggestion. The company started with Debian and then added value, seemingly without breaking anything in the standard Debian distribution.
Therefore, the real problem with software such as Conectiva's apt and MandrakeUpdateRobot is not that it uses RPM or doesn't do a good job of updating a system. The problem is that there is no generic RPM-based distribution on which Caldera, Conectiva, Mandrake, Red Hat, and other RPM distributions are based. If there were, I probably wouldn't have suggested Debian as the solution to the problem, as it would already have been solved for the most part.
Here's another important issue: Although Conectiva's apt and MandrakeUpdateRobot do fine when it comes to updating packages within whatever version of the distribution you have installed, I have never heard from anyone who has used one of those utilities to upgrade an RPM-based system from one significant version to the next. I do happen to know that you can use Debian's apt-get to go from one Debian version to the next quite easily and for free. That is the heart of satisfying DUH -- the Dementia Upgradia Habitua problem that afflicts so many folks. So if anyone reading this column has used an RPM-based autodependency upgrade utility (including Conectiva's apt port) to upgrade from Red Hat 6.2 to Red Hat 7.0, from Mandrake 7.1 to Mandrake 7.2, or perform any other significant version upgrade, by all means share the good news with me, and I'll pass it on to all readers.
Of course, the above testimony about how easy it was to continue upgrading Debian versions after Stormix folded begs the response that Stormix probably went bankrupt precisely because it had the same idea I'm proposing about how to upgrade software. I can't answer that. Whether or not that is true and whether or not that has any bearing on the value of my proposal remains to be proven either way.
