Another thought:
The major Linux distributions all come with non-standard kernels.
They all ship systems with enhancements to the kernel like the
improved RAID system, ReiserFS, extra drivers etc. etc.
Somebody on this list was busy with making a GGI centric Linux
distribution.
Now what could be done is to distribute the whole KGI/GGI/XGGI
system as an addon for the major Linux distros.
Make a bundle of RPM's for at least RedHat and SuSE in which you put:
- the KGI subsystem integrated in a enhanced kernel package
(with a source rpm along with it of course);
- the complete libGGI and extension libraries;
- the GGI Xserver.
- make the system so that you define one of the unused runlevels the
GGI runlevel, but all the 'normal' runlevel stay intact.
(for instance RedHat:
runlevel 1 = single user
runlevel 2 = network but no nfs mounts
runlevel 3 = complete network and services but no X
runlevel 4 = unused
runlevel 5 = complete network and X
)
Now, in the RedHat example, you make runlevel 4 the GGI runlevel,
so that the KGI kernel modules is loaded, and XGGI run instead of
the normal Xserver. Your GGI RPMs contain all the necessary /etc/rc.d
scripts for this.
If the user is finished with GGI, or it doesn't work right, he can
always go back to runlevel 5.
With a set of RPMs like this, you don't have to make a complete Linux
distro, people can keep their normal systems, and GGI could get more
users.
Of course, in the near future things like a hardware accelerated glx
based on GGI/KGI should be developed, because right now the DRI system
is the only way to get decent 3D graphics in Linux.
And with a GGI version of glx should come a GGI version of XFree 4.0,
which is a lot of work, but XFree 4.0 is the future of graphics in Linux,
especially with the upcoming Render extension. (Render does alpha
channels in X, anti-aliased fonts, faster rendering etc.)
I still think that an improved X Window system is the future of Unix
graphics, and GGI the right layer to realize the improvements.
Roland Nagtegaal
On Sat, Nov 25, 2000 at 03:24:25AM -0800, Jon M. Taylor wrote:
> On Sat, 25 Nov 2000, Jon M. Taylor wrote:
>
> > Linus would just say what he has always said:
> >
> > * Show me the code
> > * Direct Rendering is necessary for performance reasons
>
> Woops, I accidentally posted this before I finished arguing those
> points:
>
> > * Running X as a trusted userspace binary is OK
>
> It isn't necessary anymore, even with DRI.
>
> > * X is not obsolete
>
> X is quite obsolete. That is an entirely separate issue from
> whether the kernel should establish a device driver interface for
> accellerated video rendering and general video hardware resource
> management.
>
> > * Who will maintain KGI in the kernel?
>
> The current maintainers, plus other people who will see it
> distributed with the kernel sources and become a contributor in the grand
> free software tradition. That's the way it usually works.
>
> > * The abstraction is unnecessarily complex
>
> It is complex enough to properly abstract and virtualize access to
> the video hardware resources and capabilities, which is as complex as it
> needs to be. OS designers do not have the luxury of saying that certain
> features don't need to be accounted for, because leaving out "features"
> leads to dangling nodes in the graph of all legal hardware states, which
> leads to system instability.
>
> > * He doesn't like UDI
>
> Steffen's implementation is pretty lightweight. Most of it is in
> the driver layer. You _can_ write monolithic drivers if you want. As far
> as driver portability is concerned, that is vitally necessary for
> maintenance reasons alone. Rewriting any substantive portion of a driver
> for a given PCI device should not have to be done more than once. It puts
> a brake on hardware development progress.
>
> Jon
>
> ---
> 'Cloning and the reprogramming of DNA is the first serious step in
> becoming one with God.'
> - Scientist G. Richard Seed
