From kragen@pobox.com Fri, 6 Mar 1998 15:26:42 -0500 (EST)
Date: Fri, 6 Mar 1998 15:26:42 -0500 (EST)
From: Kragen kragen@pobox.com
Subject: Symbolics dead again?
I heard a rumor from someone at a company that uses a lot of Symbolics
equipment that Symbolics is bankrupt again. He says they bought a bit
of equipment from them during their brief revival, but now they're not
even answering their phones when called for support.
But the web site is still up.
What's going on? I hope Symbolics is still alive.
Kragen
From pisati@nichimen.com Fri, 06 Mar 1998 12:58:57 -0800
Date: Fri, 06 Mar 1998 12:58:57 -0800
From: Luca Pisati pisati@nichimen.com
Subject: Symbolics dead again?
--------------9A23DE9FD0737DAF491809DF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Kragen wrote:
> I heard a rumor from someone at a company that uses a lot of Symbolics
> equipment that Symbolics is bankrupt again. He says they bought a bit
> of equipment from them during their brief revival, but now they're not
> even answering their phones when called for support.
>
> But the web site is still up.
>
> What's going on? I hope Symbolics is still alive.
>
> Kragen
Yes, they send an announcement on SLUG mailing list.
BTW: where's the web site ?
--
Luca Pisati
Manager of Graphics Software Voice: (310) 577-0518
Nichimen Graphics Fax: (310) 577-0577
12555 W. Jefferson #285 EMail: mailto:pisati@nichimen.com
Los Angeles, CA 90066 Web: http://www.nichimen.com
--------------9A23DE9FD0737DAF491809DF
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Kragen wrote:
I heard a rumor from someone at a company that uses
a lot of Symbolics
equipment that Symbolics is bankrupt again. He says they bought
a bit
of equipment from them during their brief revival, but now they're
not
even answering their phones when called for support.
But the web site is still up.
What's going on? I hope Symbolics is still alive.
Kragen
Yes, they send an announcement on SLUG mailing list.
BTW: where's the web site ?
--
Luca Pisati
Manager of Graphics Software Voice: (310) 577-0518
Nichimen Graphics Fax: (310) 577-0577
12555 W. Jefferson #285 EMail: mailto:pisati@nichimen.com
Los Angeles, CA 90066 Web: http://www.nichimen.com
--------------9A23DE9FD0737DAF491809DF--
From kragen@pobox.com Fri, 6 Mar 1998 16:09:31 -0500 (EST)
Date: Fri, 6 Mar 1998 16:09:31 -0500 (EST)
From: Kragen kragen@pobox.com
Subject: Symbolics dead again?
On Fri, 6 Mar 1998, Luca Pisati wrote:
> Kragen wrote:
> > I heard a rumor from someone at a company that uses a lot of Symbolics
> > equipment that Symbolics is bankrupt again.
>
> Yes, they send an announcement on SLUG mailing list.
>
> BTW: where's the web site ?
http://www.symbolics.com/ redirects you to the appropriate place.
Kragen
From cwg-dated-635361b7ee90998b@DeepEddy.Com Fri, 06 Mar 1998 15:12:08 -0600
Date: Fri, 06 Mar 1998 15:12:08 -0600
From: Chris Garrigues cwg-dated-635361b7ee90998b@DeepEddy.Com
Subject: Symbolics dead again?
--==_Exmh_1410900432P
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0"
Content-Id: <14957.889218727.0@DeepEddy.Com>
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <14957.889218727.1@DeepEddy.Com>
> From: kragen@pobox.com (Kragen)
> Date: Fri, 6 Mar 1998 15:26:42 -0500 (EST)
>
> I heard a rumor from someone at a company that uses a lot of Symbolics
> equipment that Symbolics is bankrupt again. He says they bought a bit
> of equipment from them during their brief revival, but now they're not
> even answering their phones when called for support.
>
> But the web site is still up.
>
> What's going on? I hope Symbolics is still alive.
Got this in the mail a few days ago:
------- =_aaaaaaaaaa0
Content-Type: message/rfc822
Content-ID: <14957.889218727.2@DeepEddy.Com>
Content-Description: forwarded message
>From cstacy@life.ai.mit.edu Tue Mar 03 20:19:17 1998
Return-Path:
Delivered-To: cwg-sortedlists-edu-mit-ai-life-cstacy@DeepEddy.Com
Received: (qmail 6570 invoked by uid 500); 3 Mar 1998 20:19:17 -0000
Delivered-To: cwg@DeepEddy.Com
Received: (qmail 6565 invoked by uid 0); 3 Mar 1998 20:19:15 -0000
Received: from life.ai.mit.edu (128.52.32.80)
by backstroke with SMTP; 3 Mar 1998 20:19:15 -0000
Received: from arl-img-9.compuserve.com (arl-img-9.compuserve.com [149.174.217.139])
by life.ai.mit.edu (8.8.8/AI1.22/ai.master.life:1.23) with ESMTP id PAA18763
for ; Tue, 3 Mar 1998 15:11:14 -0500 (EST)
Received: (from root@localhost)
by arl-img-9.compuserve.com (8.8.6/8.8.6/2.10) id PAA25510;
Tue, 3 Mar 1998 15:10:41 -0500 (EST)
Date: Tue, 3 Mar 1998 15:09:43 -0500
From: "David K. Schmidt"
Subject: Status of Symbolics
Sender: "David K. Schmidt"
To: Lisp User Group , SLUG mail ,
The Usual Suspects
Message-ID: <199803031510_MC2-3565-9BAB@compuserve.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
In January Symbolics laid off the last 3 employees. After 10 years with
Symbolics and two unsuccessful attempts to buy the assets, I am off to
other, yet to be determined, endeavors. My last year and a half as
President, CEO, CFO, Director of Sales and East Coast Customer Service
Engineer was without a doubt the most interesting. I want to thank all
those loyal Symbolics customers who helped keep the company going well pa=
st
its perdicted demise. =
In anticipation of a number of questions that people might have, I am
providing the following information.
The person or persons who made the successful offer to buy the Symbolics
assets are using a Boston law firm, Ropes and Gray (617-951-7000), to
handle the purchase. I have heard rumors that Andrew Topping is involve=
d
in the deal, but I have no information about him. I do not know what the=
ir
plans are and do not know whether they will offer hardware and/or softwa=
re
maintenance. =
The Symbolics phone numbers in Chatsworth, CA are still in operation, but=
no one is answering the phone and I am not sure whether anyone is checkin=
g
the messages.
Princeton Capital Finance Co. (PrinCap), the current owner of the Symboli=
cs
assets, told me they were shutting down their operation on Friday, 2/27. =
Their phone number (609-275-7100) is supposed to remain in service as a
voice mail box. I was told that Steve Gander had been tasked by ABN-AMRO=
Bank to hold Symbolics together until the purchase is closed. His curren=
t
E-mail address is gander@dinar.princap.com, but that will change after th=
ey
turn off the PrinCap computers in a month or so. The only mailing addres=
s
left for Symbolics is P.O. Box 389, Princeton Junction, NJ 80530
Ron Drake is the representative of ABN-AMRO Bank who is supervising the
shutdown of PrinCap. He appears to have significant influence over what
happens to the Symbolics assets and is directing Steve Gander on what he =
is
allowed to do for Symbolics maintenance customers. His number is
212-891-0621. This is the only number for the current owners where you
will get a live person at the other end of the phone.
Before I left, the second release of Open Genera for DEC Alpha workstatio=
ns
was ready to go out for CD duplication. Genera 8.5 for Ivory workstation=
s
was close to completion, but had a few bugs left to work out. I do not
know what the future of these two products will be.
For those people with hardware problems while Symbolics is in a state of
limbo, I will be happy to try to assist you in any way I can. If you need=
help or have other questions, please feel free to contact me by E-mail at=
dkschmidt@compuserve.com or by phone at 703-455-0430.
DAVID K. SCHMIDT
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <14957.889218727.3@DeepEddy.Com>
--
Chris Garrigues Deep Eddy Internet Consulting
+1 512 432 4046 609 Deep Eddy Avenue O-
http://www.DeepEddy.Com/~cwg/ Austin, TX 78703-4513
My email address is an experiment in SPAM elimination:
If it starts with cwg-dated..., it is *only* valid for 2 weeks.
If it starts with cwg-sender..., *only* the person the message was
intended for can reply to it.
------- =_aaaaaaaaaa0--
--==_Exmh_1410900432P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQB1AwUBNQBmqJaQnaaFII2dAQGgOwMAoL2x2UvF0Zgcks4Mkr+0kkg4UqElz2IK
OFHUEaZZCeZQDO2pOjs9lNBTiifPXBUIq6/3KCsEs14rL2oy34Hmij9y0rdy8G61
yw/u8WJE9kV027VH9Ys+TQH0IMjtxPRx
=OcJ2
-----END PGP MESSAGE-----
--==_Exmh_1410900432P--
From pisati@nichimen.com Fri, 06 Mar 1998 13:19:44 -0800
Date: Fri, 06 Mar 1998 13:19:44 -0800
From: Luca Pisati pisati@nichimen.com
Subject: [Fwd: Status of Symbolics]
This is a multi-part message in MIME format.
--------------69EAC96ADCE99C51A1F92653
Content-Type: multipart/alternative; boundary="------------18718F350A4297E914C568C5"
--------------18718F350A4297E914C568C5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Here's the announcement:
--
Luca Pisati
Manager of Graphics Software Voice: (310) 577-0518
Nichimen Graphics Fax: (310) 577-0577
12555 W. Jefferson #285 EMail: mailto:pisati@nichimen.com
Los Angeles, CA 90066 Web: http://www.nichimen.com
--------------18718F350A4297E914C568C5
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Here's the announcement:
--
Luca Pisati
Manager of Graphics Software Voice: (310) 577-0518
Nichimen Graphics Fax: (310) 577-0577
12555 W. Jefferson #285 EMail: mailto:pisati@nichimen.com
Los Angeles, CA 90066 Web: http://www.nichimen.com
--------------18718F350A4297E914C568C5--
--------------69EAC96ADCE99C51A1F92653
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Return-Path:
Received: from marina.nichimen.com by biscayne.nichimen.com (4.1/SMI-4.1)
id AA29046; Tue, 3 Mar 98 13:32:56 PST
Received: from Sunset.AI.SRI.COM (Sunset.AI.SRI.COM [128.18.61.76]) by marina.nichimen.com (8.6.9/8.6.9) with ESMTP id NAA27425 for ; Tue, 3 Mar 1998 13:30:19 -0800
Received: by Sunset.AI.SRI.COM (8.8.7/SMI-4.1)
id MAA25159 for slug-internal; Tue, 3 Mar 1998 12:12:17 -0800 (PST)
Received: from arl-img-9.compuserve.com by Sunset.AI.SRI.COM (8.8.7/SMI-4.1)
id MAA25150 for ; Tue, 3 Mar 1998 12:12:09 -0800 (PST)
Received: (from root@localhost)
by arl-img-9.compuserve.com (8.8.6/8.8.6/2.10) id PAA25510;
Tue, 3 Mar 1998 15:10:41 -0500 (EST)
Date: Tue, 3 Mar 1998 15:09:43 -0500
From: "David K. Schmidt"
Subject: Status of Symbolics
Sender: "David K. Schmidt"
To: Lisp User Group , SLUG mail ,
The Usual Suspects
Message-Id: <199803031510_MC2-3565-9BAB@compuserve.com>
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
In January Symbolics laid off the last 3 employees. After 10 years with
Symbolics and two unsuccessful attempts to buy the assets, I am off to
other, yet to be determined, endeavors. My last year and a half as
President, CEO, CFO, Director of Sales and East Coast Customer Service
Engineer was without a doubt the most interesting. I want to thank all
those loyal Symbolics customers who helped keep the company going well pa=
st
its perdicted demise. =
In anticipation of a number of questions that people might have, I am
providing the following information.
The person or persons who made the successful offer to buy the Symbolics
assets are using a Boston law firm, Ropes and Gray (617-951-7000), to
handle the purchase. I have heard rumors that Andrew Topping is involve=
d
in the deal, but I have no information about him. I do not know what the=
ir
plans are and do not know whether they will offer hardware and/or softwa=
re
maintenance. =
The Symbolics phone numbers in Chatsworth, CA are still in operation, but=
no one is answering the phone and I am not sure whether anyone is checkin=
g
the messages.
Princeton Capital Finance Co. (PrinCap), the current owner of the Symboli=
cs
assets, told me they were shutting down their operation on Friday, 2/27. =
Their phone number (609-275-7100) is supposed to remain in service as a
voice mail box. I was told that Steve Gander had been tasked by ABN-AMRO=
Bank to hold Symbolics together until the purchase is closed. His curren=
t
E-mail address is gander@dinar.princap.com, but that will change after th=
ey
turn off the PrinCap computers in a month or so. The only mailing addres=
s
left for Symbolics is P.O. Box 389, Princeton Junction, NJ 80530
Ron Drake is the representative of ABN-AMRO Bank who is supervising the
shutdown of PrinCap. He appears to have significant influence over what
happens to the Symbolics assets and is directing Steve Gander on what he =
is
allowed to do for Symbolics maintenance customers. His number is
212-891-0621. This is the only number for the current owners where you
will get a live person at the other end of the phone.
Before I left, the second release of Open Genera for DEC Alpha workstatio=
ns
was ready to go out for CD duplication. Genera 8.5 for Ivory workstation=
s
was close to completion, but had a few bugs left to work out. I do not
know what the future of these two products will be.
For those people with hardware problems while Symbolics is in a state of
limbo, I will be happy to try to assist you in any way I can. If you need=
help or have other questions, please feel free to contact me by E-mail at=
dkschmidt@compuserve.com or by phone at 703-455-0430.
DAVID K. SCHMIDT
--------------69EAC96ADCE99C51A1F92653--
From joswig@lavielle.com Fri, 6 Mar 1998 22:20:49 +0100
Date: Fri, 6 Mar 1998 22:20:49 +0100
From: Rainer Joswig joswig@lavielle.com
Subject: Symbolics dead again?
At 12:58 Uhr -0800 06.03.1998, Luca Pisati wrote:
> Kragen wrote:
>
>I heard a rumor from someone at a company that uses a lot of Symbolics
>equipment that Symbolics is bankrupt again. He says they bought a bit
>of equipment from them during their brief revival, but now they're not
>even answering their phones when called for support.
>
>But the web site is still up.
>
>What's going on? I hope Symbolics is still alive.
>
>Kragen
>
> Yes, they send an announcement on SLUG mailing list.
Let's hope that there will be another future.
>
>BTW: where's the web site ? --
www.symbolics.com
Rainer Joswig, Lavielle EDV Systemberatung GmbH & Co, Lotharstrasse 2b,
D22041
Hamburg, Tel: +49 40 658088, Fax: +49 40 65808-202,
Email: joswig@lavielle.com , WWW: http://www.lavielle.com/~joswig/
From dmason@scs.Ryerson.CA Sun, 8 Mar 1998 12:07:28 -0500
Date: Sun, 8 Mar 1998 12:07:28 -0500
From: Dave Mason dmason@scs.Ryerson.CA
Subject: Symbolics dead again?
Kragen writes:
> > > http://www.symbolics.com/ redirects you to the appropriate place.
> Me either, now. They must have turned it off today.
Worked for me, just now: Sunday 12:06
../Dave
From ChrisB@ThePla.net Mon, 09 Mar 1998 06:32:01 +1100
Date: Mon, 09 Mar 1998 06:32:01 +1100
From: Chris Bitmead ChrisB@ThePla.net
Subject: Symbolics dead again?
> What's going on? I hope Symbolics is still alive.
Does it matter if Symbolics is dead, since we still have
Microsoft Windows?? :-(
Seriously, I keep wondering how long it is going to take the
software industry to catch up to where Symbolics was many years
ago.
So has anybody out there done anything since this mailing list
was started?
--
Chris Bitmead
http://www.thepla.net/~chrisb
From ChrisB@Ans.Com.Au Mon, 09 Mar 1998 16:11:34 +1100
Date: Mon, 09 Mar 1998 16:11:34 +1100
From: Chris Bitmead ChrisB@Ans.Com.Au
Subject: (no subject)
subscribe lispos
From tf@another.gun.de Mon, 9 Mar 1998 09:54:40 +0100
Date: Mon, 9 Mar 1998 09:54:40 +0100
From: Thomas Fischbacher tf@another.gun.de
Subject: Symbolics dead again?
On 08.03.1998 [19:32:01] [lispos-request@math.gatech.edu] wrote the following lines about
"Re: Symbolics dead again?"
> So has anybody out there done anything since this mailing list
> was started?
Yes, I'd say so. I currently have:
* Some extensions for GCL for rudimentary libX11 and libXpm support,
MUD-style TCP/IP servers as well as an implementation of what
is called open3() in perl.
* A portable C library interface in the form of a bunch of macros
that expand to the corresponding interfacing mechanisms of
different LISPs. (Currently supported: CMU CL / Linux and ACL / Linux)
* Some networking functions on top of this. (I didn't touch that for
quite some time and it's still quite buggy -- getsockopt() was the
last function I implemented.)
* More or less 1:1 interfaces to libX11 functions for my LISP->C package
(Why this if there is CLX? Simple answer: libraries like libGL want
libX11 structures.)
* Rudimentary OpenGL support, also on top of my LISP->C interface.
(The main problem here is to provide a more usable interface to
GLX functionality than GLX itself. I've written a minimal test
function that displays a lighted octahedron which can be rotated
by pressing a mouse button. The fine thing is that the very same code
works with ACL and CMUCL.)
* A small function showing how lesstif could be used from within LISP.
* Fast-fourier transformations (1d, 2d, 3d -- written last week).
Most of that stuff still is in quite an early stage; there are still
some bugs to be fixed, documentation is virtually nonexistent, and
there are still many opportunities for performance improvements.
However, if anyone wants to help me with one of those projects,
feel free to send me a short message. :-)
--
regards, Thomas Fischbacher - tf@another.gun.de
tf@physik.tu-muenchen.de
From crippenj@saturn.math.uaa.alaska.edu Mon, 16 Mar 1998 19:18:55 -0900 (AKST)
Date: Mon, 16 Mar 1998 19:18:55 -0900 (AKST)
From: James A. Crippen crippenj@saturn.math.uaa.alaska.edu
Subject: SchemeOS
I've been planning the "SchemeOS", a unix-compatible OS based around the
Flux toolkit and scsh, the SCheme SHell. It looks fairly promising, but I
haven't started coding anything yet. I like the idea of scheme somewhat
better than Lisp because it's smaller, easier to implement, and scsh has a
fairly complete POSIX-compatible set of system calls.
Here's the url for scsh:
http://www-swiss.ai.mit.edu/scsh/scsh.html
Need more people than just me, though, so think about it, mail me with
your thoughts.
cheers,
james
--
James A. Crippen, CS/Math tenured undergrad <> \
If the future isn't what it used to be, does that mean that the past /\
is subject to change in times to come? / \
From cmh@greendragon.com Wed, 18 Mar 1998 03:31:32 -0600
Date: Wed, 18 Mar 1998 03:31:32 -0600
From: Chris Hanson cmh@greendragon.com
Subject: Minimum set of primitives?
What set of primitives would absolutely need to be supported for a sort of
"proto-Lisp", which could be used as an implementation language for a more
full-featured Lisp (for example, Scheme)?
I remember something about there being seven primitives...
From andrey@custis.dol.ru Wed, 18 Mar 1998 13:20:01 +0300
Date: Wed, 18 Mar 1998 13:20:01 +0300
From: Andrey Taranov andrey@custis.dol.ru
Subject: Minimum set of primitives?
Hello all
Chris Hanson wrote:
> What set of primitives would absolutely need to be supported for a sort of
> "proto-Lisp", which could be used as an implementation language for a more
> full-featured Lisp (for example, Scheme)?
>
> I remember something about there being seven primitives...
That's a rather theoretical question, I suppose. If we should ever use
such an approach, then we'd better look at something practical of the
same flavour. As a good ("good" is my private opinion) example of such a
thing you can look at the design of Scheme48. It is bootstrapped from
scratch using a special subset of Scheme (not a subset strictly, because
it is tailored in some way to be easily translated into C).
WBR,
Andrey Taranov
From dmason@scs.Ryerson.CA Wed, 18 Mar 1998 08:00:04 -0500
Date: Wed, 18 Mar 1998 08:00:04 -0500
From: Dave Mason dmason@scs.Ryerson.CA
Subject: Minimum set of primitives?
Chris Hanson wrote:
> I remember something about there being seven primitives...
In terms of special forms (syntax), all of Scheme is syntactic sugar for:
lambda, a conditional (case is my preference), set!, quote
To create any definitions, you will have to add define. And if you
want to be able to define the rest of the syntax using macros, you'll
need define-macro (or equivalently, a function that returns a value
that define recognizes as a macro). Some scheme compilers (including
Steele's Rabbit, and my work) convert everything into this subset and
then optimize the bejezuz out of it.
In terms of primitive functions, there are probably at least 30, even
if you were being rigidly minimalist (for very little benefit, I
think).
A minimum set:
eq? = < + - * / quotient car cdr cons truncate set-car! set-cdr!
inexact->exact (and other transformers)
string functions (or a way to get inside a string)
vector functions (at least a minimal subset of them)
pair? list? number? procedure? (you could define most predicates in
terms of a get-tag, or some-such, function)
some more that I'm probably forgetting.
../Dave
From davies@pobox.com Wed, 18 Mar 1998 07:31:55 -0700
Date: Wed, 18 Mar 1998 07:31:55 -0700
From: Byron Davies davies@pobox.com
Subject: Minimum set of primitives?
It would be hard to do without I/O and the ability to create primitive,
efficient representations, such as for numbers.
Byron
>Chris Hanson wrote:
>> I remember something about there being seven primitives...
>
>In terms of special forms (syntax), all of Scheme is syntactic sugar for:
> lambda, a conditional (case is my preference), set!, quote
>
>To create any definitions, you will have to add define. And if you
>want to be able to define the rest of the syntax using macros, you'll
>need define-macro (or equivalently, a function that returns a value
>that define recognizes as a macro). Some scheme compilers (including
>Steele's Rabbit, and my work) convert everything into this subset and
>then optimize the bejezuz out of it.
>
>In terms of primitive functions, there are probably at least 30, even
>if you were being rigidly minimalist (for very little benefit, I
>think).
>
>A minimum set:
> eq? = < + - * / quotient car cdr cons truncate set-car! set-cdr!
> inexact->exact (and other transformers)
> string functions (or a way to get inside a string)
> vector functions (at least a minimal subset of them)
> pair? list? number? procedure? (you could define most predicates in
> terms of a get-tag, or some-such, function)
> some more that I'm probably forgetting.
>
>../Dave
From yoda@isr.ist.utl.pt Wed, 18 Mar 1998 16:22:06 +0100 (GMT+0100)
Date: Wed, 18 Mar 1998 16:22:06 +0100 (GMT+0100)
From: Rodrigo Ventura yoda@isr.ist.utl.pt
Subject: Minimum set of primitives?
>>>>> "Chris" == Chris Hanson writes:
Chris> What set of primitives would absolutely need to be supported for a sort of
Chris> "proto-Lisp", which could be used as an implementation language for a more
Chris> full-featured Lisp (for example, Scheme)?
From the theoretical point of view, one can go as low as a
Turing machine, and assert that a Turing machine can implement any
language (in fact, any computable function).
The question here is different. I believe there are several
sets of primitives on top of which any lisp-like language can be
implemented. For instance, you can implement an "if" construct using a
"case", or a "case" using "if"'s. Of course some sets must be smaller
than others, but our concern here also includes efficiency. The
minimal set may not be the most efficient one. Of course it isn't. But
we are not interested in a very complex set of primitives. It seems to
me that the pre-scheme, on top of which scheme48 is implemented, is
too complex to be easly used to build more complex languages.
Simplicity and efficiency are the two main concerns here,
IMHO. The resulting set may not be minimal in a strict sense.
Regards,
--
--
*** Rodrigo Martins de Matos Ventura, alias
*** yoda@isr.ist.utl.pt, http://www.isr.ist.utl.pt/~yoda
*** Instituto de Sistemas e Robotica, Polo de Lisboa
*** Instituto Superior Tecnico, Lisboa, Portugal
*** PGP Public Key available on my homepage
*** Key fingerprint = 0C 0A 25 58 46 CF 14 99 CF 9C AF 9E 10 02 BB 2A
From kragen@pobox.com Wed, 18 Mar 1998 12:40:38 -0500 (EST)
Date: Wed, 18 Mar 1998 12:40:38 -0500 (EST)
From: Kragen kragen@pobox.com
Subject: Minimum set of primitives?
On Wed, 18 Mar 1998, Rodrigo Ventura wrote:
> >>>>> "Chris" == Chris Hanson writes:
>
> Chris> What set of primitives would absolutely need to be supported for a sort of
> Chris> "proto-Lisp", which could be used as an implementation language for a more
> Chris> full-featured Lisp (for example, Scheme)?
>
> From the theoretical point of view, one can go as low as a
> Turing machine, and assert that a Turing machine can implement any
> language (in fact, any computable function).
The lambda calculus is equivalent to a Turing machine, and it's a lot
easier to use in Lisp :)
The theoretical point of view is not very useful. Here's an
example of why:
If you have lambda, cons, car, cdr, some conditional (cond, if, what
have you) and null?, (oh, and some way of defining a function -- I'll use the
Scheme `define', with a single cell for either function or value) you
can implement arithmetic:
; Base-1 arithmetic with the lambda calculus. Uses only cons, car, cdr,
; if, null? and define. Uses quote for the restricted purpose of quoting
; the empty list.
; Kragen Sitaker, 1998-03-18
(define nil '())
(define #f (null? (cons nil nil)))
(define #t (null? nil))
(define zero nil)
(define incr (lambda (x) (cons nil x)))
(define decr (lambda (x) (cdr x)))
(define zero? (lambda (x) (null? x))
(define plus
(lambda (a b)
(if (zero? a) b
(plus (decr a) (incr b)))))
; doesn't work if b>a; applies cdr to (). The result of this
; depends on your Lisp/Scheme system. It's OK in Lisp (returns nil,
; which means the result is zero if b>a; Scheme forbids it. Most
; Scheme implementations will probably do the same as Lisp.
; SIOD does.
(define minus
(lambda (a b)
(if (zero? b) a
(minus (decr a) (decr b)))))
(define arith-equal?
(lambda (a b)
(if (zero? a) (zero? b)
(if (zero? b) #f
(arith-equal? (decr a) (decr b))))))
(define not (lambda (a) (if a #f #t))
(define arith-greater?
(lambda (a b)
(if (zero? a) #f
(if (zero? b) (not (zero? a))
(arith-greater? (decr a) (decr b))))))
(define arith-less?
(lambda (a b) (arith-greater? b a))
(define multiply
(lambda (a b)
(if (zero? a) zero
(plus b (multiply (decr a) b)))))
etc.
> Of course some sets must be smaller
> than others, but our concern here also includes efficiency. The
> minimal set may not be the most efficient one. Of course it isn't.
Agreed! Would you really want to use a Lisp that implemented arithmetic
like the above? Probably not, for two reasons:
1. It's a lot slower than the native machine methods to do the same thing.
2. Its slowness grows as the numbers get bigger. It would be better to
use base-2 or something.
#1 is a little disturbing. It implies that the "minimal" set depends
on the machine you're using. If your machine is an i386, it has
instructions to do BCD arithmetic, for example. Assuming some users of
your Lisp have a use for BCD arithmetic, you really ought to provide
them with access to the underlying machine's BCD arithmetic
capabilities, instead of forcing them to implement their own in Lisp.
(Not many people use BCD arithmetic these days, of course, but there may
be other features of your processor that you need to find some way of
exposing for efficiency: double-length multiply results and dividends,
carry flags for multiple-precision arithmetic, vector instructions,
quick multiplies and divides by powers of two, etc. There may even be
features you need to find some way of exposing for expressiveness, such
as SMP inter-processor synchronization facilities.)
#2 is simply an accident of the particular simple example above, and is not
really important for the larger discussion.
OK, enough pontificating for now :)
Kragen
From lynbech@daimi.aau.dk Thu, 19 Mar 1998 09:16:05 +0100 (CET)
Date: Thu, 19 Mar 1998 09:16:05 +0100 (CET)
From: Christian Lynbech on satellite lynbech@daimi.aau.dk
Subject: Minimum set of primitives?
I am not all together convinced that we (that is in the context of a
lisp OS) should think about primitives such as define or case/if. In
my vision, the lisp OS should provide more basic services allowing
easy and efficient porting of *existing* implementations. Since CMUCL
or GUILE Scheme already has done efficient implementations of all
this, I see no reason to reimplement it.
So what do I mean by "basic services"? Well, this is of course common
infrastructure such as a filesystem, other I/O and memory
management. The main challenge here would be to lay out a system that
would be usefull to (and thus allow the integration of) several
different implementations of different kinds of lisps.
One good example will be memory management. Today, (UNIX)
implementations simply requests chunks of memory and implement their
own memory management. But the Truly Cool Lispos (TM) would provide a
basic set of types (such as `cell', `integer', `float' and `string')
and allow an environment to request for instance a single cons
cell. All management (including GC) would remain the responsibility of
the OS.
Taking any one lisp implementation, combine it with the Fluke kit, and
hack up the missing parts would probably be a rather easy road to
soemthing that could boot a machine up into lisp, but to me, the real
promise of a lisp *OS* would be the ability to *integrate* wildly
different implementations into one coherent working environment.
Perhaps I am just dreaming :-)
---------------------------+--------------------------------------------------
Christian Lynbech | Telebit Communications A/S
| Fabrikvej 11, DK-8260 Viby J
Phone: +45 8628 8176 | email: chl@tbit.dk --- URL: http://www.tbit.dk
---------------------------+--------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- petonic@hal.com (Michael A. Petonic)
From crippenj@saturn.math.uaa.alaska.edu Thu, 19 Mar 1998 04:24:00 -0900 (AKST)
Date: Thu, 19 Mar 1998 04:24:00 -0900 (AKST)
From: James A. Crippen crippenj@saturn.math.uaa.alaska.edu
Subject: Minimum set of primitives?
I was just thinking, one of the best places to see what a minimum set of
primitives needed for a scheme/lispish language is the end of R4RS, in the
semantic definitions. It's a bit hard if you don't understand the
symbology, but get past that and you'll see the outline for the entire
language is based off of several simple primitives, the rest are all
syntactic extensions. It's very comprehensive. Go read the R4RS.
cheers,
james
--
James A. Crippen, CS/Math tenured undergrad <> \
If the future isn't what it used to be, does that mean that the past /\
is subject to change in times to come? / \
From chrisb@ans.com.au Thu, 19 Mar 1998 14:08:06 +0000
Date: Thu, 19 Mar 1998 14:08:06 +0000
From: Chris Bitmead chrisb@ans.com.au
Subject: Minimum set of primitives?
Christian Lynbech on satellite wrote:
> So what do I mean by "basic services"? Well, this is of course common
> infrastructure such as a filesystem, other I/O and memory
> management.
I personally want to see a Lisp OS without a filesystem. Every
object that is created is part of the permanent state of the
universe. You want to store something? Don't bother. It's stored
already.
Maybe behind the scenes it is implemented as an object database.
--
Chris Bitmead
http://www.ans.com.au/~chrisb
mailto:chrisb@ans.com.au
From kragen@pobox.com Thu, 19 Mar 1998 09:14:47 -0500 (EST)
Date: Thu, 19 Mar 1998 09:14:47 -0500 (EST)
From: Kragen kragen@pobox.com
Subject: Minimum set of primitives?
On Thu, 19 Mar 1998, Christian Lynbech on satellite wrote:
> I am not all together convinced that we (that is in the context of a
> lisp OS) should think about primitives such as define or case/if. In
> my vision, the lisp OS should provide more basic services allowing
> easy and efficient porting of *existing* implementations. Since CMUCL
> or GUILE Scheme already has done efficient implementations of all
> this, I see no reason to reimplement it.
I like your idea.
> So what do I mean by "basic services"? Well, this is of course common
> infrastructure such as a filesystem, other I/O and memory
> management.
I'm not convinced that a filesystem is necessary. If, instead, the OS
simply lets you map disk into memory, periodically saving the entire contents
of virtual memory, that would be sufficient, efficient, and much more
flexible. KeyKOS worked this way.
The question is, basically, what should we put in the kernel? We
should put in things that it is useful to share between different
programs. Memory management with garbage collection is obviously a big
win to share between programs -- it lets you do IPC by simply passing a
single pointer, and lets you do security by running threads in barren
environments. Preemptive multithreading is obviously a big win -- it's
necessary to make sure that one endless loop can't lock up the system.
Secure multiplexing of I/O is a big win -- it means that your programs can
access I/O devices without being worried that other threads will be accessing
those devices at the same time.
What else is needed? Anything? What else would be much more useful in the
kernel than anywhere else?
> Taking any one lisp implementation, combine it with the Fluke kit,
I'm afraid I don't know what the Fluke kit is. Is this a FAQ?
> and hack up the missing parts would probably be a rather easy road to
> soemthing that could boot a machine up into lisp, but to me, the real
> promise of a lisp *OS* would be the ability to *integrate* wildly
> different implementations into one coherent working environment.
That would be nice.
It might not even be necessary, though. The primary usefulness of a
particular implementation of Lisp is that certain Lisp programs run
happily on it. If we were to build a Lisp OS that was flexible enough,
we could easily implement different flavors of Lisp on top of it.
What are other people's thoughts on the work involved with each approach?
Kragen
From chrisb@ans.com.au Thu, 19 Mar 1998 15:00:33 +0000
Date: Thu, 19 Mar 1998 15:00:33 +0000
From: Chris Bitmead chrisb@ans.com.au
Subject: Minimum set of primitives?
> What else is needed? Anything? What else would be much more useful in the
> kernel than anywhere else?
Is it useful to think in terms of "in the kernel" and "out of the
kernel" ?
--
Chris Bitmead
http://www.ans.com.au/~chrisb
mailto:chrisb@ans.com.au
From ggleason@tvi.cc.nm.us Thu, 19 Mar 1998 16:09:28 +0100
Date: Thu, 19 Mar 1998 16:09:28 +0100
From: Gavin E. Gleason ggleason@tvi.cc.nm.us
Subject: Benevolent Dictatorship
>On a purely social level, I think that any project trying to design an
>operating systems from scratch over the Internet is likely to fail.
>Copying an OS is simple: you know what you are trying to achieve and you
>just argue about the ways to achieve it. Designing one is probably next
>to impossible, unless the group has a "benevolent dictator" that just
>says: "decision made, move on to the next question." Even so, the
>dictator's view of the "perfect operating system" will probably turn off
>hundreds of potential volunteers. It is much better to clone something
>that someone else has already designed (as in Linux).
> Paul Prescod - http://itrc.uwaterloo.ca/~papresco
Well that certainly is encouraging! :)
You do have a point though. There is no current precedent for
a project such as this. The thing that comes closest is probably the
GNU HURD (which has taken a decade to become a useable system). Even
then there is a formal organization that is supporting it. I suppose
even Mnemonic (the web browser project) might be classified in this
"novel" internet project catagory.
Maybe that means that we must also take a radical approach to
the way in which we co-ordinate our project. From what I've seen so
far there is not a massive divergence in ideas about "what" should be in
the lisp OS. Most of the divergence is in the "how".
We will need some way of deciding how to procede given
disagreement as to the next step if we cannot agree unanimously. I
think that it is possible that the need/want for a lisp OS will
supercede our ideas about the "best" way to proceed. Maybe we should
use some sort of parlimentary procedure, and have an elected
chairman. We could put motions on the table as to the steps as they
become pertinent. Then we could vote as to which would be the best
way to continue. I don't think that a dictatorship is any more
neccassary in this project then it is in any government.
It seems to me that this would be a rational approach to the
problem. Of course all of this may be uneccassary if we can all
agree. But I have a feeling that the initial stages may be the most
difficult to agree opon.
I have some suggestions as to the "hard" problems that need to
be decided. They are as follows:
1. scheme or lisp. Yikes! Thats a dangerous one :). I don't
personally care either way. Scheme is definitely cleaner, and it
would seem ideal as a starting point for a clean and radically
different OS. Lisp on the other hand has everything already built
into the language. I'll lean whatever way seems most popular in the
interest of getting this show on the road.
2. Bootstraping. This is a particularly difficult question,
as the FLUX OS toolkit is unavailable. I think that we should open the
table for motions on options in this catagory
3. Abstractions. Finding the most basic level of abstractions
that we intend to provide in our system will be difficult because we
will have to come up with a ideas that will be useful in practice.
This will probably be a dynamic variable that changes as coding and
practical issues arise, but we should at least have some idea of where
we are going.
There are certainly more, but I think that these questions
should be resolved first. Unless someone can think of problems of a
more pressing nature. :)
Gavin E. Gleason
From kragen@pobox.com Thu, 19 Mar 1998 10:35:18 -0500 (EST)
Date: Thu, 19 Mar 1998 10:35:18 -0500 (EST)
From: Kragen kragen@pobox.com
Subject: Minimum set of primitives?
On Thu, 19 Mar 1998, Chris Bitmead wrote:
> > What else is needed? Anything? What else would be much more useful in the
> > kernel than anywhere else?
>
> Is it useful to think in terms of "in the kernel" and "out of the
> kernel" ?
Well, in some cases.
For example, if we want to implement system-wide garbage collection, we
have to guarantee that, at some level of granularity, all pointers
between objects are known to the garbage collector. The easiest way to
handle this on a fine granularity (the usual Lisp way) is to make data
types `holy' and inviolable -- only special kernel code has the right
to do pointer arithmetic, for instance, and no userland programs.
Ideally, we could get away from this evil distinction between
kernelland and userland. I don't know how, though. All I've ever seen
is moving the barrier around and changing the granularity -- on a Lisp
machine, if I understand correctly, the `kernel' was the hardware
itself, which made sure pointers weren't stored as integers and vice
versa, and did bounds-checking on arrays. (Is this correct?)
When something is `in the kernel', it is something user programs cannot
avoid using in some circumstances. Access to I/O and to memory are two
examples.
Kragen
From yoda@isr.ist.utl.pt Thu, 19 Mar 1998 18:09:20 +0100 (GMT+0100)
Date: Thu, 19 Mar 1998 18:09:20 +0100 (GMT+0100)
From: Rodrigo Ventura yoda@isr.ist.utl.pt
Subject: Minimum set of primitives?
forget theoretica questions at this level, because here resides the
bottleneck of the whole system.
A LISP virtual machine is thus needed, nothing new here. I
think that there must be two sub-sets of primitives: a sub-set of
near-direct assembly machine instructions, like adding, multiplying,
bit-manipulation, memory addressing, I/O, etc. I guess that it is
unavoidable to do something like a JIT compiler. LispOS can not rely
on a interpreted VM. The second sub-set contains all higher level
functions, like GC, memory management, persistence of LISP objects,
etc. These must be implemented as sub-rotine calls.
BTW, I liked the idea of banning the filesystem. It's sort of
using the physical memory as a huge cache to lisp objects all residing
in disk. Of course a much more complex package system (or namespace)
must be created, to incorporate all flexibility current filesystems
support.
Regards,
--
--
*** Rodrigo Martins de Matos Ventura, alias
*** yoda@isr.ist.utl.pt, http://www.isr.ist.utl.pt/~yoda
*** Instituto de Sistemas e Robotica, Polo de Lisboa
*** Instituto Superior Tecnico, Lisboa, Portugal
*** PGP Public Key available on my homepage
*** Key fingerprint = 0C 0A 25 58 46 CF 14 99 CF 9C AF 9E 10 02 BB 2A
From yoda@isr.ist.utl.pt Thu, 19 Mar 1998 19:22:53 +0100 (GMT+0100)
Date: Thu, 19 Mar 1998 19:22:53 +0100 (GMT+0100)
From: Rodrigo Ventura yoda@isr.ist.utl.pt
Subject: Minimum set of primitives?
>>>>> "Kragen" == Kragen writes:
Kragen> - nonvolatile media can be removed and moved to another machine. It's
Kragen> useful if they can be read on that other machine. This means being
Kragen> careful about cross-device links. This is especially useful in the
Kragen> case of floppy disks, Zip disks, Jaz drives, etc., but even ordinary
Kragen> hard drives are important.
Hum, that gives rise to a non-trivial question: how to handle
references, gc and removable media in an hybrid memory/disk system? I
mean, what happens if referenced objects are lost? How "ls -la" things
would work on such a system?
Regards,
--
--
*** Rodrigo Martins de Matos Ventura, alias
*** yoda@isr.ist.utl.pt, http://www.isr.ist.utl.pt/~yoda
*** Instituto de Sistemas e Robotica, Polo de Lisboa
*** Instituto Superior Tecnico, Lisboa, Portugal
*** PGP Public Key available on my homepage
*** Key fingerprint = 0C 0A 25 58 46 CF 14 99 CF 9C AF 9E 10 02 BB 2A
From kragen@pobox.com Thu, 19 Mar 1998 14:00:12 -0500 (EST)
Date: Thu, 19 Mar 1998 14:00:12 -0500 (EST)
From: Kragen kragen@pobox.com
Subject: Minimum set of primitives?
On Thu, 19 Mar 1998, Rodrigo Ventura wrote:
> BTW, I liked the idea of banning the filesystem. It's sort of
> using the physical memory as a huge cache to lisp objects all residing
> in disk. Of course a much more complex package system (or namespace)
> must be created, to incorporate all flexibility current filesystems
> support.
I don't think that's really necessary. All you need is a single kind
of obarray that maps atoms to objects; some of the objects can be
obarrays. This gives you all the flexibility of the Unix filesystem,
and comsiderably more, as well, and you need to implement *some* kind
of obarray anyway, in order to be able to run any programs.
The use-physical-memory-as-a-huge-cache idea is quite common in
self-hosted Lisp systems. It's called a `single-level store'. KeyKOS
also does this.
By the way, it is useful (especially with RAID systems, especially with
RAID4, and especially with the large read caches that are becoming
increasingly common) to make the mapping of virtual memory to disk
blocks rather dynamic. This way, a particular piece of data may be
stored in more than one place on the disk, which allows for atomic
checkpointing -- first, write all the dirty pages, then, point the
'latest-checkpoint' pointer at the new checkpoing. Also, this improves
disk performance by an order of magnitude.
Some things that mar the beautiful abstraction:
- nonvolatile media can be removed and moved to another machine. It's
useful if they can be read on that other machine. This means being
careful about cross-device links. This is especially useful in the
case of floppy disks, Zip disks, Jaz drives, etc., but even ordinary
hard drives are important.
- garbage collection requires some care if it is to be efficient.
- nonvolatile media sometimes fail. It is useful if one disk failing doesn't
make the data on the rest useless. This is connected with the removability
property.
- some applications require durability -- that is, once they receive and
acknowledge a piece of data, they're expected not to lose it, even if the
machine gets unplugged immediately. The need for this is obviously
strongest in the case of business applications, but it's nice even for
personal-use applications. This means that applications have to have
some control over when their data gets written to disk.
I'm not familiar with how historical Lisp systems or KeyKOS handled
these problems, but I suspect they are solved problems. Perhaps my elders
here can point us at some documentation.
(Well, KeyKOS handles the last one by offering a 'journal page' system call,
which forces a page to be written to disk immediately. Database servers can
force a write on the page containing their latest log entry after each time
they make a log entry. I'm not clear on how a Lisp system could handle this.)
Kragen
From espinosa@kestrel.edu Thu, 19 Mar 1998 11:11:25 -0800
Date: Thu, 19 Mar 1998 11:11:25 -0800
From: David Espinosa espinosa@kestrel.edu
Subject: kernel
Date: Thu, 19 Mar 1998 15:00:33 +0000
From: Chris Bitmead
> What else is needed? Anything? What else would be much more useful in the
> kernel than anywhere else?
Is it useful to think in terms of "in the kernel" and "out of the
kernel" ?
Great question. And what do these terms really mean? It seems that
security is the fundamental issue, and most OS researchers still
assume that security has to be based on a (standard kind of) kernel.
David
From kragen@pobox.com Thu, 19 Mar 1998 14:58:17 -0500 (EST)
Date: Thu, 19 Mar 1998 14:58:17 -0500 (EST)
From: Kragen kragen@pobox.com
Subject: Minimum set of primitives?
On Thu, 19 Mar 1998, Rodrigo Ventura wrote:
> Hum, that gives rise to a non-trivial question: how to handle
> references, gc and removable media in an hybrid memory/disk system? I
> mean, what happens if referenced objects are lost?
That's hard -- I'm looking forward to seeing if the Symbolics people
know the answer. I'm sure they've spent a lot of time thinking about
this problem.
> How "ls -la" things
> would work on such a system?
Oh, that's easy.
(obarray-names cwd) does ls -a.
(mapcar
(lambda (name)
(cons (typeof (obarray-lookup name cwd)) (cons name nil)))
(obarray-names cwd) )
is sort of similar to ls -la, assuming that `typeof' returns some sort of
information about the object, e.g. "string 120885 bytes".
Kragen
From papresco@technologist.com Thu, 19 Mar 1998 15:07:17 -0500
Date: Thu, 19 Mar 1998 15:07:17 -0500
From: Paul Prescod papresco@technologist.com
Subject: Minimum set of primitives?
On a purely social level, I think that any project trying to design an
operating systems from scratch over the Internet is likely to fail.
Copying an OS is simple: you know what you are trying to achieve and you
just argue about the ways to achieve it. Designing one is probably next
to impossible, unless the group has a "benevolent dictator" that just
says: "decision made, move on to the next question." Even so, the
dictator's view of the "perfect operating system" will probably turn off
hundreds of potential volunteers. It is much better to clone something
that someone else has already designed (as in Linux).
Paul Prescod - http://itrc.uwaterloo.ca/~papresco
"You have the wrong number."
"Eh? Isn't that the Odeon?"
"No, this is the Great Theater of Life. Admission is free, but the
taxation is mortal. You come when you can, and leave when you must. The
show is continuous. Good-night." -- Robertson Davies, "The Cunning Man"
From kragen@pobox.com Thu, 19 Mar 1998 18:42:08 -0500 (EST)
Date: Thu, 19 Mar 1998 18:42:08 -0500 (EST)
From: Kragen kragen@pobox.com
Subject: Benevolent Dictatorship
On Thu, 19 Mar 1998, Gavin E. Gleason wrote:
> We will need some way of deciding how to procede given
> disagreement as to the next step if we cannot agree unanimously. I
> think that it is possible that the need/want for a lisp OS will
> supercede our ideas about the "best" way to proceed. Maybe we should
> use some sort of parlimentary procedure, and have an elected
> chairman. We could put motions on the table as to the steps as they
> become pertinent. Then we could vote as to which would be the best
> way to continue.
I suggest another way: a sort of economy, like Linux.
Someone -- one person, or two people in close geographic proximity --
gets something working, puts it on a web site, tells other people about
it. Sort of pitches it to them, but tries to do it honestly. Other
people download it, try it, make patches to it, send it back.
If they don't like it, they can write their own. If they do like it,
they can make it better. Instead of deciding on things by majority
rule, we can decide things by trying them out and seeing what's
extremely cool and what's sort of lukewarm.
If someone thinks that xyz feature should be implemented a different
way, they can implement it that different way, put the source on their
website, and tell other people about it. It will be discussed. Some
people will decide to patch their copy of xyz one way, and some the
other. Eventually a consensus will arise, as most people decide to
do xyz one way.
Some people are likely to be more influential than others -- because
they have more time to write code, because they write better code,
because they make better decisions, or because they piss people off
less. That's OK.
> But I have a feeling that the initial stages may be the most
> difficult to agree opon.
I agree. I think someone needs to get *something* working and make it
available *first*. Then they need to run something on it, preferably
something *cool*, so other people want to run it. Maybe someone could
kludge together enough of a Linux-kernel framework to use Linux's TCP/IP
stack and device-driver support, put in a small Lisp VM, a read-eval-print
loop, and write a simple web server.
Even this small task is beyond my poor abilities, though.
> 1. scheme or lisp. Yikes! Thats a dangerous one :). I don't
> personally care either way. Scheme is definitely cleaner, and it
> would seem ideal as a starting point for a clean and radically
> different OS. Lisp on the other hand has everything already built
> into the language. I'll lean whatever way seems most popular in the
> interest of getting this show on the road.
I suspect that this choice is inconsequential. I think it'll be fairly
easy to support either Common Lisp or Scheme in the same OS framework.
> 2. Bootstraping. This is a particularly difficult question,
> as the FLUX OS toolkit is unavailable. I think that we should open the
> table for motions on options in this catagory
Someone write something. Or adapt something. FreeBSD and Linux both boot,
and we could use either of their code.
>
> 3. Abstractions. Finding the most basic level of abstractions
> that we intend to provide in our system will be difficult because we
> will have to come up with a ideas that will be useful in practice.
> This will probably be a dynamic variable that changes as coding and
> practical issues arise, but we should at least have some idea of where
> we are going.
Yes, I agree.
Kragen
From mikemac@teleport.com Thu, 19 Mar 1998 15:51:40 -0800 (PST)
Date: Thu, 19 Mar 1998 15:51:40 -0800 (PST)
From: Mike McDonald mikemac@teleport.com
Subject: Benevolent Dictatorship
>From lispos-request@math.gatech.edu Thu Mar 19 15:25:36 1998
>Resent-Date: Thu, 19 Mar 1998 18:08:30 -0500 (EST)
>Date: Thu, 19 Mar 1998 16:09:28 +0100
>From: "Gavin E. Gleason"
>To: LispOS Mailling List
>Subject: Benevolent Dictatorship
>Mime-Version: 1.0 (generated by tm-edit 7.108)
>Resent-Message-ID: <"kXYch3.0.5D1.jLQ4r"@math>
>Resent-From: lispos@math.gatech.edu
>X-Mailing-List: archive/latest/1880
>X-Loop: lispos@math.gatech.edu
>Resent-Sender: lispos-request@math.gatech.edu
>
>
>. From what I've seen so
>far there is not a massive divergence in ideas about "what" should be in
>the lisp OS. Most of the divergence is in the "how".
Have any of you read the last 1800 messages on this list? If that
doesn't convince you that there is indeed a "massive divergence" of
ideas then I guess I don't know what you mean by that term!
>
> 1. scheme or lisp. Yikes! Thats a dangerous one :).
Yikes is right. We've been over this one. Again and again and again ...
> 2. Bootstraping. This is a particularly difficult question,
>as the FLUX OS toolkit is unavailable. I think that we should open the
>table for motions on options in this catagory
That kind of leaves a stripped down Linux or BSD. And we've been
over this one many a times before too.
>
> Gavin E. Gleason
>
>
Mike McDonald
mikemac@mikemac.com
From kragen@pobox.com Thu, 19 Mar 1998 19:19:56 -0500 (EST)
Date: Thu, 19 Mar 1998 19:19:56 -0500 (EST)
From: Kragen kragen@pobox.com
Subject: Benevolent Dictatorship
On Thu, 19 Mar 1998, Mike McDonald wrote:
> That kind of leaves a stripped down Linux or BSD. And we've been
> over this one many a times before too.
I guess that means no one with the ability cares enough to implement
something. So there will never be a freely-available Lisp OS, unless
you count GNU Emacs, which doesn't even have threads.
Someone needs to write some code. It doesn't have to be perfect; it
doesn't have to satisfy everyone; it just has to be exciting enough to
get other people to help.
Kragen
From mikemac@teleport.com Thu, 19 Mar 1998 16:44:52 -0800 (PST)
Date: Thu, 19 Mar 1998 16:44:52 -0800 (PST)
From: Mike McDonald mikemac@teleport.com
Subject: Benevolent Dictatorship
>From kragen@dnaco.net Thu Mar 19 16:20:09 1998
>Date: Thu, 19 Mar 1998 19:19:56 -0500 (EST)
>To: Mike McDonald
>cc: ggleason@tvi.cc.nm.us, lispos@math.gatech.edu
>Subject: Re: Benevolent Dictatorship
>MIME-Version: 1.0
>From: kragen@pobox.com (Kragen)
>
>On Thu, 19 Mar 1998, Mike McDonald wrote:
>> That kind of leaves a stripped down Linux or BSD. And we've been
>> over this one many a times before too.
>
>I guess that means no one with the ability cares enough to implement
>something. So there will never be a freely-available Lisp OS, unless
>you count GNU Emacs, which doesn't even have threads.
>
>Someone needs to write some code. It doesn't have to be perfect; it
>doesn't have to satisfy everyone; it just has to be exciting enough to
>get other people to help.
>
>Kragen
>
Well, why don't you (the perverbiable you), get a copy of CMUCL, put
it on Linux, and start writing something. There's tons of things to
write that don't require OS kernel expertise. Things like file system
browsers, enhancing Hemlock, networking utilities (gzip, ftp, tar so
you can get the latest CMUCL from the net (when they're back up)), ...
Anytime you have to go to a shell to run a program is a program
waiting to be ported to CMUCL!
Mike McDonald
mikemac@mikemac.com
From joswig@lavielle.com Fri, 20 Mar 1998 01:56:00 +0100
Date: Fri, 20 Mar 1998 01:56:00 +0100
From: Rainer Joswig joswig@lavielle.com
Subject: path to lispos ???
At 15:07 19.03.98 -0500, you wrote:
>On a purely social level, I think that any project trying to design an
>operating systems from scratch over the Internet is likely to fail.
>Copying an OS is simple:
You could try to implement something along the lines of the
Interlisp environment (this already exists as an emulation
for the PC) or the Lisp machines of MIT heritage
(LMI Lambda, TI Explorer, Symbolics, ...). But this
is difficult. You could also look at Apple's now defunct Newton OS.
>hundreds of potential volunteers. It is much better to clone something
>that someone else has already designed (as in Linux).
Yes, you are right on this one. But this is also one of
the **************big************* weaknesses of Linux:
it is just a copy. (A copy of something I'm not a particular
fan of.)
Some random thoughts:
- make an overview of what is freely available for Lisp
(implementations, GUI code, applications, tools, ...).
- take care of the public available Lisp code of choice.
The best start for a CL-based system currently is CMU CL, IMHO.
- document. Document. DOCUMENT. ****DOCUMENT****!!!!!!
- brush up code that is available and desirable, but not actively
maintained (defsystem, UIMS code, ...).
- set up a web site: www.lispos.org . Don't use
http://somemachine.somedepartment.someuniversity.edu//~whoever/cant-remember/obscure.html
Put everything you have well documented on the web site. You can
not afford to lose people by bad documentation (GUILE currently has
no real documentation - a big mistake). The Symbolics Lisp machine
had very good documentation. Don't care less.
- identify people with time. Assign responsibilities (takes care about the docs,
ensures the web site, maintains the file server, compares the
implementations, ...)
- write a position paper. Circulate widely. Try to get donations (machines,
source, man power, ...). Provide regular updates on the project
state. Remind people every month/week about this project. Every
CS student should know about it.
- start implementing an interface (telnet server with vtxxx, CL-HTTP
access, X-based GUI (with editor, listener, inspector, command interpreter,
backtrace, HTML browser, ...), ...).
Maybe something along the lines of a CL-based Emacs-environment. Then
the Lisp development system will also be everybody's favorite
editor environment.
- Implement a CL-HTTP-based chat system for the developers.
- implement extensive introspective documentation access
(class graphs, package overviews, method overviews, apropos,
describe, documentation, ...)
- what about storing and retrieving objects?
- start implementing TCP/IP services
-- write a mail server (SMTP, POP, IMAP).
-- write a pop mail client.
-- write a DNS server
-- write a DNS client
- document. Document. DOCUMENT. ****DOCUMENT****!!!!!!
- write a file browser (like the Mac finder, ...).
- Start porting packages (SK8, ...).
- implement a more sophisticated defsystem (with patches, CLOS-based,
versions, access rights, web interface, ...).
- Reimplement C-based software in Lisp. Make the code clearer and
better documented (easy).
- develop access methods to databases.
- start writing a kernel.
- memory allocation
- process scheduling
- security
- develop a file system
...
From chrisb@ans.com.au Fri, 20 Mar 1998 01:53:00 +0000
Date: Fri, 20 Mar 1998 01:53:00 +0000
From: Chris Bitmead chrisb@ans.com.au
Subject: Minimum set of primitives?
> For example, if we want to implement system-wide garbage collection, we
> have to guarantee that, at some level of granularity, all pointers
> between objects are known to the garbage collector. The easiest way to
> handle this on a fine granularity (the usual Lisp way) is to make data
> types `holy' and inviolable -- only special kernel code has the right
> to do pointer arithmetic, for instance, and no userland programs.
>
> Ideally, we could get away from this evil distinction between
> kernelland and userland. I don't know how, though. All I've ever seen
> is moving the barrier around and changing the granularity -- on a Lisp
> machine, if I understand correctly, the `kernel' was the hardware
> itself, which made sure pointers weren't stored as integers and vice
> versa, and did bounds-checking on arrays. (Is this correct?)
>
> When something is `in the kernel', it is something user programs cannot
> avoid using in some circumstances. Access to I/O and to memory are two
> examples.
It seems to me off hand, that the kernel then, is that which
implements the Scheme (or Lisp) language. Sure, it will work
differently to normal Scheme implementations, but the Scheme
language doesn't give the user the ability to do nasty things
like pointer arithmetic and other nasty stuff. From the users
point of view, he will be merely using a Scheme implementation,
albeit one that implements multiple threads and stuff.
The other big question that arises is whether and how to support
non-Scheme programs. That is where the debate starts as to
whether UNIX should run underneath LispOS in order to support C
apps (and provide a bootstrap or base system to avoid writing
device drivers).
--
Chris Bitmead
http://www.ans.com.au/~chrisb
mailto:chrisb@ans.com.au
From chrisb@ans.com.au Fri, 20 Mar 1998 01:58:44 +0000
Date: Fri, 20 Mar 1998 01:58:44 +0000
From: Chris Bitmead chrisb@ans.com.au
Subject: Minimum set of primitives?
> Hum, that gives rise to a non-trivial question: how to handle
> references, gc and removable media in an hybrid memory/disk system? I
> mean, what happens if referenced objects are lost?
You get an exception if you try to access them.
> How "ls -la" things
> would work on such a system?
There would be no "ls -la".
Objects would be put into container objects. Of course, it might
be desirable to have some containers that index things by name
like a UNIX file system. In that case, if you had a container of
documents called "foo", you might do something like....
(names foo) =>
("doc1", "doc2", "doc3", "doc4")
and to access a document by name...
(find-by-name foo "doc1") =>
("a document about Lisp OS....")
--
Chris Bitmead
http://www.ans.com.au/~chrisb
mailto:chrisb@ans.com.au
From chrisb@ans.com.au Fri, 20 Mar 1998 02:02:01 +0000
Date: Fri, 20 Mar 1998 02:02:01 +0000
From: Chris Bitmead chrisb@ans.com.au
Subject: Minimum set of primitives?
> - some applications require durability -- that is, once they receive and
> acknowledge a piece of data, they're expected not to lose it, even if the
> machine gets unplugged immediately. The need for this is obviously
> strongest in the case of business applications, but it's nice even for
> personal-use applications. This means that applications have to have
> some control over when their data gets written to disk.
>
> I'm not familiar with how historical Lisp systems or KeyKOS handled
> these problems, but I suspect they are solved problems. Perhaps my elders
> here can point us at some documentation.
>
> (Well, KeyKOS handles the last one by offering a 'journal page' system call,
> which forces a page to be written to disk immediately. Database servers can
> force a write on the page containing their latest log entry after each time
> they make a log entry. I'm not clear on how a Lisp system could handle this.)
Yes, I can't see how you can get away from the need for a
"commit" function, which says to the system that the current
state is a place that can be recovered from if things crash. Of
course not all applications will care to use it, but some will
definitely need it, maybe even most.
--
Chris Bitmead
http://www.ans.com.au/~chrisb
mailto:chrisb@ans.com.au
From moribund@netgsi.com Thu, 19 Mar 1998 21:04:53 -0500 (EST)
Date: Thu, 19 Mar 1998 21:04:53 -0500 (EST)
From: Damond Walker moribund@netgsi.com
Subject: Benevolent Dictatorship
On Thu, 19 Mar 1998, Kragen wrote:
> I guess that means no one with the ability cares enough to implement
> something. So there will never be a freely-available Lisp OS, unless
> you count GNU Emacs, which doesn't even have threads.
>
Maybe so, but I think there is enough going on "here and there" to
eventually come to some kind of OS. Maybe not this year...maybe not next
year... I think OS is a moot point at this time. Seeing as LispOS
will eventually take it over anyway...get something to work and let it
grow from there. Remove the Linux-ism here, the WinNT gotcha there...it's
a process but it has to start SOMEWHERE.
> Someone needs to write some code. It doesn't have to be perfect; it
> doesn't have to satisfy everyone; it just has to be exciting enough to
> get other people to help.
>
Exciting? Hell, I'd settle for some that "sort of worked" at this
point. :)
Damond
From chrisb@ans.com.au Fri, 20 Mar 1998 02:07:26 +0000
Date: Fri, 20 Mar 1998 02:07:26 +0000
From: Chris Bitmead chrisb@ans.com.au
Subject: Minimum set of primitives?
Kragen wrote:
>
> On Thu, 19 Mar 1998, Rodrigo Ventura wrote:
> > Hum, that gives rise to a non-trivial question: how to handle
> > references, gc and removable media in an hybrid memory/disk system? I
> > mean, what happens if referenced objects are lost?
>
> That's hard -- I'm looking forward to seeing if the Symbolics people
> know the answer. I'm sure they've spent a lot of time thinking about
> this problem.
I don't believe Symbolics had an object file system. They just
had a regular style file system. So they didn't need to deal with
this.
--
Chris Bitmead
http://www.ans.com.au/~chrisb
mailto:chrisb@ans.com.au
From chrisb@ans.com.au Fri, 20 Mar 1998 02:12:45 +0000
Date: Fri, 20 Mar 1998 02:12:45 +0000
From: Chris Bitmead chrisb@ans.com.au
Subject: Benevolent Dictatorship
Kragen wrote:
> I suspect that this choice is inconsequential. I think it'll be fairly
> easy to support either Common Lisp or Scheme in the same OS framework.
I don't think it will be easy at all. A LispOS means an OS that
is totally integrated with the language. It may well be possible,
but I don't believe it will be easy to do properly. Half of the
"kernel" (or whatever we call it), will be running in that
language, and unlike a UNIX kernel, there won't be a very small
set of kernel calls. Everything will be integrated from top to
bottom.
--
Chris Bitmead
http://www.ans.com.au/~chrisb
mailto:chrisb@ans.com.au
From kragen@pobox.com Thu, 19 Mar 1998 22:52:56 -0500 (EST)
Date: Thu, 19 Mar 1998 22:52:56 -0500 (EST)
From: Kragen kragen@pobox.com
Subject: Benevolent Dictatorship
On Thu, 19 Mar 1998, Damond Walker wrote:
> On Thu, 19 Mar 1998, Kragen wrote:
>
> > I guess that means no one with the ability cares enough to implement
> > something. So there will never be a freely-available Lisp OS, unless
> > you count GNU Emacs, which doesn't even have threads.
>
> Maybe so, but I think there is enough going on "here and there" to
> eventually come to some kind of OS. Maybe not this year...maybe not next
> year... I think OS is a moot point at this time.
Well, I hope so!
> Seeing as LispOS will eventually take it over anyway...
Say again?
> > It doesn't have to be perfect; it
> > doesn't have to satisfy everyone; it just has to be exciting enough to
> > get other people to help.
>
> Exciting? Hell, I'd settle for some that "sort of worked" at this
> point. :)
Having something that "sort of works" is very exciting. Maybe more than having
something that works perfectly, in fact :)
Kragen
From kragen@pobox.com Thu, 19 Mar 1998 23:05:12 -0500 (EST)
Date: Thu, 19 Mar 1998 23:05:12 -0500 (EST)
From: Kragen kragen@pobox.com
Subject: Minimum set of primitives?
On Fri, 20 Mar 1998, Chris Bitmead wrote:
> It seems to me off hand, that the kernel then, is that which
> implements the Scheme (or Lisp) language.
Well, at least the primitive operations: car, cdr, aref, etc. It
doesn't have to implement call/cc, define, read, print, etc.
> Sure, it will work
> differently to normal Scheme implementations, but the Scheme
> language doesn't give the user the ability to do nasty things
> like pointer arithmetic and other nasty stuff. From the users
> point of view, he will be merely using a Scheme implementation,
> albeit one that implements multiple threads and stuff.
>
> The other big question that arises is whether and how to support
> non-Scheme programs. That is where the debate starts as to
> whether UNIX should run underneath LispOS in order to support C
> apps (and provide a bootstrap or base system to avoid writing
> device drivers).
See . I doubt it's
anything original, but it explores the issues.
I do think that avoiding writing device drivers is a *major* issue.
Device drivers compose most of the Linux kernel, most of the
programming effort that went into Linux, and much of the usefulness of
any OS.
It would be nice if we could define a `Linux device driver abstraction
layer' that has a fairly-small set of primitives (kmalloc, kfree,
MOD_DEC_USE_COUNT, etc.) that lets another OS use Linux device
drivers. Or, from another point of view, lets you replace most of the
upper layers of the Linux kernel.
I do not anticipate that this will be easy. I suspect that it may
require throwing together a hacked C compiler that lets us redefine the
behaviors of individual objects flexibly.
Another thing I've thought about is grafting LispVM capabilities onto
the normal Linux kernel, similar to the way Apache has grafted a Perl
VM onto itself in the form of mod_perl. It should be safe to run Lisp
code inside the kernel.
Random thoughts...
Kragen
From kragen@pobox.com Thu, 19 Mar 1998 23:16:57 -0500 (EST)
Date: Thu, 19 Mar 1998 23:16:57 -0500 (EST)
From: Kragen kragen@pobox.com
Subject: Minimum set of primitives?
On Fri, 20 Mar 1998, Chris Bitmead wrote:
> > Hum, that gives rise to a non-trivial question: how to handle
> > references, gc and removable media in an hybrid memory/disk system? I
> > mean, what happens if referenced objects are lost?
>
> You get an exception if you try to access them.
How do you allocate your store so that, under normal circumstances,
your second hard drive failing will not result in your system running
into exceptions when trying to boot?
I guess `boot' is sort of an undefined term. I think it should mean
getting enough primitives and enough of the VM loaded to read, compile,
and run Lisp programs.
How do you make media meaningfully movable from one machine to
another? I guess you need to have some sort of an `external linkage
table' indicating what entry points are expected from the outside
world, and what external undefined references exist. So you could
have a structure like
(define (fact n) (if (= n 0) 1 (* n (fact (- n 1)))))
which would have a single `entry point', a pointer to the cons whose
car was `define', and `exit points' for the atoms define, fact, n, if,
=, *, and -.
How could one go about making sure that all of these list nodes
actually ended up on the same disk? If one of the disks is a floppy,
it's not going to be very useful to have the cdr of the cons whose car
is (fact n) pointing onto the hard disk.
Kragen
From kragen@pobox.com Thu, 19 Mar 1998 23:21:59 -0500 (EST)
Date: Thu, 19 Mar 1998 23:21:59 -0500 (EST)
From: Kragen kragen@pobox.com
Subject: Minimum set of primitives?
On Fri, 20 Mar 1998, Chris Bitmead wrote:
> Yes, I can't see how you can get away from the need for a
> "commit" function, which says to the system that the current
> state is a place that can be recovered from if things crash. Of
> course not all applications will care to use it, but some will
> definitely need it, maybe even most.
KeyKOS got away from it for most applications by simply checkpointing
the entire system periodically -- every couple of minutes. Wrote the
full contents of memory, the complete states of all processes,
everything. Then, if the system crashed, it's as if everything between
the last full checkpoint and the reboot never happened -- it's as
though the system never stopped running, from the applications' point
of view.
This is sufficient for most applications. It potentially has the
problem that, if your OS is buggy or insecure, you can't just reboot --
you must reinstall. Solution: small, secure kernel.
Kragen
From kragen@pobox.com Thu, 19 Mar 1998 23:38:10 -0500 (EST)
Date: Thu, 19 Mar 1998 23:38:10 -0500 (EST)
From: Kragen kragen@pobox.com
Subject: Minimum set of primitives?
On Fri, 20 Mar 1998, Chris Bitmead wrote:
> I don't believe Symbolics had an object file system. They just
> had a regular style file system. So they didn't need to deal with
> this.
Hmm. Interlisp?
*hope*
Kragen
From cmh@greendragon.com Thu, 19 Mar 1998 22:47:34 -0600
Date: Thu, 19 Mar 1998 22:47:34 -0600
From: Chris Hanson cmh@greendragon.com
Subject: Minimum set of primitives?
Are there any set of extended design documents etc. for the MIT-derived
Lisp Machines that we can plow through? A lot of the questions being asked
(probably mine included) have likely already been answered by the people
who built those systems.
From kragen@pobox.com Thu, 19 Mar 1998 23:48:39 -0500 (EST)
Date: Thu, 19 Mar 1998 23:48:39 -0500 (EST)
From: Kragen kragen@pobox.com
Subject: Benevolent Dictatorship
On Fri, 20 Mar 1998, Chris Bitmead wrote:
> Kragen wrote:
>
> > I suspect that this choice is inconsequential. I think it'll be fairly
> > easy to support either Common Lisp or Scheme in the same OS framework.
>
> I don't think it will be easy at all. A LispOS means an OS that
> is totally integrated with the language.
I don't think that's necessarily the case.
To me, a LispOS means an OS that is well-suited to running Lisp
programs, and in which the benefits of Lisp are shared by all the
objects in the system.
Common Lisp and Scheme use essentially the same set of basic
operations, it seems to me (from my limited acquaintance with them,
having read R4RS and most of the Elisp manual, and written a few toy
programs in each language.) The primary differences in the underlying VM are:
1) Can an atom have both a meaningful data value and a useful functional value?
(Yes in CL, no in Scheme)
2) How are function arguments scoped? (Dynamically in CL, statically in Scheme)
3) Is general tail-call elimination required? (No in CL, yes in Scheme)
There are probably numerous other differences like these, but I suspect that
they can be papered over with different definitions.
For example, (1) can be dealt with by having the underlying VM manage
two obarrays for a CL environment, but only one for a Scheme
environment. If manipulation of obarrays is possible from the language
level, this shouldn't be too hard.
Kragen
From laheadle@midway.uchicago.edu Thu, 19 Mar 1998 22:53:44 -0600
Date: Thu, 19 Mar 1998 22:53:44 -0600
From: Lyn A Headley laheadle@midway.uchicago.edu
Subject: Benevolent Dictatorship
Gavin> our ideas about the "best" way to proceed. Maybe we should
Gavin> use some sort of parlimentary procedure, and have an
Gavin> elected chairman. We could put motions on the table as to
Gavin> the steps as they become pertinent. Then we could vote as
Gavin> to which would be the best way to continue. I don't think
This sounds doable. We can't have general votes on everything though;
some decisions should only be made by the people with intimate
knowledge of the module affected. We need to compartmentalize people
and define clear interactions between the modules. But sure, in the
early days there should be a lot of "general" votes to hash out the
overall flavor of the system.
Gavin> 2. Bootstraping. This is a particularly difficult
Gavin> question, as the FLUX OS toolkit is unavailable. I think
Gavin> that we should open the table for motions on options in
Gavin> this catagory
We should wait for flux. It should be released any time now, no?
There is plenty of designing to do before we write code anyway.
-Lyn
From laheadle@midway.uchicago.edu Fri, 20 Mar 1998 00:58:14 -0600
Date: Fri, 20 Mar 1998 00:58:14 -0600
From: Lyn A Headley laheadle@midway.uchicago.edu
Subject: Benevolent Dictatorship
Kragen> I suggest another way: a sort of economy, like Linux.
This is a pretty pragmatic approach, and it leads to a proliferation
of code, which is pretty cool, but it sure as hell doesn't lead to an
elegant system. Rather, it leads to something about as elegant as
Linux. I think it's critical that we *do not* start writing code yet.
I mean, we can't just start hacking pieces of a system without
thinking of the system as a whole. We must decide *what* we want to
build before we start building it. Note that I don't think I'm being
to theoretical or impractical here. I'm as much for using other
people's pre-existing code as the next person. We just can't toss the
code in at a moment's notice.
-Lyn
From chrisb@ans.com.au Fri, 20 Mar 1998 07:16:00 +0000
Date: Fri, 20 Mar 1998 07:16:00 +0000
From: Chris Bitmead chrisb@ans.com.au
Subject: Minimum set of primitives?
Kragen wrote:
>
> On Fri, 20 Mar 1998, Chris Bitmead wrote:
> > Yes, I can't see how you can get away from the need for a
> > "commit" function, which says to the system that the current
> > state is a place that can be recovered from if things crash. Of
> > course not all applications will care to use it, but some will
> > definitely need it, maybe even most.
>
> KeyKOS got away from it for most applications by simply checkpointing
> the entire system periodically -- every couple of minutes. Wrote the
> full contents of memory, the complete states of all processes,
> everything. Then, if the system crashed, it's as if everything between
> the last full checkpoint and the reboot never happened -- it's as
> though the system never stopped running, from the applications' point
> of view.
I can't see how you can do that with even half reasonable
efficiency without special hardware - i.e. involatile memory.
Unless you want to stop the whole system from time to time to
checkpoint everything, but don't people hate emacs when it stops
to garbage collect? I can't see this as feasible. What you talk
about would be great, but I can't see it being realistic.
--
Chris Bitmead
http://www.ans.com.au/~chrisb
mailto:chrisb@ans.com.au
From wolfram.rinke@kes-adaptive-systems.com Fri, 20 Mar 1998 09:10:04 +0100
Date: Fri, 20 Mar 1998 09:10:04 +0100
From: Wolfram Rinke wolfram.rinke@kes-adaptive-systems.com
Subject: path to lispos ???
Your are absolute right! If LispOS wants to be successfull, do it that way.
We have been working on TI Lisp machines for many years, doing customer
project. This machine (like Symbolics or LMI) had/have already versions of a LispOS and LispVM
implemented in microcode. ;-)
If you want to have a successfull LispOS clone one of them and bring it to widespread HW platforms.
Run LispOS on top of NT and UNIX. Integrate it with the WWW.
Good luck!
Wolfram Rinke
-----Original Message-----
From: Rainer Joswig [SMTP:joswig@lavielle.com]
Sent: Friday, March 20, 1998 1:56 AM
To: lispos@math.gatech.edu
Subject: path to lispos ???
At 15:07 19.03.98 -0500, you wrote:
>On a purely social level, I think that any project trying to design an
>operating systems from scratch over the Internet is likely to fail.
>Copying an OS is simple:
You could try to implement something along the lines of the
Interlisp environment (this already exists as an emulation
for the PC) or the Lisp machines of MIT heritage
(LMI Lambda, TI Explorer, Symbolics, ...). But this
is difficult. You could also look at Apple's now defunct Newton OS.
>hundreds of potential volunteers. It is much better to clone something
>that someone else has already designed (as in Linux).
Yes, you are right on this one. But this is also one of
the **************big************* weaknesses of Linux:
it is just a copy. (A copy of something I'm not a particular
fan of.)
Some random thoughts:
- make an overview of what is freely available for Lisp
(implementations, GUI code, applications, tools, ...).
- take care of the public available Lisp code of choice.
The best start for a CL-based system currently is CMU CL, IMHO.
- document. Document. DOCUMENT. ****DOCUMENT****!!!!!!
- brush up code that is available and desirable, but not actively
maintained (defsystem, UIMS code, ...).
- set up a web site: www.lispos.org . Don't use
http://somemachine.somedepartment.someuniversity.edu//~whoever/cant-remember/obscure.html
Put everything you have well documented on the web site. You can
not afford to lose people by bad documentation (GUILE currently has
no real documentation - a big mistake). The Symbolics Lisp machine
had very good documentation. Don't care less.
- identify people with time. Assign responsibilities (takes care about the docs,
ensures the web site, maintains the file server, compares the
implementations, ...)
- write a position paper. Circulate widely. Try to get donations (machines,
source, man power, ...). Provide regular updates on the project
state. Remind people every month/week about this project. Every
CS student should know about it.
- start implementing an interface (telnet server with vtxxx, CL-HTTP
access, X-based GUI (with editor, listener, inspector, command interpreter,
backtrace, HTML browser, ...), ...).
Maybe something along the lines of a CL-based Emacs-environment. Then
the Lisp development system will also be everybody's favorite
editor environment.
- Implement a CL-HTTP-based chat system for the developers.
- implement extensive introspective documentation access
(class graphs, package overviews, method overviews, apropos,
describe, documentation, ...)
- what about storing and retrieving objects?
- start implementing TCP/IP services
-- write a mail server (SMTP, POP, IMAP).
-- write a pop mail client.
-- write a DNS server
-- write a DNS client
- document. Document. DOCUMENT. ****DOCUMENT****!!!!!!
- write a file browser (like the Mac finder, ...).
- Start porting packages (SK8, ...).
- implement a more sophisticated defsystem (with patches, CLOS-based,
versions, access rights, web interface, ...).
- Reimplement C-based software in Lisp. Make the code clearer and
better documented (easy).
- develop access methods to databases.
- start writing a kernel.
- memory allocation
- process scheduling
- security
- develop a file system
...
From papresco@technologist.com Fri, 20 Mar 1998 04:18:24 -0500
Date: Fri, 20 Mar 1998 04:18:24 -0500
From: Paul Prescod papresco@technologist.com
Subject: Benevolent Dictatorship
I would say that if this LispOS project is feasible it will *just
happen* at the right time. That sounds mystical but isn't: at the point
where an X86 hosted Unix became feasible, somebody just picked up the
ball and made it happen. I believe that this has not happend with LispOS
because a) Lisp itself does not have enough of a following, b) we are SO
FAR from what we want that it hurts the brain to plan a path and c)
nobody is foolish enough to take that first step down that very long
path.
I think that the project would be more likely to succeed once those
three problems have been solved. That suggests to me that the first
priority should be making CMUCL a competitive, popular development
environment. The second priority would be to start experimenting with
editors, shells, compilers and other things that can be built without
"changing the world." Changing the world in one stroke is doomed anyhow:
people have work to do and they only want to move to OSes that allow
them to get their work done (i.e. use Unix apps). Finally, once the
critical mass has been achieved, a messiah will appear. You will
recognize him or her because he/she will say: "I've got this neat little
kernel I hacked up. It's compiled with CMUCL and uses EMACS as its UI.
Would anyone like to work on it with me?"
Paul Prescod - http://itrc.uwaterloo.ca/~papresco
The United Nations Declaration of Human Rights will be 50 years old on
December 10, 1998. These are your fundamental rights:
http://www.udhr.org/history/default.htm
From yoda@isr.ist.utl.pt Fri, 20 Mar 1998 10:39:30 +0100 (GMT+0100)
Date: Fri, 20 Mar 1998 10:39:30 +0100 (GMT+0100)
From: Rodrigo Ventura yoda@isr.ist.utl.pt
Subject: Minimum set of primitives?
>>>>> "Paul" == Paul Prescod writes:
Paul> On a purely social level, I think that any project trying to design an
Paul> operating systems from scratch over the Internet is likely to fail.
Are you from Microsoft or something??? 8-)
Now seriously, many of the *best* freeware software have been
made in this medium. Do you know Linux, Emacs, GIMP, etc.?
Paul> Copying an OS is simple: you know what you are trying to achieve and you
Hum, aren't you really from microsoft??? Now I'm getting
really suspicious... 8-)
Paul> just argue about the ways to achieve it. Designing one is probably next
Paul> to impossible, unless the group has a "benevolent dictator" that just
Paul> says: "decision made, move on to the next question." Even so, the
Paul> dictator's view of the "perfect operating system" will probably turn off
Paul> hundreds of potential volunteers. It is much better to clone something
Paul> that someone else has already designed (as in Linux).
Ok, now seriously again, of course some leadership may be
necessary at some point. But that shall not prevent us from
speculating and discussing ideas. Let's just hope someone with enought
expertise, lisp insight and leadership comes about.
Regards,
--
--
*** Rodrigo Martins de Matos Ventura, alias
*** yoda@isr.ist.utl.pt, http://www.isr.ist.utl.pt/~yoda
*** Instituto de Sistemas e Robotica, Polo de Lisboa
*** Instituto Superior Tecnico, Lisboa, Portugal
*** PGP Public Key available on my homepage
*** Key fingerprint = 0C 0A 25 58 46 CF 14 99 CF 9C AF 9E 10 02 BB 2A
From yoda@isr.ist.utl.pt Fri, 20 Mar 1998 11:30:31 +0100 (GMT+0100)
Date: Fri, 20 Mar 1998 11:30:31 +0100 (GMT+0100)
From: Rodrigo Ventura yoda@isr.ist.utl.pt
Subject: Benevolent Dictatorship
>>>>> "Mike" == Mike McDonald writes:
Mike> Well, why don't you (the perverbiable you), get a copy of CMUCL, put
Mike> it on Linux, and start writing something. There's tons of things to
Mike> write that don't require OS kernel expertise. Things like file system
Mike> browsers, enhancing Hemlock, networking utilities (gzip, ftp, tar so
Mike> you can get the latest CMUCL from the net (when they're back up)), ...
I guess CMUCL is a bad choice: too heavy, too big, too complex
and too slow.
Regards,
--
--
*** Rodrigo Martins de Matos Ventura, alias
*** yoda@isr.ist.utl.pt, http://www.isr.ist.utl.pt/~yoda
*** Instituto de Sistemas e Robotica, Polo de Lisboa
*** Instituto Superior Tecnico, Lisboa, Portugal
*** PGP Public Key available on my homepage
*** Key fingerprint = 0C 0A 25 58 46 CF 14 99 CF 9C AF 9E 10 02 BB 2A
From lynbech@daimi.aau.dk Fri, 20 Mar 1998 11:33:09 +0100 (CET)
Date: Fri, 20 Mar 1998 11:33:09 +0100 (CET)
From: Christian Lynbech on satellite lynbech@daimi.aau.dk
Subject: Minimum set of primitives?
>>>>> "Kragen" == Kragen writes:
Kragen> I'm afraid I don't know what the Fluke kit is. Is this a FAQ?
I don't think so. The Fluke tool kit is (as I understand it and from
memory) a distribution of some microkernel architecture (perhaps Mach)
which has been discussed as a promising starting point. I seem to
remember seeing somewhere that the ML OS is based on this.
One obviously has to start somewhere, and any OS needs some basic
abstractions (in UNIX this is concepts like processes and files), so
taking some existing microkernel which provides a minimal such set
would be a reasonable way to start out.
Some have argued here (again from memory) that starting with something
like Linux would inevitably mean that we inherit many of the bad
things from UNIX, such as the filesystem (yes, I do remember the many
discussions about persistent object systems her in the beginning, and
no I do not prefer UNIX files over that, I was just a little careless
in my formulation) or the all powerfull root user.
There should plenty of references to Fluke in the mailing list archives.
---------------------------+--------------------------------------------------
Christian Lynbech | Telebit Communications A/S
| Fabrikvej 11, DK-8260 Viby J
Phone: +45 8628 8176 | email: chl@tbit.dk --- URL: http://www.tbit.dk
---------------------------+--------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- petonic@hal.com (Michael A. Petonic)
From lynbech@daimi.aau.dk Fri, 20 Mar 1998 11:38:49 +0100 (CET)
Date: Fri, 20 Mar 1998 11:38:49 +0100 (CET)
From: Christian Lynbech on satellite lynbech@daimi.aau.dk
Subject: Minimum set of primitives?
>>>>> "Chris" == Chris Bitmead writes:
Chris> The other big question that arises is whether and how to
Chris> support non-Scheme programs. That is where the debate starts as
Chris> to whether UNIX should run underneath LispOS in order to
Chris> support C apps (and provide a bootstrap or base system to avoid
Chris> writing device drivers).
Oh no. A unix program needs to link against a unix runtime system. The
LispOS should be the place where hello.c compiles to a 17Mb executable
with abysymal performance. We want to end the footprint debate.
:-)
>>>>> "Chris" == Chris Bitmead writes:
Chris> ... but don't people hate emacs when it stops to garbage
Chris> collect?
One cannot hate emacs, as we say over in alt.religion.emacs. Garbage
collection is a fact of life just as the sun must set in the evening
in order to rise again in the morning.
:-) :-) :-)
---------------------------+--------------------------------------------------
Christian Lynbech | Telebit Communications A/S
| Fabrikvej 11, DK-8260 Viby J
Phone: +45 8628 8176 | email: chl@tbit.dk --- URL: http://www.tbit.dk
---------------------------+--------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- petonic@hal.com (Michael A. Petonic)
From joswig@lavielle.com Fri, 20 Mar 1998 14:51:09 +0100
Date: Fri, 20 Mar 1998 14:51:09 +0100
From: Rainer Joswig joswig@lavielle.com
Subject: Benevolent Dictatorship
At 11:30 Uhr +0100 20.03.1998, Rodrigo Ventura wrote:
>>>>>> "Mike" == Mike McDonald writes:
>
> Mike> Well, why don't you (the perverbiable you), get a copy of CMUCL, put
> Mike> it on Linux, and start writing something. There's tons of things to
> Mike> write that don't require OS kernel expertise. Things like file system
> Mike> browsers, enhancing Hemlock, networking utilities (gzip, ftp, tar so
> Mike> you can get the latest CMUCL from the net (when they're back up)), ...
>
> I guess CMUCL is a bad choice: too heavy, too big, too complex
>and too slow.
How about providing an overview/comparison of existing systems? Guessing
might not be enough.
Currently CMU CL is the only choice for a CL-based system (IMHO).
It would be even better if it would run under Windows NT.
Weak points of CMU CL:
- not enough users (this can be changed)
- hard to port
- Threads and a better GC are still in development and only for
Intel (AFAIK).
- CLOS is slow.
Rainer Joswig, Lavielle EDV Systemberatung GmbH & Co, Lotharstrasse 2b, D22041
Hamburg, Tel: +49 40 658088, Fax: +49 40 65808-202,
Email: joswig@lavielle.com , WWW: http://www.lavielle.com/~joswig/
From yoda@isr.ist.utl.pt Fri, 20 Mar 1998 14:57:02 +0100 (GMT+0100)
Date: Fri, 20 Mar 1998 14:57:02 +0100 (GMT+0100)
From: Rodrigo Ventura yoda@isr.ist.utl.pt
Subject: Benevolent Dictatorship
>>>>> "Rainer" == Rainer Joswig writes:
Rainer> How about providing an overview/comparison of existing systems? Guessing
Rainer> might not be enough.
I agree. My guessing comes from nothing else other than
personal experience with CMUCL. I was told many times how great CMUCL
was, but my personall experience told me otherwise, albeit repeated
attempts to grasp any issues that might have escaped me before. I have
tryed a few other freeware CL systems, and here goes my opinion:
CLISP: by now, this is my favourite CL system. Very compact,
useful command-line editing, reasonably fast, nice GC, very solid, but
has feable support and doesn't seem to link well with external stuff.
CMUCL: as I said before, I found it too heavy. Ok, it compiles
directly to assembly, and this is great for speed, but the GC is too
slow, it GC's too much. I think it's too huge to serve as a base for a
LispOS.
GCL: Lightweight system, compiles to C (and uses gcc to make
.o's, which are directly and dynamically linkable to gcl, which is
nice), but doesn't seem to support the standard very well -- I never
liked that off-side sloop package to implement the _standard_ loop
macro. And it doesn't seem to be updated much often...
ECL: I'm trying that one right now, it has the flavour of gcl
but seems to have more features. It also supports threads.
I'm sure the survey of the comp.lang.lisp FAQ is rather
complete (updated?), so what we really need is a survey under the
light of the LispOS.
Rainer> Currently CMU CL is the only choice for a CL-based system (IMHO).
Why do you say "only"?
Regards,
--
--
*** Rodrigo Martins de Matos Ventura, alias
*** yoda@isr.ist.utl.pt, http://www.isr.ist.utl.pt/~yoda
*** Instituto de Sistemas e Robotica, Polo de Lisboa
*** Instituto Superior Tecnico, Lisboa, Portugal
*** PGP Public Key available on my homepage
*** Key fingerprint = 0C 0A 25 58 46 CF 14 99 CF 9C AF 9E 10 02 BB 2A
From hjstein@bfr.co.il 20 Mar 1998 17:23:24 +0300
Date: 20 Mar 1998 17:23:24 +0300
From: Harvey J. Stein hjstein@bfr.co.il
Subject: Benevolent Dictatorship
Lyn A Headley writes:
> Kragen> I suggest another way: a sort of economy, like Linux.
>
> This is a pretty pragmatic approach, and it leads to a proliferation
> of code, which is pretty cool, but it sure as hell doesn't lead to an
> elegant system. Rather, it leads to something about as elegant as
> Linux. I think it's critical that we *do not* start writing code yet.
I disagree on several points here (and in the related discussions):
1. Yes, in that Linux is unix, Linux isn't elegant. However, it's
very elegant given the constraints, namely that it be unix and that
it be coded in C. In other words, much of the particulars of the
implementation are very elegant. The Linux kernel hackers work
very hard to do it the "right" way. The code tends to be clever
and extremely efficient. They rewrite large swaths of it when it
turns out that it should have been done differently. They reject
kernel changes that aren't done "correctly", or that "shouldn't" be
in the kernel. This has yielded a fast, robust kernel with lots of
functionality early on. The only downside has been the regular
proliferation of incompatible systems (moving from a.out to ELF, &
from libc to glibc, where in both cases it was a good idea to
recompile everything, and periodic kernel changes which require
certain binaries to be recompiled). However, the headaches of such
changes can be largely mitigated for the average user by upgrading
the system less frequently and by using one of the CD distributions
(such as RedHat or Debian) to do complete upgrades.
2. I don't think that this is a special case. I think that using the
Linux approach (also known as the Bazaar approach, see
http://sagan.earthspace.net/~esr/writings/cathedral-bazaar/) will
more likely yield good results than bad results.
One reason a LispOs developed in this fashon will be good is that
there will be people who like it, and like working on it. Any
section of code that is badly designed will eventually hamper
general development.At that point, one or more of the people who is
dedicated to the system will take it upon themselves to rewrite it
properly. Sure, there will always be poor sections laying around,
but they'll all eventually be replaced when they become too much of
a burden. In the mean time, at least the functionality existed.
At least with the functionality in place the system can be
used. That's a lot better than waiting around for a system while
people thrash out the details.
Another reason why the Bazaar approach works is that it's easier to
see what's wrong and what's right from a working model than from a
design spec. With the functionality in place it's easier to try
different things and see what works. Code often makes it or breaks
it based on low level particular details, details which are very
hard to fully enumerate when developing a design spec. Having a
working implementation in which to experiment and try different
things is a major advantage. I'd contend that hacking up something
that works & then rewriting sections that were done incorrectly
will yield a well designed system faster than devloping a spec and
then coding to the spec.
3. On the other hand, the Linux people did have a spec - namely the
unix interface & the posix specs, etc. They also had a lot of
preexisting artwork. Thus, I'd suggest that someone just start
cloning a lisp machine - any lisp machine, in any way shape or
form. This at least in some sense gives a high level spec. Once
it's cloned it can be ported to other hardware, lisp compilers, and
other substrates (i.e. - Flux vs Linux vs Hurd vs bare metal),
redone "correctly", etc. Given all the discussion about how to do
things here, it's clear that it won't be clear how to do things and
what things are feasable, convenient, etc, until we have something
to work with.
4. Working by consensus will obviously not work - it will just take
too long to come to agreement on each design point, and some design
points will never be agreed upon. It would be better to just code.
That's not to say that design points shouldn't be discussed.
However, the discussion will be much more productive if it's of the
form "Any ideas how I should code this component", or "Here's a
patch for fixing component X", etc, than when it sounds like "A
LispOs shouldn't have a file system", or "We have to use
cmucl/rscheme/acl on top of Flux/Linux/the bare metal".
In other words, people need to put their money where their mouth
is. If you want something, then code it. Trying to get someone
else to code it a certain way for you is ... well, I was going to
say "self righteous and arrogant", but I didn't want to say
something that strong, and I can't think of a milder way of saying
it, but that's the idea.
5. A benevolent dictatorship is ok, in that different people would
mostly be in charge of different components, but it needs to be
based on who's doing the coding. If you code a section, then
you're in charge of the section until you give it up or until
someone else does a better job on it, where "better job" is defined
by people using the system using your implementation instead of the
stock implementation. This has happened with large sections of the
Linux kernel over & over again. Maybe it's not so much a
benevolent dictatorship as it is a coding meritocracy.
That's way too much rambling for now. I just hope someone starts
coding...
--
Harvey J. Stein
Berger Financial Research
hjstein@bfr.co.il
From yoda@isr.ist.utl.pt Fri, 20 Mar 1998 15:28:30 +0100 (GMT+0100)
Date: Fri, 20 Mar 1998 15:28:30 +0100 (GMT+0100)
From: Rodrigo Ventura yoda@isr.ist.utl.pt
Subject: Back to Basics
For a second I imagined myself using the dreamed LispOS (with
some help of an now off-line Explorer Lisp machine on the corner of my
eye) and wondering whether we are trying to reinvent the weel. I mean,
let's imagine we are experimenting with LispOS code. Would we need to
reboot the machine in order to try something out? Do we really want a
LispOS that takes control over the whole machine? Wouldn't it be
better to boot LispOS ontop Linux. And in the initial development
stages, LispOS could be booted while Linux was running.
This idea is not new, and it was discussed before in this mailing
list. I think that it would be much better to work out LispOS directly
ontop the Linux kernel, ie no libc, no init, no nothing. We could use
Linux kernel _directly_ (which would be great since it is under
high-speed development). Only that instead of running /sbin/init, our
LispVM could be launched. Or better yet, maintain the old init (I
suppose it comes from the kernel sources, right?), and configure the
rest via /etc/inittab. A minimal binary tree of ELF executables is
needed, the a.out support can be stripped out from the kernel, and
once the LispVM (including the JIT compiler) has been launched, all
other stuff is in LispOS bytecode.
I don't have much OS code expertise, but these ideas make me
entusiastic enough to think about some little experimentation to build
a ultra-minimal LispOS bootstrap. And all of these without thinking
about boot loaders, assembly bootstrap, serial debugging, etc...
Regards,
--
*** Rodrigo Martins de Matos Ventura, alias
*** yoda@isr.ist.utl.pt, http://www.isr.ist.utl.pt/~yoda
*** Instituto de Sistemas e Robotica, Polo de Lisboa
*** Instituto Superior Tecnico, Lisboa, Portugal
*** PGP Public Key available on my homepage
*** Key fingerprint = 0C 0A 25 58 46 CF 14 99 CF 9C AF 9E 10 02 BB 2A
From yoda@isr.ist.utl.pt Fri, 20 Mar 1998 15:37:04 +0100 (GMT+0100)
Date: Fri, 20 Mar 1998 15:37:04 +0100 (GMT+0100)
From: Rodrigo Ventura yoda@isr.ist.utl.pt
Subject: Minimum set of primitives?
>>>>> "Paul" == Paul Prescod writes:
Paul> I don't know about the GIMP, but EMACS and Linux were *not* made in this
Paul> environment. Linux was started by *one man* who kept control over
Paul> everything (essentially) and started the project using a (relatively)
Paul> coherent existing design. Emacs is more or less the same. Neither was
Paul> created by a committee of people shouting their favourite design
Paul> features, and neither was *research* or *design*. They were both
Paul> *implementation* efforts where the designs were more or less known
Paul> already (there are lots of Unix-like operating systems and text editors
Paul> to steal features from).
Yeah, you are absolutely in some points. However note that
Linus developed a very small Linux kernel, I guess version 0.01 was
about 70k gzipped code! Nowadays it has extended beyond the 10MB! Many
of the contributions were written by people other than Linus. However
I believe Linux has total control about what enters and leaves the
kernel. Yet, I'm sure there has been gigabytes of discussion to get it
as it is now. Note also that there wasn't much to discuss at the
conceptual level (as LispOS) about a UNIX kernel. Many things were
established from the start, the only quesion was how to implement
them, in order to have an amazing fast OS while maintaining UNIX
system calls compatibility (and POSIX).
>> Ok, now seriously again, of course some leadership may be
>> necessary at some point. But that shall not prevent us from
>> speculating and discussing ideas. Let's just hope someone with enought
>> expertise, lisp insight and leadership comes about.
Paul> There's nothing wrong with talking. Just don't think that we're moving
Paul> forward by discussing "file system or object system" every three months.
Paul> We won't move forward until someone starts coding.
And you are right again. And almost everybody agrees with
you. The first line of code is the more difficult one.
So, I'll solve it right away:
--snip--
int main( int argc, char **argv ) {
--snip--
8-))))))))))))))
What the next line shall be?
Regards,
--
--
*** Rodrigo Martins de Matos Ventura, alias
*** yoda@isr.ist.utl.pt, http://www.isr.ist.utl.pt/~yoda
*** Instituto de Sistemas e Robotica, Polo de Lisboa
*** Instituto Superior Tecnico, Lisboa, Portugal
*** PGP Public Key available on my homepage
*** Key fingerprint = 0C 0A 25 58 46 CF 14 99 CF 9C AF 9E 10 02 BB 2A
From chrisb@ans.com.au Fri, 20 Mar 1998 14:54:37 +0000
Date: Fri, 20 Mar 1998 14:54:37 +0000
From: Chris Bitmead chrisb@ans.com.au
Subject: Benevolent Dictatorship
I tend to agree that 1 line of code is worth 100s of lines of
discussion. One would hope that once we have something, then if
it is bad, it will be replaced eventually. If we have nothing,
chances are it will tend to stay nothing.
Personally I would like to see something that does the main
things that we want even if it is appallingly slow, and awfully
ugly and riddled with hacks. Once people understand what we're
aiming for they will be motivated to make it elegant/fast. But
having some terribly clever and elegant ideas that aren't
actually implemented, will leave us.... well where are now.
In my opinion the way forward is to build it on top of Linux for
now. The reason is
1) It saves enormous amounts of work that we can't afford now.
2) It allows us to ignore the compatibility issues for now. We
can still run UNIX programs straight away.
3) Rebooting into a different OS that doesn't do anything isn't
fun.
4) More people will try it in the initial stages if they don't
have to go through the headaches of a different OS.
In the future, someone will be inspired to allow removal of Linux
from underneath. Personally, I'd like to see the ability to use
UNIX underneath as an option that stays. We can't change the
world in a day.
Now, when I said I'd like to see something with the "main" things
in, even if they are slow/ugly, everybody has their own idea of
what is important.
To me personally I think the persistent object system is key. I
don't see enormous advantages to a lisp os as opposed to just
running lisp on UNIX without this.
I also personally want to see Scheme as the language, because I
havn't come to terms with all of the Lisp language yet. Plus also
I think most people agree that Scheme, in terms of it's base
language is an improvment. And if we are going to try to
challenge every accepted notion of what an OS should be -- well
hey --, might as well go the whole hog.
So, when I see a Scheme running on UNIX that has a neat object
system, then I think we have a way forward. Until then it all
seems too hard to co-ordinate.
Just my opinion. Anything that gets started has to be good.
Rainer Joswig's list of things to do would be a great start. What
I think we need is one of the Scheme gurus like Paul Wilson to
get interested in this project. Maybe we should use his "RScheme"
as is -- it already can be used with a persistent object system,
is supposed to be terribly terribly elegant, it's fast, has a
true compiler.
Here's a job that anybody could do, and it's not so hard. Look at
all the Scheme implementations and find one that is closest to
what we want, and then we should agree to just start using it.
--
Chris Bitmead
http://www.ans.com.au/~chrisb
mailto:chrisb@ans.com.au
From papresco@technologist.com Fri, 20 Mar 1998 10:09:20 -0500
Date: Fri, 20 Mar 1998 10:09:20 -0500
From: Paul Prescod papresco@technologist.com
Subject: Minimum set of primitives?
Rodrigo Ventura wrote:
>
> >>>>> "Paul" == Paul Prescod writes:
>
> Paul> On a purely social level, I think that any project trying to design an
> Paul> operating systems from scratch over the Internet is likely to fail.
>
> Are you from Microsoft or something??? 8-)
>
> Now seriously, many of the *best* freeware software have been
> made in this medium. Do you know Linux, Emacs, GIMP, etc.?
I don't know about the GIMP, but EMACS and Linux were *not* made in this
environment. Linux was started by *one man* who kept control over
everything (essentially) and started the project using a (relatively)
coherent existing design. Emacs is more or less the same. Neither was
created by a committee of people shouting their favourite design
features, and neither was *research* or *design*. They were both
*implementation* efforts where the designs were more or less known
already (there are lots of Unix-like operating systems and text editors
to steal features from).
> Ok, now seriously again, of course some leadership may be
> necessary at some point. But that shall not prevent us from
> speculating and discussing ideas. Let's just hope someone with enought
> expertise, lisp insight and leadership comes about.
There's nothing wrong with talking. Just don't think that we're moving
forward by discussing "file system or object system" every three months.
We won't move forward until someone starts coding.
Paul Prescod - http://itrc.uwaterloo.ca/~papresco
The United Nations Declaration of Human Rights will be 50 years old on
December 10, 1998. These are your fundamental rights:
http://www.udhr.org/history/default.htm
From joswig@lavielle.com Fri, 20 Mar 1998 16:30:38 +0100
Date: Fri, 20 Mar 1998 16:30:38 +0100
From: Rainer Joswig joswig@lavielle.com
Subject: Benevolent Dictatorship
At 14:57 Uhr +0100 20.03.1998, Rodrigo Ventura wrote:
> CLISP: by now, this is my favourite CL system. Very compact,
>useful command-line editing, reasonably fast, nice GC, very solid, but
>has feable support and doesn't seem to link well with external stuff.
CLISP is very useful.
Has "only" a byte-code compiler. Really big
applications might be "slow". Doesn't really
try to be ANSI CL compatible. Further development is a bit slow now
(Bruno Haible stepped aside)?
> CMUCL: as I said before, I found it too heavy. Ok, it compiles
>directly to assembly, and this is great for speed, but the GC is too
>slow, it GC's too much. I think it's too huge to serve as a base for a
>LispOS.
People are working to improve GC (by having a generational GC).
When it comes to size, I don't care about that too much nowadays.
My home PC has 128 MB RAM, my next Laptop will have > 200 if
possible. RAM is cheap these days. Don't waste memory if
not necessary, but this is not my primary concern these days.
> ECL: I'm trying that one right now, it has the flavour of gcl
>but seems to have more features. It also supports threads.
Seemed to be to buggy to me.
> I'm sure the survey of the comp.lang.lisp FAQ is rather
>complete (updated?), so what we really need is a survey under the
>light of the LispOS.
There was/is source for a Common Lisp system from BBN in the
CMU archive.
Then there is WCL (old).
> Rainer> Currently CMU CL is the only choice for a CL-based system (IMHO).
>
> Why do you say "only"?
Because it is the only system with a native code compiler.
And some people are still hacking with CMU CL.
But actually for applications I don't care where my stuff runs.
I want it portable. I'm using Mac OS, Genera, Windows and
Solaris. I want to run my code on all these platforms.
ANSI CL is the language, CLIM is the UIMS and CL-HTTP is
the network. I'd rather not like to write unportable code
(Well, sometimes, ...). So if there is a new CL-based
Emacs for example, I want it portable. A one platform only version
does not make sense to me. Eventually the Lisp OS may give
a nice overall integrated environment - but until
this happens applications can already be written.
Rainer Joswig
Rainer Joswig, Lavielle EDV Systemberatung GmbH & Co, Lotharstrasse 2b, D22041
Hamburg, Tel: +49 40 658088, Fax: +49 40 65808-202,
Email: joswig@lavielle.com , WWW: http://www.lavielle.com/~joswig/
From kragen@pobox.com Fri, 20 Mar 1998 10:38:26 -0500 (EST)
Date: Fri, 20 Mar 1998 10:38:26 -0500 (EST)
From: Kragen kragen@pobox.com
Subject: Benevolent Dictatorship
On Fri, 20 Mar 1998, Lyn A Headley wrote:
> Kragen> I suggest another way: a sort of economy, like Linux.
>
> This is a pretty pragmatic approach, and it leads to a proliferation
> of code, which is pretty cool, but it sure as hell doesn't lead to an
> elegant system. Rather, it leads to something about as elegant as
> Linux. I think it's critical that we *do not* start writing code yet.
> I mean, we can't just start hacking pieces of a system without
> thinking of the system as a whole. We must decide *what* we want to
> build before we start building it.
Well, this is a good thing to some point. But we should pay attention
to the schedule that was planned for the GNU Hurd and the schedule that
was actually implemented for it, and take a lesson from that.
I suspect, though, that you have more large-system experience than I
do. Perhaps you are familiar with ways to prevent this from
happening.
Kragen
From kragen@pobox.com Fri, 20 Mar 1998 10:56:21 -0500 (EST)
Date: Fri, 20 Mar 1998 10:56:21 -0500 (EST)
From: Kragen kragen@pobox.com
Subject: Minimum set of primitives?
On Fri, 20 Mar 1998, Paul Prescod wrote:
> I don't know about the GIMP, but EMACS and Linux were *not* made in this
> environment. Linux was started by *one man* who kept control over
> everything (essentially) and started the project using a (relatively)
> coherent existing design. Emacs is more or less the same.
This is also true of the GIMP -- except it was two men instead of one.
Both of them have now left the project; it stagnated for a few months,
but now Quartic has pretty much taken over.
Kragen
From cosc19z5@Bayou.UH.EDU Fri, 20 Mar 1998 10:01:02 -0600 (CST)
Date: Fri, 20 Mar 1998 10:01:02 -0600 (CST)
From: cosc19z5@bayou.uh.edu cosc19z5@Bayou.UH.EDU
Subject: Lisp Machine Emulators?
Hi all,
Nice to see more life coming into this group. I hope it leads
to something this time, but to be honest, I doubt it still.
But my pessimism aside (I still think we need leadership darnit! :)),
I saw reference to an Interlisp emulator for the PC? Is this
a commercial product, or is it downloadable, and if so from
where? I did a brief web search but found nothing.
In fact, are there any lisp machine emulators out there, and
if so from where may they be acquired?
Apart from being able to try out a Lisp machine at home,
I think this thing may give more people a better idea
as to what needs to be done, and could be very inspirational.
Even if the system differs from what we want to do
(my understanding is that we are trying to do the same thing),
at the least they can get an idea as to the pros and cons
of a Lisp OS.
Regards,
Ahmed
From kragen@pobox.com Fri, 20 Mar 1998 11:10:08 -0500 (EST)
Date: Fri, 20 Mar 1998 11:10:08 -0500 (EST)
From: Kragen kragen@pobox.com
Subject: Benevolent Dictatorship
On Fri, 20 Mar 1998, Chris Bitmead wrote:
> Personally I would like to see something that does the main
> things that we want even if it is appallingly slow, and awfully
> ugly and riddled with hacks. Once people understand what we're
> aiming for they will be motivated to make it elegant/fast.
Well, yes. Linux 1.x was never intended to be portable. Significant
parts of it were written in assembly. Lots of assumptions about the
x86 architecture were embedded in it.
Then folks started getting ants in their pants about porting it to the
Sparc and the Alpha. Large parts of the kernel were rewritten, the
source tree was reorganized, and lots of old code was thrown out.
This was part of the 1.3.x development effort. (But only a part of it!)
Incremental development is God in the open-source world.
Kragen
From kragen@pobox.com Fri, 20 Mar 1998 11:19:30 -0500 (EST)
Date: Fri, 20 Mar 1998 11:19:30 -0500 (EST)
From: Kragen kragen@pobox.com
Subject: Benevolent Dictatorship
On Fri, 20 Mar 1998, Rainer Joswig wrote:
> I'd rather not like to write unportable code
> (Well, sometimes, ...). So if there is a new CL-based
> Emacs for example, I want it portable.
Emacs is definitely worth thinking about:
- It's certainly the most-widely-used Lisp VM
- the elisp reference manual claims that there are only minor differences
between elisp and CL, consisting mostly of CL features that don't
exist in elisp (notably, there is no CLOS at all), but I am not
in a position to evaluate this
- there are several large applications written in it -- the "IDE", of course,
several mailreaders and newsreaders, a Web browser, etc. These are
more widely used than any other large Lisp applications in the
world, and are accordingly succumbing to feature creep.
It obviously needs some work: threads and CLOS are a minimum. JIT is probably
a priority. These are big jobs. CMU CL already has them, right? (I haven't
used CMU CL.)
Kragen
From chrisb@ans.com.au Fri, 20 Mar 1998 16:24:16 +0000
Date: Fri, 20 Mar 1998 16:24:16 +0000
From: Chris Bitmead chrisb@ans.com.au
Subject: Minimum set of primitives?
Christian Lynbech on satellite wrote:
>
> >>>>> "Chris" == Chris Bitmead writes:
>
> Chris> The other big question that arises is whether and how to
> Chris> support non-Scheme programs. That is where the debate starts as
> Chris> to whether UNIX should run underneath LispOS in order to
> Chris> support C apps (and provide a bootstrap or base system to avoid
> Chris> writing device drivers).
>
> Oh no. A unix program needs to link against a unix runtime system.
No it doesn't. Only if it needs to access "UNIX"y things. A
scheme program wouldn't need to do these things, so it wouldn't
need to link with libc. (Well depending on how things are
implemented it wouldn't)
> One cannot hate emacs, as we say over in alt.religion.emacs. Garbage
> collection is a fact of life just as the sun must set in the evening
> in order to rise again in the morning.
>
> :-) :-) :-)
Garbage collecting is a fact of life, but stopping the universe
to do it, need not.
--
Chris Bitmead
http://www.ans.com.au/~chrisb
mailto:chrisb@ans.com.au
From joswig@lavielle.com Fri, 20 Mar 1998 17:30:10 +0100
Date: Fri, 20 Mar 1998 17:30:10 +0100
From: Rainer Joswig joswig@lavielle.com
Subject: Benevolent Dictatorship
At 11:19 Uhr -0500 20.03.1998, Kragen wrote:
>It obviously needs some work: threads and CLOS are a minimum. JIT is probably
>a priority. These are big jobs. CMU CL already has them, right? (I haven't
>used CMU CL.)
Erik Naggum is interested in porting Emacs to Common Lisp
(starting with ACL) using CLIM. This could be a killer application -
which also could be the user interface central for a LispOS.
His motivation is to get rid of Emacs Lisp and its implementation.
A decent version of Common Lisp would be a better base for an
editor (which might not be big - just look at MCL).
Rainer Joswig, Lavielle EDV Systemberatung GmbH & Co, Lotharstrasse 2b, D22041
Hamburg, Tel: +49 40 658088, Fax: +49 40 65808-202,
Email: joswig@lavielle.com , WWW: http://www.lavielle.com/~joswig/
From kragen@pobox.com Fri, 20 Mar 1998 11:30:49 -0500 (EST)
Date: Fri, 20 Mar 1998 11:30:49 -0500 (EST)
From: Kragen kragen@pobox.com
Subject: Lisp Machine Emulators?
On Fri, 20 Mar 1998, cosc19z5@bayou.uh.edu wrote:
> In fact, are there any lisp machine emulators out there, and
> if so from where may they be acquired?
Open Genera is a sort of Symbolics LispM emulator that runs on the
Alpha. I don't know if it can be acquired from anyone at the moment,
since Symbolics is bankrupt again. It would be nice if someone could
just give me a copy, but I don't have an Alpha.
I agree that this is very important.
I'd sure like to get a LispM myself, but I expect that I'd need to pay
someone a lot of money for it. (I don't have a Mac, so if I get a
MacIvory, I'd need to get a Mac along with it :)
Kragen
From joswig@lavielle.com Fri, 20 Mar 1998 17:31:13 +0100
Date: Fri, 20 Mar 1998 17:31:13 +0100
From: Rainer Joswig joswig@lavielle.com
Subject: Lisp Machine Emulators?
At 10:01 Uhr -0600 20.03.1998, cosc19z5@bayou.uh.edu wrote:
>But my pessimism aside (I still think we need leadership darnit! :)),
>I saw reference to an Interlisp emulator for the PC? Is this
>a commercial product, or is it downloadable, and if so from
>where? I did a brief web search but found nothing.
It is(was?) a commercial product from "Venue". I guess
it is difficult to get. I know someone who managed to get
a copy (not me) here in Germany.
>In fact, are there any lisp machine emulators out there, and
>if so from where may they be acquired?
Open Genera is an emulator of the Symbolics Genera OS
running on DEC Alpha (under OSF/1). DEC Alphas
are not very common manchines, though.
>Apart from being able to try out a Lisp machine at home,
>I think this thing may give more people a better idea
>as to what needs to be done, and could be very inspirational.
Some commercial Lisp systems are either featureful
(like LispWorks under Unix) or can interface the
native OS very good (like Macintosh Common Lisp).
There you can get very far while staying inside Lisp.
Rainer Joswig, Lavielle EDV Systemberatung GmbH & Co, Lotharstrasse 2b, D22041
Hamburg, Tel: +49 40 658088, Fax: +49 40 65808-202,
Email: joswig@lavielle.com , WWW: http://www.lavielle.com/~joswig/
From kragen@pobox.com Fri, 20 Mar 1998 11:36:27 -0500 (EST)
Date: Fri, 20 Mar 1998 11:36:27 -0500 (EST)
From: Kragen kragen@pobox.com
Subject: Minimum set of primitives?
On Fri, 20 Mar 1998, Christian Lynbech on satellite wrote:
> >>>>> "Kragen" == Kragen writes:
>
> Kragen> I'm afraid I don't know what the Fluke kit is. Is this a FAQ?
>
> Some have argued here (again from memory) that starting with something
> like Linux would inevitably mean that we inherit many of the bad
> things from UNIX, such as the filesystem
That's kind of silly. Linux lets you access block devices directly if
you want without any filesystem at all. What more could you want?
Well, I guess you might have to have a small filesystem to boot from,
but the rest of the disk can be objects all the way.
> or the all powerfull root user.
Java-style security, with unforgeable capabilities, should be plenty, I
think. There really isn't any way we can map that onto any set of Unix
users, so we shouldn't even try. Just run the LispVM as root, or
better yet, as part of the kernel.
Kragen
From kragen@pobox.com Fri, 20 Mar 1998 11:50:21 -0500 (EST)
Date: Fri, 20 Mar 1998 11:50:21 -0500 (EST)
From: Kragen kragen@pobox.com
Subject: Minimum set of primitives?
On Fri, 20 Mar 1998, Chris Bitmead wrote:
> Garbage collecting is a fact of life, but stopping the universe
> to do it, need not.
Incremental garbage collection is hard. Ever implemented it?
Nevertheless, I agree that it's extremely important for some things.
Kragen
From hjstein@bfr.co.il 20 Mar 1998 19:55:52 +0300
Date: 20 Mar 1998 19:55:52 +0300
From: Harvey J. Stein hjstein@bfr.co.il
Subject: Benevolent Dictatorship
kragen@pobox.com (Kragen) writes:
> On Fri, 20 Mar 1998, Chris Bitmead wrote:
> > Personally I would like to see something that does the main
> > things that we want even if it is appallingly slow, and awfully
> > ugly and riddled with hacks. Once people understand what we're
> > aiming for they will be motivated to make it elegant/fast.
>
> Well, yes. Linux 1.x was never intended to be portable. Significant
> parts of it were written in assembly. Lots of assumptions about the
> x86 architecture were embedded in it.
This is sort of true. Significant parts were in assembler, but they
were small parts of the whole. Lots of assumptions about x86 were
embedded, but much of it was isolated from the rest of the code.
Linus himself originally said that it wasn't portable. But, then some
DEC guys started doing the alpha port, and had it runing on DEC alphas
in a surprisingly short amount of time. It turned out that the
machine dependencies weren't so hard to isolate and fix. Of course,
since the system as a whole is mostly 3rd party (GNU & X), and these
had been running on all sorts of systems for ages, once the kernel was
ported it wasn't much additional work to get a fully running system.
Most notably, there was already a native compiler. OTOH, lots of
people did do lots of work initially getting all the apps configured
for linux/intel, as well as configuring for all the new hardware
ports, not to mention the whole XFree86 project, without which PC
video cards wouldn't be supported.
When you start thinking about all the piles of code needed/desired for
PC hardware (ethernet cards, scsi cards, video cards, IDE, parallel
port, serial port, CD players, sound cards, TV cards, scanners, all in
both PCI & AT bus versions), it would sem a gargantuan task to build
everything from scratch in Lisp. Hence, my tendency to agree with
Chris Bitmead about building it on top of Linux. In fact, I'd go
further - so as to avoid writing drivers (kernel internal & video),
build it on Linux, and use X for graphics. I don't see why this will
handicap the design - just treat Linux & X as 2 drivers. If you want
to plug in more drivers & make the thing self hosting, then go ahead.
But, that's just my opinion. He who writes the code has the say.
--
Harvey J. Stein
Berger Financial Research
hjstein@bfr.co.il
From chrisb@ans.com.au Fri, 20 Mar 1998 16:59:51 +0000
Date: Fri, 20 Mar 1998 16:59:51 +0000
From: Chris Bitmead chrisb@ans.com.au
Subject: Minimum set of primitives?
Kragen wrote:
>
> On Fri, 20 Mar 1998, Chris Bitmead wrote:
> > Garbage collecting is a fact of life, but stopping the universe
> > to do it, need not.
>
> Incremental garbage collection is hard.
I know.
> Ever implemented it?
Actually, yes.
>Nevertheless, I agree that it's extremely important for some things.
A bit hard to have a proper OS without it I would have thought.
--
Chris Bitmead
http://www.ans.com.au/~chrisb
mailto:chrisb@ans.com.au
From hjstein@bfr.co.il 20 Mar 1998 20:10:52 +0300
Date: 20 Mar 1998 20:10:52 +0300
From: Harvey J. Stein hjstein@bfr.co.il
Subject: Minimum set of primitives?
kragen@pobox.com (Kragen) writes:
> On Fri, 20 Mar 1998, Paul Prescod wrote:
> > I don't know about the GIMP, but EMACS and Linux were *not* made in this
> > environment. Linux was started by *one man* who kept control over
> > everything (essentially) and started the project using a (relatively)
> > coherent existing design. Emacs is more or less the same.
>
> This is also true of the GIMP -- except it was two men instead of one.
> Both of them have now left the project; it stagnated for a few months,
> but now Quartic has pretty much taken over.
"Control" is a strong word. Linux started as a task switcher.
Versions 0.0* were written by Linus. When it progressed to where he
thought he had something interesting, he put it up on the net. It was
still pretty far from a unix kernel. Many people defected from minix
hacking to contribute huge chunks of code (the networking support, the
ext2fs file system, ...). I think Linus was pretty open about
accepting such contributions. I'd consider him more as a "patch
coordinator" than as a head of development who "kept control over
everything".
--
Harvey J. Stein
Berger Financial Research
hjstein@bfr.co.il
From kragen@pobox.com Fri, 20 Mar 1998 12:12:59 -0500 (EST)
Date: Fri, 20 Mar 1998 12:12:59 -0500 (EST)
From: Kragen kragen@pobox.com
Subject: Minimum set of primitives?
On Fri, 20 Mar 1998, Chris Bitmead wrote:
> > KeyKOS got away from it for most applications by simply checkpointing
> > the entire system periodically -- every couple of minutes. Wrote the
>
> I can't see how you can do that with even half reasonable
> efficiency without special hardware - i.e. involatile memory.
>
> Unless you want to stop the whole system from time to time to
> checkpoint everything, but don't people hate emacs when it stops
> to garbage collect? I can't see this as feasible. What you talk
> about would be great, but I can't see it being realistic.
Well, it was used in an OS that ran mainframe OLTP applications. See
for detailed
information.
It might be worth looking at. It's an example of how a restrictive
design decision -- storing all state in one of two simple kinds of data
structures -- made it possible to do something astonishing. It would
not have been possible to retrofit this onto an OS after the fact.
Instead of stopping the whole system completely until the checkpoint is
complete, though, it simply marked all of the dirty memory as
copy-on-write, allowing applications to continue to run while the
actual disk writing occurred.
It claims that a typical KeyKOS system checkpointed every five minutes,
and the period of time in which processes are stopped is typically one
second on a loaded system.
The ratios between the size of a dollar of disk, a dollar of RAM, and a
dollar of CPU time have changed since the early 1990s, so I don't know
if this would still be true.
Kragen
From hjstein@bfr.co.il 20 Mar 1998 20:20:11 +0300
Date: 20 Mar 1998 20:20:11 +0300
From: Harvey J. Stein hjstein@bfr.co.il
Subject: Benevolent Dictatorship
hjstein@bfr.co.il (Harvey J. Stein) writes:
> Linus himself originally said that it wasn't portable. But, then some
> DEC guys started doing the alpha port, and had it runing on DEC alphas
> in a surprisingly short amount of time. It turned out that the
> machine dependencies weren't so hard to isolate and fix.
I know I'm talking to myself, but to substantiate my claims, I wanted
to list current linux ports (from
http://sunsite.unc.edu/LDP/devel.html):
Hardware Ports
ARM Linux
Linux/MIPS
DEC Alpha (AXP)
Linux/m68k (Atari and Amiga), Linux/m68k for Apple Macintosh, and Linux NeXT Cubes
Linux/VME (m68k based MVME162/166/167 boards) and a MVME147 version
ELKS Project (i8086 - i80286)
LinuxPPC (PowerPC), Linux/PowerMac (Monolithic Linux for Apple PowerMacs) as well as
LinuxPPC for Motorola PowerStack and IBM PPC
Linux/AP+ (Fujitsu AP1000+)
MkLinux for PowerMac (Micro Kernel Linux)
Linux MCA Homepage (Micro Channel bus)
SPARC/Linux
Linux/sun3
VAXlinux
HP PA-RISC
L4Linux
Linux/SGI
VMELinux, Linux for VMEbus embedded systems.
Of course, lots of these are in their prenatal state, but alot of them
also boot & run applications. There's even a port to the PalmPilot!
(see http://ryeham.ee.ryerson.ca/uClinux/).
--
Harvey J. Stein
Berger Financial Research
hjstein@bfr.co.il
From hjstein@bfr.co.il 20 Mar 1998 20:29:10 +0300
Date: 20 Mar 1998 20:29:10 +0300
From: Harvey J. Stein hjstein@bfr.co.il
Subject: Minimum set of primitives?
Rodrigo Ventura writes:
> >>>>> "Paul" == Paul Prescod writes:
>
> Paul> I don't know about the GIMP, but EMACS and Linux were *not* made in this
> Paul> environment. Linux was started by *one man* who kept control over
>
> Yeah, you are absolutely in some points. However note that
> Linus developed a very small Linux kernel, I guess version 0.01 was
> about 70k gzipped code! Nowadays it has extended beyond the 10MB!
Another size point - kernel .98 pl10, which was quite usable, was
about 200k gzipped, if I recall correctly.
BTW, this difference in source code size is largely due to drivers,
which gives an idea of the amount of work necessary for supporting PC
hardware, and this doesn't even count video cards!
--
Harvey J. Stein
Berger Financial Research
hjstein@bfr.co.il
From hjstein@bfr.co.il 20 Mar 1998 20:31:42 +0300
Date: 20 Mar 1998 20:31:42 +0300
From: Harvey J. Stein hjstein@bfr.co.il
Subject: Benevolent Dictatorship
Lyn A Headley writes:
> Gavin> 2. Bootstraping. This is a particularly difficult
> Gavin> question, as the FLUX OS toolkit is unavailable. I think
> Gavin> that we should open the table for motions on options in
> Gavin> this catagory
>
> We should wait for flux. It should be released any time now, no?
> There is plenty of designing to do before we write code anyway.
My philosophy is to never wait for code. Always use what's currently
available, or write it yourself. I've been burned every time I've
waited for something that was supposed to be released "Real Soon".
--
Harvey J. Stein
Berger Financial Research
hjstein@bfr.co.il
From ptw@pobox.com Fri, 20 Mar 1998 12:34:28 -0500
Date: Fri, 20 Mar 1998 12:34:28 -0500
From: P. T. Withington ptw@pobox.com
Subject: Lisp Machine Emulators?
On 3/20/98 11:30, Kragen wrote:
>On Fri, 20 Mar 1998, cosc19z5@bayou.uh.edu wrote:
>> In fact, are there any lisp machine emulators out there, and
>> if so from where may they be acquired?
>
>Open Genera is a sort of Symbolics LispM emulator that runs on the
>Alpha. I don't know if it can be acquired from anyone at the moment,
>since Symbolics is bankrupt again. It would be nice if someone could
>just give me a copy, but I don't have an Alpha.
>
>I agree that this is very important.
There are actually a number of pieces that would be nice to recover from
the Symbolics corpse that would be ideal for this project. One, Minima,
is a CL implementation of an operating system with processes, networking
and garbage collection that was originally developed under contract to
AT&T to run on a diskless Ivory processor. The very lowest level of run
time, in particular the memory management is Ivory specific, but much of
the code is pure CL. I don't know if AT&T retained any rights to this
work and/or if they could be persuaded to put it in the public domain.
The OG emulator is written mostly in hand-tuned Alpha assembley, but
there was a prototype written in C. Given a fast enough processor and
clever enough C compiler, you could have a reasonably fast Ivory
processor emulator. The prototype is not as faithful an implementation
as the Alpha assembley version, so some work would be needed.
Symbolics is currently in limbo, but it would be a great service to the
Lisp community if the assets were put into the public domain.
Unfortunately, the sources are the primary documentation of all the great
work that went on there; there is very little written documentation about
the evolution of the technology.
From papresco@technologist.com Fri, 20 Mar 1998 12:39:22 -0500
Date: Fri, 20 Mar 1998 12:39:22 -0500
From: Paul Prescod papresco@technologist.com
Subject: Minimum set of primitives?
Harvey J. Stein wrote:
>
> "Control" is a strong word. Linux started as a task switcher.
> Versions 0.0* were written by Linus. When it progressed to where he
> thought he had something interesting, he put it up on the net. It was
> still pretty far from a unix kernel. Many people defected from minix
> hacking to contribute huge chunks of code (the networking support, the
> ext2fs file system, ...). I think Linus was pretty open about
> accepting such contributions. I'd consider him more as a "patch
> coordinator" than as a head of development who "kept control over
> everything".
Linus did not allow things to get into Linux that he thought violated
his design principles. IOW, he kept control. If someone had suggested
(e.g.) a persistent object store in the kernel, Linus would not have let
it in, because his goal was to copy Unix, not invent something.
Paul Prescod - http://itrc.uwaterloo.ca/~papresco
The United Nations Declaration of Human Rights will be 50 years old on
December 10, 1998. These are your fundamental rights:
http://www.udhr.org/history/default.htm
From hjstein@bfr.co.il 20 Mar 1998 20:41:07 +0300
Date: 20 Mar 1998 20:41:07 +0300
From: Harvey J. Stein hjstein@bfr.co.il
Subject: Benevolent Dictatorship
kragen@pobox.com (Kragen) writes:
> On Thu, 19 Mar 1998, Gavin E. Gleason wrote:
> > Maybe we should use some sort of parlimentary procedure, and have
> > an elected chairman. We could put motions on the table as to the
> > steps as they become pertinent. Then we could vote as to which
> > would be the best way to continue.
>
> I suggest another way: a sort of economy, like Linux.
Some more Linux history to give people an idea of how things
proceeded, - functionality, who controlled what, and the time frame
involved (from
http://www.acsu.buffalo.edu/~thies/Linux/Time_Line.html):
Linux Time Line
Unknown Dates - Please Help
July 3, 1991
some device drivers, and the hard drive are now working; some basic
user-level features are now being considered
August 25, 1991
v0.01 is almost ready; MMU used for paging (not to disk yet) and
segmentation, pseudo ttys, BSD sockets, user-mode filesystem, window
size in the tty structure, systems calls are capable of supporting POSIX.1
and BSD-style filenames
September 1991
Linux v0.01: no binaries are available yet, only source code; a small
filesystem exists, along with a working disk-driver
October 5, 1991
Linux v0.02: The first "official" version of Linux was announced. This
version was able to run bash, gcc, gnu-make, gnu-sed, and compress.
This version was not very usable.
October 26, 1991
Linux v0.03: This version of Linux was considered usable.
November, 1991
Linux v0.10
December 19, 1991
Linux v0.11: This was the first stand-alone version of Linux. There was
still no SCSI support, although there were people working on it. Hardware
setup for this version consisted of ISA+AT-disk. No init/login yet either,
you would get bash as root upon bootup (standard in the next release as
well). Partially working VM (paging to disk), but 4M was needed to be
able to run the GNU binaries, especially gcc. Bootup was possible with
only 2M, but you could not compile.
December (Xmas) 1991
Linux v0.11+VM: Several people were trying to compile the kernel with
2M and failing, hence this version was made available to this small group
of individuals that wanted to test it out.
January 5, 1992
Linux v0.12: This was the first version of Linux to contain
"non-essential" features. This was also the first version that Linus
allowed any money to change hands due to Linux. Previously Linux had
been distributed free, under a very lenient copyright owned by Linus. This
previous copyright had actually been much more restrictive than the
GNU copyright.
March 1992
Linux v0.95
April 1992
Linux v0.96: This version of Linux was capable of running X-Windows
August 7, 1992
I (Jonathan Magid) take over Linux archives from Alan Clegg and move
them to sunsite.unc.edu. They had been at banjo.mcnc.org. The load on
the machine was too great (according to his boss) as it was transfering 37
megabytes/day of Linux and 386BSD stuff per day.
September 15, 1992
Alan Clegg submits a proposal for file system standardization on behalf of
the Linux-Standards list.
October 18, 1992
Linux v0.98.2: This version contained a new FPU-emulator by Bill
Metzenthen. Bigger than the old one by Linus, but instead of only doing a
few of the most important instructions, it emulates the whole 387
instruction set. It was also much faster than the old emulator + the soft
math library. The new emulator made a separate soft-float library
unnecessary, which simplified GCC distribution a bit.
Minor memory management fixes: One of the minor fixes, the trapping of
kernel NULL dereferences, proved to break a lot code. This proved to be
very good, since many kernel or driver bugs showed up. Unfortunately,
v0.98.pl2 was not usable on many computers, since the kernel bugs creep
up too often.
SCSI driver changes by Eric Youngdale. Mostly bug-fixes.
Some TCP/IP patches. TCP/IP was still alpha, and had not been
extensively tested, and hence was not up to real use yet.
Psaux mouse patches by Dean Troyer.
Starting with this version, Linus will no longer made bootdisks. This task
was turned over to H.J. Lu and Jim Winstead.
October 19, 1992
Peter Williams announced a debugged version of ed, the Unix line editor,
courtesy of Bill Metzenthen. ed was used mostly by patch and shell
scripts. In the early days of Unix ed was used as the primary editor.
October 20, 1992
Peter MacDonald announced an update to SLS. It contained man pages
that were accidentally removed in a previous release.
David Black announced Pirates BBS v1.9 for Linux. It was a multiuser
bulletin board system. Working kernel TCP/IP was required, and 10M of
disk space was recommended.
Olaf Erb announced Wampes with Linux support. The announcement
didn't describe what it was.
Thomas Dunbar announced a port of GNU's free-standing info file
reader. This package allowed you to read the GNU on-line
documentation, instead of doing it from within GNU Emacs. Also included
were makeinfo and texindex, used for formatting info files from texinfo
source code.
October 21, 1992
Mark Becker, the author of RaWrite, announced a new version. The new
version was supposed to run on ``nearly everything claiming to be
compatible with the original IBM-PC''. RaWrite was an MS-DOS utility
that was used to write out disk images (e.i. bootdisks) onto floppies. Under
Linux the equivalent command is ``dd if=diskimage of=/dev/fd0'' (if you
want to write to the first floppy). It was not possible to just copy the floppy
image file to the floppy under MS-DOS, since that would require the
floppy to have the DOS filesystem on it, which means that the disk would
have extraneous stuff on it, not just the parts in the image file.
Larry Butler announced an upload of xv 2.21 binaries. There was trouble
with his first upload (compiled with debugging and hence very large
binaries), but that got fixed quickly.
October 23, 1992
Matthew Lewis announced an upload of dclock.
October 25, 1992
Thomas Losin announced tvgalib, a graphics library for Trident 8900C
cards. This was based on the vgalib library, which is for generic VGA.
Neither requires or has anything to do with X or other windowing
systems.
October 26, 1992
Qi Xia announced a new program cksum, a (mostly) POSIX conforming
checksum program (not compatible with Unix sum).
Vince Skahan announced an upload of Newspak v1.0. It was a package of
programs related to Usenet news ported to Linux. The included programs
were: C-news (12/22/91), tin (1.1pl4), trn (2.2), smail (3.1.28). Newspak
used programs from Mailpak (by Ed Carp), which provided uucp and mail
for Linux.
Thomas Dunbar announced TeX packaged as an SLS package.
October 27, 1992
Linux v0.98.3: This version corrected most of the kernel NULL pointer
reference problems.
November 7, 1992
Doug Evans releases his Xenix filesystem for Linux (98p3).
November 19, 1992
Fred Van Kampen releases: new enhanced version of Laurence
Culhane's Slip (original released when?) ports berkeley talk/d, ftp/d, rsh/d,
host, dig, telnetd, rlogind, uucpd, tftp/d, his own inetd and telnetd.
November 20, 1992
Ross Biro releases port of the BSD lpr suite.
November 1992
Andrew Tridgell releases an early version of a NetBios server. I believe
this is the pre-origin of the Samba server.
December 2, 1992
Jim Nance releases a program to let you install a linux system over the
network (the first one?).
February 1993
First port to non-intel systems (Amiga) begins. FAQ posted by Greg
Harp.
February 1993
van Kampen releases new Slip driver, using his new Device Driver
interface, to keep drivers from having to break layering (slip used to muck
in termio and serial layers).
April 1993
van Kampen releases Net-2, which replace Biro's original TCP/IP code.
The new version features: Net source layout, BSD-osh SIOCxxx ioctl
calls (more BSD programs port to linux), ifconfig allows bit-wide
netmasks and ip-routing, integrated Donald Beckers 8390 and plip
drivers, new SLIP driver, actual /dev devices for TCP/IP, hooks for new
IP router, improved ARP module.
May 1993
Phil Hughes announces plans for Linux Journal.
September 17, 1993
Alan Cox begins to take over networking as flamewars over Net-2 (van
Kempen) vs, Net-1 (Biro) rage. He removes much of the new code for
stability reasons and starts work on Net-2D (debugged).
September 21, 1993
Alan Cox releases Net-2D (debugged). This is a release to provide a
stable transition between Net-1 and Net-2.
November 29, 1993
First Alpha release of Umsdos FS, to allow running Linux from a
MS-DOS FAT partition.
December 1993
Linux v0.99.14
December 15, 1993
van Kempen releases Beta-3 of Net-2E, while Johannes Stille releases
his own passel of fixes to Beta-2.
January 18, 1994
Peter MacDonald (SLS) releases patches agains 99p4f to make most
device drivers loadable modules. This isn't the same module support that
the Linux kernel now supports, though.
February 5, 1994
Code Freeze for Linux v1.0
February 18, 1994
Daniel Quinlan releases 1.0 of the File System Standard.
February 26, 1994
Ted Ts'o announces an Alpha release of a full-rewrite of the Linux tty
driver. The two main new features: Allows new low-level drivers to be
written, eliminating hard-coded TTY major numbers. Line discipline
interfaces were revamped to speed TTY handling (speeding slip and ppp
greatly) (FFSTND), replacing Clegg's earlier work.
March 1994
Annoucement of foundation of Linux International. Its goals are: 1)
encourage as many people, organizations, and communities as possible to
start using Linux 2) promote the development and distribution of freely
available software.
April 5, 1994
First Alpha of iBCS2, which allows you to run SVr3 (including SCO) apps
under Linux.
April 16, 1994
Linux v1.0
May 1994
Alan Cox releases his Net-3, which is a partial re-write of Net-2. Cox
more or less takes of major development of the Linux networking from
van Kempen.
August 4, 1994
First Beta of Redhat ships.
November 3, 1994
First release of Redhat ships.
Linux v1.0 - v1.0.9
March 2, 1995
Linux v1.1
1995
Linux v1.1 - v1.1.95
August 2, 1995
Linux v1.2
1995
Linux v1.2 - v1.2.13
1995
Linux v1.2.8
June 6, 1996
Linux v1.3
1996
Linux v1.3 - (pre)v2.0.14
1996
Linux v1.3.59
1996
Linux v2.0
August 11, 1997
Linux v2.1
1997
Linux v2.1 - v2.1.49
Bibliography: Aaron Thies, Linus Torvalds, Lars Wirzenius ,Mark P. Nelson, J. Richard Sladkey, Jonathan
Magid
--
Harvey J. Stein
Berger Financial Research
hjstein@bfr.co.il
From joswig@lavielle.com Fri, 20 Mar 1998 18:44:26 +0100
Date: Fri, 20 Mar 1998 18:44:26 +0100
From: Rainer Joswig joswig@lavielle.com
Subject: Benevolent Dictatorship
At 20:20 Uhr +0300 20.03.1998, Harvey J. Stein wrote:
>I know I'm talking to myself, but to substantiate my claims, I wanted
>to list current linux ports (from
>http://sunsite.unc.edu/LDP/devel.html):
GCC plays in important role in this. Take care of your
compiler! Write backends.
Rainer Joswig, Lavielle EDV Systemberatung GmbH & Co, Lotharstrasse 2b, D22041
Hamburg, Tel: +49 40 658088, Fax: +49 40 65808-202,
Email: joswig@lavielle.com , WWW: http://www.lavielle.com/~joswig/
From kragen@pobox.com Fri, 20 Mar 1998 12:48:24 -0500 (EST)
Date: Fri, 20 Mar 1998 12:48:24 -0500 (EST)
From: Kragen kragen@pobox.com
Subject: Minimum set of primitives?
On 20 Mar 1998, Harvey J. Stein wrote:
> (the networking support, the
> ext2fs file system, ...). I think Linus was pretty open about
> accepting such contributions. I'd consider him more as a "patch
> coordinator" than as a head of development who "kept control over
> everything".
He rejected some changes, though, and he maintained pretty strong
control over the overall framework.
He says he should have made the backspace key emit control-H instead of
\x7f, and a lot of people wanted him to do that. He refused at the time.
Kragen
From kragen@pobox.com Fri, 20 Mar 1998 13:02:27 -0500 (EST)
Date: Fri, 20 Mar 1998 13:02:27 -0500 (EST)
From: Kragen kragen@pobox.com
Subject: Lisp Machine Emulators?
On Fri, 20 Mar 1998, P. T. Withington wrote:
> Symbolics is currently in limbo, but it would be a great service to the
> Lisp community if the assets were put into the public domain.
> Unfortunately, the sources are the primary documentation of all the great
> work that went on there; there is very little written documentation about
> the evolution of the technology.
It would be nice if this could have happened before they went
bankrupt. Would this be legal? It might be interpreted as destruction
of assets that could otherwise be used to pay off creditors.
If it *is* legal, perhaps other companies could be persuaded to do this
in the future. Hundreds of start-ups in Silly Valley fail every year,
no?
Kragen
From wolfram.rinke@kes-adaptive-systems.com Fri, 20 Mar 1998 19:14:37 +0100
Date: Fri, 20 Mar 1998 19:14:37 +0100
From: Wolfram Rinke wolfram.rinke@kes-adaptive-systems.com
Subject: Fw: path to lispos ???
Here it is!
Jordan wrote
-----Ursprüngliche Nachricht-----
Von: Jordan Henderson
An: Wolfram Rinke
Datum: Freitag, 20. März 1998 18:02
Betreff: Re: path to lispos ???
>I agree. If Richard Coleman is still listening I would like him to
>speak directly on the subject of his original goals on starting this
>project. I seem to remember that the original idea was to make a freely
>available system which was similar in design and usefullness to the
>Symbolics/Explorer/Lambda environments.
>
>I'm concerned that this project has been hijacked by a lot of
>competing interests that insist that there is no value in doing
>a LispOS if it's not a "completely reflective" system (whatever that
>really means), or doesn't have an integrated persistent object system
>(whatever that really means) or it's not integrated top-to-bottom
>(whatever THAT really means).
>
>What has worked in the past on collaborative Internet projects?
>I'm not sure what has worked, but I know that endless speculation
>and wrangling over features has not worked, not on the LispOS
>project and not on the Tunes project.
>
>I feel that Rainer has listed a number of important goals and has
>stated a number of clearcut sub-projects that motivated people could
>start on immediately. It's not clear to anyone that the result of
>executing Rainer's list would be that super academic-buzzword-compliant
>ultra-flexible earth shakingly revolutionary system that some people
>seem to think is the goal, but I do think that having the Infrastructure
>that the execution of these sub-projects would provide would imply the
>existence of an environment where more ambitious projects could thrive.
>
>It is surprising when someone on this list says something like "I think
>we can all agree that..." and we are immediately treated to a number of
>differing views which don't agree with each other, but I'm going to
>make one of these far reaching statements now. I think we can all
>agree that we want a better computing paradigm that discards a lot
>of the baggage from historical mistakes and narrow ways of viewing
>problems, we just don't agree what intermediate steps are necessary
>to get there. I feel some are focused on building the "ultimate"
>solution from the start, while others just want better CL tools.
>
>From a practical standpoint, I feel the project lacks leadership. This
>leadership could come by widespread acknowledgement of authority to
>establish the "benevolent dictatorship" that some are calling for, or
>by the authority that comes with accomplishment (someone writing something
>substantial, the Linux model). However it comes about, leadership would
>help us focus our efforts. In the meantime, it wouldn't hurt to just
>start on Rainer's list.
>
>Unfortunately, some of the more important goals (from my perspective) can't
>be accomplished without leadership (who will be "officially" responsible
for
>maintaining lispos.org, for example).
>
>Can we at least agree we need someone to work on "promotional"
infrastructure
>(lispos.org, circulating drafts of position papers, regularly posting
reminders
>to the appropriate newsgroups, perhaps a project symbol that we could
encourage
>people to put on their web pages which links to www.lispos.org, etc.)? Or
are
>we concerned that if we empower someone (or some group) in this way that
>the project will be driven to too lofty or too narrow goals and will not be
>something we can support?
>
>-Jordan Henderson
>jordan@neosoft.com
>
>>
>> Your are absolute right! If LispOS wants to be successfull, do it that
way.
>> We have been working on TI Lisp machines for many years, doing customer
>> project. This machine (like Symbolics or LMI) had/have already versions
of a LispOS and LispVM
>> implemented in microcode. ;-)
>>
>> If you want to have a successfull LispOS clone one of them and bring it
to widespread HW platforms.
>> Run LispOS on top of NT and UNIX. Integrate it with the WWW.
>>
>> Good luck!
>> Wolfram Rinke
>>
>> -----Original Message-----
>> From: Rainer Joswig [SMTP:joswig@lavielle.com]
>> Sent: Friday, March 20, 1998 1:56 AM
>> To: lispos@math.gatech.edu
>> Subject: path to lispos ???
>>
>> At 15:07 19.03.98 -0500, you wrote:
>> >On a purely social level, I think that any project trying to design an
>> >operating systems from scratch over the Internet is likely to fail.
>> >Copying an OS is simple:
>>
>> You could try to implement something along the lines of the
>> Interlisp environment (this already exists as an emulation
>> for the PC) or the Lisp machines of MIT heritage
>> (LMI Lambda, TI Explorer, Symbolics, ...). But this
>> is difficult. You could also look at Apple's now defunct Newton OS.
>>
>> >hundreds of potential volunteers. It is much better to clone something
>> >that someone else has already designed (as in Linux).
>>
>> Yes, you are right on this one. But this is also one of
>> the **************big************* weaknesses of Linux:
>> it is just a copy. (A copy of something I'm not a particular
>> fan of.)
>>
>> Some random thoughts:
>>
>> - make an overview of what is freely available for Lisp
>> (implementations, GUI code, applications, tools, ...).
>>
>> - take care of the public available Lisp code of choice.
>> The best start for a CL-based system currently is CMU CL, IMHO.
>>
>> - document. Document. DOCUMENT. ****DOCUMENT****!!!!!!
>>
>> - brush up code that is available and desirable, but not actively
>> maintained (defsystem, UIMS code, ...).
>>
>> - set up a web site: www.lispos.org . Don't use
>>
http://somemachine.somedepartment.someuniversity.edu//~whoever/cant-remember
/obscure.html
>> Put everything you have well documented on the web site. You can
>> not afford to lose people by bad documentation (GUILE currently has
>> no real documentation - a big mistake). The Symbolics Lisp machine
>> had very good documentation. Don't care less.
>>
>> - identify people with time. Assign responsibilities (takes care about
the docs,
>> ensures the web site, maintains the file server, compares the
>> implementations, ...)
>>
>> - write a position paper. Circulate widely. Try to get donations
(machines,
>> source, man power, ...). Provide regular updates on the project
>> state. Remind people every month/week about this project. Every
>> CS student should know about it.
>>
>> - start implementing an interface (telnet server with vtxxx, CL-HTTP
>> access, X-based GUI (with editor, listener, inspector, command
interpreter,
>> backtrace, HTML browser, ...), ...).
>> Maybe something along the lines of a CL-based Emacs-environment. Then
>> the Lisp development system will also be everybody's favorite
>> editor environment.
>>
>> - Implement a CL-HTTP-based chat system for the developers.
>>
>> - implement extensive introspective documentation access
>> (class graphs, package overviews, method overviews, apropos,
>> describe, documentation, ...)
>>
>> - what about storing and retrieving objects?
>>
>> - start implementing TCP/IP services
>> -- write a mail server (SMTP, POP, IMAP).
>> -- write a pop mail client.
>> -- write a DNS server
>> -- write a DNS client
>>
>> - document. Document. DOCUMENT. ****DOCUMENT****!!!!!!
>>
>> - write a file browser (like the Mac finder, ...).
>>
>> - Start porting packages (SK8, ...).
>>
>> - implement a more sophisticated defsystem (with patches, CLOS-based,
>> versions, access rights, web interface, ...).
>>
>> - Reimplement C-based software in Lisp. Make the code clearer and
>> better documented (easy).
>>
>> - develop access methods to databases.
>>
>> - start writing a kernel.
>> - memory allocation
>> - process scheduling
>> - security
>>
>> - develop a file system
>>
>> ...
>>
>>
>>
>
>
From yoda@isr.ist.utl.pt Fri, 20 Mar 1998 19:29:36 +0100 (GMT+0100)
Date: Fri, 20 Mar 1998 19:29:36 +0100 (GMT+0100)
From: Rodrigo Ventura yoda@isr.ist.utl.pt
Subject: Benevolent Dictatorship
>>>>> "Rainer" == Rainer Joswig writes:
>> CMUCL: as I said before, I found it too heavy. Ok, it compiles
>> directly to assembly, and this is great for speed, but the GC is too
>> slow, it GC's too much. I think it's too huge to serve as a base for a
>> LispOS.
Rainer> People are working to improve GC (by having a generational GC).
Rainer> When it comes to size, I don't care about that too much nowadays.
Rainer> My home PC has 128 MB RAM, my next Laptop will have > 200 if
Rainer> possible. RAM is cheap these days. Don't waste memory if
Rainer> not necessary, but this is not my primary concern these days.
Huge RAM requirements are not satisfied with cheap RAM. Wanna
see why? Well, you have Windows95 and the Office, you have Netscape,
you have statically linked Motif, etc. Why are Object Oriented
solutions so slow? Because they waste alot of memory, just to provide
the programmer extra funconality, which becomes almost useless
afterwards.
What I mean is that more memory induces more CPU time browsing
though it. Means more time loading, GC'ing, etc. It's not just the
SIMM (or DIMM) price, but rather the whole system performance. Of
course there is such thing as time-memory trade-off, but this is not
the case.
Rainer> Currently CMU CL is the only choice for a CL-based system (IMHO).
>>
>> Why do you say "only"?
Rainer> Because it is the only system with a native code compiler.
Rainer> And some people are still hacking with CMU CL.
My opinion fall down alot when I tried a trivial factorial
function, and observed CMUCL core dumping! How can a factorial
function core-dump the CL system with large integers??? And when I
tried a agent society simulation I developed using CLISP, it kept on
GC'ing continuously, and ended-up going nowhere. Another thing I
didn't like was the hard-coded directory locations.
Regards,
--
--
*** Rodrigo Martins de Matos Ventura, alias
*** yoda@isr.ist.utl.pt, http://www.isr.ist.utl.pt/~yoda
*** Instituto de Sistemas e Robotica, Polo de Lisboa
*** Instituto Superior Tecnico, Lisboa, Portugal
*** PGP Public Key available on my homepage
*** Key fingerprint = 0C 0A 25 58 46 CF 14 99 CF 9C AF 9E 10 02 BB 2A
From jordan@Starbase.NeoSoft.COM Fri, 20 Mar 1998 12:31:10 -0600 (CST)
Date: Fri, 20 Mar 1998 12:31:10 -0600 (CST)
From: Jordan Henderson jordan@Starbase.NeoSoft.COM
Subject: path to lispos ???
Sorry for the duplication, I responded to Wolfram Rinke's note without
copying the list and when I realized that I asked Mr. Rinke to forward it
to the list, but I'd really rather have my note unquoted, because many
people (at least I do) tend to skip over quoted material.
I agree. If Richard Coleman is still listening I would like him to
speak directly on the subject of his original goals on starting this
project. I seem to remember that the original idea was to make a freely
available system which was similar in design and usefullness to the
Symbolics/Explorer/Lambda environments.
I'm concerned that this project has been hijacked by a lot of
competing interests that insist that there is no value in doing
a LispOS if it's not a "completely reflective" system (whatever that
really means), or doesn't have an integrated persistent object system
(whatever that really means) or it's not integrated top-to-bottom
(whatever THAT really means).
What has worked in the past on collaborative Internet projects?
I'm not sure what has worked, but I know that endless speculation
and wrangling over features has not worked, not on the LispOS
project and not on the Tunes project.
I feel that Rainer has listed a number of important goals and has
stated a number of clearcut sub-projects that motivated people could
start on immediately. It's not clear to anyone that the result of
executing Rainer's list would be that super academic-buzzword-compliant
ultra-flexible earth shakingly revolutionary system that some people
seem to think is the goal, but I do think that having the Infrastructure
that the execution of these sub-projects would provide would imply the
existence of an environment where more ambitious projects could thrive.
It is surprising when someone on this list says something like "I think
we can all agree that..." and we are immediately treated to a number of
differing views which don't agree with each other, but I'm going to
make one of these far reaching statements now. I think we can all
agree that we want a better computing paradigm that discards a lot
of the baggage from historical mistakes and narrow ways of viewing
problems, we just don't agree what intermediate steps are necessary
to get there. I feel some are focused on building the "ultimate"
solution from the start, while others just want better CL tools.
>From a practical standpoint, I feel the project lacks leadership. This
leadership could come by widespread acknowledgement of authority to
establish the "benevolent dictatorship" that some are calling for, or
by the authority that comes with accomplishment (someone writing something
substantial, the Linux model). However it comes about, leadership would
help us focus our efforts. In the meantime, it wouldn't hurt to just
start on Rainer's list.
Unfortunately, some of the more important goals (from my perspective) can't
be accomplished without leadership (who will be "officially" responsible for
maintaining lispos.org, for example).
Can we at least agree we need someone to work on "promotional" infrastructure
(lispos.org, circulating drafts of position papers, regularly posting reminders
to the appropriate newsgroups, perhaps a project symbol that we could encourage
people to put on their web pages which links to www.lispos.org, etc.)? Or are
we concerned that if we empower someone (or some group) in this way that
the project will be driven to too lofty or too narrow goals and will not be
something we can support?
-Jordan Henderson
jordan@neosoft.com
Wolfram Rinke writes:
>
> Your are absolute right! If LispOS wants to be successfull, do it that way.
> We have been working on TI Lisp machines for many years, doing customer
> project. This machine (like Symbolics or LMI) had/have already versions of a LispOS and LispVM
> implemented in microcode. ;-)
>
> If you want to have a successfull LispOS clone one of them and bring it to widespread HW platforms.
> Run LispOS on top of NT and UNIX. Integrate it with the WWW.
>
> Good luck!
> Wolfram Rinke
>
> -----Original Message-----
> From: Rainer Joswig [SMTP:joswig@lavielle.com]
> Sent: Friday, March 20, 1998 1:56 AM
> To: lispos@math.gatech.edu
> Subject: path to lispos ???
>
> At 15:07 19.03.98 -0500, you wrote:
> >On a purely social level, I think that any project trying to design an
> >operating systems from scratch over the Internet is likely to fail.
> >Copying an OS is simple:
>
> You could try to implement something along the lines of the
> Interlisp environment (this already exists as an emulation
> for the PC) or the Lisp machines of MIT heritage
> (LMI Lambda, TI Explorer, Symbolics, ...). But this
> is difficult. You could also look at Apple's now defunct Newton OS.
>
> >hundreds of potential volunteers. It is much better to clone something
> >that someone else has already designed (as in Linux).
>
> Yes, you are right on this one. But this is also one of
> the **************big************* weaknesses of Linux:
> it is just a copy. (A copy of something I'm not a particular
> fan of.)
>
> Some random thoughts:
>
> - make an overview of what is freely available for Lisp
> (implementations, GUI code, applications, tools, ...).
>
> - take care of the public available Lisp code of choice.
> The best start for a CL-based system currently is CMU CL, IMHO.
>
> - document. Document. DOCUMENT. ****DOCUMENT****!!!!!!
>
> - brush up code that is available and desirable, but not actively
> maintained (defsystem, UIMS code, ...).
>
> - set up a web site: www.lispos.org . Don't use
> http://somemachine.somedepartment.someuniversity.edu//~whoever/cant-remember/obscure.html
> Put everything you have well documented on the web site. You can
> not afford to lose people by bad documentation (GUILE currently has
> no real documentation - a big mistake). The Symbolics Lisp machine
> had very good documentation. Don't care less.
>
> - identify people with time. Assign responsibilities (takes care about the docs,
> ensures the web site, maintains the file server, compares the
> implementations, ...)
>
> - write a position paper. Circulate widely. Try to get donations (machines,
> source, man power, ...). Provide regular updates on the project
> state. Remind people every month/week about this project. Every
> CS student should know about it.
>
> - start implementing an interface (telnet server with vtxxx, CL-HTTP
> access, X-based GUI (with editor, listener, inspector, command interpreter,
> backtrace, HTML browser, ...), ...).
> Maybe something along the lines of a CL-based Emacs-environment. Then
> the Lisp development system will also be everybody's favorite
> editor environment.
>
> - Implement a CL-HTTP-based chat system for the developers.
>
> - implement extensive introspective documentation access
> (class graphs, package overviews, method overviews, apropos,
> describe, documentation, ...)
>
> - what about storing and retrieving objects?
>
> - start implementing TCP/IP services
> -- write a mail server (SMTP, POP, IMAP).
> -- write a pop mail client.
> -- write a DNS server
> -- write a DNS client
>
> - document. Document. DOCUMENT. ****DOCUMENT****!!!!!!
>
> - write a file browser (like the Mac finder, ...).
>
> - Start porting packages (SK8, ...).
>
> - implement a more sophisticated defsystem (with patches, CLOS-based,
> versions, access rights, web interface, ...).
>
> - Reimplement C-based software in Lisp. Make the code clearer and
> better documented (easy).
>
> - develop access methods to databases.
>
> - start writing a kernel.
> - memory allocation
> - process scheduling
> - security
>
> - develop a file system
>
> ...
>
>
>
From hjstein@bfr.co.il 20 Mar 1998 21:47:27 +0300
Date: 20 Mar 1998 21:47:27 +0300
From: Harvey J. Stein hjstein@bfr.co.il
Subject: Benevolent Dictatorship
Rainer Joswig writes:
> At 20:20 Uhr +0300 20.03.1998, Harvey J. Stein wrote:
> >I know I'm talking to myself, but to substantiate my claims, I wanted
> >to list current linux ports (from
> >http://sunsite.unc.edu/LDP/devel.html):
>
> GCC plays in important role in this. Take care of your
> compiler! Write backends.
Absolutely. I mentioned somewhere that there was substantially less
work necessary because of the existence of GNU & X, most notably
having gcc (or some other C compiler) either running on the target
systems or capable of cross compiling for the target systems. Not to
mention the hordes patching & reconfiguring said free software for
Linux.
--
Harvey J. Stein
Berger Financial Research
hjstein@bfr.co.il
From dtillman@cannonexpress.com Fri, 20 Mar 1998 13:31:45 -0600
Date: Fri, 20 Mar 1998 13:31:45 -0600
From: David Tillman dtillman@cannonexpress.com
Subject: Benevolent Dictatorship
>>>> Chris Bitmead
> In my opinion the way forward is to build it on top of Linux for
> now. The reason is
> 1) It saves enormous amounts of work that we can't afford now.
> 2) It allows us to ignore the compatibility issues for now. We
> can still run UNIX programs straight away.
> 3) Rebooting into a different OS that doesn't do anything isn't
> fun.
> 4) More people will try it in the initial stages if they don't
> have to go through the headaches of a different OS.
Yup. I am not opposed to LispOS running on top of
Linux for these very reasons. Linux is popular enough
that there will always be many hands to write a driver
for that latest whiz-bang ISDN card. Linux could be viewed
as another level of abstraction or as an API to hardware,
for short term anyway...
> I also personally want to see Scheme as the language, because I
> havn't come to terms with all of the Lisp language yet. Plus also
> I think most people agree that Scheme, in terms of it's base
> language is an improvment. And if we are going to try to
> challenge every accepted notion of what an OS should be -- well
> hey --, might as well go the whole hog.
Yup again. I have some worry that LispOS development
resources will be split between A "heavy" Lisp version
and a "light" Scheme version.
> Here's a job that anybody could do, and it's not so hard. Look at
> all the Scheme implementations and find one that is closest to
> what we want, and then we should agree to just start using it.
So far I have been liking MzScheme. It has non-OS based threads
and an object system. I haven't messed with the object system
yet so I can't report on its quality.
-Dave
--
David Tillman : dtillman@xevious.ml.org
LISP email list : lisp-request@xevious.ml.org
MzScheme email list : mzscheme-request@xevious.ml.org
From vfr750@netcom.com Fri, 20 Mar 1998 11:49:48 -0800 (PST)
Date: Fri, 20 Mar 1998 11:49:48 -0800 (PST)
From: Will Hartung vfr750@netcom.com
Subject: EMACS First? (Was: Benevolent Dictatorship)
(Rainer, I accidently R)eplied this to you and not the list...)
Rainer wrote:
>
>
> Erik Naggum is interested in porting Emacs to Common Lisp
> (starting with ACL) using CLIM. This could be a killer application -
> which also could be the user interface central for a LispOS.
> His motivation is to get rid of Emacs Lisp and its implementation.
> A decent version of Common Lisp would be a better base for an
> editor (which might not be big - just look at MCL).
How does one, as a USER, distinguish that one is running on any
specific OS?
How many folks here log in to their X-Terminals, Windows, or terminal
sessions, and immediatly fire up a screen encompassing EMACS window,
and rarely, if ever, leave it?
I'm not a fluent EMACS user...Heck, I'm not even a conversational
EMACS user. I stumble about in it and keep banging my head on sharp
corners.
What are the consequences of starting from the top of the LispOS
environment and working down towards a kernel versus starting from the
kernel up?
When Linux was being developed, once they started to get a kernel
functional, their next primary step was to get GCC compiled and
running on that kernel. Once they had GCC running, they started
working on EMACS and BASH. Once those were accomplished, the
floodgates opened and they started heaping and porting the gigs of
C-source available from GNU and BSD to recreate their UNIX
environment.
If LispOS was able to get a kernel up and bootable, then what? The
Lisp community doesn't really have access to the source base that the
UNIX community does.
However, how does ones LispOS experience appear to anyone,
sans the kernel hackers, different than if someone went into Linux,
and crafted the inittab to launch nothing but ,
for example the current iteration of ACL that Franz is kindly loaning
out.
Wouldn't that be "exciting" for most people? What if you turned on
your computer, it whirred and buzzed, and up popped an Emacs display
with a Lisp listener?
Isn't that the fantasy of the first step?
How will a first generation LispOS be more efficient than an EMACS
built in to an ACL image on top of a Linux kernel?
How long were GCC and EMACS around before Linux? How about the GNU
file utilities? How much of the evnironment of what we now know as
Linux was there BEFORE a kernel was even started or imagined?
And how much of that does the Lisp community have to leverage a LispOS
kernel once it appears?
You want to bootstrap this project from "how abouts" and "what ifs"
and "if only" to "Wow!" "Cool!" "Hey, check this out", then I think
porting EMACS to CL is the first step. EMACS is the kernel of an
exciting LispOS environment that most folks would be happy with,
inittially, and would bring a LOT of applications with it.
Lisp is the King of incremental development. Get EMACS into CL, and
running in an image of SOME kind (ACL is just handy right now, though
it isn't as portable because of licensing) is an enabler. But, CL is CL
is CL (knock on wood), once EMACS and its minions have been ported, it
provides a target and goal for CMUCL or whatever to run toward.
"You want your environment to be cool? You gotta run EMACS-CL well."
Make EMACS-CL the "Flight Simulator" of early "PC Compatibles".
No GUI, no OOFS, none of those. Not yet.
But LispOS needs a "bootstrap" monitor, and EMACS is probably the best
candidate for such a monitor. Since 90% of the folks on this list are
NOT OS or Kernel or Persistent Store or File systems hackers, getting
this monitor up gives everyone an environment that can accelerate this
whole process while the propeller beanie headed crowd huddle in their
damp basements forging a kernel to support the juggernaut that is being
formed one S-expression at a time.
Regards,
Will Hartung
(vfr750@netcom.com)
From ptw@pobox.com Fri, 20 Mar 1998 15:04:43 -0500
Date: Fri, 20 Mar 1998 15:04:43 -0500
From: P. T. Withington ptw@pobox.com
Subject: Lisp Machine Emulators?
On 3/20/98 13:02, Kragen wrote:
>On Fri, 20 Mar 1998, P. T. Withington wrote:
>> Symbolics is currently in limbo, but it would be a great service to the
>> Lisp community if the assets were put into the public domain.
>> Unfortunately, the sources are the primary documentation of all the great
>> work that went on there; there is very little written documentation about
>> the evolution of the technology.
>
>It would be nice if this could have happened before they went
>bankrupt. Would this be legal? It might be interpreted as destruction
>of assets that could otherwise be used to pay off creditors.
It would be legal for someone to buy them and put them in the public
domain. The creditors might be happy to take a few cents on the dollar.
There was talk of any or all of MIT, Franz, Harlequin doing just this,
but currently another party who is interested in the assets has them
frozen. (This is what I hear through the rumor mill).
From joswig@lavielle.com Fri, 20 Mar 1998 21:05:44 +0100
Date: Fri, 20 Mar 1998 21:05:44 +0100
From: Rainer Joswig joswig@lavielle.com
Subject: Benevolent Dictatorship
At 19:29 20.03.98 +0100, Rodrigo Ventura wrote:
>>>>>> "Rainer" == Rainer Joswig writes:
> Huge RAM requirements are not satisfied with cheap RAM. Wanna
>see why? Well, you have Windows95 and the Office, you have Netscape,
>you have statically linked Motif, etc. Why are Object Oriented
>solutions so slow? Because they waste alot of memory, just to provide
>the programmer extra funconality, which becomes almost useless
>afterwards.
Real object oriented systems with reuse are not wasting
that much space (best example the Newton OS - which
is a lot like a Lisp OS and has tiny memory requirements).
> What I mean is that more memory induces more CPU time browsing
>though it.
That's why better Lisp systems have a generational GC. Keeps the
area to scan frequently small. Some have also an ephemeral GC,
which looks for very short living objects. The Symbolics
also does copying (wasting even more address room) of objects.
This can help in preserving locality of objects.
> Rainer> Currently CMU CL is the only choice for a CL-based system (IMHO).
> >>
> >> Why do you say "only"?
>
> Rainer> Because it is the only system with a native code compiler.
> Rainer> And some people are still hacking with CMU CL.
>
> My opinion fall down alot when I tried a trivial factorial
>function, and observed CMUCL core dumping! How can a factorial
>function core-dump the CL system with large integers???
I don't know. If that happens, this looks like a bug to me.
How did the CMUCL maintainers reacted to your bug report?
> And when I
>tried a agent society simulation I developed using CLISP, it kept on
>GC'ing continuously, and ended-up going nowhere.
The trick to make CMU CL useable is to increase the heap and make
GC occur less often. Applications will need more space but will
GC less frequent. Adding a generational/ephemeral GC
would get rid of this. Improve CMU CL!
> Another thing I
>didn't like was the hard-coded directory locations.
Sure. Ask the CMUCL maintainers about it. Make a proposal.
Better send source code. Atleast complain.
From mikemac@teleport.com Fri, 20 Mar 1998 12:11:05 -0800 (PST)
Date: Fri, 20 Mar 1998 12:11:05 -0800 (PST)
From: Mike McDonald mikemac@teleport.com
Subject: Benevolent Dictatorship
>From lispos-request@math.gatech.edu Fri Mar 20 11:49:10 1998
>Resent-Date: Fri, 20 Mar 1998 14:27:48 -0500 (EST)
>Date: Fri, 20 Mar 1998 19:29:36 +0100 (GMT+0100)
>From: Rodrigo Ventura
>To: LispOS Mailling List
>Subject: Re: Benevolent Dictatorship
>Mime-Version: 1.0 (generated by tm-edit 7.95)
>Resent-Message-ID: <"J_Mnc1.0.dF7.pCi4r"@math>
>Resent-From: lispos@math.gatech.edu
>X-Mailing-List: archive/latest/1942
>X-Loop: lispos@math.gatech.edu
>Resent-Sender: lispos-request@math.gatech.edu
>
>>>>>> "Rainer" == Rainer Joswig writes:
>
> Rainer> Currently CMU CL is the only choice for a CL-based system (IMHO).
> >>
> >> Why do you say "only"?
>
> Rainer> Because it is the only system with a native code compiler.
> Rainer> And some people are still hacking with CMU CL.
>
> My opinion fall down alot when I tried a trivial factorial
>function, and observed CMUCL core dumping! How can a factorial
>function core-dump the CL system with large integers??? And when I
>tried a agent society simulation I developed using CLISP, it kept on
>GC'ing continuously, and ended-up going nowhere. Another thing I
>didn't like was the hard-coded directory locations.
>
Did you report the bug in CMUCL?
Mike McDonald
mikemac@mikemac.com
From papresco@technologist.com Fri, 20 Mar 1998 16:31:46 -0500
Date: Fri, 20 Mar 1998 16:31:46 -0500
From: Paul Prescod papresco@technologist.com
Subject: path to lispos ???
Jordan Henderson wrote:
>
> Can we at least agree we need someone to work on "promotional" infrastructure
> (lispos.org, circulating drafts of position papers, regularly posting reminders
> to the appropriate newsgroups, perhaps a project symbol that we could encourage
> people to put on their web pages which links to www.lispos.org, etc.)? Or are
> we concerned that if we empower someone (or some group) in this way that
> the project will be driven to too lofty or too narrow goals and will not be
> something we can support?
I don't think what this project needs is promotion. Probably hundreds of
individuals have posted messages about it. They just have no direction.
Running code promotes itself.
Paul Prescod - http://itrc.uwaterloo.ca/~papresco
The United Nations Declaration of Human Rights will be 50 years old on
December 10, 1998. These are your fundamental rights:
http://www.udhr.org/history/default.htm
From vogt@computer.org Fri, 20 Mar 1998 16:27:29 -0600
Date: Fri, 20 Mar 1998 16:27:29 -0600
From: Christopher J. Vogt vogt@computer.org
Subject: Lisp Machine Emulators?
At 2:04 PM -0600 3/20/98, P. T. Withington wrote:
>On 3/20/98 13:02, Kragen wrote:
>
>>On Fri, 20 Mar 1998, P. T. Withington wrote:
>>> Symbolics is currently in limbo, but it would be a great service to the
>>> Lisp community if the assets were put into the public domain.
>>> Unfortunately, the sources are the primary documentation of all the great
>>> work that went on there; there is very little written documentation about
>>> the evolution of the technology.
>>
>>It would be nice if this could have happened before they went
>>bankrupt. Would this be legal? It might be interpreted as destruction
>>of assets that could otherwise be used to pay off creditors.
>
>It would be legal for someone to buy them and put them in the public
>domain. The creditors might be happy to take a few cents on the dollar.
>There was talk of any or all of MIT, Franz, Harlequin doing just this,
>but currently another party who is interested in the assets has them
>frozen. (This is what I hear through the rumor mill).
I have this vague recolection that the original license that Symbolics (and
LMI and TI) had with MIT was such that any improvements (whatever that
means) to the original MIT Lisp code was to be available to be passed back
to MIT. So maybe MIT has, or has a right to, Genera? And if MIT has it,
maybe they could/would make it available cheaply/free?
Christopher (Chris) J. Vogt
mailto:vogt@computer.org
Omaha, NE
http://members.home.com/vogt/
From laheadle@midway.uchicago.edu Fri, 20 Mar 1998 16:32:20 -0600
Date: Fri, 20 Mar 1998 16:32:20 -0600
From: Lyn A Headley laheadle@midway.uchicago.edu
Subject: scheme vs common lisp
A consensus seems to have emerged that we need to be practical. We
all want to beg, borrow and steal whatever code we can, right?
With this in mind, I propose that we can *significantly* increase our
productivity by standardizing on RScheme as our implementation
language of choice. RScheme is quite simply a kickass language
implementation under very active development. Features extremely
relevant to this project include: hard real-time GC, Modules, a
persistent object store (already done!), Threads, an object system, a
C interface, and good performance (compiles to C *or* bytecodes).
Anyone who hasn't seriously checked out the language, go to
www.rscheme.org (at least check out the /intro.html page which lists
the main features). They have done so much of the work for us! As
soon as somebody pops that sucker into Linux, the fun can really
begin.
RScheme's main competition from the CL folks seems to be CMUCL whose
main strength, from what I gather, is that it is really fast. I also
_hear_ (please correct me if I am wrong) that the implementation is
huge and slow-compiling with a GC that we would eventually want to rip
out altogether. It is also barely supported.
The choice seems almost obvious to me. *opens the flood gates.*
Let CMUCL die and embrace the wonderful world of RScheme.
But I can hear the rumbles already. Shut up and write some code, Lyn.
After all, the *only* true measure of success is in how much code has
been written. (ok pretend like that was a segue back into the whole
democracey/benevolent dictator thing.) I think people are right that
we can't just keep exchanging emails filled with wild speculation.
But I also think it's quite important to be able to measure the
group's momentum/opinions/community spirit. Has anybody ever written
a web-based tool by which a community can hash out issues? I've been
thinking a little about it and I think it would be extremely useful to
have a site which maintained bunches of current "issues," maybe with a
list of proposed solutions to each issue and a tally of how the
community felt about the issue at a certain time. You'd just need a
server with names/passwords for each member, and people could change
their vote whenever. It would be like an instant "snapshot" of the
group's state of mind. That way people wouldn't just go out and hack
something totally random without at least having some idea in advance
how the group would react. does this sound cool to people?
-Lyn
From mikemac@teleport.com Fri, 20 Mar 1998 15:47:19 -0800 (PST)
Date: Fri, 20 Mar 1998 15:47:19 -0800 (PST)
From: Mike McDonald mikemac@teleport.com
Subject: scheme vs common lisp
>From: Lyn A Headley
>To: lispos@math.gatech.edu
>Subject: scheme vs common lisp
>Date: Fri, 20 Mar 1998 16:32:20 -0600
>
>
>A consensus seems to have emerged that we need to be practical. We
>all want to beg, borrow and steal whatever code we can, right?
>
>RScheme's main competition from the CL folks seems to be CMUCL whose
>main strength, from what I gather, is that it is really fast. I also
>_hear_ (please correct me if I am wrong) that the implementation is
>huge and slow-compiling with a GC that we would eventually want to rip
>out altogether. It is also barely supported.
>
I don't know where people get this idea that CMUCL is "barely"
supported. I'm on the cmucl-imp mailing list and there's always work
going on. Granted, most of the new work starts under Linux (We're
complaining about that????) but it does find its way into the other
ports, with Solaris usually first. (Lot's of new developement takes
place under Solaris too.) Sure, recompiling CMUCL is a daunting task
best left to the foolish. I mean brave! But you don't need to be doing
that either unless you're rewriting the GC or something.
>
>The choice seems almost obvious to me. *opens the flood gates.*
>Let CMUCL die and embrace the wonderful world of RScheme.
>
Gag me with a spoon!
Mike McDonald
mikemac@mikemac.com
From mikemac@teleport.com Fri, 20 Mar 1998 17:03:53 -0800 (PST)
Date: Fri, 20 Mar 1998 17:03:53 -0800 (PST)
From: Mike McDonald mikemac@teleport.com
Subject: scheme vs common lisp
>From: Mike McDonald
>Date: Fri, 20 Mar 1998 15:47:19 -0800 (PST)
>To: laheadle@midway.uchicago.edu, lispos@math.gatech.edu
>Subject: Re: scheme vs common lisp
>
> I don't know where people get this idea that CMUCL is "barely"
>supported. I'm on the cmucl-imp mailing list and there's always work
>going on. Granted, most of the new work starts under Linux (We're
>complaining about that????) but it does find its way into the other
>ports, with Solaris usually first.
It's been pointed out to me that the two main developers prefer
FreeBSD over Linux. The point remains the same however. CMUCL is under
active developement. [Heck, I'm working on the HPUX port. If they've
got me working on it, EVERYONE must be involved! :-) ]
Mike McDonald
mikemac@mikemac.com
From laheadle@midway.uchicago.edu Fri, 20 Mar 1998 19:57:08 -0600
Date: Fri, 20 Mar 1998 19:57:08 -0600
From: Lyn A Headley laheadle@midway.uchicago.edu
Subject: scheme vs common lisp
>>>>> "Mike" == Mike McDonald writes:
Mike> I don't know where people get this idea that CMUCL is
Mike> "barely" supported.
I got the idea from the announcement for CMUCL 17f, at
http://www.cs.cmu.edu/afs/cs.cmu.edu/local/mosaic/common/omega/Web/groups/AI/lang/lisp/impl/cmucl/announce.txt
Although the group lives on (and is working on Dylan/Gwydion), the CMU Common
Lisp project is no longer funded, so only minimal CL support is being done at
CMU.
>place under Solaris too.) Sure, recompiling CMUCL is a daunting task
>best left to the foolish. I mean brave! But you don't need to be doing
>that either unless you're rewriting the GC or something.
We don't want a compiler we can't hack. We do want incremental GC.
>> The choice seems almost obvious to me. *opens the flood
>> gates.* Let CMUCL die and embrace the wonderful world of
>> RScheme.
>>
Mike> Gag me with a spoon!
threads.
persistence.
a runtime system second to none.
I think it's great that you love CMUCL so much. I'm sure it's a fine
system and I wish you good luck with your HPUX port. However, it is
a less appropriate choice for crafting a lisp OS than RScheme.
www.rscheme.org
-Lyn
From davies@pobox.com Fri, 20 Mar 1998 20:37:55 -0700
Date: Fri, 20 Mar 1998 20:37:55 -0700
From: Byron Davies davies@pobox.com
Subject: LM software ownership
>I have this vague recolection that the original license that Symbolics (and
>LMI and TI) had with MIT was such that any improvements (whatever that
>means) to the original MIT Lisp code was to be available to be passed back
>to MIT. So maybe MIT has, or has a right to, Genera? And if MIT has it,
>maybe they could/would make it available cheaply/free?
>
>Christopher (Chris) J. Vogt
Here's what I believe about the ownership of Lisp Machine intellectual
property, after spending most of 1997 trying to get a new Lisp Machine
company started:
1. Symbolics: As you know, the original Symbolics went bankrupt a few years
ago. The assets of Symbolics were purchased by the new company, Symbolics
Technology, which in turn went bankrupt this year. As recently as
September 1997, it seemed as if the asset transfer from Symbolics to
Symbolics Technology had not been legally completed, so for a time the
intellectual property rights were up in the air. I don't know what has
happened since then. After Symbolics Technology acquired the assets, MIT
gave up its royalties from the Symbolics software, although I'm sure they
still retain a proprietary interest.
2. TI: TI exited the Lisp Machine business several years ago. When I
talked with them last April, there was one employee remaining who seemed to
know something about the former Explorer business, but by the time I
recontacted him in May, not only had he been laid off but -- according to
the security guard on the phone -- his entire division had been laid off.
Further investigation through the TI Intellectual Property office revealed
that the Computer Systems Division, which included the Lisp Machine group,
had been sold to HP in 1993, and that TI's remaining software assets were
sold to Sterling Software in early 1997. No one at TI seemed to know
whether the LM software license was included in either of these sales, but
they were willing to investigate further if we would pay high hourly rates
for their intellectual property lawyers. (It's interesting to think that
HP may own the TI Explorer software.) Afterwards, I learned from a former
Stanford employee that TI, on exiting the business, had sold all of its
remaining Lisp Machines to Swiss Air -- but I don't know what kind of a
license Swiss Air owns to the software.
3. LMI: LMI went bankrupt, but was not acquired by anyone, so its
intellectual property may still be in the hands of the bankruptcy court.
"ET", an LMI founder, tells the story of how he acquired the physical
assets of LMI from a Cambridge electronics surplus dealer, but that
transfer -- as I understand the law -- did not legally include the
intellectual property. Anything to add, ET?
4. Mystech and the U.S Army: both these organizations are rumored to have
complete source licences to Symbolics software. When the original
Symbolics went bankrupt, it is possible that both Mystech and the Army
gained additional rights to the code (software contracts are often worded
this way). I don't know if the sources could be pried out of the U.S. Army
under the Freedom of Information Act, nor what this would mean as far as
intellectual property rights.
Anybody know anything contrary or additional?
Byron
From mikemac@mikemac.com Fri, 20 Mar 1998 20:07:26 -0800
Date: Fri, 20 Mar 1998 20:07:26 -0800
From: Mike McDonald mikemac@mikemac.com
Subject: scheme vs common lisp
>To: lispos@math.gatech.edu
>Subject: Re: scheme vs common lisp
>Date: Fri, 20 Mar 1998 19:57:08 -0600
>From: Lyn A Headley
>
>>>>>> "Mike" == Mike McDonald writes:
>
>
> Mike> I don't know where people get this idea that CMUCL is
> Mike> "barely" supported.
>
>I got the idea from the announcement for CMUCL 17f, at
>
>http://www.cs.cmu.edu/afs/cs.cmu.edu/local/mosaic/common/omega/Web/groups/AI/lang/lisp/impl/cmucl/announce.txt
>
>Although the group lives on (and is working on Dylan/Gwydion), the CMU Common
>Lisp project is no longer funded, so only minimal CL support is being done at
>CMU.
Try www.cons.org.
>I think it's great that you love CMUCL so much. I'm sure it's a fine
>system and I wish you good luck with your HPUX port. However, it is
>a less appropriate choice for crafting a lisp OS than RScheme.
That's why we still have a "massive divergence" of options.
Mike McDonald
mikemac@mikemac.com
From coleman@math.gatech.edu Fri, 20 Mar 1998 23:25:11 -0500
Date: Fri, 20 Mar 1998 23:25:11 -0500
From: Richard Coleman coleman@math.gatech.edu
Subject: path to lispos ???
> I agree. If Richard Coleman is still listening I would like him to
> speak directly on the subject of his original goals on starting this
> project. I seem to remember that the original idea was to make a freely
> available system which was similar in design and usefullness to the
> Symbolics/Explorer/Lambda environments.
I'm sorry I've been so quiet in this discussion. I've busy recently
(I'm getting married tomorrow, and will be on my honeymoon all next
week).
Although I got sidetracked on another project, I still have plans
for the lispos project. I'll say more about it when I return,
but it is essentially the same as I said a few months back.
My plans are to start with CMUCL running on FreeBSD. Initially,
you will need a FreeBSD machine in order to cross-compile the source.
Those are my plans. If anyone is interested in this, there will
be plenty to do. I'll say more when I get back.
--
Richard Coleman
coleman@math.gatech.edu
From mbpomije@inav.net Fri, 20 Mar 1998 23:47:03 -0600
Date: Fri, 20 Mar 1998 23:47:03 -0600
From: Martin B. Pomije mbpomije@inav.net
Subject: path to lispos ???
Richard Coleman wrote:
>
> > I agree. If Richard Coleman is still listening I would like him to
> > speak directly on the subject of his original goals on starting this
> > project. I seem to remember that the original idea was to make a freely
> > available system which was similar in design and usefullness to the
> > Symbolics/Explorer/Lambda environments.
>
> I'm sorry I've been so quiet in this discussion. I've busy recently
> (I'm getting married tomorrow, and will be on my honeymoon all next
> week).
>
> Although I got sidetracked on another project, I still have plans
> for the lispos project. I'll say more about it when I return,
> but it is essentially the same as I said a few months back.
>
> My plans are to start with CMUCL running on FreeBSD. Initially,
> you will need a FreeBSD machine in order to cross-compile the source.
>
> Those are my plans. If anyone is interested in this, there will
> be plenty to do. I'll say more when I get back.
>
> --
> Richard Coleman
> coleman@math.gatech.edu
I'd like to help out anyway that I can. (Unfortuneatly not much right
now!) I think that the world needs an alternative to Gates and Co. The
only OSs that can comptete with NT, have similar features, and are in
the same price range are Linux and FreeBSD. Of course these are
variants of Unix, and I really don't think that Unix will ever be a
popular OS among average users because of its terrible user interface.
You can read what I had to say on comp.lang.lisp about how cheap
solutions
almost always win out. (I'd be glad to forward it to any you if you are
interested.)
Unfortuneatly, I'm not a very experienced Lisp programmer. I'm teaching
myself Common Lisp out of "ANSI Common Lisp" by Paul Graham and Scheme
out of "Structure and Interpretation of Computer Programs" by Abelson
and Sussmen. I plan on acquiring a MacIvory by the end of the month.
I'd appreciate any suggestions of how I could increase my skill level so
I could contribute. Thanks.
--
*********************************************
Semi-encrypted email address: m_b_p_o_m_i_j_e_ a_t_ i_n_a_v_ d_o_t_
n_e_t_
All non-solicited commercial email will be billed $1,000.
From jordan@Starbase.NeoSoft.COM Sat, 21 Mar 1998 08:21:18 -0600 (CST)
Date: Sat, 21 Mar 1998 08:21:18 -0600 (CST)
From: Jordan Henderson jordan@Starbase.NeoSoft.COM
Subject: path to lispos ???
Paul Prescod writes:
>I don't think what this project needs is promotion. Probably hundreds of
>individuals have posted messages about it. They just have no direction.
>Running code promotes itself.
I agree that this is true. I certainly don't think that ALL this
project needs is promotion. I was commenting on Rainer's goal of having
a single "rallying point" web presence address and also his comment that
every CS student should know about this project. I think those two
things would go a long way to gathering the project momentum.
If running code exists on a machine that nobody knows about is it running
code?
-Jordan Henderson
jordan@neosoft.com
From chrisb@Ans.Com.Au Sat, 21 Mar 1998 15:10:42 +0000
Date: Sat, 21 Mar 1998 15:10:42 +0000
From: Chris Bitmead chrisb@Ans.Com.Au
Subject: scheme vs common lisp
Lyn A Headley wrote:
> With this in mind, I propose that we can *significantly* increase our
> productivity by standardizing on RScheme as our implementation
> language of choice. RScheme is quite simply a kickass language
> implementation under very active development. Features extremely
> relevant to this project include: hard real-time GC, Modules, a
> persistent object store (already done!), Threads, an object system, a
> C interface, and good performance (compiles to C *or* bytecodes).
> Anyone who hasn't seriously checked out the language, go to
> www.rscheme.org (at least check out the /intro.html page which lists
> the main features). They have done so much of the work for us! As
> soon as somebody pops that sucker into Linux, the fun can really
> begin.
I always knew RScheme was good (which was why I suggested it the
other day), but I hadn't realised how far it had come of late
until you pointed out this URL. Hey, the thing now appears to be
well documented. That used to be the main problem with RScheme.
Hey everyone, I SERIOUSLY suggest you check out RScheme. I reckon
it is probably THE state of the art Lisp-like language
implementation out there now.
For me this now looks like a no-brainer. We should just go and
use RScheme.
--
Chris Bitmead
http://www.ans.com.au/~chrisb
mailto:chrisb@ans.com.au
From yoda@isr.ist.utl.pt Sat, 21 Mar 1998 17:41:00 +0100 (GMT+0100)
Date: Sat, 21 Mar 1998 17:41:00 +0100 (GMT+0100)
From: Rodrigo Ventura yoda@isr.ist.utl.pt
Subject: Benevolent Dictatorship
>>>>> "Rainer" == Rainer Joswig writes:
>> My opinion fall down alot when I tried a trivial factorial
>> function, and observed CMUCL core dumping! How can a factorial
>> function core-dump the CL system with large integers???
Rainer> I don't know. If that happens, this looks like a bug to me.
Rainer> How did the CMUCL maintainers reacted to your bug report?
Hum, I guess I considered myself humble enought to do not dare
pointing a bug in the claimed "best CL system". I probably did
something wrong. But as I was evaluating several CL systems, I simply
passed on to the next one.
>> And when I
>> tried a agent society simulation I developed using CLISP, it kept on
>> GC'ing continuously, and ended-up going nowhere.
Rainer> The trick to make CMU CL useable is to increase the heap and make
Rainer> GC occur less often. Applications will need more space but will
Rainer> GC less frequent. Adding a generational/ephemeral GC
Rainer> would get rid of this. Improve CMU CL!
Increase the heap size???? Well, when I did a "ps ux" I
noticed that CMUCL was using about 22MB of virtual memory! 22MB!!!
There were times when a PC with 10MB hard drive was a luxury! The
CMUCL system is far from 22MB, so why so much waste space (yeah, I
know, Linux do not actually allocates thatg space on swap space, but
rather marks its use until needed).
Regards,
--
--
*** Rodrigo Martins de Matos Ventura, alias
*** yoda@isr.ist.utl.pt, http://www.isr.ist.utl.pt/~yoda
*** Instituto de Sistemas e Robotica, Polo de Lisboa
*** Instituto Superior Tecnico, Lisboa, Portugal
*** PGP Public Key available on my homepage
*** Key fingerprint = 0C 0A 25 58 46 CF 14 99 CF 9C AF 9E 10 02 BB 2A
From papresco@technologist.com Sat, 21 Mar 1998 13:43:46 -0500
Date: Sat, 21 Mar 1998 13:43:46 -0500
From: Paul Prescod papresco@technologist.com
Subject: path to lispos ???
Jordan Henderson wrote:
>
> If running code exists on a machine that nobody knows about is it running
> code?
I just don't see any need to promote LispOS *before* there is running
code. The last time we did that we started this list and in truth it's
been more wasted time than anything. It would have been better if
someone had said: "I've got this neat running kernel and I've set up a
list for anyone who wants to help me with it." Then the infrastructure
could be built. I'm wasting time even now, in this email. :)
Paul Prescod - http://itrc.uwaterloo.ca/~papresco
The United Nations Declaration of Human Rights will be 50 years old on
December 10, 1998. These are your fundamental rights:
http://www.udhr.org/history/default.htm
From joswig@lavielle.com Sat, 21 Mar 1998 19:46:27 +0100
Date: Sat, 21 Mar 1998 19:46:27 +0100
From: Rainer Joswig joswig@lavielle.com
Subject: Benevolent Dictatorship
At 17:41 21.03.98 +0100, Rodrigo Ventura wrote:
> Hum, I guess I considered myself humble enought to do not dare
>pointing a bug in the claimed "best CL system". I probably did
>something wrong.
But what?
> But as I was evaluating several CL systems, I simply
>passed on to the next one.
Without bug reports software will never improve. Without complaining
about software documentation, installation and usage instruction
software will never improve.
Currently there are not too much Lisp users and developers. Vendors
have some excellent systems. But on the free software side we are
not seeing too many Lisp applications (besides some University stuff)
that can be compared to existing C/Perl/whatever based software.
>From people here on this list, who are interested in having something
that does not exist (besides on some exotic platforms), I would
expect also that they are willing to contribute time (e.g. real lines of code and
documentation).
> Rainer> The trick to make CMU CL useable is to increase the heap and make
> Rainer> GC occur less often. Applications will need more space but will
> Rainer> GC less frequent. Adding a generational/ephemeral GC
> Rainer> would get rid of this. Improve CMU CL!
>
> Increase the heap size???? Well, when I did a "ps ux" I
>noticed that CMUCL was using about 22MB of virtual memory! 22MB!!!
Seems not too much for a CL system. Was it on a SPARC?
When I load MCL with my usual software I start it with
30 MB on my laptop. It can be used with 5 MB, though.
Lispworks on my PC currently has (... looking ...) 46MB
after some usage.
I'm starting my Symbolics (Lisp based Genera is the OS)
with some 200-300 MB virtual memory. Sometimes when
I'm doing some log analysis my Lisp Machine gets 600 MB VM.
Doing a full GC then takes a long time (30 minutes and more).
But usually you don't need it very often (once a week?),
due to the other GC mechanism available. The basic Symbolics
Genera image file is around 50 MB on disk.
The machines from 1990 with the Ivory chip (comparable in many
ways to a 40-50 Mhz 68030) were very usable. A Lisp OS
on todays machines would be very^h^h^h^h^hextremely fast. The all in Lisp
approach makes it unnecessary to have too many software
layers (-> interpreting/translating/converting) which are slowing
things down.
>There were times when a PC with 10MB hard drive was a luxury!
When was it? Before or after the stone age? ;-)
Have you looked lately how much disk space current development
environments need (Visual C++, Codewarrior, ...)?
If you are a developer for Oracle they'll send you a
package of 50+ CDROMs (removing the duplicates for
different platforms brings it down to 30+).
The Genera OS from Symbolics is really tiny compared to
those systems. An image, much of the source
code of the OS, and the documentation would spread
to (just a guess), say, 150 MB.
My Symbolics 3640 from 1985 got in 1988 a 600 MB drive!!! We are
living ten years later. It is hard to get drives with less than 2 GB.
Typical laptops have disks between 2-5 GB.
If you want a reasonable Lisp environment or a usable Lisp OS
with GC and all the fun stuff (GUI, mailer, command interpreter,
documentation, browsers, editor, backup software, web server,
web browser, software distribution system, versioned file
system, etc.) be prepared that you will need more than
22 MB.
Actually I don't care that much about space nowadays.
Our own time is much more valuable than a few MB of RAM chips.
From gilham@csl.sri.com Sat, 21 Mar 1998 11:05:10 -0800
Date: Sat, 21 Mar 1998 11:05:10 -0800
From: Fred Gilham gilham@csl.sri.com
Subject: CMUCL (was Re: Benevolent Dictatorship)
My experience with CMUCL has been very positive. I've done a lot of
benchmarking, comparing it to ACL 4.3 running under Linux, and CMUCL
is as fast, or sometimes faster, in almost every area. CMUCL has
improved a lot over the last few years.
The one place where CMUCL falls down is in instance-creation under
CLOS. Note that most CLOS operations besides this one are as fast or
faster in CMUCL as in ACL.
The reason CLOS instance-creation is slow under CMUCL is that it uses
the generic PCL code. There's some discussion of how to fix this kind
of thing in a brief paper by D. Scott Cyphers and David A. Moon that I
ran across called ``Optimizations in the Symbolics CLOS
Implementation''. I've appended their comments about make-instance to
the end of this message. The enhancements they describe are compiler
dependent but there's already support for them in the PCL code.
Anyone interested in this should take a look at the file
`construct.lisp' in the PCL code. It describes the idea and gives the
hooks that would allow implementing the optimizations necessary to
speed up make-instance. I guess one would have to understand both
CMUCL's compiler and CLOS to do it.
This is from the paper I mentioned:
MAKE-INSTANCE
The example implementation of MAKE-INSTANCE given in the CLOS
specification is highly interpretive, and therefore slow. The following
operations can be eliminated or optimized: mapping a class name to a
class object, receiving keyword arguments, checking for invalid keyword
arguments, defaulting unsupplied initialization arguments, evaluating
slot initforms, and initializing slots from initialization arguments and
slot initforms. The necessary operations of allocating storage and
calling user-supplied initialization methods can be streamlined.
Mapping a constant class name to a constant class object is ordinary
constant-folding.
A call to MAKE-INSTANCE with a constant class and constant keywords is
optimized into a call to an automatically generated constructor function
that specializes in creating objects of that class with those
initialization arguments. This eliminates class lookup and all keyword
argument processing (positional arguments are used), and simplifies
defaulting of initialization arguments since the supplied/unsupplied
status of each initialization argument is fixed.
Other calls to MAKE-INSTANCE still call the MAKE-INSTANCE generic
function, but dispatch to an automatically generated constructor method
that specializes in creating objects of that class. Keyword argument
processing and defaulting are still necessary in this case.
The constructor function or method uses inlining of initforms, inlining
of system-defined method bodies, direct calls to user-defined method
functions, loop unrolling, elimination of redundant slot-boundp tests,
and minimized instruction sequences for storing into slots. Since the
system-defined methods called by MAKE-INSTANCE are highly interpretive
(they get the list of slot-descriptions, iterate over them, check if the
slot has any initargs, etc.) the inlining is not done by analyzing the
body of the real method, but instead by a specialized generator function
for each method. The generator functions are similar to macros, but
have access to the class definition and to the sets of initialization
arguments that are known to be supplied, defaulted, or might be either
supplied or defaulted.
These optimizations eliminate all run-time references to the class and
slot-definition metaobjects. The information contained in those objects
has been converted into compiled code instructions. With these
optimizations, MAKE-INSTANCE on Ivory is slightly faster than MAKE-ARRAY
and almost as fast as MAKE-LIST, measured for two slots or elements.
Some care is required to regenerate the automatically generated constructor
functions and methods if the class is redefined, and to arrange to generate
them at load-time rather than at run-time so that the first instantiation of
each class is not slowed down by calling the constructor generator and the
compiler.
From dtc@scrooge.ee.swin.oz.au Sun, 22 Mar 1998 11:01:58 +1000 (EST)
Date: Sun, 22 Mar 1998 11:01:58 +1000 (EST)
From: Douglas Thomas Crosher dtc@scrooge.ee.swin.oz.au
Subject: scheme vs common lisp
> Hey everyone, I SERIOUSLY suggest you check out RScheme. I reckon
> it is probably THE state of the art Lisp-like language
> implementation out there now.
>
> For me this now looks like a no-brainer. We should just go and
> use RScheme.
Some of the RScheme features look quite interesting, a few points:
* if you're serious about writing an OS based on either RScheme or
CMUCL you'll probably want to rewrite the thread and garbage
collection implementations anyway to exploit better integration with
the OS.
* having a compiler you can hack on, as for CMUCL, may help in
exploiting a tight coupling between the various subsystems.
* One strong point of CMUCL is the potential of its object
represention scheme to perform well at basic list allocation and
garbage collection. Do you know the memory allocation overhead for a
basic cons object in RScheme, which is 8 bytes in CMUCL? Just out of
curiosity how does RScheme currently perform on a test of basic list
allocation and garbage collection such as that below which completes
in 16 seconds on CMUCL x86.
Regards
Douglas Crosher
-=-=-
(defvar *a* nil)
(defvar *b* nil)
(defun tst ()
(dotimes (i 20)
(declare (fixnum i))
(setf *b* nil)
(dotimes (j 500000)
(declare (fixnum j))
(push (+ i j 1.2345d0) *b*))))
From davies@pobox.com Sat, 21 Mar 1998 18:11:17 -0700
Date: Sat, 21 Mar 1998 18:11:17 -0700
From: Byron Davies davies@pobox.com
Subject: The Cathedral and the Bazaar
In case anyone hasn't read this article about the general principles behind
Linux's success, it's now been published online (prettified) by First
Monday at http://www.firstmonday.dk/issues/issue3_3/raymond/index.html.
Byron
From davies@pobox.com Sat, 21 Mar 1998 18:26:13 -0700
Date: Sat, 21 Mar 1998 18:26:13 -0700
From: Byron Davies davies@pobox.com
Subject: Crossing the Chasm & Gothic Cathedrals
During the past year, while a partner and I were trying to start up a new
Lisp company, I gave a lot of thought to what might make Lisp "cross the
chasm" into the mainstream of computing. My conclusion was, "It's the
apps, stupid", but we were too focused on the technology -- which we didn't
own -- to make use of the conclusion.
The notion of "crossing the chasm" came from Geoffrey Moore's book of that
title, which I recommend heartily. The book is about taking a high-tech
product into the mainstream by paying attention to principles of technology
diffusion. The basic idea is that adopters of a new technology form a bell
curve, with innovators and early adopters at one end, the mass market in
the middle, and late adopters at the other end. The chasm that companies
fall into is between early adopters and the mass market: they've got a
product that the innovators (the "techies") and the early adopters have
fallen in love with, but they can't get a critical mass of customers to buy
the product. The generic solution is to define a niche market for which
you develop a "whole product", and use this as a lever into the mainstream,
much as Apple did with desktop publishing.
Moore's second book, "Inside the Tornado", talks about what a company
should do once it crosses the chasm and its product starts selling like
hotcakes ("just ship"). His third book, which I haven't seen yet, is "The
Gorilla Game: An investor's guide to picking winners in high technology".
All this serves as an introduction to the following message, from the
"Crossing the Chasm" discussion list. The thread it refers to began with a
flame against existing email solutions. The message itself has an
interesting discussion about products ("Gothic cathedrals") that die
because they start out with TOO MANY features.
Relevant?
Byron
==========
Date: Sat, 21 Mar 1998 08:59:50 -0700
From: Bill Meade
To: "CROSSING THE CHASM discussion list"
Reply-To: CROSSING THE CHASM discussion list
List-Subscribe:
This thread on email has gotten me thinking about 2 things. First, the
idea of "universal inbox" has a strong case of creeping elegance.
Creeping elegance:
A couple years ago I worked as a marketing director at an email software
company that had a product (that won Comdex's best product award) that
was a "universal inbox" because ... it could download email from any
(AOL, Compuserve, Prodigy, etc.) online service. Clearly a different
paradigm than the Netscape/Cooltalk or MS Netmeeting paradigm that has
been evoked in response to Chris O'Leary's musings. What changed the
paradigm?
I had an experience when working with an engineer friend that gave me a
clue. While we were using Cooltalk's white-board, I became bored in
about 5 minutes. I said "This isn't as useful as email." to which my
friend replied "Whaaaaaaaaat are you talking about!" And from there we
drilled into why I was bored and why he was thrilled and how both could
happen on the same internet connection. Bottom line: working style.
I'm an asynchronous person. I want to think up, write down, send, and
forget. My friend on the other hand, is from a long tradition of
engineers arguing while they scribble equations or technical diagrams on
the same piece of paper. In short my friend's working style is very
synchronous. Email is what bores him.
I think this is a clue in addition to Chris O'Leary's observation that
the frictions are so great that drawings are practically impossible to
use in the email paradigm. What we have here are requirements without a
burning mission critical business process to serve as a poster child for
a solution. The internet may be the doorway to friction-free capitalism,
but on the way to the net we have to deal with myriad small frictions
with computers (Get a Mac!), applications software (email), and probably
worst of all communications demons. Anyone else ever had a modem that
isn't demon possessed?
So what?
This makes me think of the second idea harping back to my pocket theory
of gothic cathedrals. The thumbnail of this pocket is that because
market requirements are for fully transformed products, and because
designers must iterate toward redefinition by successive stepping-stone
approximations, initial introductions are usually overly complicated
(i.e., designers are in denial about not knowing true requirements)
gothic cathedrals of functionality. Favorite examples are Lotus Agenda.
The world's most overcomplicated PIM. The thing was so powerful that it
collapsed of its own weight once you had about 2 years worth of contacts
in it.
After the gothic cathedrals like Newton, come the "cherry picking"
designs like the PalmPilot. After Agenda came Lotus Organizer (bought
from outside because Lotus was in denial about the gothic cathedral being
too complicated). The big implications of gothic cathedrals in general
are that:
(1) Cathedrals crush all competitive architectures. No cherry-picker product
can be developed IN THE SAME ORGANIZATION as a gothic cathedral.
(2) If cathedral products are not managed into cherry-picking products
they ruin the market. This is what happened to pen-based computing.
In particular, premature declaration of a mass market will set up
a gothic cathedral to be gradually killed (death from 1000 cuts)
by a cynical media. It is not pricing that ruins high-tech markets
it is promising.
(3) The only people who learn from the experimental trials of a gothic
cathedral
are the cathedral's competitors. The organization putting the
cathedral out
(and this may be an object-oriented proof of predestination) will ALWAYS be
too much in denial to learn. Perhaps because there will be so much
interpersonal turbulence that nobody dares collaborate for fear of
backstabbing. *Note* Once you've worked in a company with this turbulence
you too will spell backstabbing as one word. ;-)
(4) Creative people won't stay at companies selling gothic cathedrals because
the turbulence and denial are effective innoculants against creativity
being harnessed, appreciated, or condoned. Hello Chris!
(5) Investors hate gothic cathedrals because they want to fund cherry-pickers
but don't know them when they see them. So, gothic cathedrals get funded
by people that hate them ... and it shows. This is the true cultural
confict of capitalism.
(6) People with gothic cathedral products love to read Geoffrey Moore because
they hope to recombine the building blocks they've opened veins to
develop. The dream is to "get it right" and come "roaring back" into
a tornado. I've never seen this happen though it does seem possible and
if I had a gothic cathedral product I'd fall into the same death magnet.
I think that if you've opened a vein to develop a product, it can become
a family member and no decent parent will cut an arm off one child and
stitch it onto another. The market however, waits for the whole product.
Closing:
Now I think that email has a bunch of gothic cathedrals right now.
CC:Mail (which looks dormant and unrevised) is one. IMAP is another
which nobody with an installed base who paid, has endorsed. Eudora is
becoming a gothic cathedral (anyone sent voice email lateley?). It seems
like every new internet capability like HTML and RealAudio gets nominated
as "the missing link" between where email is today and the whole product
that will come roaring back into a tornado. However, given the
synchronous/async way people work and the fact that functions we know
belong (like drawing) are not expressive options, I'm guessing that we
won't see a cherry-picking product for a while. Why? Because there is
no burning mission-critical business process to motivate the amputation
of the false arms and legs that email packages have grown.
Bill Meade
bill@ecatalyst.com
(208) 938-0272 H
(208) 396-3145 O
*** To subscribe to chasmlist email requests@ecatalyst.com a message with
no subject and a one line message that says: subscribe chasmlist
From davies@pobox.com Sat, 21 Mar 1998 19:24:27 -0700
Date: Sat, 21 Mar 1998 19:24:27 -0700
From: Byron Davies davies@pobox.com
Subject: scheme vs common lisp
Has anyone ever developed compiler declarations for Scheme?
FYI, MCL 4.0, on a 200 MHz 604E, takes 25+ seconds and allocates 24 bytes
per double-float cell.
Byron
>Just out of
>curiosity how does RScheme currently perform on a test of basic list
>allocation and garbage collection such as that below which completes
>in 16 seconds on CMUCL x86.
>
>Regards
>Douglas Crosher
>
>-=-=-
>
>(defvar *a* nil)
>(defvar *b* nil)
>
>(defun tst ()
> (dotimes (i 20)
> (declare (fixnum i))
> (setf *b* nil)
> (dotimes (j 500000)
> (declare (fixnum j))
> (push (+ i j 1.2345d0) *b*))))
From chrisb@ans.com.au Sun, 22 Mar 1998 05:29:55 +0000
Date: Sun, 22 Mar 1998 05:29:55 +0000
From: Chris Bitmead chrisb@ans.com.au
Subject: scheme vs common lisp
> * One strong point of CMUCL is the potential of its object
> represention scheme to perform well at basic list allocation and
> garbage collection. Do you know the memory allocation overhead for a
> basic cons object in RScheme, which is 8 bytes in CMUCL? Just out of
> curiosity how does RScheme currently perform on a test of basic list
> allocation and garbage collection such as that below which completes
> in 16 seconds on CMUCL x86.
>
> (defvar *a* nil)
> (defvar *b* nil)
>
> (defun tst ()
> (dotimes (i 20)
> (declare (fixnum i))
> (setf *b* nil)
> (dotimes (j 500000)
> (declare (fixnum j))
> (push (+ i j 1.2345d0) *b*))))
I'd be happy to run this on RScheme if someone could convert it
to scheme.
Admittedly my lisp is rather poor compared to my Scheme, but the
above code doesn't make any sense to me.
--
Chris Bitmead
http://www.ans.com.au/~chrisb
mailto:chrisb@ans.com.au
From dtc@scrooge.ee.swin.oz.au Sun, 22 Mar 1998 20:07:20 +1000 (EST)
Date: Sun, 22 Mar 1998 20:07:20 +1000 (EST)
From: Douglas Thomas Crosher dtc@scrooge.ee.swin.oz.au
Subject: scheme vs common lisp
> * One strong point of CMUCL is the potential of its object
> represention scheme to perform well at basic list allocation and
> garbage collection. Do you know the memory allocation overhead for a
> basic cons object in RScheme, which is 8 bytes in CMUCL?
After reading the implementation notes for RScheme; every object in
RScheme has a two word header so a cons object uses 16 bytes of memory
or twice as much as CMUCL, although CMUCL instances similarly have an
effective word header.
Chapter 5 of the implementation notes of RScheme regarding the use of
safe points suggests this may need a rethink for a higher performance
base: "In principle, safe points probably slow a system down
significantly. ... For a system like RScheme which is not likely to
every be that fast, the overhead is not that great."
CMUCL does need to execute some code atomically which has some
overhead but by appropriate code generation and a tight coupling with
the garbage collector it is possible to GC at most points.
Regards
Douglas Crosher
From chrisb@ans.com.au Sun, 22 Mar 1998 11:50:34 +0000
Date: Sun, 22 Mar 1998 11:50:34 +0000
From: Chris Bitmead chrisb@ans.com.au
Subject: scheme vs common lisp
> After reading the implementation notes for RScheme; every object in
> RScheme has a two word header so a cons object uses 16 bytes of memory
> or twice as much as CMUCL, although CMUCL instances similarly have an
> effective word header.
Why 16 bytes, and not 12 bytes?
--
Chris Bitmead
http://www.ans.com.au/~chrisb
mailto:chrisb@ans.com.au
From chrisb@ans.com.au Sun, 22 Mar 1998 14:04:03 +0000
Date: Sun, 22 Mar 1998 14:04:03 +0000
From: Chris Bitmead chrisb@ans.com.au
Subject: Let's begin SchemeOS
Well I've decided I'm going to do some real work on a Scheme OS,
and I invite anybody with the same vision to help me. This is my
vision. If you like my vision, join me.
This is my project plan....
--Step 1--
As I've said before, I can't see enormous point in a Scheme OS
without a Persistent store replacing the file system. That is
where major, order of magnitude increases in productivity are
going to occur. This is where the superiority of the system will
make UNIX/Windows junkies sit up and take notice. It removes the
need for programs to continually convert everything from disk to
memory representation, but more importantly, it allows a user of
the system to easily write cute little Scheme scripts that do
incredibly powerful things. Whereas on UNIX you now need
sophisticated packages like procmail to say filter your mail,
instead with Scheme OS you would write a few little obvious
Scheme statements that could do the same thing. It is cute LITTLE
things like this which will make SchemeOS great. Little bits of
code that people will contribute that will solve big problems
through pure elegance.
It therefore follows, that STEP 1 for this Scheme OS, is to
design an initial object model for the things in the operating
system.
The design phase will answer questions like...
What sort of hierarchy will be in the persistent store?
What sort of object will store an email message?
What sort of object will store a text file?
How to store executable bits of code?
Should there be objects to represent versions?
What objects do we need to implement security?
An example of what comes out of this might be that we have mail
folders which are collections of mail objects. Mail objects might
consist of a FROM text member, a TO text member, a Subject text
member and a mail text member. I'll leave you to speculate on
what object methods the mail object and mail collection objects
might have.
The end result will be a huge object model. Even if the project
ends here, I think we will have left something useful for some
future effort to start from.
--Step 2--
But of course, we don't want it to stop there. Once the object
model is done, the basic object structure can be coded in Scheme
(Probably RScheme, since it already works with a persistent
store).
Once that's done, then a framework is in place, that lots of
people can come along and do little bits and pieces without being
overwhelmed. Like someone with a couple of hours to spare can
write some Scheme to convert a UNIX mail file into a Scheme mail
object in the persistent store.
I like the functional programming model, so the object model will
be designed to not conflict with the functional programming
paradigm as much as is reasonable.
The system shall be implemented on top of UNIX, for all the
reasons previously mentioned. Personally I shall be using Linux.
Therefore, the initial bits of code written will be done to hide
the UNIX view of the universe, and to instead provide a view of
things which is ideal to SchemeOS. Things like code to convert
UNIX mail files to SchemeOS mail objects. That way code built on
top will not be aware that underneath it all it is really UNIX
that is delivering email.
At some future time, some people may want to provide ways to
remove UNIX all together. That is too far in the future to
contemplate at this stage. What we need now is something that
proves the concept, rather than trying to re-invent everything
from the ground up. Lets get the basic object interfaces right,
and implement those interfaces in whatever way gets things
working fast.
--Step 3--
Once all the basic objects are in place and doing basic things.
To use the email example again... Once we have a email object
that delivers your mail (behind the scenes via UNIX), then basic
apps can start to evolve. Like UNIX history, these apps will
start off with basic apps, which will slowly evolve into more
sophisticated apps. UNIX started with the basic "mail" program,
which then evolved to elm, pine etc etc.
Unlike others, I'm not overly concerned about getting emacs
working. The reason is that current implementations of Emacs, are
very much devoted to the UNIX view of the universe. That is,
everything is a text file, and everything is stored in a UNIX
file system. That means porting emacs straight out is not
terribly useful. Eventually however, a good deal of Emacs may be
able to be ported to SchemeOS, albeit working quite a lot
differently. In any case, text files will be much less important
in Scheme OS, and therefore Emacs will be quite a lot less
important too, since it is primarily a text editing tool. Until
SchemeOS gets it's own text editor, we can use a UNIX editor, and
write a Scheme program to import the UNIX text file into a Scheme
text object. I've never used a Structure editor, so I don't know
how good they can be, but maybe SchemeOS might have very little
need indeed for text editors, if we decide a structure editor is
a better way to write Scheme.
--Step 4--
Once we have implemented enough of the system that we have proved
the concept to ourselves, only then we shall tackle the hard
technical issues. Issues like whether RScheme is the right scheme
to use, whether the persistent store we are using is good enough
for our purposes. Whether the thread model we choose will work
well with multiple users. Whether SchemeOS should be able to work
without UNIX. Whether we can get Lisp and Scheme to work
together. All these issues are too hard to tackle right at the
beginning. We need to have something now that is very clear in
it's goals, and very functional in what it gets done. People will
rise up later to tackle these things. Expert people who are
inspired by our vision, and skilled enough to implement it right.
-- What to do now--
I don't know if it appropriate to continue to use this mailing
list or not. Since isn't a lot else is going on, I would hope so
and presumably everyone else might find the discussion useful,
even if they ultimately intend to build a LispOS of some other
vision. If it is not considered appropriate to use this mailing
list some other host will need to be found.
The first step then is to put forward a list of objects that we
need to design. Objects to hold all the important sorts of data
that UNIX would store in text files, and objects to organise
those other objects.
Once we have that list of objects, we shall design interfaces.
Then we shall code the basic structure of the objects. Then we
shall implement them. Then we shall build apps that use them.
--
Chris Bitmead
http://www.ans.com.au/~chrisb
mailto:chrisb@ans.com.au
From papresco@technologist.com Sun, 22 Mar 1998 10:30:56 -0500
Date: Sun, 22 Mar 1998 10:30:56 -0500
From: Paul Prescod papresco@technologist.com
Subject: Let's begin SchemeOS
Chris Bitmead wrote:
>
> As I've said before, I can't see enormous point in a Scheme OS
> without a Persistent store replacing the file system. That is
> where major, order of magnitude increases in productivity are
> going to occur. This is where the superiority of the system will
> make UNIX/Windows junkies sit up and take notice. It removes the
> need for programs to continually convert everything from disk to
> memory representation, but more importantly, it allows a user of
> the system to easily write cute little Scheme scripts that do
> incredibly powerful things.
Well, it doesn't make sense to go into this whole debate again, but I
think you've misplaced the "blame" for Unix's hassles. The problem is
not that Unix has a filesystem, but that software usually stores
information in that filesystem in random, incompatible file formats with
no natural mapping to memory objects. On a system with a file system
where the files are persistent objects, I can do this:
(define bad-guys (read-file "/etc/bad.lsp"))
(define users (read-file "/etc/passwd.lsp"))
(write-file
(filter
(lambda (x) (member x bad-guys)))
"/etc/passwd.lsp")
Even Unix allows this!
Paul Prescod - http://itrc.uwaterloo.ca/~papresco
"I want to give beauty pageants the respectability they deserve."
- Brooke Ross, Miss Canada International
From chrisb@ans.com.au Sun, 22 Mar 1998 16:09:09 +0000
Date: Sun, 22 Mar 1998 16:09:09 +0000
From: Chris Bitmead chrisb@ans.com.au
Subject: Let's begin SchemeOS
> Well, it doesn't make sense to go into this whole debate again, but I
> think you've misplaced the "blame" for Unix's hassles. The problem is
> not that Unix has a filesystem, but that software usually stores
> information in that filesystem in random, incompatible file formats with
> no natural mapping to memory objects. On a system with a file system
> where the files are persistent objects, I can do this:
>
> (define bad-guys (read-file "/etc/bad.lsp"))
> (define users (read-file "/etc/passwd.lsp"))
> (write-file
> (filter
> (lambda (x) (member x bad-guys)))
> "/etc/passwd.lsp")
>
> Even Unix allows this!
If you do the above, then I guess you have an object file system,
albeit one that is
a) inefficient - presumably the .lsp files are ascii text
b) not at all transparent. Every load and store has to be
explicit, which kinda defeats the purpose. Say goodbye to all
that elegance.
c) Not very practical - you can't have object references that
cross the boundary between one file and another file. This is a
big killer.
d) Not convenient. You would have to decide on some arbitrary
break down on how much to store in one file.
Your above example in SchemeOS with persistent store file system
would look something like this I guess...
(set! *user-list* (filter (lambda (x) (member (name x)
*bad-guys))) *user-list))
Even just this one example shows the amount of unnecessary crud
that can be gotten rid of.
Once you realise that everything should be a lisp object (you
seem to have realised that already), there becomes this arbitrary
problem of which objects to store in which file when using a
UNIX file system. If you have a mail folder with mail messages,
do you store each message in a separate file, or lots of them
together in one file? What if you want a mail message in two
different folders, but you don't want to duplicate it? In Unix,
you can't do it. Inevitably, if you tried to use UNIX files for
storing data, you would end up storing everything in one file to
avoid breaking links, and not all of the links that will
eventuate can be planned in advance. And if you're going to store
everything in one file, then it has to be a real persistent
store. You can't be re-writing 100 Meg just because you changed
one object.
If a SchemeOS had something equivilent to a /etc/password it
wouldn't be just a lame structure of various strings. There would
be a collection of user objects. Each user object would have a
reference to some kind of root object for that user (like a home
directory) You could directly navigate from the user object to
their personal objects. Those objects might include say a
document whose author points back to the global user object.
Refererences criss-cross the universe allowing direct navigation
everywhere.
The whole deal with the persistent store is about object
orientation. That is storing the code that manipulates data with
the data itself. If there was a /etc/password equivilent it would
be a collection with methods appropriate for managing users.
I must ask you... Why would you want to muck around with a
conventional UNIX file system at all given all its disadvantages?
Just for backward compatibility perhaps?
--
Chris Bitmead
http://www.ans.com.au/~chrisb
mailto:chrisb@ans.com.au
From kragen@pobox.com Sun, 22 Mar 1998 16:12:45 -0500 (EST)
Date: Sun, 22 Mar 1998 16:12:45 -0500 (EST)
From: Kragen kragen@pobox.com
Subject: scheme vs common lisp
On Sun, 22 Mar 1998, Chris Bitmead wrote:
> > After reading the implementation notes for RScheme; every object in
> > RScheme has a two word header so a cons object uses 16 bytes of memory
>
> Why 16 bytes, and not 12 bytes?
One word is 32 bits on most modern machines. Thus, one word for the car, one
word for the cdr, two words for the header -- total four words. 32 bits is 4
bytes, thus 16 bytes per cons.
Kragen
From lynbech@daimi.aau.dk Sun, 22 Mar 1998 22:30:18 +0100 (CET)
Date: Sun, 22 Mar 1998 22:30:18 +0100 (CET)
From: Christian Lynbech on satellite lynbech@daimi.aau.dk
Subject: Let's begin SchemeOS
>>>>> "Chris" == Chris Bitmead writes:
Chris> Unlike others, I'm not overly concerned about getting emacs
Chris> working. The reason is that current implementations of Emacs,
Chris> are very much devoted to the UNIX view of the universe. That
Chris> is, everything is a text file, and everything is stored in a
Chris> UNIX file system.
This, I guess, depends on your point of view (fanatism warning: I
*love* emacs). While emacs does have a number of filesystem oriented
functions, these a by no means essential.
The basic structure is the `buffer' which basically just is a string
with associated information (with the concept of buffer local variables
probably being the most important).
Chris> In any case, text files will be much less important in Scheme
Chris> OS, and therefore Emacs will be quite a lot less important too,
Chris> since it is primarily a text editing tool.
Well, text remains an important part of users life, no matter how it
is stored, and it would takes something of a hack to beat emacs at
editing text.
Chris> Until SchemeOS gets it's own text editor, we can use a UNIX
Chris> editor
Then why not simply use UNIX emacs?
Chris> I've never used a Structure editor, so I don't know how good
Chris> they can be
I have somewhere some references to a couple of articles written by
Richard Stallmann and (I think) Erik Sandewall in ACM Computing
Surveys (I think) discussing the pros and cons of structure editors. I
can try to dig them up if you like.
---------------------------+--------------------------------------------------
Christian Lynbech | Telebit Communications A/S
| Fabrikvej 11, DK-8260 Viby J
Phone: +45 8628 8176 | email: chl@tbit.dk --- URL: http://www.tbit.dk
---------------------------+--------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- petonic@hal.com (Michael A. Petonic)
From rideau@ens.fr Mon, 23 Mar 1998 01:45:41 +0100 (CET)
Date: Mon, 23 Mar 1998 01:45:41 +0100 (CET)
From: Fare Rideau rideau@ens.fr
Subject: Let's begin SchemeOS
>>: Paul Prescod
>: Chris Bitmead
>> The problem is not that Unix has a filesystem,
>> but that software usually stores information in that filesystem
>> in random, incompatible file formats with no natural mapping
>> to memory objects.
"Natural mapping to memory objects" sounds wrong to me
(at least in the context of a "standard encoding"),
but maybe that's just because I'm interested
in heterogeneous distributed systems,
and also because I think that memory and disk have
different enough space/time constraints,
so that they require altogether different encodings
if performance means anything.
>>[Follows example of lisp script to access a SEXP encoded /etc/passwd.lsp]
> If you do the above, then I guess you have an object file system,
> albeit one that is
>
> a) inefficient - presumably the .lsp files are ascii text
> b) not at all transparent. Every load and store has to be
> explicit, which kinda defeats the purpose. Say goodbye to all
> that elegance.
> c) Not very practical - you can't have object references that
> cross the boundary between one file and another file. This is a
> big killer.
> d) Not convenient. You would have to decide on some arbitrary
> break down on how much to store in one file.
>
And you forget, which is most important:
e) not consistent with respect to concurrent access and/or power failures.
A *major* advantage of a system-managed object-based persistent store
is that you no longer have to emulate complicated unenforcable
locking mechanisms (or forget them and be suffer someday).
These are transparently managed by the meta-object protocol,
and from the user point of view, modifying the /etc/passwd
will be an atomic transaction (or part of a larger transaction).
> (set! *user-list* (filter (lambda (x) (member (name x) *bad-guys*))
> *user-list*))
>
> Even just this one example shows the amount of unnecessary crud
> that can be gotten rid of.
Also, a system-managed object store has a great advantage,
that makes possible lots of things just unimaginable with a filesystem:
f) since there is no need for a low-level standard representation,
data can be made of high-level objects instead,
and new fields/annotations can be dynamically added to them,
so that the user "list" can be a high-level extensible knowledge base
instead of a mere clumsy statically-defined ground-level database.
g) Another advantage of the absence of low-level standard representation
is precisely that the actual representation might be dynamically selected
by the system for maximal space/size performance
depending on the intended use
instead of having to comply to a stubborn static compromise
between space, size, and human readability.
Note that these last two points are about
high-level standards allowing metaprogramming and reflection,
as opposed to low-level standards tying you down to one implementation
with static definitions.
I agree with the rest of Chris' remarks
(as well as with most of what he posts here).
> I must ask you... Why would you want to muck around with a
> conventional UNIX file system at all given all its disadvantages?
> Just for backward compatibility perhaps?
As an aside, and even though I hate all this cruft,
I do think backward compatibility should be some of a concern,
be it only to transfer data to and from the LispOS,
until we can fully migrate all our data toward a trusted LispOS,
PS:
* I still think that there is room for several LispOS projects,
and since we obviously can't agree on a unified project anyway,
we can at least agree to disagree on what to do next:
using Scheme, ANSI CL, or another dialect,
basing implementation on RScheme or CMUCL,
hosting on self (or Flux) or Linux/BSD,
starting from the application or system side,
storing objects with a filesystem or a persistent store.
* As for my personal opinion on what *I* am going to do,
I have an article underway about what a Reflective Architecture is;
but everyone should be doing what *one* thinks is best
that one can contribute to.
When some code eventually appears and gets to be used,
the path to a unified projet might (or not) be clearer.
* As for getting code available, would it be possible
that we, as a consortium of users, convince (with words and/or money)
whoever still owns Lisp Machine code
(Symbolics successors, Xerox, TI, HP, MIT, etc)
to make it publically available?
I am ready to participate financially in such an operation.
Maybe the demise of Symbolics is an occasion to
buy their assets for cheap!?
Else, when will some/all of this code become public domain anyway?
US Legal affairs are sure not *my* specialty...
## Faré | VN: Уng-Vû Bân | Join the TUNES project! http://www.tunes.org/ ##
## FR: François-René Rideau | TUNES is a Useful, Not Expedient System ##
## Reflection&Cybernethics | Project for a Free Reflective Computing System ##
"I think sex is better than logic, but I can't prove it."
From papresco@technologist.com Sun, 22 Mar 1998 21:33:59 -0500
Date: Sun, 22 Mar 1998 21:33:59 -0500
From: Paul Prescod papresco@technologist.com
Subject: Let's begin SchemeOS
Chris Bitmead wrote:
>
> If you do the above, then I guess you have an object file system,
> albeit one that is
>
> a) inefficient - presumably the .lsp files are ascii text
No, they are whatever is the "standard file format" for the operating
system.
> b) not at all transparent. Every load and store has to be
> explicit, which kinda defeats the purpose. Say goodbye to all
> that elegance.
You think that this is a flaw, but it is actually a strength.
People don't want a "transparent" file system:
* they want to know when something is saved (the word "saved" has its
root the word "safe")
* they want to know *what drive* something is on (for reasons of
storage size, portability, security, and physical locality)
* they want to name their data objects
* they want to group those data objects with hierarchical names (at
least)
> c) Not very practical - you can't have object references that
> cross the boundary between one file and another file. This is a
> big killer.
That isn't true. HTML, SGML and "OLE" objects have references that cross
boundaries between files all of the time. Managing those links is a hard
problem, whether you have a hierarchical file system or an "object file
system", because files disappear, drives are removed, and so forth.
> d) Not convenient. You would have to decide on some arbitrary
> break down on how much to store in one file.
This break-down may not be convenient for programmers, but it is very
convenient for users. It is this breakdown that allows me to move a
particular "file" to a floppy disk or send it to a friend across the
Internet.
> Your above example in SchemeOS with persistent store file system
> would look something like this I guess...
>
> (set! *user-list* (filter (lambda (x) (member (name x)
> *bad-guys))) *user-list))
Egad. I don't even want to *know* the number of variables defined in
your top level namespace! You'll notice that my examples were in /etc/.
The equivalent in your model is probably something like:
(cadr (assoc 'user-list
(cadr (assoc 'etc *root*)))
That's not so much more convenient, and as soon as you make a syntax for
shortening it, you are essentially reinventing the hierarchical path
system.
> Once you realise that everything should be a lisp object (you
> seem to have realised that already), there becomes this arbitrary
> problem of which objects to store in which file when using a
> UNIX file system. If you have a mail folder with mail messages,
> do you store each message in a separate file, or lots of them
> together in one file?
Probably one per file so that they can be moved and deleted independent
of each other. Mobility defines granularity.
> What if you want a mail message in two
> different folders, but you don't want to duplicate it? In Unix,
> you can't do it.
You make a link. In UNIX you *can* do it, if folders are directories. If
folders are files, then you make a hypertext link (using XML, OLE or any
other linking technology).
> The whole deal with the persistent store is about object
> orientation. That is storing the code that manipulates data with
> the data itself. If there was a /etc/password equivilent it would
> be a collection with methods appropriate for managing users.
That sounds good, but a bug in that software will render your
/etc/passwd inoperable -- like a bug in Word renders a .doc file
inoperable. That's exactly what we should be running away from.
Important data should live in well documented data formats accessible to
any program that wants access to it.
> I must ask you... Why would you want to muck around with a
> conventional UNIX file system at all given all its disadvantages?
> Just for backward compatibility perhaps?
I haven't advocated a UNIX file system. I advocated a *file system* --
e.g. a user-level concept of persistent store distinct from RAM where
objects can be moved around, deleted and otherwise managed indepedent of
the code that created them.
Paul Prescod - http://itrc.uwaterloo.ca/~papresco
"I want to give beauty pageants the respectability they deserve."
- Brooke Ross, Miss Canada International
From chrisb@Ans.Com.Au Mon, 23 Mar 1998 04:12:18 +0000
Date: Mon, 23 Mar 1998 04:12:18 +0000
From: Chris Bitmead chrisb@Ans.Com.Au
Subject: Let's begin SchemeOS
Paul Prescod wrote:
> > b) not at all transparent. Every load and store has to be
> > explicit, which kinda defeats the purpose. Say goodbye to all
> > that elegance.
>
> You think that this is a flaw, but it is actually a strength.
>
> People don't want a "transparent" file system:
>
> * they want to know when something is saved (the word "saved" has its
> root the word "safe")
I tend to agree that people want to know when things are saved.
But why on earth is that an argument against an object file
system?????
> * they want to know *what drive* something is on (for reasons of
> storage size, portability, security, and physical locality)
I tend to agree. But why on earth is that an argument against an
object file system?????
> * they want to name their data objects
They most definitely don't want to name every object in the
system, from every cons cell, number, collection etc. Only a very
limited number of objects need a name. A word document is
actually a big collection of OLE objects in a proprietry format.
But you don't want to name every object within there.
> * they want to group those data objects with hierarchical names (at
> least)
They want to group things hierarchially, but NOT JUST
hierachially. Tree hierachies are only a subset of the infinite
ways people would like to group, index and link their data.
A conventional UNIX style file system is merely a very small
subset of an object file system.
> > c) Not very practical - you can't have object references that
> > cross the boundary between one file and another file. This is a
> > big killer.
>
> That isn't true. HTML, SGML and "OLE" objects have references that cross
> boundaries between files all of the time. Managing those links is a hard
> problem, whether you have a hierarchical file system or an "object file
> system", because files disappear, drives are removed, and so forth.
Yes, it is a hard problem. That is why these links need to be
managed as automatically as possible. Objects shouldn't just
"disappear", but yes when drives are moved that needs to be
catered for, and an object file system can do that just fine.
> > d) Not convenient. You would have to decide on some arbitrary
> > break down on how much to store in one file.
>
> This break-down may not be convenient for programmers, but it is very
> convenient for users. It is this breakdown that allows me to move a
> particular "file" to a floppy disk or send it to a friend across the
> Internet.
It's not very convenient for users at all. Like when Word
documents have links to external things, the user never knows
what to do and the recipient of the Word doc is inevetiably
missing things.
With an object file system, this can be made much more automatic.
Just say copy this object and anything that is directly or
indirectly linked to it onto a floppy. There is no problem here.
> (cadr (assoc 'user-list
> (cadr (assoc 'etc *root*)))
>
> That's not so much more convenient, and as soon as you make a syntax for
> shortening it, you are essentially reinventing the hierarchical path
> system.
I don't much care at the moment whether they are global things or
assoc lists or whatever. Yeah sure, hierarchies are pretty
important structures. Nobody wants to throw out hierarchies all
together. The point is tha hierarchies are much too limiting.
They are just a mere subset of what can be done.
> > Once you realise that everything should be a lisp object (you
> > seem to have realised that already), there becomes this arbitrary
> > problem of which objects to store in which file when using a
> > UNIX file system. If you have a mail folder with mail messages,
> > do you store each message in a separate file, or lots of them
> > together in one file?
>
> Probably one per file so that they can be moved and deleted independent
> of each other. Mobility defines granularity.
Then eventually you get to the stage of having one object per
file, even down to one cons cell per file, because you never can
be sure what you want people to have external links to.
> > What if you want a mail message in two
> > different folders, but you don't want to duplicate it? In Unix,
> > you can't do it.
>
> You make a link. In UNIX you *can* do it, if folders are directories. If
> folders are files,
Ok, you have hard links all over the place. Put one object in
each file, and that might be one way to implement a true object
database. A very inefficient one if it's based on a UNIX file
system. If you're talking about some other, to-be-built file
system, that works like this with one object per file, then you
are talking about an object database. Make the path names
transparent and we are talking about the same thing.
> then you make a hypertext link (using XML, OLE or any
> other linking technology).
I can only assume you havn't ever used an object database very
much???
> That sounds good, but a bug in that software will render your
> /etc/passwd inoperable -- like a bug in Word renders a .doc file
> inoperable. That's exactly what we should be running away from.
> Important data should live in well documented data formats accessible to
> any program that wants access to it.
You've got to be joking!!!!! If every man and his dog knows the
format of an important file/object, then everybody will write
their own code to update it and potentially stuff it up. If
updating important data is hidden behind well defined and
debugged interfaces, updating it can be made safe. That is the
whole point of OO, to stop people updating data in ways they
shouldn't. Instead make methods to update things the right way.
The vipw, was an extremely crude program made to do this on UNIX
with /etc/passwd, but it was never enforced.
> > I must ask you... Why would you want to muck around with a
> > conventional UNIX file system at all given all its disadvantages?
> > Just for backward compatibility perhaps?
>
> I haven't advocated a UNIX file system. I advocated a *file system* --
> e.g. a user-level concept of persistent store distinct from RAM where
> objects can be moved around, deleted and otherwise managed indepedent of
> the code that created them.
Being able to manipulate data apart from the code that relates to
them is the antithesis of OO. I suggest you read some basic OO
stuff first.
All I am advocating is removing limitations of conventional style
file systems. You can use an OO file system just like UNIX if you
want to, it's just that you're not limited to that.
--
Chris Bitmead
http://www.ans.com.au/~chrisb
mailto:chrisb@ans.com.au
From chrisb@Ans.Com.Au Mon, 23 Mar 1998 04:27:42 +0000
Date: Mon, 23 Mar 1998 04:27:42 +0000
From: Chris Bitmead chrisb@Ans.Com.Au
Subject: Let's begin SchemeOS
Christian Lynbech on satellite wrote:
>
> >>>>> "Chris" == Chris Bitmead writes:
>
> Chris> Unlike others, I'm not overly concerned about getting emacs
> Chris> working. The reason is that current implementations of Emacs,
> Chris> are very much devoted to the UNIX view of the universe. That
> Chris> is, everything is a text file, and everything is stored in a
> Chris> UNIX file system.
>
> This, I guess, depends on your point of view (fanatism warning: I
> *love* emacs). While emacs does have a number of filesystem oriented
> functions, these a by no means essential.
Well yes. I imagine that SchemeOS would end up with something
fairly Emacs like, if not Emacs itself. Whatever editors people
like enough, they will take the time to port.
> Chris> In any case, text files will be much less important in Scheme
> Chris> OS, and therefore Emacs will be quite a lot less important too,
> Chris> since it is primarily a text editing tool.
>
> Well, text remains an important part of users life, no matter how it
> is stored, and it would takes something of a hack to beat emacs at
> editing text.
That's fine. I use emacs myself. But you might be surprised how
much text editing can be elimitated.
> Chris> Until SchemeOS gets it's own text editor, we can use a UNIX
> Chris> editor
>
> Then why not simply use UNIX emacs?
Sure, use whatever you like.
> Chris> I've never used a Structure editor, so I don't know how good
> Chris> they can be
>
> I have somewhere some references to a couple of articles written by
> Richard Stallmann and (I think) Erik Sandewall in ACM Computing
> Surveys (I think) discussing the pros and cons of structure editors. I
> can try to dig them up if you like.
Yeah, that might be interesting.
--
Chris Bitmead
http://www.ans.com.au/~chrisb
mailto:chrisb@ans.com.au
From cmh@greendragon.com Mon, 23 Mar 1998 00:25:49 -0600
Date: Mon, 23 Mar 1998 00:25:49 -0600
From: Chris Hanson cmh@greendragon.com
Subject: Pre-Scheme -> assembly?
I've been looking at Scheme48, and I also read Kelsey's paper on its use of
Pre-Scheme for implementing the Scheme48 VM.
How hard would it be to get the Pre-Scheme compiler to emit assembly rather
than C?
How hard would it be to eliminate OS dependencies from the generated code
so it could (for example) be run on the metal?
From yoda@isr.ist.utl.pt Mon, 23 Mar 1998 12:04:28 +0100 (GMT+0100)
Date: Mon, 23 Mar 1998 12:04:28 +0100 (GMT+0100)
From: Rodrigo Ventura yoda@isr.ist.utl.pt
Subject: Let's begin SchemeOS
>>>>> "Paul" == Paul Prescod writes:
Paul> You think that this is a flaw, but it is actually a strength.
Paul> People don't want a "transparent" file system:
Paul> * they want to know when something is saved (the word "saved" has its
Paul> root the word "safe")
Paul> * they want to know *what drive* something is on (for reasons of
Paul> storage size, portability, security, and physical locality)
Paul> * they want to name their data objects
Paul> * they want to group those data objects with hierarchical names (at
Paul> least)
I may be right as far as old-fashion computational people's
desires are. But what we are proposing here is _not_ a replacement for
UNIX. It is LispOS, with a bunch of new compuitational concepts that
go beyond the old-fashioned shell-program-disk design.
Do you know what your words make me remind of? When
multitasking OS's appeared, and people prefered older ones, because
"they wanted to know in what memory address a program started". They
didn't liked code relocation, neither virtual memory, because in that
way they didn't knew whenever data were in memory or in disk.
What we want is to dettach from old computational paradigms
and start riding towards a new one. Doesn't it sound sexy?
Let me now answer how this new paradigm can answer your
questions:
* There is a fsync() syscall to assure all cached data is
saved. In the same fashion, a sync-like function could exist to assure
that all objects are saved on disk;
* Explicit drive specification could be attained as
needed. Otherwise, let the system organize itself. Wouldn't it be
great, to have several disks and letting the system take care of
distributing them?
* Any object can be bounded to a symbol (actually, the symbol
is bound to that object);
* Hierarchy of objects is crucial for LispOS. The old package
system must be improved.
Regards,
--
--
*** Rodrigo Martins de Matos Ventura, alias
*** yoda@isr.ist.utl.pt, http://www.isr.ist.utl.pt/~yoda
*** Instituto de Sistemas e Robotica, Polo de Lisboa
*** Instituto Superior Tecnico, Lisboa, Portugal
*** PGP Public Key available on my homepage
*** Key fingerprint = 0C 0A 25 58 46 CF 14 99 CF 9C AF 9E 10 02 BB 2A
From yoda@isr.ist.utl.pt Mon, 23 Mar 1998 12:18:57 +0100 (GMT+0100)
Date: Mon, 23 Mar 1998 12:18:57 +0100 (GMT+0100)
From: Rodrigo Ventura yoda@isr.ist.utl.pt
Subject: Release 0.01 of LispOS
Hi. As I posted before, and generally anyone agrees,
experimental code is needed to get LispOS started. I've done some
experimenting with some concepts that were discussed before. Here's
what I got:
I think that the best plataform to begin with is a bare Linux
kernel. So, I compiled a bare-bones, minimal Linux kernel (about 200k
compressed kernel vmlinuz) and a minimal filesystem with just /dev and
corresponding generic devices (MAKEDEV generic). Next, a lisp virtual
machine that dialogs directly with the kernel. So, I picked scheme48
and statically compiled with. Ok, it still uses libc statically, but
that could be stripped of later, and replaced for a scheme interface
to the linux syscalls -- a generic way of making this interface is
needed. Maybe something like parsing the *.h files and translating it
into a module structure. But right now, it's just a statically linked
scheme48 without dynamic linking (modify a #define in some .h
file). Then I put the vm and the bootstrap image on /lispos, and
configured lilo to boot with init=/lispos/scheme48vm. The thing is, it
boots ok, and starts scheme48 right away! (what a surprise 8-).
Anyway, this is a minimal LispOS 8-)
What remains to be done? Well, everything I guess. My first
needs were:
* adjust the keymap to pt;
* readline facility would be great;
* an editor is required -- something like emacs?
* a scheme to save stuff other than the bulk image dump;
* and of course, ways to mount stuff, put the / writtable, etc.
I'm curious about RScheme, but I wonder whenever it is as easy
to dettach from the rest of UNIX as scheme48 was. From what was here
discussed, I find RScheme much more appealing.
Regards,
--
*** Rodrigo Martins de Matos Ventura, alias
*** yoda@isr.ist.utl.pt, http://www.isr.ist.utl.pt/~yoda
*** Instituto de Sistemas e Robotica, Polo de Lisboa
*** Instituto Superior Tecnico, Lisboa, Portugal
*** PGP Public Key available on my homepage
*** Key fingerprint = 0C 0A 25 58 46 CF 14 99 CF 9C AF 9E 10 02 BB 2A
From joswig@lavielle.com Mon, 23 Mar 1998 13:42:51 +0100
Date: Mon, 23 Mar 1998 13:42:51 +0100
From: Rainer Joswig joswig@lavielle.com
Subject: Let's begin SchemeOS
At 12:04 Uhr +0100 23.03.1998, Rodrigo Ventura wrote:
> Let me now answer how this new paradigm can answer your
>questions:
> * There is a fsync() syscall to assure all cached data is
>saved. In the same fashion, a sync-like function could exist to assure
>that all objects are saved on disk;
> * Explicit drive specification could be attained as
>needed. Otherwise, let the system organize itself. Wouldn't it be
>great, to have several disks and letting the system take care of
>distributing them?
> * Any object can be bounded to a symbol (actually, the symbol
>is bound to that object);
> * Hierarchy of objects is crucial for LispOS. The old package
>system must be improved.
>
> Regards,
How an OS with persistent objects and without files can be seen
from the (now defunct) Newton OS.
- basic storage mediums are memory cards.
- you can use more than one memory card plus internal memory.
- cards are being formatted to carry a bunch of soups.
- a soup has a name.
- soups on different storage locations with the same soup name
will be merged.
- you can store frames in those soups.
- you can move data from on storage location to another within
the same merged soup.
- data put in the soup will be automatically indexed and compressed.
- you can build any kind of access mechanisms (by date, name,
content, hierarchical, etc.) on top of that.
- you can remove and soups to a running system.
This all fits very well into an elegant architecture
(frames, ...).
I'm not sure if a Lisp OS should use it as a primary
method for storing data, but atleast it is a possibility.
Rainer Joswig
Rainer Joswig, Lavielle EDV Systemberatung GmbH & Co, Lotharstrasse 2b, D22041
Hamburg, Tel: +49 40 658088, Fax: +49 40 65808-202,
Email: joswig@lavielle.com , WWW: http://www.lavielle.com/~joswig/
From chrisb@Ans.Com.Au Mon, 23 Mar 1998 13:03:14 +0000
Date: Mon, 23 Mar 1998 13:03:14 +0000
From: Chris Bitmead chrisb@Ans.Com.Au
Subject: Let's begin SchemeOS
Well I've done a little bit of thinking and I've written a few
ideas down. At least it's a place to start discussions. If you
agree with me that a SchemeOS is all about object modelling and
persistent stores, then I invite comments. If you don't like
persistent stores, hit delete now.
My main concern is that I am still thinking in too much of a UNIX
way, No doubt some more lateral thinkers may be able to put
forward more elegant things. But we need to start somewhere.
The following are object definitions in what is, as far as I
can make out, RScheme's class definition style. As a quick
overview, the syntax is
(define-class ()
slot...
)
where a slot is either just
or
(name :type )
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; The root object of the whole persistent store
(define-class ()
(users :type ) ; The users on the system
(devices :type )) ; devices on the system
; A collection of all the users on the system
(define-class ()
)
; class definition
; This class gives the basic information about a user
(define-class (