[many good and true thoughts deleted]
> Linux is quite stable, much more than Windows is. But this is only
> partly true. Yes, it's stable in text mode, but the X Server crash quite
> easily, and will crash much more with DRI, and of course with DGA.
True - at least for some servers I used in the past. Admittedly, even XGGI
crashes occasionally (about once every three months or so - I notice it,
because it happens so rarely :-), but XGGI won't take the machine with it
when running on kgicon. I just restart it and carry on.
> Just take much memory from the system,
*grin* yeah. I've seen a friend of mine with an 80MB X server in memory ...
This is sick. I really love the memory footprint of XGGI:
PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND
722 becka 17 0 13484 13M 1480 R 0 1.1 10.5 8:24 XGGI
and of course the uid :-).
> With respect to the packaging of GGI, I propose:
> GGI+GII core in one package.
O.K.
> Every target in its own package.
This is very hard to do. The debian packages do it, but it heavily breaks
the build system. I don't think not simply delivering all packages has a
significant impact on acceptance. O.K. - it will turn down the downloads
a little, but not really much. Most targets are metatargets and helpers that
should be there anyway to enjoy the full beauty of LibGGI.
> KGI can't actually be a package because it needs to patch the kernel. I
> think another talk with the Kernel people about KGI is in order (at
> least after 2.4 arrives).
I think a few words from Steffen would be good on what is happening with
KGI.
> 1) the GGI core looks more thin.
> 2) The targets look thinner too, and may be choosed individually by the
> people.
A quick du over my LibGGI tree estimates savings of only about 25% by
separating out the targets, while generating almost 30 additional packages,
where you need many of them anyway.
It is ok and actually needed for binary packages (to avoid a dependency-
monstrosity for the single LibGGI package).
RPMs and DEBs have nice dependency management and this will both help the
user to install only the needed stuff and also demand such a split to make
sure LibGGI does not depend on X, libaa, glide, ... .
But I don't think it would be good for the sources. SANE does it in much
the same way, and I'd say it makes much less sense there, but they are
still well accepted.
Almost any installation would want the subdirs:
common, file, memory, multi, palemu, sub, tele, tile, trueemu,
And then one or more of:
- X,Xlib,xf86dga
- fbdev, kgi
- aa, terminfo, vcsa, monotext
- directx
- glide
- lcd823
- suidkgi
- svgalib,vgagl,vgl
Some of which need:
linvtsw, mansync
The most common installation will want at least the fb and the X targets
installed, leaving only 11 drivers out - a few hundred k of source.
CU, Andy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
