.comment: 86ing XFree?
When Good Code Goes Goofy
Can we agree that XFree86 has become a mess?
If you don't, download the current CVS tree and try to make some sense of it. Or, if your connection is such that you really can't spare a couple of days to get it, download the source for XFree86-4.01 and take a look. For an extra-special good time, try building it with direct rendering (DRI) support and a kernel module for your 3-D video card. See what I mean?
Ah, you probably thought that the docs
would help you. Lots of luck. The
INSTALL.TXT in the top-level
directory of the source was last updated just under three years ago.
Here's a typical passage, pasted from that file:
"Edit xxcc//ccoonnffiigg//ccff//ssiittee..ddeeff for local preferences. If you want to install somewhere other than //uussrr//XX1111RR66..44, change PPrroojjeeccttRRoooott. (Do _n_o_t use DDEESSTTDDIIRR.) If you want to build with _g_c_c uncomment the HHaassGGcccc22 line. If you have _g_c_c, but not _c_c, please read the full build instructions."
And that is the first paragraph of the "Easy Build Instructions."
Now. XFree can be built. I've
done it several times. Because it relies on the hoary old
it requires skills otherwise long dormant, or acquisition of new skills
that are unlikely to be of use anywhere else. The compilation
produces--or comes to a halt because it cannot produce--all sorts
of stuff that it is guaranteed you do not need. The resulting
binaries can conflict with whatever is already on your machine such
that it can lock solid--I've encountered this with dueling GL
libraries--and sorting it all out is mind-bogglingly difficult.
What's more, the current XFree86
configuration tools are just awful. There is no longer an
XF86Setup. The old, console-based standby,
xf86config, fails to recognize a lot of modern hardware: We now
have video cards with lots of memory, and we have monitors manufactured in the
last few years that are--surprise!--different from the ones built earlier.
There is a new configuration tool that I have yet to see produce a useful
XF86Config file on any machine anywhere.
Indeed, I endured several months during which my monitor would not hold horizontal sync. I'd provided the correct parameters both for it and for my video card, a Matrox G400 with 32 megs, scarcely something exotic or unusual. And it just wouldn't work.
Finally, in desperation, I thought I'd
tweak the modelines a little. But XFree86-4.01 does not by default
have any! In order to get the thing to work, I ran a copy of
XF86Setup from XFree86-3.3.6, produced an
/etc/XF86Config, and pasted the modelines from it into my
/etc/X11/XF86Config. For 1280x1024, the resolution I favor, the
modeline was this:
Modeline "1280x1024" 135.00 1280 1312 1416 1664 1024 1027 1030 1064
And still no horizontal sync. I began playing with the first number, 135.00. First I cranked it down to 125.00. Horizontal sync was just fine, but the refresh rate was low. I began tweaking it upward. As I did, the refresh rate increased. The sync remained just fine. It maxed out at 142.00, which gave me 1280x1024 @ 85Hz. (After that, it dumped into 1600x1200 @ 60Hz., which was briefly interesting but nothing I'd care to live with.) In my incremental testing I discovered that of all the possible values, 135.00, the one calculated, was the only one that didn't sync. A system that allows you to have reliable graphical video only if you experiment and hack, at the risk of blowing up your monitor, is not necessarily the best choice for general use. No wonder people (often secretly, lest they be thought impure for having actually paid for software) explore the commercial alternatives.
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.