.comment: Help Comes From Unexpected Places

By: Dennis E. Powell
Wednesday, August 9, 2000 08:49:21 AM EST
URL: http://www.linuxplanet.com/linuxplanet/opinions/2169/1/

How I Spent My Summer Vacation

It all started with XScreenSaver.

I love XScreenSaver, the framework of which was built by the legendary Jamie Zawinski with modules coming in, apparently, from all over the place. There are scores of them, and when XScreenSaver is running in its default mode it cycles through them in no particular order. It's possible to be surprised by the appearance of a new module months after you have installed the thing. There is money to be made producing a little set-top box that boots Linux and X and does nothing but run XScreenSaver on all those giant projection and flat-panel teevees out there, as a kind of neo-modern Lava Lamp for the few minutes each day when the television itself isn't otherwise on.

Jamie is a tremendously considerate programmer. When I downloaded the source for a new version a few weeks after having installed a new Linux distribution, following the very easy compilation XScreenSaver warned me that there was an RPM of an earlier version aboard. It then explained how to remove it (which not everyone already knows) before doing "make install." This demonstrates a connection between developer and user that is remarkable--something other developers should emulate.

It is also one of the surprising manifestations of help that appear all over the place in Linux, but not always where you'd look if you were inexperienced with the operating system.

Last month I decided to make some changes around here. There are some excellent 3-D modules in XScreenSaver, and while they worked, they did so spasmodically, with frame rates of 1 or 2 per second. The sharks and whales, instead of swimming gracefully, looked as if they'd been dropped in boiling water and were now in their death throes. Other GL modules, that would be entrancing were they running at full speed, reminded me of the Zapruder film on the latest conspiracy show.

My impression was that someone, somewhere, was running these things at a high frame rate. If they could, so could I. And so began an odyssey that rivaled the day a few years ago when first I saw a prompt that said [root]#. More than rivaled, actually--things were pretty well worked out after my first week with Linux.

Hardware Hell

Time had come, anyway, to upgrade a little hardware. My old FIC VA-503+ motherboard had done yeoman service, but it did not, for instance, support ATA-66, which the newer VA-503A did. The place that offered the best price also had a low price for AMD K6-2-550 chips (this stuff really is becoming inexpensive), which was a 37.5 percent increase over the K6-2 I had. And the STB Velocity 128 that had been such a big deal just a couple of years ago now didn't seem to cut it, and Matrox G400 AGP boards with 32 megs of memory and dual heads were not all that expensive.

Two days later my order arrived and I learned some new things. These included the fact that while the English in motherboard manuals has gotten better, they don't really tell you any more, and there's now much more to be told; that if there is a way to make an FIC VA-503A motherboard deliver more than 64 of my 256 megs of memory to Linux I couldn't find it; and somebody is apparently relabeling AMD chips, because this one would boot at 550mHz, but that's about all--things like compiling even simple software invariably ended in the dreaded "internal compiler error," which is how egcs tells us our hardware is no good.

I figured I could live without ATA-66, so I popped the old VA-503+ into the machine, moved everything back, downloaded and burned a new CMOS (to make the board accept the K6-2-550), put in the new chip, discovered that the new chip still wouldn't work at 550, jumpered it to 500 (whereupon everything now pretty much worked), ran XF86Setup, and fired up one of the GL modules.

No improvement. None. In fact, there was (and occasionally still is) some serious weirdness, in which the monitor loses horizontal sync, making it look as if I'd strapped an orbital sander to one side of it. I had if anything made things worse, though my processor was 25 percent faster. Whoopee.

The hardware vendor offered support to the extent that they'd take the stuff back for a mere 15 percent restocking fee, and I'd pay the shipping. I would not be upset if they were playing in the driveway one day when I back out the truck. I was effectively stuck with the stuff.

Okay, the motherboard I could use somewhere else, and the vid card would probably be okay with some tuning, and the chip didn't cost much and was faster (though I was puzzled that its 3-D Now! was more like 3-D When?).

Turns out, I had just completed the easiest part of my quest to make the whales and sharks swim.

Waist Deep and the Water's Rising

My new, high-powered video card had been roundly praised as one of the finest in the world, leading me to suspect that properly configured it would deliver the performance I sought. I started on the XFree86 home page where, digging a little, I learned that 3-D is lightning-fast because it is directly rendered--so long as you're running XFree86-4.01 and Linux 2.3.99 or better.

Well, okay. Linux-2.4.0-test4 was current at the time, so I downloaded the source and burned a new kernel. (By the way--2.4 is going to be tremendous, but from what I see on the kernel mailing list, I don't think it will be with us real soon now. A couple months at least.) I included frame buffer support, AGP support, support for my motherboard's VIA chipset--all kinds of good stuff. It worked, as expected, right off the bat. This because of other unexpected places where help is available. For instance, no one should even dream of building a new version of the Linux kernel without reading the Changes file in the Documentation subdirectory of the kernel source. This isn't some changelog, it's a listing of the non-kernel packages that you need to upgrade if you want this kernel to compile and work. It also lists the places to get all the updated packages. (It's a good idea to read the docs for them, too--it wasn't until PPP failed that I learned that with the new PPP one must create a /dev/ppp.) And if one builds the kernel with make xconfig, almost every possibility--and there are many--has a complete, readable, and often funny helpfile.

An aside: Did you know that the source code in /usr/src/linux should not be that of your new kernel but instead that of the kernel against which your glibc was built? I didn't, but no less an authority than Linus himself pointed this out recently, and when it comes to the kernel he is by definition right. This was a puzzle, because some applications, notably XFree86, go to the Linux source at compile time, and I wondered what happens when it's not the same source as was used to build the kernel.

The new kernel working as it should, I downloaded the binaries for XFree86-4.01. The install script provided works very well. The new X configuring tool, xf86cfg, is pretty awful in that it never did produce a configuration that would work here at all. Worse, the whole business produced exactly no improvement in performance. I asked on one of the XFree86 mailing lists and was told that I needed to make sure that I had the proper kernel module, mga.o, loaded. I not only didn't have it loaded, I didn't have it period. Someone mentioned that this would get produced by compiling the DRI source.

Some more research led me to the development site for DRI, the direct-rendering interface for XFree86--the stuff that lets X manipulate your video hardware directly. There isn't some DRI package waiting to be downloaded; you have to get it by anonymous CVS. I did so, read the installation document (which is found, unexpectedly, with the XFree86 docs, which are themselves found in the unexpected /usr/X11R6/lib/X11/doc directory, probably not the first place a newbie would look; though a version of DRI is included in XFree86-4.01) and compiled and installed the thing. Mind you, this is CVS code, meaning that it is in some respects pre-alpha, so the fact that it works at all is more than one can expect with any confidence. It did work, somewhat. You will be unsurprised to learn that the increased frame rate in GL applications was not there. You might be surprised, as I was, that so much as trying to start a GL anything--demo, screensaver, whatever--would now lock the machine up tight. Absolutely solid. Reproducibly. For years I had not been able to lock Linux despite constant abuse of it. E2fsck takes a long time on a 20-gig IDE drive. And I got to experience it a lot, as I attempted, unsuccessfully, to fix the problem, with each attempt returning the same result, reboot, fsck....

A post to a KDE list resulted in my introduction to a fellow named David G. Watson. This is one of the best aspects of the Linux help system.

Everyone should have a Linux guru. Mine is Bob Bernstein. When I've well and truly broken something, I can email or, if I've really screwed things up, phone him. He has a multitude of distributions either currently running or capable of being booted at once, all the time. My first week with Linux would have taken a month but for his help. He's brilliant, knowledgeable, down-to-earth, and willing to give of his time to help others with Linux trouble. But people have their specialties, and hacking X isn't one of Bob's many.

There are a lot of people who have at least some of those characteristics, and some who have most or all of them, and David G. Watson falls into the latter group. He spent a lot of time over the next few days helping me sort out the GL situation. The mga.o module, he told me, does not get automatically installed and needed to be copied by hand and started by hand. Lo and behold, it hadn't even built! DRI, which like XFree86 itself uses the obscure imake in addition to the more commonly encountered autoconf and make, needed to have a line uncommented in order to build the modules. So I recompiled--but the build blew up in the 3dfx module, before it got to mga.o. Editing of the appropriate Makefile.linux cast 3dfx into oblivion and soon I had my mga.o.

Mr. Watson spent a lot of time trying to sort out my situation, all by email. In the course of it, he taught me a great deal about the workings of X. All this just because I posted a question to a mailing list. We were finally both defeated, though I suspect that had Mr. Watson not been in Ohio but instead here in Connecticut, he probably could have solved the problem in five minutes at my keyboard. I figured I had been communicating with a computer professional of some sort. I asked. David G. Watson graduated this year from high school--he was home schooled--and will start his computer science studies at Kent State next month. Help from unexpected places.

The Voyage Home

Out of the clear blue, I received a note from Michael Meding, who is well known in some of the upper reaches of the Linux world. It was a list of questions and instructions as to how to get the answers--determining what was loaded, whether it was loaded properly, how to determine the precise frame rates, and so on. He'd seen my post on the XFree86 list and was wading in to throw me a rope.

Again, we didn't get the problem solved directly, and he did tell me that G400 performance under X is not what it will be in the months to come. But again, I learned a great deal, and from this I was able to sort out the unhappy fact that there were two versions of Mesa, the Open GL clone, on my machine, and they seemed to be in dispute with one another.

Which causes me to voice a complaint that arose in an email exchange with Lou Grinzo, the writer who graces many pages, sometimes those of LinuxPlanet. How is it that some operating systems have multiple versions of essentially the same thing, all peacefully coexisting, while with Linux this is often a matter of luck? While I do not have a definitive answer, I certainly have part of it. Take a look in /usr/lib.

You will find, say, libFoo.so, which will be a symlink to libFoo.so.1, which will be a symlink to libFoo.so.1.2, which will be a symlink to libFoo.so.1.24sept96 or somesuch. There are many things that can interrupt this flow, which in any case is ridiculous. If the thing is backward-compatible, it ought to overwrite the original; if it's not, then call it something else! And let developers point their code to the real thing, not some link in a chain that may or may not lead to the right place. Storage is cheap.

DRI and XFree86-4.01 build their own Mesa, based on a beta of a still-unreleased version. At least some Linux distributions put Mesa in /usr/lib, not /usr/X11R6/lib. Which brings up another thing: more and more packages are insinuating themselves into /usr/X11R6. Take a look at /usr/X11R6/bin sometime and be amazed at the number of applications that have deposited themselves there. Wipe out your XFree86 to build a new one and you'll have a lot of other stuff to install, too. This is just pure sloppiness. The only thing that ought to be in /usr/X11R6 is XFree86.

So time had come to return to first principles. I was running an alpha XFree86 (the DRI CVS code) under a beta kernel, with beta KDE2 for good measure. At least I could run a release XFree86. David Watson had pointed out that XFree86-4.01, if you compile it yourself, will, too, make an mga.o module. I downloaded the 4.01 code, edited the site.conf file (where there is a place to enter the location of the Linux source tree for the kernel you're using, in case you've followed Linus's advice), and built it. It built, all except the kernel module, which I dove in and built by hand, moved by hand, but did not have to start by hand.

Again the GL applications froze the machine. I'd had about enough of this. I downloaded the latest release version of Mesa and built and installed it. Then, using good old Midnight commander, I copied the new Mesa files over their old counterparts wherever they appeared.

Holding my breath, I started a GL screensaver. And the whales and sharks were swimming!

The Moral of the Story

Now you know how you, too, can through the expenditure of a few hundred dollars and several hours a day for a month bring to life some decorative software that you don't need. (Most of the XScreenSaver modules, by the way, don't use Mesa at all, and if you don't have it set up so that they can run at least somewhat the ones that need Mesa just don't compile.) There's a good chance that this is not information that you'll draw on immediately. But chances are that you'll find yourself gradually drawn into a similar situation one day: maybe you'll decide to upgrade your compiler, but RPM tells you that you need to upgrade your glibc, so you decide to do that, but glibc needs some new things--and before you know it, you're neck-deep in quicksand. Linux distributions are so nicely and reliably packaged that one really needs do nothing more than upgrade the whole system from time to time to get the (almost) newest stuff. But Linux inspires tinkering or tinkers gravitate to Linux, I don't know which. So part of the story is how easy it is to get into personally uncharted territory in pursuit of a seemingly simple goal.

Nor is that a Bad Thing. But when you're elbow-deep and sinking fast, it's good to know where help can be found. People relatively new to Linux are often accustomed to having telephone numbers they can dial for technical support, albeit often for pay. Linux distributors offer pay support, too, but I don't know of any who would deal with the mess I made in the quest for working 3-D screensavers. Yet help is available, all over the place. It helps to have a Bob Bernstein, but the Linux community is richly populated with ad-hoc gurus, too, on mailing lists especially. If you haven't yet, subscribe to your distribution's mailing list or, if there are several, the one that comes closest to your level of knowledge. Yes, there are usually lots of messages, and they can be a pain to wade through. But if you do wade through them, you'll learn a great deal. Often your questions will be answered before you ask them. Remember that everybody there is volunteering his or her time, so don't think you're owed help. When you do have a question that you simply cannot answer some other way, ask it on the mailing list. When someone else has a question that you can answer, answer it.

The moral of the story is that there's almost nothing that you can't find out this way--and that the authoritative, clear voice of experience and knowledge who helps you out may be someone en route to his first year of college.