Someone should really update that entire Cathedral vs Bazaar paper to
include how much time and effort is lost due to miscommunication by the
peanut galleries. Everyone knows that KGI/EvStacks is not ready to be
included in the kernel. There are still terminal problems, only xterm is
supported natively (I know someone had a problem with that), the event
subsystem isn't complete and there is no support for other architectures.
Right now, graphics cards are one of the few devices which must be accessed
directly from userspace with no kernel abstraction layer. How can anyone
expect to run a real multi-user server when you have multiple programs
trying to access video cards at once? While we are at it, why don't we pull
the entire network card subsystem and put that into userspace too and see
how long that survives in a real multi-user system. How many times do people
have to told, anything which can make a system unstable should not be put in
userspace. That's what macrokernels are all about, low-level hardware
interfaces.
Now if you think that no one will ever need a multi-user graphical system,
you are sadly mistaken. I have known several people who would have found
using a single server with multiple keyboards and monitors attached to
multiple video cards very appealing for things like internet cafes. Sure,
you could get a multiheaded X server, but what happens when you want to run
a straight console. Grocery stores are another example, a single
keyboard/monitor for each register which sends information to a single
server.
X is not being scrapped (well, not by the GGI project at least). There are
some radicals in the GGI project mailing list which bring up wild fantasies
about running web browsers directly from the console with fully graphical
interface. In fact, in order to get X to work ontop of KGI, about 0.1% of it
is modified. Now, if you think this is "scrapping" X, then you better look
at how much of X is the hardware graphics subsystem and how much of it is
higher abstraction layers of the base graphics subsystem. Hell, X doesn't
even use it's own drivers for hardware devices on older Unices.
Now, the solution up until now has been fbcon. Geert did a very good job
with this and while not being multiplatform right now, with enough work it
could be. However KGI is a better solution, there is no doubt about it, but
it is radical from a UNIX perspective.
There are a lot of hard feelings about GGI because it is replacing code
which other people have written. There will be people who will fight to the
bitter end to keep KGI from being integrated simply because it makes their
work obsolete.
Now you said it yourself, KGI should not be put into the kernel simply
because of minor reasons like your machine crashes when you switch consoles
really quickly. However, it should not be kept out of the kernel because of
equally minor points. If the best argument that you can come up with to keep
KGI out of the kernel is that you think it will replace X, then we should
all see KGI's inclusion in the next development series of kernels since that
is a truly lame excuse.
If kernel bloat is the problem, then someone should take a look at how big
the kernel is right now. The SCSI subsystem is HUGE as is the network
hardware subsystem. What's another 10 megs of driver source to the Linux
kernel? I mean, that's about the 1/2 the size the kernel went from 2.0 ->
2.1 series right? That's what we get for supporting more hardware than any
other UNIX or UNIX-like OS. We all wish that x86 people would create a new
graphics standard which was actually enforced... but that won't happen any
time soon.
I have a feeling that all opposing KGI have vested interests in alternate
technologies, whether they be superior or not. In the end, all that really
matters is how many people start using GGI because if someone like Id
Software requires you to patch your kernel for KGI to play Quake 3 under
Linux, there will be little choice but to include KGI into the mainstream
kernel or suffer the flood of millions of users mailing you about why they
have to patch their kernels.
Of course, that's just my opinion, I could be wrong :)
Jordan
-- Jordan Mendelson : http://jordy.wserv.com Web Services, Inc. : http://www.wserv.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu