Why not?
Josh Ockert
torstenvl at gmail.com
Mon Mar 14 05:37:28 PST 2005
http://www.linux-mag.com/content/view/60/112/ is the interview, btw
On Mon, 14 Mar 2005 14:39:53 +0200, Giorgos Keramidas
<keramida at ceid.upatras.gr> wrote:
> 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
>
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
>
More information about the freebsd-questions
mailing list