First: Rafeal and I are starting to look for people who wish to help, if
anybody is interested, please let us know! (does anybody even read these
I've spent a lot of time fiddling! Fiddling takes a lot of time since
recompiling the code takes 15 hours!
**Glibc-3.3: Could not get to work, when I compile with this I can't do a
chroot and continue the build process (chroot segfaults) back to glibc-2.2.5
**GCC-3.2: Does not compile glibc-2.2.5, back to gcc-3.1
**Patched linux kernel 2.4.19pre8: Applied the vmware.o video framebuffer
patch, it seems to work ok but is quite slow. Hopefully the vmware.o will
start appearing in the new kernels soon. (see NuVu below as to why I am
**Patched linux kernel 2.4.19pre8: 2.4.19 is different than 2.4.18 in one
way which hit me in a bad, bad way! As you may know, I rely on the devfs to
run the install cd, I just pass root=/dev/cdroms/cdrom0 to the kernel and it
will mount the proper root file system easily!
Unfortunately, 2.4.19 loads devfs AFTER trying to mount root! This means
that when the kernel tries to mount root, there is no /dev/cdroms/cdrom0,
only /dev/had, /dev/hdb, etc. If this is the way the Linux kernel will
stay, then I have to make the move to syslinux and initrd, which is not a
bad thing, it will just take a while to make it work right.
**NuVu: The codename, or perhaps final name, of the new display system
which SGSTEP will use. That's right, no X11. My intention is to create a
very lightweight WindowServer which will be build upon DirectFB, which uses
the linux video framebuffer (hence, explaining why the vmware.o is needed)
At first, I was going to use DirectFBs built-in system of handling multiple
apps, this would have made NuVu very, very easy to create. Unfortunately,
all DirectFB apps need to be run as root and they share a common shared
memory area (passwords can be sniffed). This will clearly not work.
So now I'm working on making a extra level of abstraction. The server will
be linked with libdirectfb and communicate with clients via gnustep
distributed Objects (DO) (NuVu will be an objc/GNUstep "Tool"). Only very
simple messages will be passed between the server and clients, like:
createwindow, mousemove, keypressed, etc. NO drawing code will be passed
between client and server. Instead, the server will create a shared memory
area of a pixmap, the client will draw to the pixmap and tell the server
when to display the contents. This means that all the burden will be placed
on the client side software. Luckily, there are some great libs out there
to help, libart provides great anti-alias graphics and freetype (pango too?)
can provide the text. It will still be a difficult task. Also, the will be
nno "window Manager" the clients will handle window decoration and
Note that when I say client side I am talking about a new gnustep-backend.
Applications will need no modifications to compile
With NuVu, we can probe for the video card right after init loads and switch
to framebuffer mode and then continue on with a graphical init.
**I've added all kinds of goodies to the current source tree, I wish I could
share it with CVS, but it is just way to large at 3.5GB.
Automount (not configured, just there)
Libhardware (awesome hardware detection, will work GREAT for the installer!)
And some other little stuff
The upcoming Interim Developer Releases (IDR) will be based on X11 for a
while, we are shooting to make the final 1.0 release use NuVu.
Once again, does anybody read this stuff?