.comment: Help Comes From Unexpected Places - page 4
How I Spent My Summer Vacation
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!
- Skip Ahead
- 1. How I Spent My Summer Vacation
- 2. How I Spent My Summer Vacation
- 3. How I Spent My Summer Vacation
- 4. How I Spent My Summer Vacation
- 5. How I Spent My Summer Vacation
Solid state disks (SSDs) made a splash in consumer technology, and now the technology has its eyes on the enterprise storage market. Download this eBook to see what SSDs can do for your infrastructure and review the pros and cons of this potentially game-changing storage technology.