.comment: 86ing XFree? - page 3
When Good Code Goes Goofy
As a practical matter, we're stuck with XFree86 or one of the commercial replacements, though as you can see above there is growing grumbling and talk of a rewrite or replacement.
And despite all that I've said and reported here, there can be no doubt that the people who have built XFree86 over the years have done good and noble work, and are continuing to do so. New and interesting extensions--the antialiasing stuff, for instance--give XFree86 new promise and currency.
But it has grown to resemble a house to which a succession of owners have tacked on new rooms here and there, with no sense of the grand design. The new stuff is fine, but the old stuff is in some respects just too old. The thing has gone shabby from inattention in a lot of places.
Though it's not the kind of work that interests the greater variety of volunteer programmers, the source tree is in need of some pruning. C'mon--imake? This stuff needs to get accessible. In an era when XFree86 is nearly as important as the kernel itself, why is it that configuring and compiling Linux is so very easy and configuring and compiling XFree86 is so shatteringly difficult? The source for a full build of XFree86 runs nigh onto 300 megs. It contains a lot of stuff that is mutually exclusive. There ought to be a way, beyond the vestigal script now available, to pare down the source that one needs to fetch, a way to configure it on the fly, right at the beginning (ever see Linux's "make menuconfig," XFree86'ers?) not just for the instant build but for running on the machine itself. It needs support for automake, which has long since been adopted by most of the rest of the civilized world. There needs to be one place and one place only for extensions, and not a riot of easily broken symbolic links. XFree86 now requires more customized configuration than ever before in wringing performance out of modern graphics cards. This should be no more difficult than configuring and compiling normal applications, and certainly no more difficult than burning a new kernel.
Because in my discussion of all this with the people I quoted and several people I didn't quote, there was one universal thread: XFree86 needs some work, and if it's not done, somebody will start with a clean sheet of paper and produce a replacement that people can know, not fear. Maybe its functionality ultimately will end up in the kernel. Maybe it will be a complete standalone replacement.
Or maybe XFree86 itself will get the attention it needs and deserves.
We're just a few weeks away from the 21st century. It would be great to have XFree86 join us there.
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.
- 1Linux Top 3: RHEL 6.7, BackBox Linux 4.3 and RoboLinux 8.1
- 2Linux Top 3: SLES 11 SP4, Chromixium OS 1.5 and Canonical Licensing
- 3Linux Top 3: VirtualBox 5, Point Linux 3.0 and OpenSUSE Leap 42.x
- 4Linux Top 3: Linux 4.2 rc1, 4MLinux 13 and antiX15
- 5Linux Top 3: Linux Mint Rafaela, OpenMandriva Lx 2014.2 and VectorLinux 7.1