From frodef at cs.uit.no  Mon Feb  2 09:37:49 2004
From: frodef at cs.uit.no (Frode Vatvedt Fjeld)
Date: Mon, 02 Feb 2004 10:37:49 +0100
Subject: [movitz-devel] What's up?
Message-ID: <2h4qu94yaa.fsf@vserver.cs.uit.no>

So far I've seen by far many more subscription notices than actual
messages on this list.. :-) I'd be interested to hear about
experiences with getting Movitz up and running and any plans for
using/developing it. I mean, are everyone just here to keep half an
eye on things, are you unable to navigate the pile of code to make
sense of anything, or what?

Myself, I'm trying to concentrate on getting a PhD shipped rather
soonish, and part of that is trying to figure out GC.

-- 
Frode Vatvedt Fjeld




From davep at davep.org  Mon Feb  2 11:47:02 2004
From: davep at davep.org (Dave Pearson)
Date: Mon, 2 Feb 2004 11:47:02 +0000
Subject: [movitz-devel] What's up?
In-Reply-To: <2h4qu94yaa.fsf@vserver.cs.uit.no>
References: <2h4qu94yaa.fsf@vserver.cs.uit.no>
Message-ID: <20040202114702.GH5715@hagbard.davep.org>

* Frode Vatvedt Fjeld <frodef at cs.uit.no> [2004-02-02 10:37:49 +0100]:

> So far I've seen by far many more subscription notices than actual
> messages on this list.. :-) I'd be interested to hear about experiences
> with getting Movitz up and running and any plans for using/developing it.
> I mean, are everyone just here to keep half an eye on things, are you
> unable to navigate the pile of code to make sense of anything, or what?

[In the spirit of explaining myself...] Personally I subscribed because it
sounded very interesting and I, as you say above, wanted to keep half an eye
on things. I guess I'm more of a spectator than anything else. No, I'm not
entirely sure what to make of the code and the most I've done is managed to
fire up the los0-image that came down from CVS inside bochs. Beyond that I
don't really have much of a clue at the moment. That, obviously, reflects on
me, not on this project. If and when I get the time to have a closer look
I'm sure I'll get to a point where I'd actually be able to build things and
possibly play.

-- 
Dave Pearson
http://www.davep.org/



From jdz at dir.lv  Mon Feb  2 16:20:19 2004
From: jdz at dir.lv (Janis Dzerins)
Date: Mon, 02 Feb 2004 18:20:19 +0200
Subject: [movitz-devel] What's up?
In-Reply-To: <2h4qu94yaa.fsf@vserver.cs.uit.no>
References: <2h4qu94yaa.fsf@vserver.cs.uit.no>
Message-ID: <401E78C3.8080702@dir.lv>

Frode Vatvedt Fjeld wrote:

> So far I've seen by far many more subscription notices than actual
> messages on this list.. :-) I'd be interested to hear about
> experiences with getting Movitz up and running and any plans for
> using/developing it. I mean, are everyone just here to keep half an
> eye on things, are you unable to navigate the pile of code to make
> sense of anything, or what?

I got it up and runnig with sbcl (and with ACL trial too).  Then I 
started to read IA32 and AMD64 documents because the last assembler code 
I wrote was for 80286 and DOS.  I also was reading linux sources for 
framebuffer and VESA stuff.

In short -- I have looked a bit through the sources and have not decided 
where to start doing anything.  But I will!

One thing I would like to find out is how to work with the stuff: mainly 
I think I would like to know about the bochs interface through procfs. 
If that is described somewhere, just point me where should I start 
reading.  Haven't got this far, yet.  And I'm a bit sick at the moment.

> Myself, I'm trying to concentrate on getting a PhD shipped rather
> soonish, and part of that is trying to figure out GC.

I guess working on GC means knowing lots of implementation details only 
you have (at the moment).  But I think it would be beneficial for 
everybody else to have some knowledge of the details.  I'd really like 
to see more discussions on such things here (this is devel list, after 
all :).  So please share with us when you have anything to say.

--
Janis Dzerins

   Common Lisp -- you get more than what you see.



From frodef at cs.uit.no  Mon Feb  2 17:29:58 2004
From: frodef at cs.uit.no (Frode Vatvedt Fjeld)
Date: Mon, 02 Feb 2004 18:29:58 +0100
Subject: [movitz-devel] Re: What's up?
References: <2h4qu94yaa.fsf@vserver.cs.uit.no> <401E78C3.8080702@dir.lv>
Message-ID: <2h8yjl2xux.fsf@vserver.cs.uit.no>

Janis Dzerins <jdz at dir.lv> writes:

> One thing I would like to find out is how to work with the stuff:
> mainly I think I would like to know about the bochs interface
> through procfs. If that is described somewhere, just point me where
> should I start reading.

This is not much described anywhere, and even if it at one time was
one of the most central things about this project, that code now
slightly lagging behind. The procfs stuff is only tested/designed for
FreeBSD as that's what I'm using, but I'm guessing porting it to linux
or NetBSD would be easy. What it currently does is to allow me to
attach to bochs running Movitz and inspect memory and CPU state, or do
a backtrace, which at times can be very valuable for debugging.


> I guess working on GC means knowing lots of implementation details
> only you have (at the moment).  But I think it would be beneficial
> for everybody else to have some knowledge of the details.  I'd
> really like to see more discussions on such things here (this is
> devel list, after all :).  So please share with us when you have
> anything to say.

I'll be happy to share any technical information I know, on request,
but currently I don't have time to actively write down all the little
details beyond what I've already done in the report (movitz.pdf) that
is available. I'm also not sure there would be much point anyway, as
many things have not stabilized yet.

Concerning GC in particluar I hope to produce some text (and code)
within a few months.

-- 
Frode Vatvedt Fjeld




From mikel at evins.net  Mon Feb  2 18:05:03 2004
From: mikel at evins.net (mikel evins)
Date: Mon, 2 Feb 2004 10:05:03 -0800
Subject: [movitz-devel] What's up?
In-Reply-To: <2h4qu94yaa.fsf@vserver.cs.uit.no>
References: <2h4qu94yaa.fsf@vserver.cs.uit.no>
Message-ID: <534B64B2-55AA-11D8-9BDE-000A958E5B06@evins.net>


On Feb 2, 2004, at 1:37 AM, Frode Vatvedt Fjeld wrote:

> So far I've seen by far many more subscription notices than actual
> messages on this list.. :-) I'd be interested to hear about
> experiences with getting Movitz up and running and any plans for
> using/developing it. I mean, are everyone just here to keep half an
> eye on things, are you unable to navigate the pile of code to make
> sense of anything, or what?
>
> Myself, I'm trying to concentrate on getting a PhD shipped rather
> soonish, and part of that is trying to figure out GC.
>

I joined because I want to write an operating system in Lisp.

I've got several other open-source projects going, so I'm liable to be 
a little slow in developing things, but I certainly joined with the 
intention of writing code.

Thus far I've booted the image and explored the running lisp, and I've 
experimented a little with building the code under openmcl and sbcl, 
and that's as far as I've gotten. I'll do more later; I've been busy 
with the other projects just lately.

--me




From nyef at softhome.net  Mon Feb  2 20:28:13 2004
From: nyef at softhome.net (Nyef)
Date: Mon, 2 Feb 2004 15:28:13 -0500
Subject: [movitz-devel] What's up?
In-Reply-To: <534B64B2-55AA-11D8-9BDE-000A958E5B06@evins.net>
References: <2h4qu94yaa.fsf@vserver.cs.uit.no>
	<534B64B2-55AA-11D8-9BDE-000A958E5B06@evins.net>
Message-ID: <20040202202813.GA15120@miyu.paradiesanalytics.com>

On Mon, Feb 02, 2004 at 10:05:03AM -0800, mikel evins wrote:
> 
> I joined because I want to write an operating system in Lisp.

You too, huh?

> I've got several other open-source projects going, so I'm liable to be 
> a little slow in developing things, but I certainly joined with the 
> intention of writing code.

Same here. Right now my focus is in fixing a certain deficiency in Wine,
with some messing about with Smalltalk on the side.

I was a little discouraged after my last round of changes to my floppy
driver didn't work right. I'll put it on my queue to look at again soon.

--Alastair Bridgewater



From a_bakic at yahoo.com  Mon Feb  2 21:23:29 2004
From: a_bakic at yahoo.com (Aleksandar Bakic)
Date: Mon, 2 Feb 2004 13:23:29 -0800 (PST)
Subject: [movitz-devel] What's up?
In-Reply-To: <2h4qu94yaa.fsf@vserver.cs.uit.no>
Message-ID: <20040202212329.3629.qmail@web40613.mail.yahoo.com>

> I'd be interested to hear about
> experiences with getting Movitz up and running and any plans for
> using/developing it. I mean, are everyone just here to keep half an
> eye on things, are you unable to navigate the pile of code to make
> sense of anything, or what?

Hi,

I saw it booting under Bochs and I played with it just a little bit. I looked
at the source files, too. First of all, I may need to refresh my memory wrt.
x86 assembly. Are there some good on-line/downloadable references? Next, I
wonder what kinds of MoKAs (besides the mentioned 3D/AI OS) might be killer
KAs. I assume it would not be trivial to reuse the code and have Movitz run on
a non-x86 device (something like uClinux). I need to take a deeper look into
the compiler code and see if I could contribute in the foreseeable future. I
hope to find structure in there besides the documented protocol. BTW, what is
the status of the CMUCL port?

> Myself, I'm trying to concentrate on getting a PhD shipped rather
> soonish, and part of that is trying to figure out GC.

A GC is probably the first thing needed; it is good that you are working on it.
Do you have a relatively detailed plan, i.e., a list of things you would like
to see done sooner rather than later? Perhaps you could drive us (and,
indirectly, help us learn faster) by throwing in smaller contribution projects
(unless I failed to see something like this in the documentation).

Alex

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/



From frodef at cs.uit.no  Mon Feb  2 21:46:05 2004
From: frodef at cs.uit.no (Frode Vatvedt Fjeld)
Date: Mon, 02 Feb 2004 22:46:05 +0100
Subject: [movitz-devel] Re: What's up?
References: <2h4qu94yaa.fsf@vserver.cs.uit.no>
	<20040202212329.3629.qmail@web40613.mail.yahoo.com>
Message-ID: <2hvfmp17fm.fsf@vserver.cs.uit.no>

Aleksandar Bakic <a_bakic at yahoo.com> writes:

> I saw it booting under Bochs and I played with it just a little
> bit. I looked at the source files, too. First of all, I may need to
> refresh my memory wrt.  x86 assembly. Are there some good
> on-line/downloadable references?

The x86 manuals are available from http://developer.intel.com, I find
those quite good, at least for anyone who grasps the basics of
assembly.

> Next, I wonder what kinds of MoKAs (besides the mentioned 3D/AI OS)
> might be killer KAs.

One idea might be a firewall/router/etc kind of thing.

> I assume it would not be trivial to reuse the code and have Movitz
> run on a non-x86 device (something like uClinux).

It certainly isn't.

> BTW, what is the status of the CMUCL port?

CMUCL seems to work about 96% of the way. Something weird happens
during dump-image.

> Do you have a relatively detailed plan, i.e., a list of things you
> would like to see done sooner rather than later?

The first thing obviously would be to get the development environment
up and going on other platforms than my Allegro/FreeBSD. Incremental
compiles, for example.. In my emacs, for Movitz buffers, I've got
M-C-x wired up to do the right thing, i.e. to recompile the
function/method/whatever under the current *image*. And a key-chord
that dumps an image and fires up bochs, and so on. This is in
movitz-mode.el, which hooks into ELI (ACL's emacs
interface). Something similar would have to be ported/written for
slime or ilisp.

-- 
Frode Vatvedt Fjeld




From plathrop at nmu.edu  Tue Feb  3 00:21:16 2004
From: plathrop at nmu.edu (Paul D. Lathrop)
Date: Mon, 2 Feb 2004 19:21:16 -0500
Subject: [movitz-devel] What's up?
In-Reply-To: <2h4qu94yaa.fsf@vserver.cs.uit.no>
References: <2h4qu94yaa.fsf@vserver.cs.uit.no>
Message-ID: <E19CA020-55DE-11D8-8149-000A9573C480@nmu.edu>

I've been lurking on the list and keeping an eye on Movitz because 
though I am terrible interested in Lisp, especially as a language for 
OS design, I am woefully under-educated. I also don't currently have 
any x86 boxes to play on, so that surely hasn't helped. The code is 
fairly readable as far as I've seen, but I will admit I've been more of 
a browser than an in-depth reader.

--Paul Lathrop
plathrop at nmu.edu

On Feb 2, 2004, at 4:37 AM, Frode Vatvedt Fjeld wrote:

> So far I've seen by far many more subscription notices than actual
> messages on this list.. :-) I'd be interested to hear about
> experiences with getting Movitz up and running and any plans for
> using/developing it. I mean, are everyone just here to keep half an
> eye on things, are you unable to navigate the pile of code to make
> sense of anything, or what?
>
> Myself, I'm trying to concentrate on getting a PhD shipped rather
> soonish, and part of that is trying to figure out GC.
>
> -- 
> Frode Vatvedt Fjeld
>
>
> _______________________________________________
> movitz-devel site list
> movitz-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/movitz-devel
>




From mikel at evins.net  Tue Feb  3 20:17:04 2004
From: mikel at evins.net (mikel evins)
Date: Tue, 3 Feb 2004 12:17:04 -0800
Subject: [movitz-devel] Lisp OS
In-Reply-To: <2hvfmp17fm.fsf@vserver.cs.uit.no>
References: <2h4qu94yaa.fsf@vserver.cs.uit.no>
	<20040202212329.3629.qmail@web40613.mail.yahoo.com>
	<2hvfmp17fm.fsf@vserver.cs.uit.no>
Message-ID: <EF1E57A5-5685-11D8-8C08-000A958E5B06@evins.net>

The reason I downloaded Movitz and joined the list is that I'm 
interested in OS development in Lisp. That interest has its roots in 
two experiences: first, working with a Symbolics machine and Genera in 
the late 80s; second, being a programmer working on an operating system 
at Apple in the early nineties. The operating system was for a new 
platform that eventually became the Newton, and everything except the 
microkernel and the QuickDraw library were written in a new programming 
language called Ralph; Ralph was later renamed Dylan, and later than 
that its syntax was changed to something more familiar to C 
programmers, but Ralph was originally just Scheme plus CLOS.

Working with Genera was a lot of fun, and quite different from any 
other OS I've used. Working on the Dylan version of Newton's OS was 
even more fun.

One of the things that the two had in common was that they were both 
designed to be Lispy; that is, the abstractions and interfaces provided 
were designed to be natural to the Lisp programmer.

There's a lot of code and a lot of documentation available about how to 
write operating systems, but nearly all of it assumes that system 
programmers will use C, and they are organized around that assumption. 
If you assume that the system-programming language is Lisp and you 
think about system programming in Lisp, things turn out a little 
differently.

To take one example, I have experience working with Apple's QuickDraw 
libraries on five different processors (6502, 68K, PowerPC, x86, and 
ARM) and four operating systems (Apple IIGS, MacOS, Windows, and 
NewtonOS). The versions of QuickDraw whose API was presented in C were 
more similar to each other than different, despite different processors 
and operating systems, but when we did a windowing system in Ralph for 
the Newton, based on the lowest-level QuickDraw code, that version of 
QuickDraw was different from the others. QuickDraw had seven very 
low-level routines; all the familiar C API was implemented in terms of 
those low-level routines. We kept the low-level routines, but discarded 
the higher-level API; the guy working on QuickDraw implemented a new 
high-level API that was a better match for Lisp.

This Lisp-based QuickDraw API was more different from any of the 
C-based APIs than any of them were from one another.

As an example of the differences, traditional QuickDraw code copies 
relatively large data structures quite a bit, because various different 
routines need access to them in various different ways, and it becomes 
nearly impossible to tell in a nontrivial application which routine 
should deallocate them. In our incarnation of QuickDraw almost all that 
copying was eliminated because garbage-collection freed us from 
worrying about dangling pointers and memory leaks. The various drawing 
data structures lived as long as they were needed and were 
automatically deallocated when they weren't needed anymore. This 
difference in style amounted to an automatic optimization of memory and 
CPU use that gave us a fast, memory-efficient, great-looking graphics 
system that was easy and natural to use.

This story is a prologue to a discussion I'd like to have about OS 
design in Lisp (and on Movitz): what would a modern OS look like if 
designed around the natural abstractions and expressions of Lisp?

Plan 9 is said to be organized around 3 fundamental concepts:

1 - everything in the system looks like a file
2 - files respond to the same unifying protocol regardless over whether 
they are local or remote
3 - the namespace of the filesystem is subjective; that is, each 
process names all the files in the universe using a single namespace, 
but that namespace is defined relative to the process itself, so two 
different processes may have very different views of the same set of 
files.

These fundamentals give rise to a system with powerful and elegant 
abstractions. What are the corresponding small number of powerful 
fundamentals of a modern Lisp OS? What are the irreducible atoms of 
which it is constructed? What are the abstractions that make for the 
most natural expression of OS ideas in Lisp? What would the ultimately 
Lispy OS look like?




From frodef at cs.uit.no  Tue Feb  3 21:04:06 2004
From: frodef at cs.uit.no (Frode Vatvedt Fjeld)
Date: Tue, 03 Feb 2004 22:04:06 +0100
Subject: [movitz-devel] Re: Lisp OS
References: <2h4qu94yaa.fsf@vserver.cs.uit.no>
	<20040202212329.3629.qmail@web40613.mail.yahoo.com>
	<2hvfmp17fm.fsf@vserver.cs.uit.no>
	<EF1E57A5-5685-11D8-8C08-000A958E5B06@evins.net>
Message-ID: <2hisin27uh.fsf@vserver.cs.uit.no>

mikel evins <mikel at evins.net> writes:

> [..] Plan 9 is said to be organized around 3 fundamental concepts:
>
> 1 - everything in the system looks like a file
> 2 - files respond to the same unifying protocol regardless over
> whether they are local or remote
> 3 - the namespace of the filesystem is subjective; that is, each
> process names all the files in the universe using a single namespace,
> but that namespace is defined relative to the process itself, so two
> different processes may have very different views of the same set of
> files.
>
> These fundamentals give rise to a system with powerful and elegant
> abstractions. [..]

Regarding file-abstractions/pathnames specifically, my perspective is
that they are (in unix and e.g. plan 9) a solution to a naming problem
that results from having separate address spaces, and no dynamic
typing. So my feeling towards this would obviously be to solve that
problem by not introducing it, so to speak.

> [..] What are the corresponding small number of powerful
> fundamentals of a modern Lisp OS? What are the irreducible atoms of
> which it is constructed? What are the abstractions that make for the
> most natural expression of OS ideas in Lisp? What would the
> ultimately Lispy OS look like?

There are a lot of angles from which to attack this I suppose. But one
I find interesting is the idea that information should be kept
carefully in the system. Dynamic typing is the fundamental aspect of
this, and CLIM etc. a logic extension. And this leads to what is my
impression that people rave about from the lisp machines: the level of
integration and resulting user experience. I wonder how this might be
extended further in a distributed setting, the web, etc.

Other angles would be such issues as what is a process? An
application? Safety? Security? Users? As I've probably said before, my
hope is that Movitz can provide a platform for exploring these things.

-- 
Frode Vatvedt Fjeld




From tsiivola at cc.hut.fi  Wed Feb  4 07:07:34 2004
From: tsiivola at cc.hut.fi (Nikodemus Siivola)
Date: Wed, 4 Feb 2004 09:07:34 +0200 (EET)
Subject: [movitz-devel] Lisp OS
In-Reply-To: <EF1E57A5-5685-11D8-8C08-000A958E5B06@evins.net>
References: <2h4qu94yaa.fsf@vserver.cs.uit.no>
	<20040202212329.3629.qmail@web40613.mail.yahoo.com>
	<2hvfmp17fm.fsf@vserver.cs.uit.no>
	<EF1E57A5-5685-11D8-8C08-000A958E5B06@evins.net>
Message-ID: <Pine.GSO.4.58.0402040902470.28697@saha.hut.fi>

On Tue, 3 Feb 2004, mikel evins wrote:

> automatically deallocated when they weren't needed anymore. This
> difference in style amounted to an automatic optimization of memory and
> CPU use that gave us a fast, memory-efficient, great-looking graphics

This reminds me of my *hunch* why swapping was (or so I've heard it) never
a problem on Lisp Machines, but tends to be on "modern" platforms:

 Single garbage collector over all processes (can) improves locality of
 reference globally, but even the best per-process allocation schemes are
 doomed to fail when the number of processes grows. Of course, the OS can
 try to deal with this, but that seems to be a lot harder than writing a
 decent GC...

Can anyone debunk/corraborate this?

Cheers,

 -- Nikodemus




From tsiivola at cc.hut.fi  Wed Feb  4 07:27:04 2004
From: tsiivola at cc.hut.fi (Nikodemus Siivola)
Date: Wed, 4 Feb 2004 09:27:04 +0200 (EET)
Subject: [movitz-devel] What's up?
In-Reply-To: <2h4qu94yaa.fsf@vserver.cs.uit.no>
References: <2h4qu94yaa.fsf@vserver.cs.uit.no>
Message-ID: <Pine.GSO.4.58.0402040912170.28697@saha.hut.fi>

Currently (for the next month or two at least) I'm pretty much doomed to
just follow what's going on.

In the medium term I'm interested in working on various relatively
independent bits that directly affect my "user experience": like teaching
it about scandinavian keyboards, working on various drivers, improving the
line editor, etc.

In the long term I'm looking forward to hacking the compiler, working
towards making it self-hosting, and what ever arises en route to having a
Lisp OS.

What I "want" from Movitz is the joy of writing lisp, and hopefully at one
point a sane OS.

What I can realistically offer is not too much: my experience is limited
to a few projects of my own, plus some SBCL patching. Most of the things
I'd like to do for Movitz are things I need to learn first.

On the documentation front, what I most miss are comments in the source
?la SBCL/CMUCL. They often explain the motivation behind things, and
shamelessly mark things that are not really ideal or right as such. It's
especially good to see comments to the effect of "I'm not really sure this
is right, but it seems to be because..." when that is the case: it saves
plenty of puzzling over puzzling code.

Cheers,

 -- Nikodemus



From frodef at cs.uit.no  Wed Feb  4 10:07:13 2004
From: frodef at cs.uit.no (Frode Vatvedt Fjeld)
Date: Wed, 04 Feb 2004 11:07:13 +0100
Subject: [movitz-devel] Re: What's up?
References: <2h4qu94yaa.fsf@vserver.cs.uit.no>
	<Pine.GSO.4.58.0402040912170.28697@saha.hut.fi>
Message-ID: <2hektb17la.fsf@vserver.cs.uit.no>

Nikodemus Siivola <tsiivola at cc.hut.fi> writes:

> On the documentation front, what I most miss are comments in the
> source ?la SBCL/CMUCL. They often explain the motivation behind
> things, and shamelessly mark things that are not really ideal or
> right as such.

I'm trying (harder) to fill out comments and docstrings while working
on code these days. Btw I don't know how many are watching the CVS
notices, but I'm trying to add informative check-in comments too.

-- 
Frode Vatvedt Fjeld




From mikel at evins.net  Wed Feb  4 18:44:42 2004
From: mikel at evins.net (mikel evins)
Date: Wed, 4 Feb 2004 10:44:42 -0800
Subject: [movitz-devel] Re: Lisp OS
In-Reply-To: <2hisin27uh.fsf@vserver.cs.uit.no>
References: <2h4qu94yaa.fsf@vserver.cs.uit.no>
	<20040202212329.3629.qmail@web40613.mail.yahoo.com>
	<2hvfmp17fm.fsf@vserver.cs.uit.no>
	<EF1E57A5-5685-11D8-8C08-000A958E5B06@evins.net>
	<2hisin27uh.fsf@vserver.cs.uit.no>
Message-ID: <320AD254-5742-11D8-92BC-000A958E5B06@evins.net>


On Feb 3, 2004, at 1:04 PM, Frode Vatvedt Fjeld wrote:

> mikel evins <mikel at evins.net> writes:
>
>> [..] Plan 9 is said to be organized around 3 fundamental concepts:
>>
>> 1 - everything in the system looks like a file
>> 2 - files respond to the same unifying protocol regardless over
>> whether they are local or remote
>> 3 - the namespace of the filesystem is subjective; that is, each
>> process names all the files in the universe using a single namespace,
>> but that namespace is defined relative to the process itself, so two
>> different processes may have very different views of the same set of
>> files.
>>
>> These fundamentals give rise to a system with powerful and elegant
>> abstractions. [..]
>
> Regarding file-abstractions/pathnames specifically, my perspective is
> that they are (in unix and e.g. plan 9) a solution to a naming problem
> that results from having separate address spaces, and no dynamic
> typing. So my feeling towards this would obviously be to solve that
> problem by not introducing it, so to speak.

What's nice about files and pathnames in Plan 9 is that

1. The basic concepts are easy to grasp

2. They are applied extremely uniformly, so that a single abstraction 
is sufficient to represent the majority of things that programmers and 
users want to use.

3. The namespace is hierarchical, and can uniformly encompass and 
organize every system resource (disk storage, network services, running 
processes, memory, devices...) using a single naming mechanism

4. The namespace is subjective; that is, each user constructs his or 
her own namespace organized for the user's convenience and 
understanding, not for the convenience of the computer. Any system 
resource may be mounted at any node in the namespace, without 
exception.

Like Lisp, Plan 9 has advantages that are not immediately obvious until 
you try them out. As an example, a web browser in Plan 9 can be utterly 
trivial--literally a one-line shell script, because every web server on 
the net is just a file somewhere in /net/tcp (or wherever the user 
decides to mount tcp) and windows are just files in /w.

This is not to argue that a Lisp OS should use the same sort of 
abstraction; rather, it is to argue that Plan 9 demonstrates how far 
the uniform application of a simplifying abstraction can get you. What 
I'm interested in, in this context, is this: what are the simplifying 
abstractions that are natural in Lisp? What Lisp features can collapse 
the complexity of a modern OS into something as simple as, or simpler 
than, Plan 9? Closures over streams, perhaps?

>
>> [..] What are the corresponding small number of powerful
>> fundamentals of a modern Lisp OS? What are the irreducible atoms of
>> which it is constructed? What are the abstractions that make for the
>> most natural expression of OS ideas in Lisp? What would the
>> ultimately Lispy OS look like?
>
> There are a lot of angles from which to attack this I suppose. But one
> I find interesting is the idea that information should be kept
> carefully in the system. Dynamic typing is the fundamental aspect of
> this, and CLIM etc. a logic extension. And this leads to what is my
> impression that people rave about from the lisp machines: the level of
> integration and resulting user experience. I wonder how this might be
> extended further in a distributed setting, the web, etc.

I agree, but we should keep in mind that one reason LispMs were so 
highly integrated was that no consideration whatsoever was given to 
security. Absolutely everything on the system was completely and 
totally unprotected. Sure, you could stop any process and inspect or 
change any value in any slot, or redefine any function all the way down 
to the metal, and this made for a great development environment. It 
should be kept in mind, though, that anybody else could do the same 
thing to your machine, whether you wanted them to or not.


>
> Other angles would be such issues as what is a process? An
> application? Safety? Security? Users? As I've probably said before, my
> hope is that Movitz can provide a platform for exploring these things.
>

I hope so too; that's why I find it appealing.

There's a lot more to talk about on all those subjects, but I don't 
want to write a giant screed on all of them right now. Maybe later. :-)

--me




From movitz at u-h-l.de  Wed Feb  4 19:17:44 2004
From: movitz at u-h-l.de (Klaus Uhl)
Date: Wed, 04 Feb 2004 20:17:44 +0100
Subject: [movitz-devel] Re: Lisp OS
In-Reply-To: <320AD254-5742-11D8-92BC-000A958E5B06@evins.net> (mikel evins's
	message of "Wed, 4 Feb 2004 10:44:42 -0800")
References: <2h4qu94yaa.fsf@vserver.cs.uit.no>
	<20040202212329.3629.qmail@web40613.mail.yahoo.com>
	<2hvfmp17fm.fsf@vserver.cs.uit.no>
	<EF1E57A5-5685-11D8-8C08-000A958E5B06@evins.net>
	<2hisin27uh.fsf@vserver.cs.uit.no>
	<320AD254-5742-11D8-92BC-000A958E5B06@evins.net>
Message-ID: <87k732r6w7.fsf@ulm.my.lan>

mikel evins <mikel at evins.net> writes:

> This is not to argue that a Lisp OS should use the same sort of
> abstraction; rather, it is to argue that Plan 9 demonstrates how far
> the uniform application of a simplifying abstraction can get you. What
> I'm interested in, in this context, is this: what are the simplifying
> abstractions that are natural in Lisp? What Lisp features can collapse
> the complexity of a modern OS into something as simple as, or simpler
> than, Plan 9? Closures over streams, perhaps?

I'm not a Lisp expert but what about objects? Everything in Common
Lisp is an object, even classes. Could that be a "natural" abstraction
for a Lisp OS?

Klaus

-- 

                 Programming today is a race between software engineers
                 striving to build bigger and better idiot-proof programs
		 and the universe trying to produce bigger and better idiots.
\|/ ____ \|/     So far, the universe is winning.
"@'/ ,. \`@"                                                   (Richard Cook)
\_| \__/ |_/     
   \__U_/        Mail : movitz at u-h-l.de
                 WWW  : www.u-h-l.de
                 PGP  : 0x128F9DEC                 
                 ICQ  : 133448107
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/movitz-devel/attachments/20040204/8930fb63/attachment.sig>

From mikel at evins.net  Wed Feb  4 21:39:13 2004
From: mikel at evins.net (mikel evins)
Date: Wed, 4 Feb 2004 13:39:13 -0800
Subject: [movitz-devel] Re: Lisp OS
In-Reply-To: <87k732r6w7.fsf@ulm.my.lan>
References: <2h4qu94yaa.fsf@vserver.cs.uit.no>
	<20040202212329.3629.qmail@web40613.mail.yahoo.com>
	<2hvfmp17fm.fsf@vserver.cs.uit.no>
	<EF1E57A5-5685-11D8-8C08-000A958E5B06@evins.net>
	<2hisin27uh.fsf@vserver.cs.uit.no>
	<320AD254-5742-11D8-92BC-000A958E5B06@evins.net>
	<87k732r6w7.fsf@ulm.my.lan>
Message-ID: <93658E3E-575A-11D8-8676-000A958E5B06@evins.net>


On Feb 4, 2004, at 11:17 AM, Klaus Uhl wrote:

> mikel evins <mikel at evins.net> writes:
>
>> This is not to argue that a Lisp OS should use the same sort of
>> abstraction; rather, it is to argue that Plan 9 demonstrates how far
>> the uniform application of a simplifying abstraction can get you. What
>> I'm interested in, in this context, is this: what are the simplifying
>> abstractions that are natural in Lisp? What Lisp features can collapse
>> the complexity of a modern OS into something as simple as, or simpler
>> than, Plan 9? Closures over streams, perhaps?
>
> I'm not a Lisp expert but what about objects? Everything in Common
> Lisp is an object, even classes. Could that be a "natural" abstraction
> for a Lisp OS?
>

I think that's not saying enough. Everything in Common Lisp is an 
object, that's true, but saying so does nothing to make sense of the 
perhaps complicated world of machine resources managed by an operating 
system. Plan 9 achieves a simplification of the way that human 
beings--programmers or users--interact with the machine by choosing a 
particular small set of objects in terms of which to represent a wide 
variety of resources. The abstraction they choose is not necessarily 
the right one for Lisp, but it works in terms of what they were trying 
to do.

Idioms that are natural to Lisp include variables and slots for 
containing things; lists for managing groups of things; (generic) 
functions for doing things. Just as an off-the-top of the head idea for 
discussion, imagine that each user of a Lisp OS gets a namespace with 
functions defined that return collections (lists? tables? databases?) 
of useful resources. For example, suppose that all of these expressions 
make sense to type at a listener (and that they presumably have 
corresponding direct-manipulation equivalents in a presentation system 
of some sort):

(open-documents)
(open-documents :newer-than (yesterday))
(users :onlinep t)
(tools :for-documents-of-type :text)
(setf (get-contact "Joe Blow") (get-input-from-user :type :contact))
(invite (get-contact "Joe Blow")
		:session-scope :private
		:session-type :shared-read-write
		:session-lifetime :unlimited
		:include-documents (documents #<some-query>)
		:security #<some-security-protocol-specifier>)

Most of these examples are similar to things we were trying to do in 
the Lisp version of Newton. The exception is the last one, which 
represents some sort of concept of ownership and permissions that can 
be selectively extended from one person to another, to include some 
specified set of machine resources.

--me




From ffjeld at common-lisp.net  Tue Feb 10 01:31:54 2004
From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld)
Date: Tue, 10 Feb 2004 02:31:54 +0100
Subject: [movitz-devel] CMUCL success
Message-ID: <2hllnbvhx1.fsf@vserver.cs.uit.no>

I just wanted to report that with the latest CVS checkins I believe
Movitz basically runs under CMUCL (at least 18e which is the version
I've got).

The set of known lisp implementations that works with Movitz is now
Allegro, SBCL, and CMUCL.

The only implementation I've tried and not gotten to work is CLisp,
which core-dumps some time during the build process.

Note that there is in principle nothing that binds the Movitz
development environment to the x86 platform. Even for testing, bochs
can be used on most architectures and operating systems.

-- 
Frode Vatvedt Fjeld