OSes (was: Patterns in Self)

[Jecel Assumpcao Jr]

On Fri, 01 Dec 2000, David Ungar wrote:
> I guess Linux looks good if you are stuck with Windows. I've been 
> using Unix since 1975 and I'm sure someone could do a much better 
> operating system based on different fundamentals than
> byte-stream files, containment-hierarchy directory trees, and C. Not 
> that the world is going this way, though.

Oh no! Don't tell me Mushroom is dead? ;-) Anyway, there is Aperious
(ex Apertos, ex Muse) in each of Sony's robot dogs.

On Fri, 01 Dec 2000, Toby Everett wrote:
> Sing it, brother.  Why are we so wedded to the concept of location for
> organizing data, rather than simply allowing multiple, arbitrary
> organization schemes to be superimposed as needed on an otherwise
> unorganized sea.

I just love to spread my objects around in Kansas without having to
think up a unique name for each one (which I won't remember later
anyway). There is that outliner for a circleMorph in the upper left,
and below it a shell with an expession to enumerate everybody and tell
me the average method size, and to the right of that....

My magazine collection is still rather large (after throwing most of it
away) but I remember where I put things and can find them even if they
aren't in alphabetical order or in neat hierarchical folders.

On a very different topic, I would like to ties Dave's comment above
with what Gordon said in the other thread (about the need to work
together). I think that Self/R (ex Merlin) is the OS we need for the
future, but that each separate Self project has its niche (let me
compare them to similar Smalltalks):

     JSelf - like Talks2 (http://www.architur.de/talks2/t2_index.html)
it runs on top of Java to get two advantages: portability, by running
everywhere there is a Java VM implementation, and ease of distribution,
by using mostly what people already have installed anyway

     OpenSelf - like GNU Smalltalk
(http://www.smalltalk.org/versions/GNUSmalltalk.html) it is lightweight
and easy to interface with external systems. That makes it great as a
scripting language for Unix

     Self 4.1.2 - like VisualWorks (http://www.cincom.com/visualworks/)
it represents a mature system and many years of intense development. It
is a solid platform on which to build bigger things.

     Self/R - like Squeak (http://www.squeak.org/) it is meant to be
self contained and easy to evolve and port.

I don't think any of the other Selfs are currently relevant. One
obvious contrast is that Self/R has only been designed (no code yet)
while Self 4.1.2 has been available for a very long time, now. I'll
ignore this tiny detail :-) in my comparisons below.

The question is: should we throw 3 of these away and focus all our
efforts on the remaining one (note that JSelf is current "frozen")?
Self 4.1.2 would be the obvious choice, but I don't see it becoming as
portable as JSelf or ever as "light" as OpenSelf. And here are some
features that I think would make it nice to have Self/R:

   Self in Self - no need to deal with C++ compilers and development
environments. I'll add a copy of part of an email Craig Chambers sent
to this list in 1990 about the problems of having a Self compiler
compile itself, but I still think it is a good idea. Another way in
which Self/R is written in itself is in having "narrow interfaces" to
the underlying system: the graphics system show do everything in Self
(fonts, ovals, etc) and just use the libraries in the OS (if there is
one at all) to blast the final bits to the screen. The good part is
that porting becomes much easier and you don't have to keep dealing
with other people's bugs (Self 4.0's dates were very broken in Solaris
2.5, for example. I tried to fix them but found that all the work was
being done in Unix and I couldn't touch it) and the bad part is that
you make no use of all the effort people are putting into other
programs (in the example I gave, dates started working perfectly in
Solaris 2.6 without me having to do anything).

   Reflection - systems written in themselves can be very dangerous.
Just see how easy it is to break Kansas. Can you imagine if you could
rewrite the garbage collector while it was running? Squeak doesn't have
this problem because the system you are changing and the system that is
running it are separate (the problem is that transfering your changes
from one system to the other after you are done is slow and awkward).
In Self/R you get the best of both worlds by having the base level
objects supported by multiple meta level objects. So if you break
something while trying to write a new garbage collector, the whole
system won't come crashing down on you but enough of it will continue
to run (using the old, unmodified meta objects) to allow you to fix
things. This is rather like Kansas opening up a new window in which you
can use the debugger whenever the old window breaks too badly.

   Distributed Persistent Object Store - this is an alternative to
Snapshots and the Transporter. It is also an alternative to the virtual
memory in the OS. Your objects are automatically swapped to/from disk
in "clusters". A version system allowed you to back up whenever things
seem to have become corrupted. I won't go into more details here, but
it is interesting that the new Groove software (http://www.groove.net)
has some features in common with my design. The important thing is that,
when running on top of another OS, Self/R can be lightweight by only
loading the clusters actually needed to run a given application. These
clusters are also the key to making it easy to distribute Self/R - if
someone attaches one to an email they send you, it will be simple to
get the components you need to see it on your machine (like getting
Acrobat Reader when you run across your first PDF file).

So, what do you people think. Are these things worth having?

-- Jecel
---------------------------------------------------------
Date: Mon, 24 Sep 90 14:18:49 PDT
From: craig (Craig Chambers)
Message-Id: <9009242118.AA03049 at self.stanford>
To: self-interest
Subject: re: self compiler questions

[.......................]
 vme131!lsi4!jecel at uunet.UU.NET writes:
>I don't like C++ very much - couldn't the Self compiler be written
>in Self ( which, I hope you will agree, is much nicer ) and compile
>itself using a tiny bootstrap interpreter?
 
We've been asked that question many times.  When we first designed the
language, we didn't know whether we'd be able to reach Smalltalk
performance, let alone C performance, so bootstrapping was never
considered.  However, even if we were to reimplement our compiler in
Self, there are still some tricky issues left.  One is the fact that
the compiler's compiled code would be in the code cache, and so might
get flushed, in which case the system would have to fall back to the
interpreter to interpret the Self compiler to compile some application
code.  This could make compiler pauses very distracting.  Also, bugs
in the Self compiler could be very difficult to find, especially if it
compiles itself.  Finally, there would be a large dependency between
the Self code and the virtual machine.  The Self compiler would have
to communicate a lot of information to the virtual machine, and vice
versa, in order to generate the same high quality code.  Designing the
interface between the virtual machine and the Self compiler is a hard
problem.

[........................]