Hello.
Does anyone knows any running projects of Lisp-based OS'es?
I've found the mailing list archives, but it is closed know.
And, as I've figured out, noone ther gone further than arguing about
which Lisp compiler to choose.
I would be happy to join a team developing such a thing...
--
Wartan.
...she mades you tea, ask for your autograph...What a laugh!...
Re: LispOSHis Holiness the Reverend Doktor Xenophon Fenderson, the Carbon(d)ated
From: His Holiness the Reverend Doktor Xenophon Fenderson, the Carbon(d)ated
Subject: Re: LispOS
Date:
Message-ID: <w4ozouihv5f.fsf@nemesis.irtnog.org>
>>>>> "WH" == Wartan Hachaturow <····@softhome.net> writes:
WH> Hello. Does anyone knows any running projects of Lisp-based
WH> OS'es? I've found the mailing list archives, but it is closed
WH> know. And, as I've figured out, noone ther gone further than
WH> arguing about which Lisp compiler to choose.
A big problem with creating a free LispOS is that many people are
interested enough to have an opinion (often vocal) on how it should be
done, but not interested enough to dig through the relevant research
(e.g. on GC, BIBOPs, and so forth), nor spend time creating (or
adapting) a tool-chain (compiler/linker/debugger) and kernel
(drivers/GC/etc.). Building a Lisp system that is capable of not only
"just" standing alone, but also providing features people expect of
modern operating systems (multiple users, threads and processes,
networking, etc.), is an ENORMOUS task, and to be honest, I think the
immensity of starting effectively from scratch (even if one could
adapt a tool-chain like CMUCL's Python---or even adapting the entirety
of any of the free Lisps---to the task) scares a lot of people away
from the idea.
(Whoo. Sorry for being so long winded.)
I can't speak for other Lisp hackers, but if I were to start writing a
Lisp-based operating system in emulation of the classic Lisp machines,
I would keep very quiet about my work until I had something that
could, at the very least, boot on a PC or Alpha and print "Hello,
world!" in an infinite loop. Until then, "LispOS" is so much
vaporware and the people exclaiming "we're going to work on it, let's
all form a mailing list and get down to hacking" are doing the mental
equivalent of masturbating---there's a whole lot of effort being
expended without really creating anything. That's a sad thing to say,
but I think that if you'll look through the various mailing list
archives (both for the old lispos and lispvm lists and the new lispos
list), you'll start to see my point.
WH> I would be happy to join a team developing such a thing...
Until someone has come up with a storage management system (GC plus
virtual memory plus a run-time type system), some kind of boot
program, and a compiler/linker to build it all, having a team really
isn't going to do any good. Free software works best when there is
something for the hackers to play with, not when a committee is trying
to come up with some package ex nihilo---I have never seen a project
get off the ground just because a bunch of people gather together
around a cool idea. But that's just my opinion. I may be wrong.
Hopefully, someone wiser (Erik? Kent?) will correct me if I am.
Matthew Economou (aka Xenophon Fenderson, the Carbon(d)ated)
--
"What though the field be lost? / All is not lost; the unconquerable Will,
And study of revenge, immortal hate, / And courage never to submit or yield."
-- Lucifer,
'Paradise Lost', Milton
>>>>> "XF" == d writes:
XF> (e.g. on GC, BIBOPs, and so forth), nor spend time creating (or
XF> adapting) a tool-chain (compiler/linker/debugger) and kernel
XF> (drivers/GC/etc.).
Yeah, that's what I noticed from lispos mailing-list.
But I've found some mails from people, who really started
writing a code. In scheme, as I remember.
I was wondering if any of these started projects alive now...
XF> modern operating systems (multiple users, threads and processes,
XF> networking, etc.), is an ENORMOUS task, and to be honest, I think the
XF> immensity of starting effectively from scratch (even if one could adapt
Well, writing a thing like NachOS is not so complicated. Even rewriting
early versions of NachOS from C++ to Lisp, as a starting point...
XF> really creating anything. That's a sad thing to say, but I think that
XF> if you'll look through the various mailing list archives (both for the
XF> old lispos and lispvm lists and the new lispos list), you'll start to
XF> see my point.
Uh! And where is the new lispos mailing list?
XF> Free software works best when there is something for
XF> the hackers to play with, not when a committee is trying to come up
XF> with some package ex nihilo---I have never seen a project get off the
I am not strong enough to start such a project by myself. That's why I've
looked for someone already started.
--
Wartan.
...she mades you tea, ask for your autograph...What a laugh!...
Wartan Hachaturow <····@softhome.net> writes:
> >>>>> "XF" == d writes:
>
> XF> (e.g. on GC, BIBOPs, and so forth), nor spend time creating (or
> XF> adapting) a tool-chain (compiler/linker/debugger) and kernel
> XF> (drivers/GC/etc.).
>
> Yeah, that's what I noticed from lispos mailing-list.
> But I've found some mails from people, who really started
> writing a code. In scheme, as I remember.
You may perhaps be thinking of scsh? There was some discussion on
comp.lang.scheme.
I'm not sure it had gotten very far, because they were saying things
along the lines of "wanna-be emacs", while at the same time someone on
cll (I think) was answering "Why can't there be a shell like emacs?"
by pointing towards scsh. }:)
NB, scsh is a shell, not an OS. Which IMO is fine. Let the stuff
that sits close to the hardware be in C.
--
Tom Breton, http://world.std.com/~tob
Not using "gh" since 1997. http://world.std.com/~tob/ugh-free.html
In article <···············@nemesis.irtnog.org>,
"His Holiness the Reverend Doktor Xenophon Fenderson, the Carbon(d)ated" <········@irtnog.org> writes:
>>>>>> "WH" == Wartan Hachaturow <····@softhome.net> writes:
>
> WH> Hello. Does anyone knows any running projects of Lisp-based
> WH> OS'es? I've found the mailing list archives, but it is closed
> WH> know. And, as I've figured out, noone ther gone further than
> WH> arguing about which Lisp compiler to choose.
>
> A big problem with creating a free LispOS is that many people are
> interested enough to have an opinion (often vocal) on how it should be
> done, but not interested enough to dig through the relevant research
> (e.g. on GC, BIBOPs, and so forth), nor spend time creating (or
> adapting) a tool-chain (compiler/linker/debugger) and kernel
> (drivers/GC/etc.).
But a LispOS has almost nothing to do with those things. The idea behind a
LispOS wasn't to go off and reimplement Unix kernel hacks. It was to find a
way to deploy the LispM's ENVIRONMENT on modern, cheap hardware. Most of that
is strickly user level coding.
>Building a Lisp system that is capable of not only
> "just" standing alone, but also providing features people expect of
> modern operating systems (multiple users, threads and processes,
> networking, etc.), is an ENORMOUS task, and to be honest, I think the
> immensity of starting effectively from scratch (even if one could
> adapt a tool-chain like CMUCL's Python---or even adapting the entirety
> of any of the free Lisps---to the task) scares a lot of people away
> from the idea.
It is a BIG task. The LispM environment's components are so intertwined that
it's extremely difficult to pick a spot and start. But ultimately, I don't
think it matters where you start since you'll have to iterate many times. The
important thing is to just start somewhere.
Mike McDonald
·······@mikemac.com
·······@mikemac.com (Mike McDonald) writes:
> It is a BIG task. The LispM environment's components are so
> intertwined that it's extremely difficult to pick a spot and start.
> But ultimately, I don't think it matters where you start since
> you'll have to iterate many times. The important thing is to just
> start somewhere.
I think the GUI substrate (CLIM/DW/whatever) doesn't really get/share
a lot of its functionality with other applications, though pretty much
every application (editor/doc-viewer/listener/etc) inherits/uses its
functionality.
Thus, I would pick that as a starting point (and lean towards the
editing substrate for the listener and editor as the first
application).
And you've already been doing this....
Christopher
On Fri, 07 Jan 2000 18:12:53 GMT, Mike McDonald <·······@mikemac.com> wrote:
>In article <···············@nemesis.irtnog.org>,
> "His Holiness the Reverend Doktor Xenophon Fenderson, the
> Carbon(d)ated" <········@irtnog.org> writes:
>>>>>>> "WH" == Wartan Hachaturow <····@softhome.net> writes:
>>
>> WH> Hello. Does anyone knows any running projects of Lisp-based
>> WH> OS'es? I've found the mailing list archives, but it is closed
>> WH> know. And, as I've figured out, noone ther gone further than
>> WH> arguing about which Lisp compiler to choose.
>>
>> A big problem with creating a free LispOS is that many people are
>> interested enough to have an opinion (often vocal) on how it should be
>> done, but not interested enough to dig through the relevant research
>> (e.g. on GC, BIBOPs, and so forth), nor spend time creating (or
>> adapting) a tool-chain (compiler/linker/debugger) and kernel
>> (drivers/GC/etc.).
>
> But a LispOS has almost nothing to do with those things. The idea
>behind a LispOS wasn't to go off and reimplement Unix kernel
>hacks. It was to find a way to deploy the LispM's ENVIRONMENT on
>modern, cheap hardware. Most of that is strictly user level coding.
If you're writing a Lisp-based kernel, most of your time will be spent
on maintenance doing the following:
- Coding USB drivers, because all the new [keyboards| mice| modems|
...] are using USB,
- Coding drivers for some new SCSI adaptor
- Patching the kernel to cope with a problem with the BIOS on some
new motherboard
- Coding X drivers for nVidia's latest graphics card
- Drivers for Ethernet
All of this may be summed up by the notion that running Lisp atop a
UNIX kernel has the significant merit that supporting hardware becomes
Somebody Else's Problem.
>>Building a Lisp system that is capable of not only
>> "just" standing alone, but also providing features people expect of
>> modern operating systems (multiple users, threads and processes,
>> networking, etc.), is an ENORMOUS task, and to be honest, I think the
>> immensity of starting effectively from scratch (even if one could
>> adapt a tool-chain like CMUCL's Python---or even adapting the entirety
>> of any of the free Lisps---to the task) scares a lot of people away
>> from the idea.
>
> It is a BIG task. The LispM environment's components are so
>intertwined that it's extremely difficult to pick a spot and
>start. But ultimately, I don't think it matters where you start since
>you'll have to iterate many times. The important thing is to just
>start somewhere.
Flux OSkit <http://www.cs.utah.edu/flux/oskit/> at least tried to take
advantage of the Linux and FreeBSD drivers; that's about the only way
I'd suggest *considering* a non-UNIX kernel at this time.
It would surely be a nice thing to have some abtractions more
supportive of a LispM than those in "native UNIX;" it's sure
attractive if those abstractions are only minor hacks so that you can
get as much milage as possible out of the hardware support that can be
"gotten for free."
--
"I visited a company that was doing programming in BASIC in Panama
City and I asked them if they resented that the BASIC keywords were in
English. The answer was: ``Do you resent that the keywords for
control of actions in music are in Italian?''" -- Kent M Pitman
········@hex.net- <http://www.ntlug.org/~cbbrowne/lisposes.html>
* Jeff DelPapa wrote:
> Perhaps the "right thing" is to think about what a "conventional" OS
> could do better about managing the memory of a lisp universe. This
> isn't a new idea, Twenex had user mode paging as an option... If
> someone attacked one of the open source kernels, and built such a
> facility, we might just have something.
There's no point in doing anything like this unless you're aiming at a
64-bit platform. For a 32-bit machine the solution is buy more
memory. It's almost always just going to be cheaper to put an
address-space of memory in a 32-bit machine than it is to worry about
whether a page is resident or not. If not now then certainly before
you finish the design...
--tim
··@world.std.com (Jeff DelPapa) writes:
> However one of the big wins of the Lispm OS was that the GC and the
> paging engine were aware of each other. When the GC could avoid
> touching things that weren't resident, it worked a whole lot better.
Err... how could it do that? Paged-out objects can contain references
to paged-in objects. How can you GC without looking at at the
paged-out stuff?
> the GC should be able to ask that
> a given page get loaded, and continue on. The current method "touch
> it and wait until its back" is not one that gives prompt response.
Now this makes a lot of sense, was it what you were talking about above?
The current Unix way of doing something like this is to have several
threads or processes working, when one thread/process is waiting for
page-in another can use the CPU. (Threads need kernel support to do
this)
I don't know if GC can be written in such a way. (Perhaps if GC is one
thread and the application is several other threads. Don't know if
you would ever do much GC under those conditions, though)
>The lispm's would do just fine with 200:1 virtual to real ratio's.
Just out of curiosity, what kind of numbers are we talking about here?
Stig Hemmer,
Jack of a Few Trades.
* Stig Hemmer wrote:
> Err... how could it do that? Paged-out objects can contain references
> to paged-in objects. How can you GC without looking at at the
> paged-out stuff?
I think this is just the generational-GC problem again. In a
generational GC you want to avoid looking at old generations. But
they can contain pointers to the most recent generation, if they've
been modified. So you need to have some trick that you do when you
modify an old object -- the most obvious one might be to relocate it
immediately to the current generation, leaving a forward reference in
the old generation. The lispms certainly had support for magic
forwarding pointers which would help with this.
So if you drive the paging off the GC, so you only ever page out old
generations, then you know that nothing that you've paged out can
point at anything in core, unless you've modified it (which means it's
just been paged in anyway).
I think it's a lot hairier than that actually, but something like that
ought to work.
--tim
In article <··········@world.std.com>, Jeff DelPapa <··@world.std.com> wrote:
>In article <···············@epoksy.pvv.ntnu.no>,
>Stig Hemmer <····@pvv.ntnu.no> wrote:
>>··@world.std.com (Jeff DelPapa) writes:
>>> However one of the big wins of the Lispm OS was that the GC and the
>>> paging engine were aware of each other. When the GC could avoid
>>> touching things that weren't resident, it worked a whole lot better.
>>
>>Err... how could it do that? Paged-out objects can contain references
>>to paged-in objects. How can you GC without looking at at the
>>paged-out stuff?
>
>Simple, when you hit a reference that would take a page fault to
>resolve, you just ignore it for that pass. If you can't follow it
>quickly, move on to the next one.
I'm not sure that answers the question. Suppose page 1 has object A
containing a reference to object B on page 2, which has a reference to
object C on page 3, and page 2 is paged out. You start scanning page 1,
and copy object A to copy-space. You don't scan page 2, so it's
automatically included in total in copy-space. But how do you find out
that object C should be copied to copy-space? You can't see the reference
to it unless you scan page 2.
What you seemed to be describing is the relationship between generations in
a generational GC.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <······@bbnplanet.com> writes:
> In article <··········@world.std.com>, Jeff DelPapa <··@world.std.com> wrote:
> >In article <···············@epoksy.pvv.ntnu.no>,
> >Stig Hemmer <····@pvv.ntnu.no> wrote:
> >>Paged-out objects can contain references to paged-in objects. How
> >>can you GC without looking at at the paged-out stuff?
> >
> >Simple, when you hit a reference that would take a page fault to
> >resolve, you just ignore it for that pass. If you can't follow it
> >quickly, move on to the next one.
>
> I'm not sure that answers the question. Suppose page 1 has object A
> containing a reference to object B on page 2, which has a reference to
> object C on page 3, and page 2 is paged out. [...] how do you find out
> that object C should be copied to copy-space? You can't see the reference
> to it unless you scan page 2.
>
> What you seemed to be describing is the relationship between generations in
> a generational GC.
Yes, that's right. The usual generational techniques apply. In
particular, a remembered set can be used to record that object B
points to object C (or some approximation thereof). One of the tricks
of the LispM pager was to scan pages as it was paging them out; this
updated the remembered sets, and allowed the GC to only page in pages
that actually did contain pointers to old-space. This is an enormous
improvement, since such pages are normally rare.
The LispM did scan paged-in pages first, as well.
And there were other tricks that are hard to implement without more
control over virtual memory than is afforded by most of the currently
popular OSs, like manipulating the mappings and adjusting the page-out
heuristics to understand the dynamics of GC. Memory is a resource
that benefits greatly from centralized management; the current OS
architecture is just too compartmentalized.
--
Pekka P. Pirinen
Adaptive Memory Management Group
Harlequin Limited/Xanalys Inc.
Every time history repeats itself, the price goes up.
··@world.std.com (Jeff DelPapa) writes:
> Perhaps the "right thing" is to think about what a "conventional" OS
> could do better about managing the memory of a lisp universe. This
> isn't a new idea, Twenex had user mode paging as an option... If
> someone attacked one of the open source kernels, and built such a
> facility, we might just have something.
If and when the GNU Hurd becomes a viable, actively maintained
OS, this might be a useful substrate to experiment with this kind of
code, since it's based on Mach and as such might offer more
opportunities to fool around with this.
OTOH, I think that more speed is still one of the least important
things _I_ want from a LispOS and/or current Lisp implementations.
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
On Fri, 14 Jan 2000 18:12:36 GMT, Jeff DelPapa <··@world.std.com>
concluded we would all be made wiser by knowing that:
>In article <······················@news4.giganews.com>,
>Christopher Browne <········@hex.net> wrote:
>>On Fri, 07 Jan 2000 18:12:53 GMT, Mike McDonald
>><·······@mikemac.com> wrote:
>>All of this may be summed up by the notion that running Lisp atop a
>>UNIX kernel has the significant merit that supporting hardware becomes
>>Somebody Else's Problem.
>
>However one of the big wins of the Lispm OS was that the GC and the
>paging engine were aware of each other. When the GC could avoid
>touching things that weren't resident, it worked a whole lot better.
I did have memory management in mind; that's why I kept OSKit on the
list, even though it's *somewhat* obscure. (At least in comparison to
Linux or *BSD.)
There's merit to having some form of extension to the memory
management system, and I expect that precise insights on that need to
be left to wiser heads than mine.
>I agree that making hardware support someone elses problem is a good
>thing. In my arrogant opinion, one of the things that doomed the
>lispm companies was having to support the cost of chip development.
>Sun had many years running before it decided to do more than let
>motorola keep its CPU's up to date....
Cheap microprocessors have gotten a whole lot faster and cheaper than,
I suppose, LispM makers expected. Note that Cray is no longer an
independent enterprise either; the most famous of the "massively
custom computing engines" is *not* doing terribly well.
>Perhaps the "right thing" is to think about what a "conventional" OS
>could do better about managing the memory of a lisp universe. This
>isn't a new idea, Twenex had user mode paging as an option... If
>someone attacked one of the open source kernels, and built such a
>facility, we might just have something.
>
>The main part of it, is arranging for the process to be able to very
>quickly ask "is this page in memory, or on disk". It also needs to ask
>the question "has the page been changed". Helpful would be some sort
>of advance requesting mechanisim -- the GC should be able to ask that
>a given page get loaded, and continue on. The current method "touch
>it and wait until its back" is not one that gives prompt response.
If this could be done as a minor kernel patch to (say) Linux, I'd not
be surprised at all to see this go in.
--
"I've discovered that P=NP, but the proof is too long to fit within
the confines of this signature..."
········@ntlug.org- <http://www.hex.net/~cbbrowne/lisposes.html>
"His Holiness the Reverend Doktor Xenophon Fenderson, the Carbon(d)ated"
<········@irtnog.org> writes:
> I can't speak for other Lisp hackers, but if I were to start writing
> a Lisp-based operating system in emulation of the classic Lisp
> machines, I would keep very quiet about my work until I had something
> that could, at the very least, boot on a PC or Alpha and print
> "Hello, world!" in an infinite loop.
From <http://www.cs.rice.edu/CS/PLT/packages/mzscheme/index.html>:
MzScheme is available in kernel form for x86 machines, which allows
MzScheme to boot without the aid of a separate operating system. The
MzScheme kernel is based on the OSKit <http://www.cs.utah.edu/flux/oskit/>.
So, simply booting is solved. People can start with this to investigate the
more interesting LispOS issues.
Eric.
--
-------------------------------------------------------------------------------
Eric Eide <·····@cs.utah.edu> . University of Utah Dept. of Computer Science
http://www.cs.utah.edu/~eeide . +1 (801) 585-5512 voice, +1 (801) 581-5843 FAX
On 06 Jan 2000 22:08:35 +0300, Wartan Hachaturow <····@softhome.net> wrote:
>Hello.
>
>Does anyone knows any running projects of Lisp-based OS'es?
>I've found the mailing list archives, but it is closed know.
>And, as I've figured out, noone ther gone further than arguing about
>which Lisp compiler to choose.
>
>I would be happy to join a team developing such a thing...
You might check the URLs at the URL below.
--
As of next Tuesday, ITS will be flushed in favor of TRSDOS 2.1.
Please kill yourself.
········@ntlug.org- <http://www.hex.net/~cbbrowne/lisposes.html>