[movitz-devel] Topic of list

[James A. Crippen]

"Chris Capel" <chris at iBankTech.NET> writes:

> This seems to me like a good list to discuss operating system design
> issues specific to a hypothetical MoKA.  This has been summarily brought
> up, but would this be a good place to get in depth about what the Right
> Thing is as far as a lisp OS goes?  A few things that've been on my
> mind:
> 
> Would a persistent object store instead of a filesystem be more
> approiate? (Say yes.)

Sorry, no, not as a replacement. You would have trouble implementing
the filesystem part of many existing applications, for instance.
LispMs had both a persistent object store (an OODBMS, actually,
Statice on Genera and PCLOS on Explorer) and a filesystem. They served
different purposes. Filesystems aren't useful for organizing
nonhierarchical data, but persistent object stores are more clumsy and
slower than filesystems when it comes to clearly hierarchical or block
data. There are also reinstantiation problems such as ensuring that
restored persistent objects are still EQ to the originals before
storage, which can be a major PITA.

If you think a POS is a good idea then don't hesitate to implement
it. But it's not a good idea to have a general purpose operating
system without a filesystem for it. People are very used to file
handling and will be very confused when confronted with a system that
doesn't do so.

Now, if you wanted to get creative you could implement a filesystem as
a sort of POS. But the user interface would look just like any other
filesystem and that's how people would tend to use it, hierarchical or
not. But filesystems have significant wins when it comes to linear
data and hierarchical organization, and there are many well known
designs and optimizations available for handling such data, whereas
making a fast and efficient POS is still not a well understood
problem.

If you're looking towards a special purpose system or an embedded
system that relies only on a POS then of course that makes sense. But
for general purpose, especially desktop programming use, a POS isn't a
sufficient replacement for a filesystem. The two organize data in
completely different ways, and have very different purposes.

> How would security be handled?

The original LispMs had an open architecture. Anything could look at
and write to anything. The user could poke at random locations in
memory using LOCF in the listener. So essentially on a LispM there's
no 'security'. This is very appropriate for a developer's workstation,
because security really gets in the way. Put it on a network and make
the network secure, but trust the developer to Do The Right Thing on
his own box. Don't run unauthorized and unreviewed foreign code. And
you don't have the null pointer or random pointer problem in Lisp that
you do in C so there's a lot less worry about heap corruption.

However, security shouldn't be hard to handle if you implement
multiprocessing like on a Unixy system where every process has its own
address space. But that may not be a win for Lisp. IPC is a pain in
the butt and multiprocessing might be better handled the old LispM way
for Lisp, with a global shared address space and lots and lots of swap
(usually 10 to 1 or more).

Threading is also a royal PITA in many cases. It's a big win in some
ways, but if you make your processes lightweight enough and have an
open and shared address space then you get threads for free, because
they're just like ordinary processes. Have your threads lock global
data structures and bind their local data structures, and no problems.

> Would enforcing a strict barrier between packages be enough to solve
> package conflicts and problems, and what would this barrier look like?

Package locking is already implemented in some Lisps. See CMUCL, which
IIRC has such a beast. Package locking is widely regarded as a Good
Thing. Bt of couse it's circumventable, but only if you really want to.

> This kind of questions aren't really strictly Movitz related, but the
> Movitz project does host a little kernel.  Would a real OS kernel built
> (eventually) on Movitz be in a separate project?  Until such a kernel
> materializes, should this kind of discussion take place here or
> somewhere else?

I don't think that 'LispOS' should be discussed here unless code is
actually being produced. Without code the discussion is just noise
here (and yes, I did just contribute to it). Design ideas should be
hashed out elsewhere, on a new LispOS list (the old one is dead) or on
cll. There's a great potential for LispOS discussion to turn into a
huge thread and maybe a flamewar, and that would be totally
inappropriate here. This list should be reserved for discussion of
actual code being implemented in Movitz, and not mere ideation.

'james

-- 
James A. Crippen <james at unlambda.com> Lambda Unlimited
61.2204N, 149.8964W                      Recursion 'R' Us
Anchorage, Alaska, USA, Earth            Y = \f.(\x.f(xx))(\x.f(xx))