x.org is Hacker Trash

Jon Senior jon at restlesslemon.co.uk
Thu Mar 29 13:02:20 PDT 2007


>-----Original Message-----
>A fully configured kernel to support all your hardware etc. will still
>take a while to compile. Say you get a new USB pen, do you just
>compile
>that and "add it on" to your kernel or do you have to build
>the whole
>damn thing again?

Personally I compile it as a module and just "add it on" to my kernel. Is this not the correct approach?

> Now I know you can keep your built tree so it
>will
>compile fast but say you rm -fr'ed? No joy, build from scratch.

True... but no different to X. And you can easily save your configuration (all the GUIs - even the text ones - have an export option) which means that you don't have to keep the source kicking around if you don't want to.

>And I
>know there are dkms systems (which are great) but this wasn't your
>point! You were defending the BIG project approach as a way to get
>more
>people to test things! The kernel is a hell of a confusing thing to
>configure correctly for a novice user. It's managed to get round this
>by
>having a fairly nice GUI to set the various options.

Actually, I think the issue is not BIG project vs modular, so much as ease of setup. And if X were easier to build from scratch, then it is a fairly sure notion that more people would experiment.

>Your argument that it's easy to get out there to test on a variety of
>systems where as modular X does not, just doesn't hold true! I
>packaged
>x11-server13 and x11-driver-video-intel13 for Mandriva to add the
>xserver 1.3 and intel driver RCs to the mix. It was very easy to build
>this on top of our existing xserver but just use a different prefix
>for
>these parts. It works flawlessly and meant I didn't need to build (and
>thus have users install and download) a whole heap of other
>libs/utils/drivers too. By being able to build these packages so
>easily
>it makes for a far better testing ground for new X features. It's just
>a
>matter of finding out (e.g. by asking or reading) what the
>dependencies
>for new feature X are and build them in order. It's not rocket
>science.

It's not rocket science, but it's harder than falling over. There is a balance to met somewhere between the two. Xorg currently has rocket like tendencies as apposed to the dumb klutz vs the paving slab!

>It's all very easy.

No it's not. If it was all very easy then this conversation would not have been happening. I may not be an über coder, but it did take about 3 days work to build Xorg from source. I didn't have that much trouble building a Linux kernel back in '97 when I was using the script that listed each option in sequence and prompted "y/n/m" for each.

>My €0.02

Add mine to the pile (I must be at around €0.06 by now!)

Enough whinging. I'm going to attempt to build something more practical (>From my perspective at any rate). If I succeed I'll add it to the Wiki.

Jon





More information about the xorg mailing list