Hi,
Recent lisp convert, long time Linux/BSD user, C programmer. This
question is more of a curiosity that's been nagging at me than anything
else - and it'll help give me a balanced perspective on lisp itself.
What's stopping 'a' Lisp OS from getting off the ground in PCs? What
would be the benefits of such an OS? And the cons asides from device
drivers? Overall and in terms of a programming enviroment for Lisp in
particular. What could you do in such an OS as a Lisp programmer that
other environments tend to hinder?
I'm assuming that speed and garbage collection wouldn't necessarily be
a problem
because Linear Lisp could be used. Is this a bad assumption to make?
And why have the other Lisp OSes died down more or less? (AFAIK, may be
wrong on this.)
-rolf
"rolfwind" <········@yahoo.com> writes:
> What's stopping 'a' Lisp OS from getting off the ground in PCs? What
> would be the benefits of such an OS? And the cons asides from device
> drivers? Overall and in terms of a programming enviroment for Lisp in
> particular. What could you do in such an OS as a Lisp programmer that
> other environments tend to hinder?
Demand. A more integrated Lisp development environment. Few users
means less software. I don't know.
Take a look at Movitz.
If I wanted to create a Lisp OS, I would cheat. The first thing I
would do is take a Linux kernel and X11 and use that as my platform
for a Lisp environment. Once a complete user space is built, the
kernel can be changed out underneath. By having libc available, other
Unix software could run on this "Lisp system" without having to jump
through any hoops.
--
http://www.david-steuber.com/
The UnBlog: An island of conformity in a sea of quirks.
http://www.david-steuber.com/snippets/Boycott_Sony/
David Steuber <·····@david-steuber.com> writes:
> "rolfwind" <········@yahoo.com> writes:
>
>> What's stopping 'a' Lisp OS from getting off the ground in PCs?
>> What would be the benefits of such an OS? And the cons asides from device
>> drivers? Overall and in terms of a programming enviroment for Lisp in
>> particular. What could you do in such an OS as a Lisp programmer that
>> other environments tend to hinder?
>
> Demand. A more integrated Lisp development environment. Few users
> means less software. I don't know.
>
> Take a look at Movitz.
>
> If I wanted to create a Lisp OS, I would cheat. The first thing I
> would do is take a Linux kernel and X11 and use that as my platform
> for a Lisp environment. Once a complete user space is built, the
> kernel can be changed out underneath. By having libc available, other
> Unix software could run on this "Lisp system" without having to jump
> through any hoops.
A good starting point would be Xen: port Movitz on Xen!
http://common-lisp.net/project/movitz/
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/
http://wiki.xensource.com/xenwiki/
--
__Pascal Bourguignon__ http://www.informatimago.com/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d? s++:++ a+ C+++ UL++++ P--- L+++ E+++ W++ N+++ o-- K- w---
O- M++ V PS PE++ Y++ PGP t+ 5+ X++ R !tv b+++ DI++++ D++
G e+++ h+ r-- z?
------END GEEK CODE BLOCK------
Pascal Bourguignon wrote:
>
>
> A good starting point would be Xen: port Movitz on Xen!
>
> http://common-lisp.net/project/movitz/
> http://www.cl.cam.ac.uk/Research/SRG/netos/xen/
> http://wiki.xensource.com/xenwiki/
This is a great idea! We've just started offering Xen VPSs as part of
our lisp hosting service (sorry about the plug, but it was on-topic at
least).. if Movitz can be made to run under Xen, we could offer _real_
lisp servers :). How cool would that be!
drewc
--
Drew Crampsie
drewc at tech dot coop
"... the most advanced use of lisp in the field of bass lure sales"
-- Xach on #lisp
On 15 Nov 2005 00:06:58 -0800, "rolfwind" <········@yahoo.com> wrote:
>And why have the other Lisp OSes died down more or less? (AFAIK, may be
>wrong on this.)
>
>-rolf
Sam Steingold answered the question very accurately:
http://www.podval.org/~sds/tool.html
| There have been many failed efforts to re-implement the LispOS. It is
| nice that people are still thinking about it, but it is a pity that
| they just talked and wrote no code.
And then there are the issues of adoption, commercial support and all
the rest but all of them are secondary.
--
JCR
On Tue, 15 Nov 2005 10:00:34 -0800, J.C.Roberts wrote:
> On 15 Nov 2005 00:06:58 -0800, "rolfwind" <········@yahoo.com> wrote:
>
>>And why have the other Lisp OSes died down more or less? (AFAIK, may be
>>wrong on this.)
>>
>>-rolf
>
> Sam Steingold answered the question very accurately:
>
> http://www.podval.org/~sds/tool.html
> | There have been many failed efforts to re-implement the LispOS. It is
> | nice that people are still thinking about it, but it is a pity that |
> they just talked and wrote no code.
>
> And then there are the issues of adoption, commercial support and all
> the rest but all of them are secondary.
But what advantage does a LISP based OS bring that no other language
brings, and is it a big enough difference to overcome the "good-enough"
factor?
On Tue, 15 Nov 2005 15:33:52 -0500, BR <··········@comcast.net> wrote:
>On Tue, 15 Nov 2005 10:00:34 -0800, J.C.Roberts wrote:
>
>> On 15 Nov 2005 00:06:58 -0800, "rolfwind" <········@yahoo.com> wrote:
>>
>>>And why have the other Lisp OSes died down more or less? (AFAIK, may be
>>>wrong on this.)
>>>
>>>-rolf
>>
>> Sam Steingold answered the question very accurately:
>>
>> http://www.podval.org/~sds/tool.html
>> | There have been many failed efforts to re-implement the LispOS. It is
>> | nice that people are still thinking about it, but it is a pity that |
>> they just talked and wrote no code.
>>
>> And then there are the issues of adoption, commercial support and all
>> the rest but all of them are secondary.
>
>But what advantage does a LISP based OS bring that no other language
>brings, and is it a big enough difference to overcome the "good-enough"
>factor?
The "good enough" factor is not the real issue. The real issue is only
solved by adoption. Only with adoption and usage is experience gained
and the "experience" you have is your most valuable asset.
As they say, "The devil you know."
If someone decided to make all the doors in your place open from the
opposite side, you would eventually adjust but regardless if the
reversed doors actually work a lot better, your first inclination is to
shoot the bastard that reversed them. ;-)
Perl is more than "good enough" for me to write some nice cross-platform
build/release tools. None the less, I took the hard road of learning a
new language rather than using one I already know. I'm doing the tools
in Common Lisp for the experience... -and trying to figure out who is
responsible for reversing all the doors :-)
JCR
BR wrote:
> But what advantage does a LISP based OS bring that no other language
> brings, and is it a big enough difference to overcome the "good-enough"
> factor?
- Security (no buffer overflows)
- Smaller code base
- Better API (GC everywhere, Higher-Order Functions)
- Good Introspection of the whole system -> great hackability
-> Easier (less error-prone, more productive) development of drivers,
apps, just about everything (provided, your Lisp-OS-Lisp PL has some
useful intriscs or abstractions for bit-bashing and I/O)
Some Cons:
- Maybe worse performance. However, you'd probably get better
reliability (no memory leaks, no full crashes) and security--and I think
a system running longer but slightly slower is (mostly) preferable to a
system that runs fast in the first place but crashes or has security leeks.
Also note that GC may actually be a performance *win* compared to manual
allocation, e.g. on dual-core machines software using copying GCs
usually tend to speed up better due to better locality of reference and
thus more cache hits (which will become increasingly important as the
processor-memory speed gap is still growing).
- Incompatibility with practically everything. You *could* compile
C-code on a Lisp-OS but it'll hardly be useful, since you'd need to port
much C API, too. An intermediate solution would be to take a
microkernel, e.g. Xen, L4, Hurd, and have your Lisp-Stuff coexist with
some full Unix environment, e.g. XenoLinux, XenoBSD, L4Linux on top of
it and share the drivers. However it'll take *much* time to build up
such a system, thus is practically impossible to do as a community work.
So if I could think of the absolute killer app for such an OS that would
be worth all the trouble I probably wouldn't post it here, except for
getting the absolute best Lisp-hackers in the world to join my freshly
founded company and give my best to become the next to join the club of
the Lisp millionaires. (Hint: it's probably not Desktop apps.. at least
not yet.)
From: =?utf-8?b?R2lzbGUgU8ODwqZsZW5zbWk=?= =?utf-8?b?bmRl?=
Subject: Re: Questions about a Lisp OS
Date:
Message-ID: <0nsltweren.fsf@kaktus.ii.uib.no>
BR <··········@comcast.net> writes:
> On Tue, 15 Nov 2005 10:00:34 -0800, J.C.Roberts wrote:
>
> But what advantage does a LISP based OS bring that no other language
> brings, and is it a big enough difference to overcome the "good-enough"
> factor?
Others has mentioned some of other pros and cons, but the main obstacle in
implementing an operationg system today is the enourmous amount of
hardware that has to be supported, especially on the x86-platform.
You have to support a huge number of cpu, chipsets, graphics cards,
network cards, modems, usb devices, and all other kinds of hardware that
the users can think of using. The main problem on Linux (and even Windows)
is to catch up with all the hardware out there, including bugs that
have to be worked around.
Now you can of cause target a less hetrogenous platform, like the mac,
but even there it will be a lot to support. The lisp machines and most
other OSes of its time was developed on hardware that was not
"industrial standard" like it is common today, so the task of writing
device drivers was much easier.
If you will have any hope of making a usable lispy system, the system should
better be based on an existing OS kernel to support the hardware, and put
the system on to of that.
--
Gisle Sælensminde, Phd student, Scientific programmer
Computational biology unit, BCCS, University of Bergen, Norway,
Email: ·····@cbu.uib.no
"rolfwind" <········@yahoo.com> writes:
> What's stopping 'a' Lisp OS from getting off the ground in PCs? What
> would be the benefits of such an OS?
Perhaps your second question to some extent answers the first: The
potential benefits are somewhat unclear, and therefore there is less
motivation for people to work on such a beast.
> And why have the other Lisp OSes died down more or less? (AFAIK, may
> be wrong on this.)
Well, all I can say is that Movitz is not dead, even if it's perhaps
started to smell a bit funny the last couple of months.
--
Frode Vatvedt Fjeld
rolfwind wrote:
> Hi,
>
> Recent lisp convert, long time Linux/BSD user, C programmer. This
> question is more of a curiosity that's been nagging at me than anything
> else - and it'll help give me a balanced perspective on lisp itself.
>
> What's stopping 'a' Lisp OS from getting off the ground in PCs? What
> would be the benefits of such an OS? And the cons asides from device
> drivers? Overall and in terms of a programming enviroment for Lisp in
> particular. What could you do in such an OS as a Lisp programmer that
> other environments tend to hinder?
>
> I'm assuming that speed and garbage collection wouldn't necessarily be
> a problem
> because Linear Lisp could be used. Is this a bad assumption to make?
>
> And why have the other Lisp OSes died down more or less? (AFAIK, may be
> wrong on this.)
I wrote a Lisp OS once. More accurately, I was one of six programmers
who were paid for two years by a large PC firm to write an OS in Lisp..
Speaking from that perspective, the main obstacle is that it's a lot of
frickin' work.
You can argue that the amount of work doesn't prevent it being done, and
point to Linux to support your argument, and you would be right. But you
will only have argued that doing it isn't impossible. Lots of things
that aren't impossible don't get done, because for something to get
done, someone has to actually do it. And the harder it is, the less
likely it is that someone will do it.
Movitz even gives anyone who is interested a pretty good start on the
first part: writing the kernel. Linux was originally just a kernel,
after all. What made it an OS was that it was a kernel that did a pretty
good job of looking like UNIX, so that it was pretty easy to port and
reimplement a vast amount of existing useful software (that, and the
fact that there was a bunch of useful UNIX-like software being avidly
re-engineered by free software enthusiasts).
A Lisp kernel has a more troublesome situation. Maybe you could make a
Lisp kernel with a POSIX API, so you could port lots of UNIX and Linux
software. But if you do that, why are you doing a Lisp OS? What's the
point? You just end up with yet another UNIX clone.
Instead, maybe you want to do something really Lispy; I know that's what
I would want to do. But then you are biting off an even larger hunk of
work.
Six of us worked way more than full time for two years and wrote a
pretty interesting OS that was never shipped. What we had at the end was
something that was pretty cool and that was fun to use and develop for,
but which provided zero support for anything else that was out there in
the world. You couldn't build UNIX programs on it. You couldn't run Mac
or Windows or other existing software on it. It had no support for
familiar file formats (because instead we had invented an interesting
novel method of storing data that was pretty cool).
I guess it comes down to this: do you write yet another UNIX clone, but
one that is written in Lisp? If so, what for? Why bother? Or do you
write something really original and interesting? If so, who's gonna use
it, and for what? And do you really grasp just how much work you're
talking about if you do that?
Writing a Lisp OS now is a crazy idea. It's a crazy idea that I would
still like to carry out, but I need a way to pay the bills, and there
isn't anyone with deep pockets around right now itching to pay me to do
it again.
On Wed, 16 Nov 2005 10:47:47 -0800, mikel <·····@evins.net> wrote:
>rolfwind wrote:
>> Hi,
>>
>> Recent lisp convert, long time Linux/BSD user, C programmer. This
>> question is more of a curiosity that's been nagging at me than anything
>> else - and it'll help give me a balanced perspective on lisp itself.
>>
>> What's stopping 'a' Lisp OS from getting off the ground in PCs? What
>> would be the benefits of such an OS? And the cons asides from device
>> drivers? Overall and in terms of a programming enviroment for Lisp in
>> particular. What could you do in such an OS as a Lisp programmer that
>> other environments tend to hinder?
>>
>> I'm assuming that speed and garbage collection wouldn't necessarily be
>> a problem
>> because Linear Lisp could be used. Is this a bad assumption to make?
>>
>> And why have the other Lisp OSes died down more or less? (AFAIK, may be
>> wrong on this.)
>
>I wrote a Lisp OS once. More accurately, I was one of six programmers
>who were paid for two years by a large PC firm to write an OS in Lisp..
>Speaking from that perspective, the main obstacle is that it's a lot of
>frickin' work.
>
>You can argue that the amount of work doesn't prevent it being done, and
>point to Linux to support your argument, and you would be right. But you
>will only have argued that doing it isn't impossible. Lots of things
>that aren't impossible don't get done, because for something to get
>done, someone has to actually do it. And the harder it is, the less
>likely it is that someone will do it.
>
>Movitz even gives anyone who is interested a pretty good start on the
>first part: writing the kernel. Linux was originally just a kernel,
>after all. What made it an OS was that it was a kernel that did a pretty
>good job of looking like UNIX, so that it was pretty easy to port and
>reimplement a vast amount of existing useful software (that, and the
>fact that there was a bunch of useful UNIX-like software being avidly
>re-engineered by free software enthusiasts).
>
>A Lisp kernel has a more troublesome situation. Maybe you could make a
>Lisp kernel with a POSIX API, so you could port lots of UNIX and Linux
>software. But if you do that, why are you doing a Lisp OS? What's the
>point? You just end up with yet another UNIX clone.
>
>Instead, maybe you want to do something really Lispy; I know that's what
>I would want to do. But then you are biting off an even larger hunk of
>work.
>
>Six of us worked way more than full time for two years and wrote a
>pretty interesting OS that was never shipped. What we had at the end was
>something that was pretty cool and that was fun to use and develop for,
>but which provided zero support for anything else that was out there in
>the world. You couldn't build UNIX programs on it. You couldn't run Mac
>or Windows or other existing software on it. It had no support for
>familiar file formats (because instead we had invented an interesting
>novel method of storing data that was pretty cool).
>
>I guess it comes down to this: do you write yet another UNIX clone, but
>one that is written in Lisp? If so, what for? Why bother? Or do you
>write something really original and interesting? If so, who's gonna use
>it, and for what? And do you really grasp just how much work you're
>talking about if you do that?
>
>Writing a Lisp OS now is a crazy idea. It's a crazy idea that I would
>still like to carry out, but I need a way to pay the bills, and there
>isn't anyone with deep pockets around right now itching to pay me to do
>it again.
Is it OK to ask what happened to the company and the source code?
This one particular phrase has been stuck in my head since I read it:
ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-514.pdf
| LISP is often referred to as a "high-level machine language."
I'm still trying to learn how the heck this is done, particularly across
architectures and it seems like you might know or at least point be able
to point me in the right direction for docs to read.
Thanks,
JCR
J.C. Roberts wrote:
> On Wed, 16 Nov 2005 10:47:47 -0800, mikel <·····@evins.net> wrote:
>
>
>>rolfwind wrote:
>>
>>>Hi,
>>>
>>>Recent lisp convert, long time Linux/BSD user, C programmer. This
>>>question is more of a curiosity that's been nagging at me than anything
>>>else - and it'll help give me a balanced perspective on lisp itself.
>>>
>>>What's stopping 'a' Lisp OS from getting off the ground in PCs? What
>>>would be the benefits of such an OS? And the cons asides from device
>>>drivers? Overall and in terms of a programming enviroment for Lisp in
>>>particular. What could you do in such an OS as a Lisp programmer that
>>>other environments tend to hinder?
>>>
>>>I'm assuming that speed and garbage collection wouldn't necessarily be
>>>a problem
>>>because Linear Lisp could be used. Is this a bad assumption to make?
>>>
>>>And why have the other Lisp OSes died down more or less? (AFAIK, may be
>>>wrong on this.)
>>
>>I wrote a Lisp OS once. More accurately, I was one of six programmers
>>who were paid for two years by a large PC firm to write an OS in Lisp..
>>Speaking from that perspective, the main obstacle is that it's a lot of
>>frickin' work.
>>
>>You can argue that the amount of work doesn't prevent it being done, and
>>point to Linux to support your argument, and you would be right. But you
>>will only have argued that doing it isn't impossible. Lots of things
>>that aren't impossible don't get done, because for something to get
>>done, someone has to actually do it. And the harder it is, the less
>>likely it is that someone will do it.
>>
>>Movitz even gives anyone who is interested a pretty good start on the
>>first part: writing the kernel. Linux was originally just a kernel,
>>after all. What made it an OS was that it was a kernel that did a pretty
>>good job of looking like UNIX, so that it was pretty easy to port and
>>reimplement a vast amount of existing useful software (that, and the
>>fact that there was a bunch of useful UNIX-like software being avidly
>>re-engineered by free software enthusiasts).
>>
>>A Lisp kernel has a more troublesome situation. Maybe you could make a
>>Lisp kernel with a POSIX API, so you could port lots of UNIX and Linux
>>software. But if you do that, why are you doing a Lisp OS? What's the
>>point? You just end up with yet another UNIX clone.
>>
>>Instead, maybe you want to do something really Lispy; I know that's what
>>I would want to do. But then you are biting off an even larger hunk of
>>work.
>>
>>Six of us worked way more than full time for two years and wrote a
>>pretty interesting OS that was never shipped. What we had at the end was
>>something that was pretty cool and that was fun to use and develop for,
>>but which provided zero support for anything else that was out there in
>>the world. You couldn't build UNIX programs on it. You couldn't run Mac
>>or Windows or other existing software on it. It had no support for
>>familiar file formats (because instead we had invented an interesting
>>novel method of storing data that was pretty cool).
>>
>>I guess it comes down to this: do you write yet another UNIX clone, but
>>one that is written in Lisp? If so, what for? Why bother? Or do you
>>write something really original and interesting? If so, who's gonna use
>>it, and for what? And do you really grasp just how much work you're
>>talking about if you do that?
>>
>>Writing a Lisp OS now is a crazy idea. It's a crazy idea that I would
>>still like to carry out, but I need a way to pay the bills, and there
>>isn't anyone with deep pockets around right now itching to pay me to do
>>it again.
>
>
> Is it OK to ask what happened to the company and the source code?
The company was Apple Computer; it still seems to be doing okay. The
source code still belongs to them, and they won't release it; I asked.
> This one particular phrase has been stuck in my head since I read it:
> ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-514.pdf
> | LISP is often referred to as a "high-level machine language."
>
> I'm still trying to learn how the heck this is done, particularly across
> architectures and it seems like you might know or at least point be able
> to point me in the right direction for docs to read.
A good starting point is Movitz. It isn't an OS; it isn't even a kernel.
It's a Lisp that runs on the bare x86. It's a good start if you want to
write a kernel in Lisp, and looking at how it works is a good start on
understanding how to operate close to the metal in Lisp.
On Fri, 18 Nov 2005 01:14:10 -0800, mikel <·····@evins.net> wrote:
>>>Writing a Lisp OS now is a crazy idea. It's a crazy idea that I would
>>>still like to carry out, but I need a way to pay the bills, and there
>>>isn't anyone with deep pockets around right now itching to pay me to do
>>>it again.
>>
>>
>> Is it OK to ask what happened to the company and the source code?
>
>The company was Apple Computer; it still seems to be doing okay. The
>source code still belongs to them, and they won't release it; I asked.
>
>> This one particular phrase has been stuck in my head since I read it:
>> ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-514.pdf
>> | LISP is often referred to as a "high-level machine language."
>>
>> I'm still trying to learn how the heck this is done, particularly across
>> architectures and it seems like you might know or at least point be able
>> to point me in the right direction for docs to read.
>
>A good starting point is Movitz. It isn't an OS; it isn't even a kernel.
>It's a Lisp that runs on the bare x86. It's a good start if you want to
>write a kernel in Lisp, and looking at how it works is a good start on
>understanding how to operate close to the metal in Lisp.
Thanks Mike. When I learned a bit more CL, I'll take a look at it.
Kind Regards,
JCR
mikel <·····@evins.net> writes:
> Writing a Lisp OS now is a crazy idea. It's a crazy idea that I would
> still like to carry out, but I need a way to pay the bills, and there
> isn't anyone with deep pockets around right now itching to pay me to
> do it again.
I can think of a number of people who could front the cash without
missing it if it were to end up inhaled as a fine, white powder. But
I don't think my mind control ray will work on them.
Refer to my earlier post about cheating and writing a user space Lisp
environment instead on top of a working Linux kernel + X11 (although
OpenGL could also be used via SDL or something).
--
http://www.david-steuber.com/
The UnBlog: An island of conformity in a sea of quirks.
http://www.david-steuber.com/snippets/Boycott_Sony/
David Steuber wrote:
> mikel <·····@evins.net> writes:
>
>
>>Writing a Lisp OS now is a crazy idea. It's a crazy idea that I would
>>still like to carry out, but I need a way to pay the bills, and there
>>isn't anyone with deep pockets around right now itching to pay me to
>>do it again.
>
>
> I can think of a number of people who could front the cash without
> missing it if it were to end up inhaled as a fine, white powder. But
> I don't think my mind control ray will work on them.
:-)
I know two billionaires well enough that they might take my phone call
if I seemed like I had something important to say, but if they found out
what I had to say was that I wanted to write another Lisp OS, they would
both tell me to go jump in the lake, and wouldn't take my next phone
call. :-)
>
> Refer to my earlier post about cheating and writing a user space Lisp
> environment instead on top of a working Linux kernel + X11 (although
> OpenGL could also be used via SDL or something).
>
Yah, I've thought of that, too. It's not too far from what we did,
though the kernel in question was not Linux. But it would be more
interesting to write the kernel in Lisp, too. And anyway, an awfully
large part of what needs to be written isn't the kernel anyway.
mikel <·····@evins.net> writes:
> Yah, I've thought of that, too. It's not too far from what we did,
> though the kernel in question was not Linux. But it would be more
> interesting to write the kernel in Lisp, too. And anyway, an awfully
> large part of what needs to be written isn't the kernel anyway.
I agree with you on the kernel. The reason for the cheat is for
drivers and such. Obviously with a popular kernel, you can count on a
number of drivers being available "for free".
The awfully large part that isn't in the kernel is hopefully where
Lisp would shine. Once you have abstracted your kernel interface
(which should include the IO devices), then you ought to have a nice
illusion of a real Lisp environment.
Something else that might be cool is if the file system was written in
Lisp and used the same GC techniques for disk memory management. I'm
wildly speculating here. EXT3 and other Unix file systems already do
a form of GC anyway. But you could go a step further and bring back
versioned files and perhaps also DB like functionality.
--
http://www.david-steuber.com/
The UnBlog: An island of conformity in a sea of quirks.
http://www.david-steuber.com/snippets/Boycott_Sony/
David Steuber wrote:
> mikel <·····@evins.net> writes:
>
>
>>Yah, I've thought of that, too. It's not too far from what we did,
>>though the kernel in question was not Linux. But it would be more
>>interesting to write the kernel in Lisp, too. And anyway, an awfully
>>large part of what needs to be written isn't the kernel anyway.
>
>
> I agree with you on the kernel. The reason for the cheat is for
> drivers and such. Obviously with a popular kernel, you can count on a
> number of drivers being available "for free".
>
> The awfully large part that isn't in the kernel is hopefully where
> Lisp would shine. Once you have abstracted your kernel interface
> (which should include the IO devices), then you ought to have a nice
> illusion of a real Lisp environment.
Yes; the point I was getting at is the core of my answer to the question
of why it isn't done: because it's a flipping great wodge of work. I
thoroughly agree, though, that doing it is an opportunity to do
something cool.
> Something else that might be cool is if the file system was written in
> Lisp and used the same GC techniques for disk memory management. I'm
> wildly speculating here. EXT3 and other Unix file systems already do
> a form of GC anyway. But you could go a step further and bring back
> versioned files and perhaps also DB like functionality.
What we did was make a frame language for representing high-level
representations of content. Our framestore was stored in RAM that was
intended never to lose power, and we had in mind a checkpointing scheme
for backup purposes.
There were some problems we needed to solve; the one that looms large in
my memory is a security problem. We intended to be able to serialize and
deserialize lambdas, and that introduces some serious security issues.
While it's very cool to be able serialize some arbitrary frames that
include executable code in them, and send them to someone else over a
net for deserialization, it obviously introduces serious virus and worm
problems. We had not designed a solution to that problem when our plug
was pulled.
On Sat, 19 Nov 2005 10:22:46 -0800, mikel <·····@evins.net> wrote:
>There were some problems we needed to solve; the one that looms large in
>my memory is a security problem. We intended to be able to serialize and
>deserialize lambdas, and that introduces some serious security issues.
>While it's very cool to be able serialize some arbitrary frames that
>include executable code in them, and send them to someone else over a
>net for deserialization, it obviously introduces serious virus and worm
>problems. We had not designed a solution to that problem when our plug
>was pulled.
Would a sand-boxing approach work?
In other words, one or more restricted VM's for running the untrusted
code.
JCR
J.C. Roberts wrote:
> On Sat, 19 Nov 2005 10:22:46 -0800, mikel <·····@evins.net> wrote:
>
>
>>There were some problems we needed to solve; the one that looms large in
>>my memory is a security problem. We intended to be able to serialize and
>>deserialize lambdas, and that introduces some serious security issues.
>>While it's very cool to be able serialize some arbitrary frames that
>>include executable code in them, and send them to someone else over a
>>net for deserialization, it obviously introduces serious virus and worm
>>problems. We had not designed a solution to that problem when our plug
>>was pulled.
>
>
> Would a sand-boxing approach work?
>
> In other words, one or more restricted VM's for running the untrusted
> code.
Off the top of my head, I don't see why not.
But, as I say, we hadn't gotten around to it by the time the plug was
pulled.
J.C. Roberts <···············@abac.com> writes:
> On Sat, 19 Nov 2005 10:22:46 -0800, mikel <·····@evins.net> wrote:
>
>>There were some problems we needed to solve; the one that looms large in
>>my memory is a security problem. We intended to be able to serialize and
>>deserialize lambdas, and that introduces some serious security issues.
>>While it's very cool to be able serialize some arbitrary frames that
>>include executable code in them, and send them to someone else over a
>>net for deserialization, it obviously introduces serious virus and worm
>>problems. We had not designed a solution to that problem when our plug
>>was pulled.
>
> Would a sand-boxing approach work?
>
> In other words, one or more restricted VM's for running the untrusted
> code.
http://www.eros-os.org/
http://www.coyotos.org/
In one word: capabilities.
--
__Pascal Bourguignon__ http://www.informatimago.com/
In deep sleep hear sound,
Cat vomit hairball somewhere.
Will find in morning.