release 0.0.0.20 and thoughts

[spc@gate.net]

On some network somewhere in cyberspace, Billy Tanksley transmitted:
> 
> On Sun, 13 Aug 1995 spc@gate.net wrote:
> 
> >   Well, there are certain cases where it's easy to check, but there comes a
> > point where it's just plain silly to decide certain attributes about a
> > program.  Hypothetical case:  The Ackerman Function.  Given the following
> > (it's in C but it could easily be done in any language):
> 
> >   I know, I know.  You can run it in the "Isolation Box (TM)", but this is
> > the type of thing I'm talking about.
> 
> Actually, from what I've heard from here, you have two choices in modern 
> OS design: OSes that are secure because they're paranoid (isolation 
> boxes) and OSes that are insecure because they don't isolate.
> 
> Fare' and co. appear to me to be wanting to add a third category to that: 
> OSes that are secure because they can choose intellegently whether or not 
> to isolate.
> 
  But isolation doesn't cost that much (on hardware that supports virtual
memory) because EVERYTHING goes through virtual memory.  QNX supports
virtual memory but doesn't swap (i.e. if you have 16M RAM in a QNX system,
then you have 16M Virtual RAM - it doesn't swap out to disk).

  It seems as if Fare and Co. believe that virtual memory is SLOW and
EXPENSIVE and SHOULDN'T BE DONE, except in isolation boxes.  But what you
end up with is a Mac, or Windows that doesn't swap.

> However, there are certain things we CAN prove about that function.  We 
> can't prove that it terminates, but we can show that it doesn't modify 
> any permanent variables.  We can also show that it does or doesn't yield 
> control to the multitasker.  We can show that it doesn't trash memory 
> (aside from the recursion stack, which is contained anyways).
> 
  Well, because of the recursion it can't share a stack with other tasks
(and I'm eagerly awaiting to see how tasks can share stacks).

> > >    Apart for microkernels (that completely suck), I completely agree.
> 
> >   Well, can you explain WHY a microkernel sucks?  
> 
> He seems to think they're slow.  I'm just listening, but I haven't heard 
> why yet.
> 
  On a single processor machine sending messages to itself, yes it may be
slow (although in my experience they haven't been), but on a multiprocessor
machine (or networked) they gain speed since processing can proceed in
parallel.

> >   Okay, that takes us to about 1955.  The point I was making is that it
> > SHOULDN'T take megs and megs of RAM to do what is currently being done. 
> > Yes, OO is neat.  But does it REALLY require 4M of RAM?
> 
> OO SHOULD make all (eqivalent) software smaller.  Most implementations 
> now, therefore, are not OO.  QED.  :)
> 
> There are some well-implemented OO systems out; the only one I actually 
> have used to any extent is PC-Geos, since it comes with a VERY powerful 
> word processor.  It's a multitasking, multithreading, OO, GUI OS that 
> fits in 4M of ROM and runs in 512K.  That 4M ROM includes things like 
> scalable fonts, context-sensive help, and miscellaneous stuff.
> 
  And AmigaOS os based upon both OO and microkernel design (it's one of the
cleanest kernel designs I've ever seen).  That's why it can run in 512K ROM
and 512K RAM (although it doesn't have truely scalable fonts).

  I can see where OO CAN deliver smaller executables, but it's far from
being the Holy Grail of paradigms.  And as far as code reuse goes, I feel
that shared libraries (more along the lines of DLLs or Amiga libraries
today) offer more code reuse than OO (as done today) ever will.

> >   Now, sending a message or attempting to gain a semaphore are forms of
> > yield(), in that the calling execution unit is blocked until the condition
> > is met (and in my Amiga example, that's why 16 tasks can be in the system
> > without taking CPU time at all, because they're all blocked).  
> 
> Just a sec.  Sending a message outside of your thread should not block 
> you; it probably should do a yield, but no blocking.  Now calling a 
> method is different.
> 
  True.  But if a execution unit waits for a reply, it then blocks.

> > Preemtive multitasking doesn't prevent two execution units from cooperating. 
> > No, really, it doesn't.  
> 
> As I understand it, the reverse is also true.  Coop multi does not 
> prevent an object from preempting its own decendants.
> 
  Explain how that is done.

> >   Please, don't take away my freedom to do stupid things to my computer.  I
> > thought that's what TUNES was about.  And if I want preemtive multitasking,
> > I should be able to add it, no?  But here you are, dictating what YOU thing
> > everybody should want.
> 
> No, he's dictating the basic design of TUNES, and he's trying to keep it 
> open.  The nice thing about cooperative multitasking is that you can 
> easily replace it with preemptive-- you can't go the other way around.
> 
  Well, from what I hear from the Mac people, it isn't quite as easy as you
make it out to seem.

  -spc (See, the Mac STILL doesn't have preemptive multitasking)