.comment: Separated By a Common Operating System

By: Dennis E. Powell
Wednesday, June 27, 2001 09:20:55 AM EST
URL: http://www.linuxplanet.com/linuxplanet/opinions/3543/1/

From Disaster Arises . . . More Disaster

It all started with gcc-3.0.

When it was released two weeks ago, I downloaded it to take a look. I was interested, especially, because it is said to have finer granlarity in its processor optimization, actually taking advantage of features in AMD chips not available in earlier versions.

Reading the docs I learned that among the things that the new compiler is known not to do successfully is build glibc. In that my glibc-2.2 doesn't work with some things, and in that the upgrade to it from glibc-2.1 had been uneventful, I figured that I might as well go ahead and upgrade it now, while I still had gcc-2.95.2 around.

(Yes, it's possible to have both aboard, but this is slightly tricky and consumes more than slight disk space. And there's something about it that rubs me wrong, even as I never tried to use both KDE-1.x and KDE2 at the same time. In fact, I don't keep multiple desktops on my machine. I know that there are those who do, but it seems to me that these are chiefly people for whom the computer is the end unto itself rather than a tool for doing things, like the guy who spends weekends fixing up and polishing an old car that you may not touch and that he never actually drives. There are exceptions, of course, but I think the many-desktop crowd tends toward this.)

Because the kernel headers in /usr/include ought to be the ones against which glibc was compiled rather than the ones in the currently running kernel, it seemed to me that it might be a good idea to upgrade to Linux-2.4.5 as well. So I did, dutifully copying the appropriate headers -- /linux and /asm -- to /usr/include. Then I built glibc-2.2.3, which was entirely smooth and trouble-free. It passed the tests. And, though it is possible to keep multiple versions of it aboard, too, for reasons given above (and the fact that this would presumably be a fairly minor upgrade), I made install to /usr.

As the files were copied, I should have sniffled a little and said goodbye to my beloved Caldera eDesktop 2.4, heavily modified, because I was seconds away from running it for the last time. Though Caldera will supposedly release its 3.1 workstation product this Friday, it is not likely to be the kind of distribution of special appeal to non-enterprise desktop users and it will cost more than Linux distributions typically cost, now approaching Red Hat in price and exceeding Red Hat if you want any support. I had already decided that when I finally broke eDesktop 2.4, I'd switch distributions. And now I had finally broken eDesktop. Badly.

My first hint came when I tried to su root and was tole there was no user "su." I did an orderly shutdown and rebooted; all was well until I tried to login. My username and password were accepted without error -- but the login prompt returned. Likewise when I tried to login as root.

Through a succession of floppy boots and chroots I was able to move things along to the point where I encountered all kinds of library errors that I probably richly deserved but didn't get when I went from glibc-2.1 to 2.2 but surely did not expect now. I've on several occasions over the years done a floppy boot to go in and fix something I'd broken, but this time I just made things worse (to the extent that they can get worse on a machine that has been rendered unusable).

Yes, it was all dumb, dumb, dumb. I had chosen poorly. I'd really screwed up my machine, and there was no way I knew of getting out of it. It was entirely my fault, and there are lots of ways I could have avoided it.

Always Look on the Bright Side . . .

On the other hand, here was an opportunity to take a look at other distributions. While it's conceivable that I could have reconstructed my system, basing it once again on eDesktop 2.4, its been-there-done-that aspects were distasteful and I rejected the notion.

After some consideration, I decided I'd switch to one of two candidates: Progeny Debian or the new SuSE 7.2. I acquired 'em both; overnight delivery from SuSE cost as much as the distribution did, but until I fixed things I was stuck on the notebook, whose keyboard is among the worst I've ever used -- I think its previous owner bathed it in something sticky, and cleaning notebook keyboards isn't the trivial thing that cleaning desktop keyboards is. (I've actually washed the latter with warm water, after having removed keycaps and case, and left it to dry in the sun, resulting in full restoration of function. Pretty drastic, but if the keyboard is otherwise dead it's something to do before giving up entirely.)

Progeny seemed a good way to dip my toes into Debian. Previous commercial distributions based on Debian have not succeeded, but anecdotal evidence suggests that this had nothing to do with the underlying software. People who know and use Debian love it, and there must be a reason beyond the strong political component. And from what I've heard, it seems as if Progeny has done it right.

SuSE, as I've said before, seems to me to be Linux's best hope for a widespread desktop presence. SuSE Personal Edition is aimed squarely at the desktop user, installs and configures more easily than any distribution I've seen, has a lively and helpful user mailing list (two, now, actually, the second devoted to more general discussion that some believe is off-topic on the main list), and seems to have as great an understanding of my desktop of choice, KDE, as anyone.

What follows is not going to be a comparison of the two except in the most cursory sense.

I began by trying the SuSE update system on my wife's machine. In maybe 20 minutes, it had updated everything SuSE 7.1 on her hard drive to SuSE 7.2, keeping all the configuration information intact -- there was absolutely nothing to set up. Run the update program, reboot, that's it. Very nice. Nicer still, font anti-aliasing in KDE is enabled by default, and it worked out of the box on my wife's LCD panel. (Unfortunately, SuSE provides little in the way of TrueType fonts.)

The install on my desktop machine went very nicely, too, though it does some things and makes some choices that I didn't like. For instance, CD-R drives have been around for awhile. They require ide-scsi translation. SuSE missed this, about which more in a little bit. I have a G400 video card with 32 megs running a 19-inch monitor that I run at 1600x1200. That resolution was not offered in the video setup program, and it defaulted to 3-D being off. I really had to fight it tooth and nail to keep it from installing XFree86-3.3.6 as well as XFree86-4.03 -- this involved going through it package by package, unchecking the XFree86-3.3.6 stuff, and enduring the error messages that told me I didn't know what the hell I was doing. It also doesn't want to install a number of packages useful to people who regularly compile software. And I have yet to figure out why the OpenGL, lesstif, and OpenSSL stuff that it installs seems unrecognizable to the configure program. Additionally, its file system seems a weird hybrid of Slackware and Red Hat, with /var filled with unusual things such as /X11R6. This requires some sort of explanation unless we are to conclude that SuSE wants its users to get only binary packages from SuSE -- I suspect that I could do a world of harm by grabbing the source for XFree86-4.1 and building and installing it. Likewise, SuSE does some strange stuff with KDE. No, not throwing it into /usr -- I said strange, not stupid. But it makes /opt/kde and /opt/kde2, the former presumably for KDE-1.x stuff (which I told it not to install, so it made directories containing nothing), and there's a symlink somewhere in /usr/X11R6, too. I'm sure that there are perfectly good reasons for all of this, but it would be very helpful to users for SuSE to explain what it's done and why, so that those of us who tinker won't break more than we'd planned. To top it all off, the default prompts for user and root are not $ and # respectively on SuSE 7.2, a tradition broken for no good reason.

Progeny and I did not hit it off from the beginning, because it uses GRUB instead of lilo. I know and like lilo; I've gotten out of a world of hurt with lilo; and I have no opinion on GRUB except that I see no need for it. In any case, my first false start -- which led me, at first reboot, to face the dreaded "LI" where my boot choices should have been, and have to resort to a DOS boot floppy whence I ran fdisk /mbr to nuke lilo.

The installation program is about par for the graphical installation program course. I noted with delight that it recognized, right off the bat, the need for ide-scsi for the CD-R machine. Whatever one has to say about Progeny and its underlying Debian, technical shortcomings won't come up, because they don't exist (though the very latest code isn't going to be mentioned either; Debian is famous for its circumspection when it comes to new stuff).

Nor is Progeny the most likely candidate for, say, a Caldera refugee. I have not spent enough time in it to offer extensive details, but everything, from the file system to the package manager, is just a little different. This is not a criticism; it can be argued that in many ways Debian's approach is better. But someone switching to Progeny from the Red Hat/Mandrake/Caldera/SuSE side of things is not going to hit the ground running with Progeny in the the same sense that he or she might with a move among those distributions.

In the end, I chickened out. I have Progeny on a second hard drive, and plan to spend some time learning its unique features. But the day's goal was a working production machine to replace the installation I'd just destroyed, and this pretty well dictated SuSE. Comparing the two, which are both Linux but which are otherwise so different, I was reminded of Churchill's remark that America and Britain are two nations separated by a common language.

This did spawn a thought, which probably won't make anyone happy but which I think is a good idea. There has been a campaign of sorts to get Linux, when it is referred to, to be called GNU/Linux. Those who follow the FSF's political stance on software have pretty much done this, and those who don't pretty much haven't, for a variety of reasons. Yes, I have GNU stuff on my hard drive, but I have a whole lot of stuff from other people, too, and to adopt the argument that is often used, I'd have to call my system KDE/Sun/TrollTech/theKompany.com/somepeopleI'veforgotten/GNU/Linux, which is a little awkward. On the other hand, the differences between the Debian-based systems and the others (Slackware is in a category of its own) are considerable, and saying "Linux" to refer to all of them is as useful as saying BSD to refer to the many flavors of that operating system. It seems to me that to call Debian-derived stuff "GNU/Linux" would happily establish the distinction, and be entirely appropriate, given the Debian movement's particular care as to the licensing of code it includes. It strikes me as the perfect compromise.

Bending SuSE to My Will

I really like SuSE 7.2. If I knew someone who thought trying Linux would be a good idea, it's the distribution I'd recommend. It installs easily, and once it's installed it's easy to use. Someone who has never used computers would have no more trouble mastering this than mastering Windows, though I suppose that person would remain ignorant about crashes and reboots. This is no small thing: There are lots of countries that aren't rolling in money, and one cannot get another operating system that combines the ease of use, robust functioning, and good selection of applications for what SuSE costs. The anti-piracy "features" of Windows XP will create a perfect market for alternatives in such countries. If SuSE doesn't move to capitalize on these emerging markets, then the people at SuSE are crazy. Likewise a number of other markets, from schools to small OEMs.

It was of course only seconds after I'd booted my nice new SuSE 7.2 that I began making changes. I don't like icons on the desktop, so I nuked 'em. Next, I needed to figure out why my KDE settings hadn't survived, in that my ~/ had. I looked around and found that instead of ~/.kde, SuSE used ~/.kde2. I nuked it and made a symlink to ~/.kde until I could track down the source of the problem.

I always keep a copy of XF86Config in my home directory, for occasions just such as this. I dumped out of KDE -- and back to the KDM graphical login. Okay, back into KDE, open a konsole. Looked like hell -- letter spacing was all over the place. Awful. Typed "xhost + localhost" and then sued root and typed "nedit /etc/profile" which informed me that I no longer had nedit. The smart thing would have been to "rpm -Uvh download/nedit-5.0.i386.rpm," but I didn't. I did "kedit /etc/profile" and changed the default runlevel to 3, saved the file, opened /etc/lilo.conf and changed the "vga=" line so that it was now "vga=normal," saved lilo.conf, ran /sbin/lilo, exited konsole, dumped out of KDE, rebooted from KDM, and pretty soon saw the nice text bootup -- which in SuSE is especially pleasing, because as it starts services and loads drivers it presents it all in an appealing and useful way. I logged in, sued root, and copied the XF86Config from my ~/ to /etc/X11/, and while I was at it copied my TrueType fonts to /usr/X11R6/lib/X11/fonts/truetype, and ran ttmkfdir. Then exited root and did "startx," and things were returning now to normal.

Next came editing ~/.xinitrc so that it would start xscreensaver right before it started KDE. This didn't take, and I discovered that though I thought I'd installed Jamie's can't-live-without screensavers, I hadn't. Grabbed the latest source, but the GL stuff wouldn't build, because the GL stuff included with SuSE 7.2 lacks the right pedigree or something. Back to the SuSE CD to go traipsing around in search of their xscreensaver rpm. Found it and installed it and all was well. Except that the GL screensavers are unbearably slow. (As is their GL stuff in general; "gears" at its default size from the commandline does 40fps, which is glacial -- why can't anybody get this right?)

Time now to put a modern KDE on the machine. SuSE ships with KDE-2.1.2, which is -- okay -- the current release. But a lot has happened since it was rolled out, and I've grown to enjoy it (note to KDE users: You're going to love KDE-2.2). So I grabbed the latest CVS and began by building QT. The QT that SuSE ships is 2.30, which Is fairly modern, but qt-copy from KDE's CVS tree always has some little tweaks. As expected, ./configure told me that the QT directory was set to "" and it needed to be where the source was, so I edited /etc/profile again to give it the QT environment variables and rebooted. And now, on reboot, I noticed an error after I'd logged in: /bin/ksh was not found. This had no effect, in that I don't use ksh, but it was annoying. I looked around and found nothing interesting -- I did have /bin/ksh (though I have no need for it), and in any case it had no effect on things working. Still, it bothered me, so I posted a note to the SuSE list. Before long came word: I'd edited /etc/profile in kedit, hadn't I? And kedit has word wrap on by default (as, in my opinion, no Linux text editor should). So I installed nedit and fixed /etc/profile, and the error disappeared.

Then I built qt-copy. As noted above, I don't like to keep multiple versions of things all over the place. I don't run multiple versions of things at once. For years now, my QT has been /usr/lib/qt; my kde, /opt/kde. In these two cases, because I build them both fairly often, I make a small exception: both of these locations are symlinks, to /usr/lib/qt[date] and opt/kde[date] respectively. When you're building from CVS, things blow up from time to time, and an exit strategy is good, and this is the easiest one I know -- just change the symlink to the previous, working, version. Next build, nuke the older of the two existing, working versions and add the new one.

Renaming the stuff in /opt, as provided by SuSE, was a little more complicated, but it became less so when I learned that /opt/kde was essentially empty. Also, it seemed that SuSE's YaST2 wanted to look at /opt/kde2. So I renamed /opt/kde2, made a directory in /opt for the new CVS stuff I was about to build, symlinked /opt/kde to it, and /opt/kde2 to /opt/kde, and started building KDE from CVS.

I lucked out -- I picked a time when everything in the CVS tree built just fine, though kdelibs reported the absence of OpenSSL (though some form of it had been installed by SuSE), and kdebase said I had no lesstif, though SuSE had provided it. Someday someone is going to realize that it will be much harder for Linux to be taken seriously unless backward and forward compatibility is provided in things like dynamic libraries. Yeah, that makes it tougher for developers. It can be argued that developer convenience is not what we're all here to achieve.

Anyway, after many, many hours -- KDE does not compile quickly, but there's a lot to it -- I fired up X. And there was the latest KDE. With an ugly background.

Ages ago I set up XPlanet (a really neat application; if it's not your desktop background, it probably ought to be) with a moon map to be a realtime moonphase indicator in high resolution on my KDE desktop. Then I realized that I didn't have Opera installed, so I ran its rpm, then went to the Xplanet website to see if, while I was at it, there were a newer version, which there was. (I use Opera for web browsing, most of the time. I very much like Konqueror, and for file management and ftp duties it's unsurpassed, but I'm more comfortable, at least for now, browsing with Opera.) I snagged the new XPlanet, built and installed it, copied my moon.jpg from my home directory to /usr/local/share/xplanet, and a minute or so later my moon desktop was back.

I was mostly done, but there were still a couple of tasks to perform: Getting the CD-R to work properly and seeing if maybe I could fix the abysmal GL performance. Each required a kernel recompile.

I already had the Linux-2.4.5 source in my ~/download directory (SuSE 7.2 ships with 2.4.4), so I decided I'd use it and base my build on SuSE's configuration. Where did I get that configuration? I'm glad I asked that: it's in /boot/ as vmlinuz.config. Load it after making mrproper in the kernel source, and you'll see what you've got -- which is a module for just about everything supported by Linux. I mostly didn't mess with it, though I did remove support for some things I know I will never use. Then I set about fixing things.

It shouldn't matter, but here it consistently does: If you have a Matrox Millennium MGA G-400 video card, and if GL performance matters to you, compile agpgart.o and mga.o -- AGP and MGA direct rendering -- into the kernel itself (Y instead of M) and do not enable framebuffer support. (As a benchmark, run gears in a virtual terminal before and after. Here, it went from 40 frames per second to 342 fps.)

I also enabled support for generic scsi and ide-scsi translation, and removed support for ATAPI CD-ROM drives. Then I built and installed the kernel. All was well.

Except for XCDRoast, which had worked just fine under Caldera and which now blew up, when I tried to run it SUID, with the news that GTK+ objected to this. The alpha XCDRoast 0.98 that SuSE ships has this added feature over the 0.96ex I was using; some, myself included, would not consider this an advance, nor the switch from Tk to GTK+ -- it's a friggin' CD burner! It doesn't have to be pretty! I visited RPM -e on it and downloaded the source for 0.96ex. Which blew up on ./configure, citing the absence of Tcl/Tk/Tix, which was a hell of a note because I specified them for installation when I installed SuSE 7.2. The RPM database reported them installed. But they were and are nowhere to be found (though I haven't searched /var yet, SuSE's very favorite directory).

I went to the SuSE online update site, using the YaST2 configurator, and grabbed the security fixes that had been posted. Interestingly, the next time I started the machine, I was in runlevel 5, even though I'd edited /etc/inittab to default to 3. This was an issue because KDM, at the moment I'd grabbed it from CVS, had a little problem: it wouldn't accept keyboard input (this has since been fixed). I clicked on the menu, asked for a console login, didn't get it, but now KDM was accepting letters. (This is one of the multitude of reasons I have for despising KDM and, before it, XDM. If you can't login at a text prompt and remember the command "startx," then you probably shouldn't be using a computer at all.) Anyway, it turns out that everytime SuSE's configuration program runs, it resets /etc/inittab to runlevel 5 unless you've edited its startup scripts to do something else. This is one of the stupidest things I've ever encountered, the kind of stuff we'd expect from Corel or somebody but not from an outfit that bills itself as "the Linux experts." There is just flat no need for it.

Who Is the User?

In its 7.2 distribution, SuSE goes far in making Linux very easy for the newbie. But in so doing, it gratuitously makes life tougher for the Linux user who has been around the block a time or two. It tries to lock users into getting software only as binaries from SuSE -- RPMs for other things such as XCDRoast often just won't work with SuSE 7.2 (nor is SuSE alone in this; other distributions seem equally bent on fragmenting Linux into oblivion) -- and it not only supposes that users employ its cute little configuration tools, it flat-out insists on it, to the point of actually undoing changes made by other means. The Corel refugee won't much care, but somebody coming from Caldera will probably be pretty irritated, with good reason. It makes sense for SuSE to welcome such persons rather than do things for no apparent purpose other than to render useless their existing knowledge of Linux.

This column started out in the hope of comparing Progeny with SuSE; that fell apart when I realized that Progeny's take on things, inherited from the Debian to which I understand it remains true, is just too different from the RPM-based-distributions' way of doing things for me to learn it in a short time. What I went on to discover, though, is that the lumping together of RPM-based distros really can't be done, either. They are beset by incompatibilities such that they might as well be different operating systems (with some exceptions for people who compile their own stuff, presuming that they remember to install the -devel version of everything, which is also ridiculous). Knowledge of one distribution has little to do with any other distribution. This sort of thing occasionally results in indignant howls, as when Red Hat shipped gcc-2.96. Usually, though, it goes largely unnoticed. But it has its effect, and that is confusion among prospective users. Not long ago, if you got a Linux distribution you got Debian, Slackware, or something else, and the something elses were largely interchangeable as to what they installed -- the differences were in installation and configuration tools, the newness of the stuff included, and what applications were provided. Upgrading was fairly simple, because an RPM for one would probably work for all. And Linux desktop use grew.

Now incompatibilities are being introduced hand over fist, as distributions fight for a bigger and bigger piece of a diminishing pie, until oneday one will own all of nothing. Does this do anything useful for the distributions, users, Linux, anybody? Well, no. And while I've singled SuSE out because it's the one where I've most recently encountered this nonsense, no distribution is exempt. If Microsoft were to cook up a plan to cause Linux to disappear in a virtual Tower of Babel it could scarcely be more effective than that which has been adopted by distributions on their own, voluntarily.

Churchill's words ring true.