|
.comment: How Distributions Can Succeed (and help Linux take over the world)
SuSE 7.1 RevisitedLast week I wrote about my observations of two packages I was surprised by in my installation of SuSE 7.1 -- pcmcia-cs, which was surprisingly good, and XFree86-4.02, which was surprisingly bad. Actually, it was not so much the packages themselves as their configuration that struck me: the former worked perfectly with no configuration, while the latter, after days of configuration (and all sorts of messages to newsgroups, study of documents, and a note to tech support whose response did not provide a solution) didn't work and still doesn't. The responses, both public and private, were about as expected, though I still don't see how the column could be read as a general attack on SuSE, which I think is a fine distribution and which is the one I'd recommend to anyone contemplating a first exploration of Linux for desktop use. Having played around with SuSE 7.1 on the notebook machine for a few days and having, I thought, learned where any little bombs specific to the distribution -- and all distributions have them -- were hidden, I undertook to install it on my wife's desktop machine. Unlike the notebook, it can boot from its CD drive. Like the notebook, it has an 800x600 LCD panel. The installation went very well. The graphical version of Yast2 fired right up, slightly off-center, but the display's "center" button fixed that. The installer did take issue with me when I told it not to format the /home partition. I hit the "Tough, Do What I Told You to Do" or words to that effect button and the install proceeded. It was pleasing to see "LCD" among the monitor choices, but I've not been able to determine the extent to which this is merely a placeholder. I said that it was an 800x600@60Hz version, and it took. (One does wonder when XFree86 will catch up in hardware detection with the GUIs found elsewhere.) There is no group packaging system I've ever found that works well. Some distributions install packages based on the use to which you tell it you intend to put the computer. Others are vague in different ways, and SuSE is among them. For instance, I don't want the vestiges of KDE-1.x. As worthy as I'm forever being told that a variety of window managers and desktops are, I will have KDE2, thanks, and you can keep the rest; if I change my mind, I know where the CD is. Neither SuSE nor any other distribution I've seen offers as part of a fairly simple installation routine that level of choice -- it's always either the general groups or a package-by-package install. The latter would be time-consuming but tolerable were it not for the tendency of distributions to split things up in odd ways and rename them as they go along. There is no reason why QT should be more than one package; likewise kdeadmin, kdebase, kdegames, kdegraphics, kdelibs, and so on. The felony is confounded by distributions having abandoned the once-common practice of including in the printed docs a listing of all the packages, what they do, why you might want them, and what else they require. As it is, you always get more than you want and less than you need. Nevertheless, in under an hour there was a working SuSE 7.1 on my wife's machine, running XFree86-4.03 and KDE-2.1.1. I grabbed the much-improved Opera beta 8, which had gotten wiped out in the installation, and my wife's system was pretty close to where it had been. In a number of respects better. For instance, the boot prompt is replaced by a nice Tux graphic with a listing of the lilo choices (which I promptly rearranged to make Linux-2.4 the default). The seldom-used Windows drive was listed through no intervention of my own. Access to its files is available by default on the SuSE incarnation of the KDE desktop, though I moved all the desktop icons, as in my habit, from the Desktop folder and into a different directory, which I then linked on Kicker -- makes for a far cleaner desktop, I think. And there was some goofiness. The default is to boot into Run Level 5, which in SuSE and most other distributions is graphical. Having discovered that SuSE creates a /var/X11R6 and does some things with /etc/rc.d that are new and annoying to me, I wondered if I would at least find the default run level setting in /etc/inittab. I did. Then it occurred to me what distributions ought to be providing, what they oughtn't to be providing, and how they could succeed without causing Linux to be incompatible with itself.
Another Little Step for the LSBComments are being accepted for the latest proposed incarnation of the Linux Standard base. I have three proposals that would make life easier: -- The existence of /opt as the parking place for things that sensibly call for isolation. Desktops are an example, because these are frequently updated with the latest code, and it's easier to back up a directory that contains all of it than it is to go through the file system and pick out all the pieces. Failing this, create an exception for self-contained packages in /usr/local. -- Settle on a standard package management system. It has to be one that traps and includes the results of "make install." Everything necessary for this exists; it simply needs to be incorporated. -- Go into some detail. The effect ought to be that a competent Linux hand will be unsurprised by what he or she finds in the file structure of any Linux system. The effect would be a Linux Standard Base with some meaning. While of course there will always be different versions of practically everything, there would be no doubt as to where they're found, and there would be a disincentive for distributors to take flyers off into /var/X11R6 and things like that (unless it is decided that all should). I can anticipate some of the whines: "But that about choice?" I'll give you choice: You could then choose to run any package on any distribution. Those who are kind enough to produce binaries of their programs would not have to go through hell to do so -- it'd be pretty much down to a version for each of the several common versions of glibc. Support would be less of a headache, because it would be the product, rather than the product on a particular distribution, that would be supported. This means that the authors would get to discuss their application, rather than its packaging (which is half or better of the support problems -- check any mailing list). And there would be fewer compilation problems from distribution to distribution. But If the Distributions Were All Alike . . . When you buy a distribution, what are you really seeking? Well, CDs containing a kernel and everything else that makes a Linux system, because you don't want to download it all yourself and unless you are one of a relatively few, even if you did download it all you wouldn't know quite what to do with it. So there is the convenience of that which you can get online for free, more or less, all in one place. You're getting docs of quality varying from helpful to useless. You're getting some vestigial degree of support, though not much over what you can get online anyway. And you're getting installation and configuration tools. What would change if there were an absolutely iron-clad Linux Standard Base? Nothing. Distributions would still ship a CD full of Linux, because what you're paying for is the convenience of not having to download it all. They would ship documentation, and some of it would still be useful and some of it would still be awful. They would ship their own little configurators (some of which are good and some of which are linuxconf). Actually, that's not quite right. Distributions would have to get better, but they'd also be able to get better. With a standard base that's an inviolable known quantity, the choice of one distribution over another would be made through the quality of the documentation and the quality and flexibility of the installation tools. These are perfectly salable, though usually overlooked, additions to the value of a distribution. Instead of the situation as it exists today, where many users are afraid to get binaries from anyone other than their distribution because otherwise they might not work, they would be able to get them from just about anywhere. This would free up distributional resources for the production of better tools and docs. It would also free up distributions to specialize. I think that it's wonderful that SuSE has remained committed to the desktop (though they offer a server edition as well). Wouldn't it be even better if as part of the installation routine, the choice of desktops offered by SuSE were made with screenshots, a little about the applications that are native to each desktop, why you might choose one over the other (XFCe for low-resource systems, for instance), and so on? Mightn't it be good if, by the time the new user has installed a distribution, he or she has learned something about the Linux being installed? It's also great that Caldera is going after the enterprise. Their tools have already become somewhat focused -- WebMin is not something a typical desktop user would employ frequently, but a sysadmin might use it a lot absent fluency in the details of editing configuration files -- and Caldera would be free to make them more so. With it all would come less incentive, in fact, a community-based disincentive, to change other things. There really is little reason to screw around with rc.d, but lots of reason to come up with a bulletproof X configurator or an easy way to set up a Samba share. Nor would this reduce the participation of distributions in project development. Many of the commercial distributors have people on the payroll whose sole job is to work on free projects, be they KDE or Gnome or WINE or something else. It makes sense that as distributors specialized they would probably choose to pay people to work on areas where the distribution itself is focusing, but there's nothing wrong with that. The fact is that to have a star developer with your company as part of his or her email address is a little like having a star basketball player wearing your shoes. It's a prestige thing. With less time and money spent messing around making your distribution incompatible with everyone else's, there would be more of both to devote toward improving the operating system in general. The greatest advantage would come to Linux itself. There has been a subtle but insidious forking of Linux that, if it continues, will cause its hope for widespread adoption to disappear in a virtual Tower of Babel. Individuals and companies who are accustomed to getting a Windows application and that's that (okay, Windows itself is forking and may well get stuck in its own CE-ME-NT) are likely to be less patient than some of us have been in the lack of binaries for our particular distribution. (Just this week, I sought to add the estimable Plugger to my notebook, only to discover that there is no glibc-2.2 binary; yes, the source is available, but it requires the Netscape plug-in toolkit, and I've about had it with feeding details of my life to yet another Netscape form.) With a defined Linux, as opposed to [Distribution] Linux, this problem would disappear (though glibc version incompatibilities will forever be with us, developers would probably welcome the change). All this would require a solid LSB to get published rather than just talked about. It would require the compliance of distributors. It would require a little vision, abandonment of the idea of knocking out the competition right now and instead understanding that if there is ever a one-distribution Linux, it won't be a commercial distribution and it won't be widely used. Linux is under fire, and it will get worse. A solid definition of what it is that constitutes Linux, plus a variety of distributions that employ different ways of utilizing it, would assure that Linux survives the onslaught. I don't think anything else will.
|