FreeBSD and Linux

[Martin Cracauer]

I've been convinced it is not the right time to discuss these in
detail, although I have strong preferences, as you might have noticed
:-) 

So far we approach two concepts:
- building a userlevel CMUCL around a free Unix clone kernel
- start from scrtach with minimal hardware support

The second doesn't need a kernel at all and everything we do for the
first solution can be done so that it works with both kernels. Thinks
like a paging control interface are performance value only and we
probably find enough people from both camps to push these once the
thing is running at all.

I can't resist to correct you in the following, so that the
informatiom on this list stays clean.

> 1) FreeBSD has more liberal license (which I think is an advantage
>    for lispOS).
> 2) Networking code is documented in detail in
>    Richard Steven's book
> 3) Good book on internals from McKusick et al...
> 4) no kernel threading (I believe they have user level
>    threading in -current)
> 
> 1) Linux is GPL
> 2) has kernel threading (clone)
> 3) internals not as well documented
> 
> But I think for scalability, we definitely need the kernel
> threading.

FreeBSD's rfork does the same as Linux clone(). Support for multiple
processors is running, but not in releases on FreeBSD. What FreeBSD is
behind in is to provide a rfork() - based threads library for use by a
C program, while Linux already has a clone()-based Posix Threads
library.

We don't need this userlevel C library anyway. As far as my view of
CMUCL goes, we either use our own userlevel threading (as commercial
Lisp systems do) or we base our work on clone() or rfork() directly,
which makes FreeBSD and Linux equivalent in this respect.

Additionally, please take License issues *very* serious. The GPL
doesn't allow includion of sources with *any* other licenses. This is
not a problem for CMUCL, which is explicitly public domain (== nothing
you can't do), but it is for importing BSD sources, which state you
have to name the author and makes it incompatible with the GPL. Linux
folks ignore this usuallay and place code under the GPL and leave the
statement about credits, which isn't allowed by the GPL. 

Let us take this serious and do things right, both in code and in
copyrights. Licensing issues are a real danger for free projects, both
because you may loose source code and/or money and because you can
loose developers who don't agree.

Using the GPL, for example, might bring us support from the FSF, while
a BSD lincese might attrack commercial companies to push the project
into something usable and then take the source and make a commercial
branch from it (which I don't have anythihg against, but others
might).

But in the near future I see no reason to decide. We leave each
component under the license it happens to be under. We should not
narrow CMUCL's public domain status, for example. That would cause the
CMUCL people not to take our improvements back into the main thing (or
*they* would loose developers).

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@wavehh.hanse.de>
http://cracauer.cons.org
Fax +49 40 522 85 36