LispOS: LispEnv or Tunes?

[Fare Rideau]

It appears to me that, besides the VM topic,
there is another main division in the LispOS project.

There are
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.

1)
 = 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.
2)
 = 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,
  etc.
 = 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...

Best regards,

== Fare' -- rideau@ens.fr -- 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
URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"