Re: djblinux?

> Why not consider a BSD kernel, then?

 I'm f*ing tired of "applicative" software packages being tied to a
certain kernel+libc combination.

 1. [OT rant] libc being tied to a kernel
 The Unix system call interface is supposed to be portable. Actually,
system call implementation cannot be portable, but the C interface to
system calls should be.
 Current libcs do 2 different things:
 (a) - C interface to assembler system calls, such as pipe()
 (b) - "applicative" entry points, such as malloc()

 I firmly believe that a "libc" should be reduced to the (b) part. The
(a) part, which is the only really kernel-dependent part, should be
provided by kernel authors. That way, libcs would be portable.
(And I could use the diet libc on an OpenBSD kernel - my dream system.)

 Let's call "libcsys" the (a) part.


 2. software being tied to a kernel+libc combination

 There is no reason for software to be non-portable, except for
applications concerning the specific part of the system (mount...),
which would explicitly have to be linked against the libcsys.
 If we're starting a distribution from scratch, since most /package-
followers take care not to break portability, there would be no
benefit in restraining ourselves to a single kernel + libc. After all,
daemontools (which started it all) _is_ portable, and is _meant to be_
portable, to offer the same guarantees on every Unix platform.
I'm seriously considering a BSD kernel... as well as a Linux kernel,
a Solaris kernel (except it isn't free), ... you name it.
(Uh, maybe not Hurd. :))

-- 
 Ska