Time to get busy!

[Jordan Henderson]

> 
> I quoted almost all of Ahmed's message below since it keeps me from 
> typing in a nearly identical message. I *may* have a bit more experience 
> in software engineering and design but I have the same problems in
> attacking this project. I am most interested in the LispOS kernel
> and lower-level OS design for this project (for now anyway) but my
> detailed knowledge of this not extensive and my experience even less.
> However, I would like to contribute much more than just cheerleading --
> I can do/would do the research necessary to come up to speed in
> whatever aspect I am thrust into, but I will need a bit of guidance
> too from those who actually know what they are doing.
> 
I really agree with Ahmed's sentiments as well.  I put out a call for a
manifesto recently, because I think we either need to get focused on the
ultimate goals here.  But, I don't feel that I could write the manifesto
or be a leader in this project in any substantive way.  

I still think we need to draw upon the experience of the FSF here for
inspiration.  Their goal was to have a Unix knock off OS, and now they've
got two, Linux and the Hurd.  How did they start?  Infrastructure, 
infrastructure, infrastructure.  The first "product" of the FSF was 
Emacs, an editor!  Then came GCC.  Another thing they had was a 
visionary who kept it on track, provided direction and heavy promotion.

Remember that Linux was never an FSF project, but the copyleft kept it
in line with their goals.  The same thing could happen here.  If people
don't like the goals, but do like some of the tools being developed, it
can only help what I feel must be the meta-goal of the project which is
more and better support for Lisp (and other superior languages like 
Scheme and ML).

I think we need a manifesto, a set of goals and a visionary (maybe a set
of a few visionaries who are closely attuned to one another).  I don't 
feel that the leaders will dictate development or quash groups that have
ideas that they don't feel are in line with the goals, they will just 
serve as a focal point for "approved" projects that are on-the-list.  These
projects will be given out to people or groups who have demonstrated 
that they have expertise (or the realistic expectation of gaining it)
in the areas they are attacking.  Perhaps a powerful integrated development
environment on top of Unix (Linux) based on CMUCL (or whatever) could be
a focal point "product".  This "product" might attract corporate 
sponsorship in the same way that FSF does for GCC and Emacs, or the
way ACT does for thier Ada development system.  

I don't think it's practical to run off and develop an OS without lots of
research first, unless the goal is to reproduce old Lisp machines on top of
stock hardware.  If it is determined that this is the goal, then just
develop a system that is exactly like some past Lisp machine.  There will
need to be some level of Kernel infrastructure developed to support this
as the past Lisp machines interpreted Lisp more-or-less in hardware, but
if the goal is to just redo the Lisp machines, the path is more or less
clearly defined.

> 
> Just for the record, I have decided that Mike McDonald's quick start
> approach on a Linux/FreeBSD/... system would be most expedient. If we
> want to move it to something else after some development we can do so.
> In the meantime, we will have to rely on those who know what *must*
> be in a LispOS to keep us safe from unix damage.
> 
> Now, which is it -- Linux or FreeBSD? If Linux, which Linux -- RedHat,
> Slackware, Debian, mkLinux?
> 
> Pie in the sky always looks fantastic, but pie in my plate tastes much
> better. This project won't happen overnight - lets start with something
> that works, even if it *is* unix based for now. We're going to throw
> most of it away anyway as we go along, and I would love to be able to
> take advantage of the work that has been done on all those damn device
> drivers. We might even gain some insight into what must be done to
> have a unix subsystem/runtime/whatever as part of the LispOS (calm down,
> this means Unix on LispOS NOT LispOS on Unix). I think this would be
> a worthy goal eventually if it proves not to be too hairy.
> 

I really agree with all of this.  How about the first product be
a portable development system with integrated editor.  I personally 
am somewhat attracted by the idea that the whole thing should be
Scheme-based, as I think it would be easier to implement as minimal
OS core, and continuations might benefit OS design.  But, I think
there is more support for CL.  CL is probably a better starting point for
the portable integrated environment.  

How about it?  Any energy behind a portable integrated environment to
run on Linux/FreeBSD/<Commercial Unices>/<Windows>?  It could be used
to prototype the windowing system and all the apps could first be 
built using it.  One danger I see of such a beast is that if we attempt
to develop the object model on top of it the object model will get mapped
to Unixy concepts which might skew things quite a bit.

I've also kept Ahmed's comments below because they can't be stressed too
strongly.  We really need leaders that we can rally around to supply
some of the answers to the questions he asks.  I do want to point out that
perhaps we shouldn't be too concerned about not having a strong Software
Engineering background before we pick up some work.  A lot of stuff was
done for the FSF by hackers who didn't have much background.  A lot of
stuff done by hackers has provided a lot of good examples of what not to
do also.  So, even if you are not up to designing and implementing something
you can learn-by-doing, and provide a good lesson to others of the pitfalls
of a certain path.  Someone else pointed out that CL-HTTP is a really good
example of software engineering using CL.  I see this project as a good
focal point for spreading the word about good CL applications and 
promulgating them (providing a prep.ai.mit.edu of CL apps?).

Someone else (Bill House?) made the very valid point that ease-of-installation
should be paramount.  I really agree with this too.  We need to get something
out there that anyone can install and begin to see the great benefits of our
direction.

How about nominations for a steering committee?  Once elected, the steering
committee can work to serve as the focal point.  Any volunteers for the
steering committee?  I think the steering committee should be made up of 
people with heavy Lisp experience, which lets me out.  I'm not worthy to 
make the comments I made above, I'm all talk.  I'm just a guy who learned
Lisp at school almost 20 years ago and long to be able to use Lisp "in
the real world".  I feel strongly that the world of OSs written in C has
led us to the dead end of Unix and Windows.  

> --  Dwight
> 
> 
> --------
> From: Ahmed <cosc19z5@Bayou.UH.EDU>
> 
> | >   OK everyone, enough talk It's time to get busy! :-) Why don't people
> | > start picking projects that they're interested in?
> | 
> | Question:  what sort of time frame are we looking at for developing
> | any given module?  Also won't there be a precise set of criteria
> | for any given module?  I mean wouldn't there need to be a list of
> | requirements for things like API, desired performance, functionality,
> | etc...?  Just asking for say "a networking system", seems to be asking
> | for trouble since there seems to be a wide range of interpretation
> | as to what should and shouldn't be in a given networking system.
> | 
> | Also what about coding standards?  I'm interested in contributing
> | code in Lisp, but I'd like to know for instance, what sort of
> | naming conventions should be employed, how should reliance
> | on non-ANSI features go, is one free to use functional programming
> | techniques (the latter would necessitate tail recursion optmization
> | in CMUCL which is what I'm assuming is going to be used for the
> | Lisp code at this point).  CMUCL/Linux is our implementation
> | right?  I need to know before I go about installing this thing
> | and getting familiar with its nuances.
> | 
>   [ -- snip -- ]
> |
> | My software engineering experience is non-existent (I code therefore
> | I am), but shouldn't there be more formalism involved than just
> | saying "We need a persistent OO store, Make It So!"?
> | 
>   [ -- snip -- ]
> | 
> | BTW, do you want those who contribute code to have experience in
> | the particular domain in which they are developing?  I have
> | zero experience in some of the areas I'm thinking of taking up,
> | but I'm more than willing to do the research necessary to teach
> | myself what to do if that's not a problem (heck I'm looking forward
> | to it since that makes it more of a challenge and will help
> | expand my knowledge greatly -- this could be one helluva learning
> | experience for me!).
> |
> 
>