LispOS: LispEnv or Tunes?
Tue, 29 Apr 1997 21:54:59 +0200 (MET DST)
It appears to me that, besides the VM topic,
there is another main division in the LispOS project.
1) people who want some Lisp Environment quick,
where everything a user needs could be done in Lisp.
The foundations of the Lisp Environment could be kludgy,
have lots of dependencies and idiosyncrasies, but that's no problem,
because the kludgiest Lisp Environment
is much better than any C Environment.
2) people who'd like to found a clean Operating System
not restricted to a particular flavor of Lisp
(and perhaps even open to other real languages),
with nice semantics and lots of orthogonality in features,
which would allow for scalability to future architectures,
configurable GC, etc.
These projects look both very useful to me,
though they seem quite distinct.
= For such a project, using Common LISP is clearly the good choice,
and CMUCL seems full of promises.
= Also, this project would be more oriented toward developing actual
applications in LISP and defining LISP bindings for every single
activity users may like to engage in,
rather than developping elaborate OS features.
= This project would be better off being done purely on top of a free UN*X
(Linux, *BSD) (what are the differences between Free*, Net*, Open*?).
It seems that building on top of Flux/Mach/whatever would be a nice hack,
but nothing essential to this project;
Slightly modifying Linux/BSD to fit the needs of the Environment
would be easier and more gratifying.
= real-time response, security with respect to multiprogramming,
distributed code, high-performance, scalability, originality,
are no essential goals for this project, as long as we have
enough of a reasonable approximation so that proficient people
can live comfortably.
= For such a project, Common LISP has too much legacy and bloat
to be used as a founding stone, though a Common LISP layer
is sure a eventual must as part of the building.
= The project might include the definition of a minimal core language
and module system, which will make it long before it can produce
actual operational code.
= However, the project would be fitter to explore how a system could
be efficiently implemented,
where everything is an object (a la LISP, not a la C++),
where there are several pools of GCed memory,
some persistent, some real-time, some distributed,
where there is guaranteed (software) isolation between components
of various users, so that one can make assumptions that others
wouldn't trust without crashing more than his part of the system,
where concurrent versioning is part of the storage system,
where massively parallel hardware is supported,
where the schedule of disk/network access is
coordinated by advanced heuristics instead of being done at the last moment,
= Such a project would definitely benefit from directly managing
the hardware (notably page management); it is an OS project,
rather than a user environment project.
= after all, this looks rather like the Tunes project than
what most folk on LispOS have expressed the desire to see;
I guess most people here want 1)
So if we are to few people interested in 2) here,
we could migrate to my tunes mailing list.
To me, the two projects are somewhat complementary:
1) would provide a livable and comprehensive user environment
2) would provide a clean, safe, performant, and adaptative founding
The two projects would benefit from each other,
and could merge back once 2) is advanced enough.
BTW, I don't think we should split the lists yet.
Maybe a few days from now,
after we've finished discussing common subjects...
== Fare' -- email@example.com -- Franc,ois-Rene' Rideau -- DDa(.ng-Vu~ Ba^n ==
Join the TUNES project for a computing system based on computing freedom !
TUNES is a Useful, Not Expedient System