X.org, distributors, and proprietary modules [LWN.net]

X.org, distributors, and proprietary modules

Posted Aug 14, 2006 20:51 UTC (Mon) by drag (guest, #31333)
In reply to: X.org, distributors, and proprietary modules by iabervon
Parent article: X.org, distributors, and proprietary modules

I don't think the idea of modularization was ever made to allow increased binary compatability with obsolete drivers. That would make things easier and would be nice, but I don't think it was the point behind modularlization.

The idea is that by moving to a modular build system you acheived several things.. For instance:
moving from X-specific build system to one that is popular (abiet considured seriously flawed by many) means that X developers don't have to designed build tools anymore. Also many more new developers would be familar with the new one.

Dividing up the system into clearly defined parts aided in dependancy tracking.. That way with clearly defined borders on functionality you could have people learn to work with a paticular section of code without having to make them understand everything else. Helps out new developers.

Also having it in modular sections aids greatly in distros like Debian with doing upgrades and such. With this you can upgrade peicemeal without breakage of X or apps that depend on X. Before you had to pretty much upgrade it all all the time.

With drivers and such it wasn't so much a big deal. You could always compile and run drivers seperately from X.

Thing is with binary only drivers your going to have this problem..
Your going to be forced to (on occasion)
1. run obsolete kernels for compatability
2. run obsolete X for compatability
3. run obsolete distros for compatability
3.5. Only be able to run very specific distros for compatability
4. any and all above may have serious serious bugs or security hazards you won't be able to use because they will break your binary compatability.
5. Unable to run a lot of open source software that may cause breakage with binary only drivers if they ran together or that they require certain patches or newer versions that are incompatable with your binary drivers.
6. unable to get effective support from Kernel developers/X developers/Redhat etc etc.

The easiest, quickest, cheapest, and most effective solution to this problem is:
Don't buy hardware that requires binary drivers!
Not to dificult.

the only thing that you can't find nowadays that is open source is is Drivers for nvidia cards or R500 and newer ATI cards (r1xx through r4xx have Free and open source drivers. This is everything from ATI 7200 to ATI x850, the r300 drivers may still require you to compile from CVS for greatest effectiveness)

I suggest a nice 945g intel motherboard and Pentium-D 9x0 cpu. They are cheap, easy to find, have everything you need (sata, pata, video, audio, gigabit network, usb 2.0, and some models have firewire) and they are inexpensive. Otherwise that Core Duo stuff is looking very very nice.

Other then video cards there is no reason you should be running Binary only drivers. You can easily find open source supported hardware. Nowadays even Wifi devices are almost universally supported by open source drivers. There realy isn't a reason to run ndiswrapper unless you very unlucky. (of course wifi needs a bit more maturing to make it trouble free in Linux as anybody can tell you)

to post comments

X.org, distributors, and proprietary modules

Posted Aug 14, 2006 21:16 UTC (Mon) by iabervon (subscriber, #722) [Link] (2 responses)

Well, as you mention, modularization lets you upgrade the server separately from everything else (there can't be dependancies, because everything else could be talking to a server over the network, anyway). So being stuck with the server from 7.0 doesn't mean you can't use the latest versions of everything else or vice versa. I remember one of the specific reasons for modularization being that it took too long for all of the client-side stuff to be simultaneously stable, and so new server versions capable of supporting new drivers were unacceptably delayed; obviously, this works in the opposite direction as well, so a desireable effect is increased local client compatibility with obsolete servers (and therefore obsolete drivers).

(Personally, I've never used a proprietary driver, or even a separately-distributed free driver, even with the (old) nVidia card I have in one of my machines.)

X.org, distributors, and proprietary modules

Posted Aug 14, 2006 22:28 UTC (Mon) by drag (guest, #31333) [Link] (1 responses)

Ya I don't know for sure. Maybe a X developer would be able to clarify.

To me the point has always been so that you are able to run newer drivers then your current X version has, not so much you can remain binary-compatable with old drivers.

The idea is that as driver mature you should be able to install new versions for bug fixes and such.

X.org, distributors, and proprietary modules

Posted Aug 15, 2006 9:53 UTC (Tue) by daniels (subscriber, #16193) [Link]

You can, it's just that the ABI was broken in the move to 7.1. I think the specific change was adding privates to glyphs to allow glyph caching, which was actually an Xgl change ...