First proposal: what should LispOS feel like?

Mike McDonald mikemac@titian.engr.sgi.com
Tue, 29 Apr 1997 15:52:29 -0700


>Date: Tue, 29 Apr 1997 21:06:58 +0200 (MEST)
>From: Martin Cracauer <cracauer@cons.org>
>To: lispos@math.gatech.edu
>Subject: First proposal: what should LispOS feel like?
>
>I think we don't have enough agreement here what we want to beast to
>look like.
>
>How should LispOS be different from FreeBSD/Linux/X11 or Windows?

  The theory is that the tightly coupling of the various OS services
under a LispOS allows you to quickly and efficiently do things that
are really though to do in the compartmented world of a traditional
OS. 

>How should LispOS be different from a decent Lisp development system
>(say: Lispworks) running on a normal platform?

  The theory is that all of those OS services should be integrated
into the lisp environment so that you can monitor, change, replace, or
fix any piece in the system. You should, according to the theory,
treat system services just like any other function.


>A MS-Windows system can be told to boot with just basic services.

  I'm not particularly concerned with running under MS-Windows.


>I want my new Lisp machine to ask me in advance for some things that
>can't be changed once the Lisp is running (done using commandline
>parameters on stock systems) and optionally to save these for further
>repeat.

  What things can't you change after you've booted and you're up and
running? That's the whole point of a LispOS, everything is changable
from the user environment!


>OK, the system boots into whatever normal state is defined. A typical
>picture might be:
>- all network interfaces has been brought up, including routes.

  I want these inside my lisp world.

>- it has started some network services like HTTP and mail servers

  Especially these ones!

>- it prompts me for login on network ports (like Telnet does)
>- it prompts me for login on the console
  
  I'd prefer to see a lisp login prompt, not a Unix one.

>I want a X11 server to come up, maybe that should be done later.
>
>When I log in, I expect these things to show up:
>- A Lisp listener or some command line like Genera's Common Processor
>  that messes with Lisp objects instead of Unix ASCII streams.

  Gotta have one of these.

>- An editor written in whatever Lisp dialect the machine runs, or at
>  least understanding code in that language for customization and
>  package programming.

  Gotta have one of these too.

>- A meaningful Window management capability that is integrated with
>  Lisp's needs. The most important feature is to support fastest
>  selection of a given tool. That equivalent Genera's 'select'
>  key. There should be one keystroke to get to the Listener, to the
>  editor. The Window manager should be written in the platforms' Lisp
>  dialect and probably be running in the same world as the editor and
>  the listener.

  I already have one of these. :-) I'll send you my .ctwrm file that
gives me Select-E, Select-M, Select-N, Select-W, Select-D, Select-S,
and Select-T. (Select-L is on my home machine.) I use Caps-Lock for
the select key. Works great! 

  But I agree with your point. :-)


>And yes, I want several worlds. Maybe the whole stuff for my login
>session should be *one* world (Listener, Editor, Window manager,
>Browsers). But the background processes like HTTP servers should have
>their own world that survives crashes of my login world and that
>doesn't get messed up by manipulating my "front world" (nice term).

  Having several worlds running at the same time is a problem. Which
one has the TCP/IP stack in it? (Better be only one.) I can understand
the desire to have a stable, delivery world and a developement world
running at the same time. I just don't know how to do it. It's like
having two copies of the Unix kernal running in case I crash the user
one.

>I didn't made my mind up about OO file store yet.
>
>
>Conclusions:
>- I want different User IDs with different permissions on Object like
>  memory areas, files and port, whatever and I want different processes
>  to be run under different UserIDs

  Not me! I want access to everything on the system. I hate annoying
machines that think they can protect me from myself. Their
"protection" just gets in my way.

>- Therefore I want both: Lisp threads inside a world. And several
>  worlds running in parallel, for different users or several for one
>  user. 

  I vision is of a single user machine. (What percentage of Unix
machine do you think actually have more than one real user on them at
any time? I'd bet it's much less than 10%. And Windows machines? Zero?)


>So, this looks pretty much like a customized Unix system, doesn't it? 
>
>I'd say no. It is a system that uses of Unix what it needs to and what
>is useful in Unix. The free kernels are good and we need them, we
>can't re-implement them, not to speak of drivers.

  About the only thing I ultimately want from Unix is a convientent
interface to it's existing device drivers. The rest of the Unix
baggage like user IDs and permissions can take a hike!


>Then, we start the real stuff. We write a *working* Web browser, based
>on a Free CLIM clone.

  Sure'd be nice to have a working version of CLIM! ;-)

>We implement interfaces to everything we can get hold of on The
>Net. HTTP the least. Corba the next. Active-X/DCOM.

  Everythign that's doable, anyway. (Somethings require so much
additional garbage to be dragged in that they end up being not
practicle.)


>Most important: Speak up, tell me why my model doesn't fit what you
>expect from such a project. Don't miss the opportunity to make a
>complete idiot out of yourself by overlooking fatal drawbacks of your
>dream worlds :-)

  Don't worry, I'll put my two cents in for everyone to take pot
shots at. :-)


>Define what the Window manager should look like. The Window manager
>should be programmed in the platform's Lisp dialect and live in the
>same world as the rest of a login session. We have to define what it
>should do, define an API.

  Gotta define a windowing system before we define a window manager.

>Decide over a Lisp API for threads and processes, including the
>std-I/O problem and debugger calling.
>
>Start hacking. Actually, I'm more a putting-things-together man than a
>real hacker that creates things from scratch. Maybe that is why my
>proposal has actually quite few coding opportunities in it :-) 

  Me? I just architect systems. I don't actually write code. :-) (Just
kidding! But I do view coding as a necessary evil.)

  Mike McDonald
  mikemac@engr.sgi.com