Re: Evolutionary Code Development (was: GGI, EGCS/PGCC, Kernel source)

Shaw Terwilliger (
Thu, 26 Feb 1998 13:23:37 -0600 (CST)

> I suggest that you take GGI into the mainstream kernel. This way
> it will get public review. The GGI people will get criticism,
> error reports, complaints. They will also get patches and
> interested developers. And there will be people interested into
> integrating current approaches like fbcon with GGI.

I very much agree with this statement. GGI, in my humble opinion, is a
Good Thing. Even if it's not perfect, it's a heck of a lot better than the
current graphics subsystem we have (plus the SVGAlib hacks and a myriad of
X servers, each targeting a different video card), and it gives us room to
evolve. Without a starting point, this branch of the kernel won't grow.

The reason I'm not more behind GGI than I am (read: actively participating
in testing, development, and use) is because it's not in the main kernel
distribution. I had the energy and determination one day to grab the latest
GGI source and patch my kernel with it, only to find out that it didn't patch
cleanly. I gave up and said, "maybe I'll try again with a new kernel version."
GGI isn't all that important to the way I use Linux now, so it wasn't something
I had to get working.

> But all this won't happen unless you expose GGI to some real
> world use and pains by including it into the mainstream kernel.
> Let's just see if it survives and improves.

The only way to get more people like me (your Linux user/developer) to know
these new features is to include them with the kernel source. GGI will
hide in the background, avoiding the testing and evolution other kernel
features have benefitted from in the past.

I do see peoples' points that including something as large as GGI in the kernel
does increase the size of the tarball, and makes for even longer downloads
of drivers most people won't toy with. But is GGI important enough to be
placed in the kernel source tree? I think so. Perhaps it's time to clean
the thing out. Can we break up the kernel source tree somehow? Net drivers
in one package, SCSI in another, etc.? Just an idea.

-Shaw Terwilliger (

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to