.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.
- 1Linux Top 3: Fedora 24, Peppermint 7 and Solus 1.2
- 2Linux Top 3: Alpine Linux 3.4, deepin 15.2 and Linux Lite 3.0
- 3Linux 4.7 Set to Boost Live Patching, Security and Power Management
- 4Linux 4.6 Charred Weasel adds USB 3.1 Support
- 5Linux Top 3: OpenIndiana 2016.04, Ubuntu 16.04 and Debian's New Leader