hardware/kernel & lispOS vs. ENV & Names Silk/Jade
Fri, 2 May 1997 06:14:05 -0400 (EDT)
From: Mike McDonald <email@example.com>
> >Date: Thu, 1 May 1997 17:23:56 -0500
> >To: LispOS <firstname.lastname@example.org>
> >From: Chris Hanson <email@example.com>
> >Subject: Re: LispOS directly on hardware or on Unix kernel?
> >I think another problem with putting LispOS on Unix initially and then
> >trying to replace the underlying layer is that the core operating system --
> >memory, process, and communication management -- may be significantly
> >different in design between a Lisp-oriented OS and Unix.
> Sure, I can buy that. I think from time to time as the system is
> being evolved, major chunks of the system wiil have to be ripped out
> and replaced. If we can do a half way decent job of defining
> interfaces, then hopefully that pain can be localized. The alternative
> is to design the whole thing out first, then start implementing it
> without changing any of the interfaces. I don't think that's a viable
> approach for such a fuzzy project being manned by transient
> volunteers. That approach would also mean it would be a long, long
> time before we saw the results of (car '(a b)). I'd rather live with
> having to periodicly revisit portions of the system than wait for the
> "ideal" system to be designed and built.
This could even be a selling point of the project: the ability to build a large, efficient system out
of local components. Proof-of-concept: the main commercial arm of Oberon, Oberon Microsystems is
pushing to release "Black Box Component Builder" based on "Component Pascal" (nee Oberon/F and
I advocate planning for revision (and change of personnel).
From: Fare Rideau <firstname.lastname@example.org>
>Subject: UserLand & Kernel efforts: complementary, not opposite
In short: LispOS underneath LispENV and *nix/kernel underneath LispENV.
It is reasonable to divide the effort between LispENV and a LispOS. (Hmm.
How much like emacs would LispENV look... I recall H. Baker's
suggestion to rationalize and simplify emacs.)
I, also, think it desirable to make it easy for the curious to try the new system. That is, without
repartitioning disk drives, or switching machines. This can be a goal.
Make it possible for people to get work done on as many levels as possible. Not everyone is
going to have their hands in the lisp kernel. This should be a priority.
I, too, share F. Rideau's concerns regarding the efficiency of the system (size and execution speed),
and I would hope to see efficient versions running on a variety of platforms. One (or two) at first
Finally, is the term 'Jade' being used for anything? How about:
LispOS -> Silk
LispENV -> Jade
Actually, vice-versa would be more correct.