Doing it better 1998-10-20
###

> > One problem with this idea is it precludes running Linux on it, as it it
> > written in C. A verified Linux wouldn't be all that bad an idea, though...
>
> I would prefer to use Linux as a development platform and run a custom OS
> on something else until it was powerful/stable enough to use for
> development. Run the custom OS under Linux would be best, then another
> machine wouldn't be needed. OTOH, an RPC would be a nice machine to write
> a standalone OS for first time around, as it's nice and clean and
> well-documented.

Agreed on every count.

> > On top of this we build an I.P. stack. We should use I.P. because
> > everybody else does, and we might want them to forward our messages for
> > us. However, we shouldn't rule out other options.
>
> Indeedly doodle. I think the best thing is to write custom protocols where
> possible ('cos it's fun, 'cos it's minimal, 'cos it's better and more
> uniform) but to allow standard software to be interfaced. Have plenty of
> glue to things like IP, PostScript, PCI cards &c.

That's not quite what I said. I think it is usually wiser to use
established protocols. People don't like learning new ones: let's learn
theirs.



> > We should not regard re-booting as a viable option. We should also
>
> Booting should certainly be viable, just not necessary (but consider power
> failure or CPU/memory/&c. failure.

Absolutely: bad choice of words.

> > anticipate revisions, especially backward compatible ones.
>
> I'm of the opinion that pervasive versioning is the way to do this: don't
> worry about compatible protocols &c. except where absolutely necessary,
> but just keep old ones around until they're not needed.

I disagree. Why won't this file created on a new computer run on that old
one? I think the computer should know.



> I think that:
>
> 1. Your idea of "facts" should be the basis of the idea of typing in the
> whole system. The most general form of typing is making, checking and
> ensuring that assertions hold. It covers access control, language typing
> and security. It should be in the fundamental calculus.

Blimey! That's calling my bluff. You don't mind not being able to compile
C efficiently, then? This is a decision which warrants much thought, not
least because a full verification calculus is not an easy thing to design.
Who knows what problems might crop up? You have to model time, memory, the
works. Interrupts...? I agree it is highly desirable. We should try it
before making a decision.

> 2. As soon as we have the lowest level virtual machine (not worth it
> before for positive and negative reasons) we should advertise the project
> on the internet. Shouldn't expect much interest at first (just another "Me
> too best in the world project", but any would be nice. We might be
> interesting because of our formal approach (rather than
> OS-based/language-based/OOP-based &c. of most people). Also, if we
> encourage participation at the stage when there are many things we could
> be doing, and organise things so that if people want to do what conflicts
> with our own goals, that's fine, we just get a family of systems, then
> interesting things might happen.

Good marketing. We like.

> I'm really keen on packing as much as possible into the very minimal
> calculus-VM. We should have a minimal VM and a minimal picokernel, as
> separate as possible (computation vs interaction). Distribution should be
> in this level conceptually, but of course without devices or protocols.
> Don't need to get as high-level as threads. Basically need:

Sounds bad to me. Not enough levels. I reiterate: don't try to build a
distributed kernal until you have well-designed single machines to write
it for.

A better idea is to pack very little into each level, but have lots of
them. There's no need for the kernal/application distinction to be only a
dichotomy.

> Computation
> Location (space-time)
> Naming
> Escape to hardware

Location is too high level. Assume one machine, one keyboard, one screen.
Naming goes away, because there are then only a finite number of things to
be named. Please explain the distinction between computation and escape to
hardware.

> plus the minimal user interface which should, I think, be essentially a
> minimally simple calculus browser, and even though minimal the concepts of
> the interface should be as separate as possible from the actual
> (presumably initially text mode) UI code.

We're not going to get anywhere with primitive tools. Let's use the host
for what it is worth.


Alustar. I'm getting worse at typing that, aren't I?