How do we get started?
Thu, 22 May 1997 23:09:18 -0500
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
DEFINE OUR *CONSTRAINTS* FIRST, THEN DESIGN WITHIN THEM
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
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.
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).
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.