How do we get started?

[Dwight Hughes]

We really need to get a more concrete plan of how to BEGIN and what
LispOS 0.0.0 MUST contain -- not what LispOS 1.0.0 WILL contain. 

Since I don't have better sense than to be a human lightning rod,
and have no real sense of humility either, here are some thoughts
on how we might cut the project down to a manageable size to
get started:

DEFINE OUR *CONSTRAINTS* FIRST, THEN DESIGN WITHIN THEM

Constraint 1:
   Each design and implementation cycle should be no longer than 4 to
   6 months (perhaps only 3 to 4 months). 

   We should only plan in detail for that length of time and keep the
   individual tasks simple enough to finish in that length of
   time without too much sweat (maybe not goldplated, but at least
   of useable quality). Do it, figure out what we learned, what
   worked, what didn't, what we liked, what sucked, then dump the trash
   and design the second onslaught. Do baby implementations at first
   to develop understanding (and skill, for some of us), then
   progressively refined and elaborated implementations. What LispOS
   0.0.0 will contain should be guided by these constraints -- don't
   define more at one time than can be created in the time allotted.
   This should help keep our designs simple and clean -- and us more
   motivated.

Constraint 2:
   We should *always* have a working OS and configuration. We should
   never at any time be dead in the water. At the end of each cycle
   we should have a modified but still working OS and configuration.

   This won't effect the LispEnv people but makes a big difference to
   the LispOS core group. This means we must take small and reasonable
   steps - build your next stage before abandoning the last one. This
   also means we must *start* with a working OS and configuration.
   This means Linux, FreeBSD, or perhaps one of the microkernel
   implementations. For developing the kernel functionality and other
   lower-level features, we might be better off with one of the
   microkernel-based OSs, assuming they are reasonably stable. 

Constraint 3:
   The environment where LispOS is should always be *useful*, as a whole.
   
   So we will *use* it and *advance* it. This means until we have enough
   of the infrastructure for LispOS built to make it useful _by itself_
   leave it as part of a Un*x environment -- if you are in a hurry to
   see it fly by itself, help build something useful. This also means
   that the full jump to something like the Flux OS Toolkit won't
   happen right away -- no matter, we must still define what we mean
   by the "kernel" of the LispOS and define and implement the primitives
   and retarget CMU-CL (after getting the debugger to single-step for
   the x86 family and defining and implementing threads in it).

Constraint 4:
   Each design and implementation cycle should be "complete" within itself.

   At the end of it you should have a complete working system/subsystem/
   sub-subsystem/utility/.... It may only contain a fraction of the
   functionality it may need to do everything you will eventually
   want, but what it does it should do completely. The design cycle
   should not be used to create some random part you cannot use without
   creating the other 500 random parts of your grand design. This way
   designs can adapt, change, evolve, be scrapped, be swallowed up
   by something else,... with minimal effort and maximum utility to
   the LispOS as a whole.


Constructive comments welcome.

-- Dwight