Re: replacing X Window System !

[Valdis.Kletnieks@vt.edu]

On Wed, 17 May 2006 14:39:37 +0200, linux cbon said:

> If we have a new window system, shall all applications
> be rewritten ?

No.  /bin/cat and /bin/ls will survive unscathed.  However, if you
have a graphical application, it will need reworking.  That's a LOT
of code.

> My idea is that the kernel should include universal
> graphical support.

And if we discover the API is wrong, or there's a bug, what then?

Or if you just want to try a different window manager?

> And then we would NOT need ANY window system AT ALL.

And if Gnome is in the kernel, what do all the KDE and Enlightenment
users supposed to do?

> It would be faster, simpler, easier to manage etc.

It wouldn't be faster, and it wouldn't be simpler, and it wouldn't be
easier to manage.

Come back when you've examined all the code in libX11 (that's just *one*
of the libraries), and identified *all* the locking issues, put in
schedule() calls at all the right places to allow pre-emption, and converted
it to use only 16K of stack space (that's *generous* - if it were in the
kernel, it would have a lot less than 16K available).

And consider that currently, you can update your kernel and usually not
need to make much change to your Xorg source tree, and vice versa.  A bug
in Xorg doesn't force a kernel upgrade.  Now imagine that you hit a bug
in Xorg that's fixed in the 2.6.28 kernel - but releases after 2.6.26 don't
boot on your hardware because of a bug with the SATA disk controller you
have.

And if my X server dies on me, I don't usually need to wait for the
entire system to reboot.  If it was in the kernel, it just became a
panic/reboot rather than "init respawns gdm and life goes on".

I'm idly wondering how many years of actual system kernel hacking and
sysadmin experience you have - I know for a fact that I've been doing it
for a living since well before many frequent posters to this list were
even born (Hi, Kyle! :)  And the single most important point I've learned
in almost 30 years of making a living at it is:

There is *nothing* that ruins a sysadmin's entire week as badly as a
lengthy pre-req chain.  "We need to upgrade A, but that requires a new
release of B, which means we need to upgrade C as well, but the next
release of C won't work with hardware J of ours...".   People who
complain about Red Hat systems having "pre-req hell" with RPMs are
wimps - I've *never* seen a pre-req chain since Red Hat 7.0 that was more
than 5 or 7 RPM's deep.  IBM's AIX 3 often had pre-req chains over
100 deep - I once had a *single* bugfix against one /etc script replace
*literally* over 3/4 of /usr....)

Attachment: pgpaVrdxFl6yu.pgp
Description: PGP signature