different alternatives for lispOS
25 Apr 1997 05:45:14 -0700
>>>>> "RC" == Richard Coleman <firstname.lastname@example.org> writes:
RC> 1) Layer a scheme distribution directly on top of the Flux OS
I suspect this is too hard, and won't result in utility that will keep
people engaged in improving the system. On the other hand, a more
novel approach might keep the attention of a smaller group of hackers
(perhaps academically oriented). It seems that is already occuring, as
you noted with Shivers' group.
RC> 2) Layer a scheme distribution on top of a minimal Linux
RC> distribution. Strip out everything except what is need to boot
RC> the system (and a few small utilities). Merge the virtual memory
RC> code and GC code. Then slowly replace all the standard apps with
RC> lisp/scheme variants. Also change the threading on the scheme to
RC> sit directly on the clone system call.
I think a microkernel approach would help here, because it would be
easier to attach a debugger to user level code. Debugging GC is hard
enough: to have the entire system crashing because such bugs would
really be fun! Still, I think #2 is the best approach, though,
because it could go in a number of different directions without too
RC> 3) Layer scheme on top of some virtual machine such as the java
RC> VM. Using kawa would probably be a good idea here.
RC> (http://www.cygnus.com/~bothner/kawa.html) Also, other virtual
RC> machines have been proposed, and should be considered.
(not necessarily incompatible with #1 or #2, of course)
RC> 4) Build a large lisp-based user environment instead of a whole
RC> OS. This is essentially just a generalization of (X)Emacs. This
RC> has been proposed several times (GROW project for instance). Most
RC> projects like this have been propsed to use Guilde. The advantage
RC> is that is it could be made to run just about everywhere.
This is a LispOS mailing list, right?
RC> I'm actually leaning toward version 2. But that would depend on
RC> how many people are interested in helping to hack on the sytem.
RC> There are quite a few people on the list at this point, so the
RC> interest is definitely there.
Sounds good to me!
RC> But as I've said on the newsgroups, it would make sense to start
RC> small and build on the small successes. A two phase plan would be
RC> to start on version number 4, with the aim of eventually using
RC> that code to accomplish version number 2.
Some degree of focus is needed. I know I'll continue to have my
application oriented interests that I'll be pursuing, and my
experience is that there a natural tendency to integrate.