Moving from XFree86 to X.Org
I moved a workstation from XFree86 to the X.Org server this week. The machine runs KDE all day and uses direct rendering, so my goal was not to celebrate a fork. It was to change the plumbing without making the desktop notice.
The reason for the move is now familiar. XFree86 4.4 adopted a licence clause that major free software distributors consider unacceptable or incompatible with how they combine software. X.Org X11R6.7 provides a continuation based on the earlier code and the broader development tree, under licences distributions are prepared to ship.
I let the distribution packages perform the replacement. This matters because the server is only one part of X: client libraries, fonts, loadable modules, drivers, and configuration paths must agree. Hand-installing a server over packaged files is an excellent way to create a system owned jointly by two package databases and nobody in particular.
Before upgrading, I saved the current X configuration and recorded the working video driver, horizontal and vertical monitor ranges, mouse protocol, keyboard layout, and enabled modules. I also made sure I could log in on a text console and knew how to stop the display manager.
The existing configuration required very little adjustment. Some installations use xorg.conf, while compatibility with an existing XF86Config may be provided. I prefer the new filename once the migration works; ambiguity is not a feature I need in emergency configuration.
The first test was a plain server start, followed by keyboard, mouse, resolution, and font checks. Then I tested KDE and direct rendering:
glxinfo | grep direct
That answer alone is not enough, but it quickly exposes a missing DRI module or mismatched userspace library. I also ran a 3D application and checked the X server log for modules that failed to load. A fast-looking spinning object is not a substitute for reading errors, though it is more festive.
Remote X clients and font paths deserve testing if the machine uses them. The wire protocol remains X11, but package changes can alter which font server or directories are configured. The migration should preserve capabilities, not just produce a local terminal window.
In normal use, KDE behaves exactly as it should: unexcited. Applications do not need to know whether the server came from XFree86 or X.Org. The visible result is deliberately boring.
The interesting change is organisational. Driver and extension work now has a development home tied more closely to the larger desktop community. That does not guarantee perfect engineering or rapid releases, but active collaboration is preferable to waiting behind a project boundary that many contributors had found difficult.
My advice remains to use distribution packages and retain a console escape route. This transition is technically conservative, but X sits underneath the entire graphical session. Even boring plumbing can flood the house when replaced casually.