[unios] Retro [was Re: Everyone chill]

[Tom Novelli]

On Fri, Apr 30, 1999 at 02:37:28PM -0700, Tril wrote:
> tcn is writing Retro in the HOPE that it will be useful for TUNES.  That's

Actually this is why I'm writing it, in this order:
1) As a simple, efficient OS for my own use (and anyone else who wants it)
2) To run on new computer architectures
3) Possibly for Tunes and/or UniOS (this was basically an afterthought)

> entirely his perogative.  Whether it will or will not be useful remains to
> be seen.  Anyone is free to help him OR not help him.  Criticism should be
> sent to /dev/null.  Instead of criticism, do your own work instead.  If
> anyone can't figure out what to do, e-mail me.  I'll make a list if you
> want.  Most of the work needed is lots of reading and summarizing, of the
> mailing list, as well as lots and lots of papers out there on the net, and
> reviewing systems in the Review project.  But if you have an idea for a
> reflective architecture, that's welcome too.  I personally agree that
> writing microkernels is useless, but if someone is writing one, they
> obviously don't believe that, so let them.  And hope they make a good one!

You could run Tunes under Linux and other existing OSes... but when you run
Tunes by itself, it'll be smaller, faster, and more useful.  Linux (thanks
to its Unix legacy) puts lots of barriers between programs and the hardware. 
Tunes-under-Linux would basically be a demonstration, like Squeak-smalltalk. 
GGI will be a big help for graphics under Linux, but standalone Tunes will
always have the upper hand.  Also, I'm afraid people will have a hard time
compiling Tunes-under-Linux because it'll need certain versions of certain
libraries and modules.. that can be a headache.  Well, we'll do our best to
avoid those problems.  Standalone, Tunes will rock! 

Retro is not a microkernel; it's just small.  Microkernels are known for
being inefficient because they isolate each module, so one faulty module
won't crash the whole kernel.  You get more reliability, but there's lots of
task switch overhead and module-to-module communications overhead.  Linux is
not a microkernel; its kernel & modules aren't protected from each other,
and it's still reliable.

Retro isn't just a kernel... it has compilers, interpreters, user intefaces,
utilities, and all the things that make up a usable computing environment
(although most of it hasn't been written yet).  Retro's kernel is modular,
but the modules aren't isolated as in a microkernel.  Also, the entire
kernel will be organized as objects in the persistent storage system, just
like non-kernel objects.  If you guys need a name for it, I guess it's an
exokernel... I'm not exactly sure what "exokernel" is supposed to mean, but
it's close enough to Retro. :)

> David Manifold <dem@tunes.org>
> This message is placed in the public domain.

-- 
Tom Novelli <tcn@tunes.org>