Why not?

[Giorgos Keramidas]

On 2005-03-13 16:53, Bart Silverstrim <bsilver at chrononomicon.com> wrote:
>> While each distros kernel is probably less different than a NetBSD
>> vs.  FreeBSD kernel, there still each different and a lot more of
>> them.  I had to download and install a very specific kernel from
>> redhat to use on my debian system so I could use my wireless card.
>>
>> Also, some features can very wildly like IPSEC, some distros patch in
>> FreeSWAN's stack, others the KAME stack.
>
> Some vendors may be directly patching certain features, for the most
> part you shouldn't have to download a specific kernel for a feature to
> work in Linux unless you wanted it pre-packaged.  You should be able
> to update it by downloading the latest features, running the config to
> enable/disable what features you want compiled into the kernel (or as
> modules), then compile it.

On the contrary, there are numerous cases when local patches, specific
to the distribution of Linux that is used, are used:

https://www.redhat.com/archives/linux-lvm/2002-November/msg00050.html
http://www.redhat.com/archives/fedora-announce-list/2004-February/msg00018.html

Backported fixes are not evil, but they are bad when they are available
only if you are running "FooLinux version X".

> But still, there is one source kernel, and unless the vendors did
> something proprietary (which I don't believe they're supposed to be
> allowed to do), you can compile your own kernel with your own set of
> enabled and disabled features from the Linux kernel source tree
> whether you're running Red Hat or Debian; it may break if that
> particular distro is depending on certain features as you have it
> configured and you fubar the new kernel's config, but it is still a
> matter of tweaking that configuration to get it working again.

Hardly.  Configuration changes will never fix a driver that is only
available as a patch to the kernel source tree, when the patch fails
to apply, build or install correctly -- a common case with some drivers
(i.e. Cisco VPN or SysKonnect).

It's a bit surprising that Linus dismisses the BSD kernel teams as
fragmented, when one considers the multitude of sites and the dozens of
"local hacks, patches" and other interesting stuff one has to do in
order to customize the kernel installation of a Linux kernel.

Let us put aside for a while the blatant error of considering three
distinct systems as one, when they are just that: three distinct systems
that just happen to share a lot of code and like cooperating on work
that is a benefit for all three.

There *is* one place where I can go to download my FreeBSD stuff.  There
is one web page, and not a zillion different sites that I have to search
through for hours.  There is a single CVSup mirror that I can use both
at work and at home.  But that's because I'm using _one_ of the BSD
systems.  People who use some other BSD-derived system go to their own
sets of sites, mirrors, etc.

> I can't download the sources for NetBSD's kernel, compile it on my
> FreeBSD box, and have it work no matter how much tweaking I do to the
> configuration...if I'm wrong, please someone correct me.

Actually, you can.  The NetBSD folks state that only a system relatively
compliant with POSIX is required for cross-building NetBSD on a local,
non-NetBSD system:

http://cvsweb.netbsd.org/bsdweb.cgi/src/BUILDING?rev=1.53&content-type=text/x-cvsweb-markup
(See the REQUIREMENTS section.)

> I *think* (and I'm not following the story closely) what Linus was
> saying is that it's stupid to have so many people working in parallel
> on such similar cousins...NetBSD, OpenBSD, and FreeBSD.  They share
> code, they share info, but optimize for certain goals and have a lot
> of redundancy.

Redundancy is good from a survival perspective.  Diversity is also good,
from an evolutionary perspective.  For every bad thing Linus can say
about having separate teams working on the systems they enjoy working
with, we can probably come up with htwo reasons why this is good.

> Linux's kernel is Linux's kernel, modified by individuals but still
> one big bulky source tree to work from.

Hardly.  Otherwise, it would be easy to point a browser to a single,
central place and browse the history of the Linux kernel from 0.9.x to
1.x and then to 2.x.  The fact that some bits are available in a
proprietary repository somewhere is not good enough.

In general, it's a nice interview of Linus and very enjoyable to read,
but I'm afraid he is not right about everything when he talks about the
BSDs; which is not very surprising, I guess.

- Giorgos