[Nottingham] Linux, GNU, HURD, and now... Valix

[Jim Moore]

Martin wrote:
> Folks,
>
> Linux is now impressively big.
>
> GNU is impressive in itself!
>
> HURD appears to be a parallelism nightmare.
>
> (There's BSD and all the various other *nix stuff that are GNU-less.)
>
> And now...
>
> There is Valix!
>
> http://www.themicrogeeks.com/sites/valixsite/
>
> ####
> The Valix Operating System is an operating system in development with 
> the goal of having a simple desgin. Valix will run no userland binaries: 
> instead, an object-oriented interpreter [for C++ ?] will be built into 
> the kernel...
> ####
>
>
> Rather an interesting idea, and refreshingly different from both Linux 
> and HURD. I like the idea of "simple" :-)
>
> Cheers,
> Martin
>
>   
sorry... I saw "Valix" and read "sexual performance aid"...

Saying that, sounds an interesting step backward (or forward, depending 
on your viewpoint). If I recall correctly, RISC OS has a built in BASIC 
V interpreter, through which it chainloads userland binaries in BASIC 
(natively) and C (via a bolt-on interpreter - which is weird because the 
kernel was written in C). This does seem to be a logical way of doing 
things from the getgo, and to me seems to be the reason why, while not 
stupidly fast (hey, I'd like to see RISC OS 3.1 run native on a 2GHz x86 
processor!), the platform was amazingly stable and resilient. And boots 
in a couple seconds from a cold start.

Kernels these days seem to me to be trying to do too much: I/O flow 
control, buffering, trapping (which is a silly thing to have the kernel 
doing - a watch program should be seperate from the process it's 
watching!), memory paging, whatever else people expect a kernel to be 
able to do... so they get bigger and bigger until they can't see their 
feet anymore, and like NT or an obscenely overweight nuclear safety 
inspector, just fall over merely by virtue of their own mass.

DOS was stable because all it did was provide a single layer interface 
between the I/O bus and the user. Memory paging was applicaiton 
controlled. None of that memory invaded kernelspace, because the kernel 
sat in the bottom *640KB* of system memory and that segment was reserved 
in the BIOS for just that purpose. If the application terminated 
unexpectedly, you could just move on to the next operation instead of 
having to reboot the system (or sit through a kernel paging error and 
thenclely induced restart) to recover from a corrupted live kernel image 
such as you do with NT. Right now the kernelspace (PID #4) in my 
Wintendo has swallowed 78MB of user RAM. JUST WHAT does a kernel process 
*need* with 78MB of memory?

-- 
Are more people violently opposed to wearing fur than leather because it's easier to harass rich women than motorcycle gangs?