The Marketing of LispOS?

[cosc19z5@bayou.uh.edu]

[Snip]

> > 	 Wouldn't it be cool to have your virtual memory be Lisp aware?
> 
> > Only if I can percieve it.  Otherwise, what would the point be?  For
> > me, what matters is what I can see and observe directly, which is
> > why I'm content for a CL Shell in lieu of a full fledged O/S.
> 
> Let me attempt to explain a little better here. There is this
> perception that Lisp is slow. Now current Lisps that run on stock
> hardware interact with an underlying OS. This os, probably written in
> C, has a lot of built in assumptions. I would like to know how much
> these assumptions affect the Lisp system and how much difference, if
> any, would you see from having Lisp assumptions there instead of C
> assumptions. 

Well you were talking about virtual memory being Lisp aware, but
what you are talking about now seems to be a bit more involved
than just that.  Basically, it looks like you are talking about
a full fledged LispOS, or at least a Lisp kernel, written in
such a way as to run Lisp code as efficiently as possible.


> 
> I would rather work at the application level, but if the foundation is 
> shakey...

Well, who is to say we can't work at the application level while
remaining independent of the foundation?  Let's say we write
some portions of the O/S or applications in Lisp on stock
hardware without an underlying Lisp kernel.  What happens then?
Well it may not run as fast as it could, but once the kernel
is swapped, that will change, and all our work can be moved
over verbatim.  It wouldn't be like we lost anything.

And if the work is of an acceptable speed, we can use what
we have on stock hardware, rather than waiting for the decidedly
more complex task of kernel development to complete.


> > I'd have to think about this.
> 
> I was looking at the Inside NT book and noticed that they had an
> Object Manager. I was thinking that if you took the object concept all 
> the way down to the kernel, there are some things you would like to be 
> objects, but for performance reasons, they probably shouldnt have the
> full CLOS machinery. But you might want a portion of that
> machinery. This would probably take a couple of passes to get right.

Hmmmm, wasn't this brought up before?  I'm not sure what the
consensus was, but I like the idea.  I'm all in favor of
making the O/S as high a level as possible -- this includes
user view (Interface) and programmer view (API, Scripting, etc...).



> > 	 How fast would that dusty 486 sitting in my closet be running 
> > 	 LispOS?
> 
> > Since I don't have a 486 in my closet, I really couldn't care less.
> 
> :-)

Sorry, I couldn't resist :)


> > It just so happens that getting LispOS in a position to be used by
> > others for profit helps its chances to succeed that much more.
> 
> It looked to me as if some people were starting to use "popularity"
> and "acceptance" as design criteria. I think that there are a lot of
> interesting ideas that have been presented. 

Well as far as popularity and acceptance go, they don't impose
extra design burdens.  From what I'm seeing, making a truly
useful, high-quality O/S would also fulfill the requirements
for "popularity" and "acceptance".

The other places where the terms would come in, would be 
independent of the design of the O/S, and they would involve
attempts at distribution/advertising and flexible licensing;
basically, trying to make others notice the product we developed
and consider using it.

I mean there is a degree of wanting to do our own thing, after
all, we are not writing a Winblows clone :)


> Most of them look like
> they will be portable to other Lisp environments and do not need a
> from-the-metal LispOS. 

Definitely.  I can see many of the benefits being reaped without
having to do anything more than write lisp code and use
the listener to good effect.


> Implement things that fulfill a need or is very 
> interesting. Just like the mainstream wasnt really interested in
> another Unix clone, its not interested in another OS written in
> Lisp. But it would be cool to do anyway.
> 

They could be interested if they liked it enough.  Remember, a
LispOS would be very radical.  Granted, we had Lisp machines,
but they are nowhere near as well known as Unix systems.

Something that's powerful, high level, free, compatible with
existing software, and radically different might turn enough
heads.  Even if there's no mainstream acceptance, it may
get a few more people to take a look at Lisp, and that would
be a good thing.

I'm not holding on to any pipe dreams.  Trying to push a
new O/S through is a daunting task.  Look at Linux, it's
been around for a while, turned quite a few heads, but
it's market share is still quite small.

How many other O/Ses are under development?  How many have
we heard of?


> > For me, this is Lisp advocacy, the attempt to bring a better O/S
> > (both working to further the sorry state of computing), and the
> > chance for me to work on a project that is both fun and potentially
> > significant.
> 
> I cant disagree with this. I think that there are two perspectives
> here. One is to design from the top down. We develop the interfaces
> and envrironment on top of Windows/Unix that allow us to interoperate,
> embrace and extend. I like this idea, I have Harlequin LispWorks for
> Unix and Windows so this would work for me.

So do I.  If given a choice, I'd pick this over the second route.
I've got Harlequin FreeLisp and ACL on Win95 and have access
to CMUCL 17f on Unix.


> 
> The other is to work from the bottom up we build a small, tight kernel
> of primitive lisp objects, define a device driver model,
> interrupt/exception model, memory management model, object and
> resource management, and other basic OS tidbits. We know this is
> non-trivial. The question is, is it worth the effort? 

It could be if it made a noticeable performance increase in
Lisp code.


> If I were doing
> this, I would have initially an Intel version and later an Alpha
> version (would probably need to abstract the hardware). Now initially
> I was not interested in this, but I started thinking about memory
> management and wondered what primitives I would need to define to
> work on the processor page tables from Lisp. Ive never thought about
> these things before, so the bright shiny object distracted me. :-)
> 

Hehehehehe :).
It's definitely something worth considering.

For the time being though, I would go for the first route.  Even
if it's slow, it's a concrete product and would serve as a
model, a proof of concept, and it can be modified as time goes on.

That's my approach.  I write everything without regard for
speed or error checking, but just to get a usable prototype
available.  If the idea is deemed worthy, then it can be
beefed up.  If it's deemed unworthy, the effort invested
in it is minimal so there's no great loss.


> > My attitude is to make LispOS free, and make the license flexible
> > enough to allow commercial use.  No monetary gain for me.
> 
> I agree with this but only in the sense that if commercial interests
> think I am doing something thats interesting to them, then, and only
> then, would we have to talk about it. Until that time, I toil on my
> pet project, ignored by the mainstream. That way my priorities are in
> the correct order.

Well, we do need to get this issue settled up front because this
is where the licensing comes in.  If folks are going to share
code, then they need to do so with some kind of license in place,
and the license chosen will have impacts on any potential
commercial development.


> 
> -Reggie
> 


-- 
Cya,
Ahmed