[conspire] Debian/BSD

[Rick Moen]

Quoting Bill Lazar (bill at billsaysthis.com):

> I asked because I'm new to the free *NIX scene and one of the puzzles,
> for me, is the differences between the two 'main' kernels. Since you are
> generally in favor of Debian as a distro, I thought you or others might
> have experimented with both and would be able to share some comments.

That's good reasoning.

So, let's talk a bit about kernels.  In the late 1980s, BSD finally
started escaping from academia, as the UC Berkeley Computer Science
Research Group (CSRG) people tried several subterfuges to hide the fact
that they'd escaped AT&T's copyright claims by replacing substantively
all AT&T code with their own inventions.  One of those ploys was the
release of the first unencumbered version as the "Net/2" tape
(ostensibly just a revision of the networking code, but the tape
surreptitiously included the entire OS).

Various people understood full well the implications, leading to an
Intel-compiled version called 386BSD, created around 1990.  About which
time, for reasons unrelated to 386BSD, AT&T's lawyers descended,
blighting the BSD scene until the 1994 settlement.  When the dust
settled, the 386BSD project had collapsed and CSRG had been dissolved,
leaving three free-software offshoots of 386BSD (FreeBSD, NetBSD, and
OpenBSD), along with a number of more-distant proprietary cousins:
original SunOS, NeXTStep (which is now Apple Darwin and Mac OS X), DEC
Ultrix, MachTen, etc.

The three progeny of 386BSD justify themselves, in part, through
specialisation:  Very loosely speaking, OpenBSD is about security,
NetBSD is about portability, and FreeBSD is about maximum
stability/performance on IA32.  But all three of them are refuges for
die-hard fans of the pure Berkeley-flavour userspace utilities and
administrative regime, as opposed to the generally AT&T System V-style
framework the rest of the world has move on to.  (As of System V release
4, the vast majority of the Unix world adopted a generally SystemV-ish
system structure with "BSD enhancements" -- the better-designed
utilities that had been the main reason computing snobs had preferred
BSD up to that point.  This was a compromise practically everyone could
live with, which was then reflected in the POSIX spec, which in turn
most Linux-based systems follow fairly closely.)

But the various BSDs lived on, keeping the original faith alive.
NetBSD, one of the three free-software forks, had a kernel designed to
be easily ported to new hardware.  It was/is not very high-performance;
it's very conservatively and reliably designed; it doesn't have good SMP
or very broad driver support for hardware chipsets, filesystems, etc.

Don't forget that an OS kernel consists of sets of drivers, code to
service low-level hardware requests (e.g., interrupts), a process
handler and scheduler, a memory handler (including virtual memory), code
for mediating with filesystems, various cache handlers, and handlers for
semaphores and signals.  That's all it is.  In particular, users have no
direct interaction with the kernel, whatsoever.  (That's a shell's job.)

BSD proponents would say that the NetBSD kernel is better than the Linux
one in being more "correctly designed" (a polemical term), with a more
reliable and settled development process.  Linux proponents would
maintain the reverse, on grounds of the Linux kernel being more modern
and ambitious, with a more-active and productive development model (also
polemical terms, albeit less so).

A true-blue BSD user expects to see a Berkeley init structure in /etc, a
ports skeleton and Berkeley package system for adding new software, and
the pure-Berkeley userspace utilities set (with a few intrusions of GNU
pieces, here and there).  Needless to say, he would not see that on a
Debian system running on the NetBSD kernel:  He'd see the loathed
SystemV/POSIX/Linux monster squatting atop the beloved (but mostly
invisible) BSD kernel.

Meanwhile, a Linux enthusiast would see what _looks_ a lot like a
traditional GNU/Linux system, except it doesn't run Linux binaries for
the same architecture without recompiling, it's slower, it lacks a lot
of the usual drivers, and it has a really bizarre kernel-compile
routine.

I hope that helps.

-- 
Cheers,
Rick Moen                                          ROMANI, ITE DOMVM!
rick at linuxmafia.com