Why not?

[Loren M. Lang]

On Mon, Mar 14, 2005 at 10:55:00AM -0500, Bart Silverstrim wrote:
> 
> On Mar 14, 2005, at 7:39 AM, Giorgos Keramidas wrote:
> 
> >On 2005-03-13 16:53, Bart Silverstrim <bsilver at chrononomicon.com>  
> >wrote:
> >
> >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".
> 
> Just for drivers? I wasn't sure what DM was...are any of these patches  
> that were released available as source for other Linux kernels, or are  
> these things being released without ever giving out the source to  
> integrate with the primary Linux kernel tree?

Device mapper which is to linux as geom is to freebsd.  The code was
already part of the official linux 2.6 sources, redhat just wanted to
use a 2.4 kernel, but still have the device mapper system up to date
with 2.6.

> 
> >>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).
> 
> You're right, if you have an application that requires modification to  
> the kernel then config changes won't fix it.  But that isn't the common  
> case, and you should be able to take that application and apply it to  
> the kernel tree source to create the working version, no?  Or are they  
> distro specific?  In the few times I ran into it the "melding" wasn't  
> distro-specific.

The biggest problem with all the various linux kernel is that, since
linus chose to make linux be intolerant of binary drivers, you need the
exact kernel that a driver was compiled for.  Some vendors like nvidia
provide a wrapper around their binary driver to avoid this, but many
vendors shipping binary-only driver do not as was the case with my wifi
card.  I have to have one specific kernel of one specific linux distro,
neither of which I was using at the time.

> 
> >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.
> 
> Then it would best be summed up as a difference in opinion over  
> operations management and organization management.
> 
> >>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.)
> 
> No, I didn't mean compile it and deploy it.  I mean replace my system's  
> kernel with that kernel and have it work.  The source trees are  
> different, the resulting kernel would expect to work on a NetBSD  
> *system*, not a FreeBSD system with a NetBSD kernel.
> 
> >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.
> 
> Again, it's a difference in organization and management opinion.
> 
> >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.
> 
> I was under the impression that kernel.org was the authoritative source  
> for the Linux kernel.  What people are doing on the side was their own  
> project.  *shrug*  I could be wrong :-)

kernel.org is the official source of straight vanilla linux, but no
distros use vanilla linux, they all have tons of patchs applied to it,
some more than others.  Even source code device drivers sometimes have
trouble compiling with these heavily patch kernels.  Each distro has too
worry about what security patches their version of the kernel needs.
It's not nearly as clean as the way the BSDs do it.

> 
> >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.
> 
> No, but don't discount editing of the interview as a factor too in  
> accuracy.
> 
> But on the other hand, Linus doesn't really give a flip about BSD.  He  
> has his own project, and he does (justifiably) have a lot to be proud  
> of (at the risk of inflating his ego more).  He doesn't sound like he's  
> really all that involved in distro flamewars or whatnot.  So...it's  
> just another article for people to read :-)

-- 
I sense much NT in you.
NT leads to Bluescreen.
Bluescreen leads to downtime.
Downtime leads to suffering.
NT is the path to the darkside.
Powerful Unix is.

Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc
Fingerprint: CEE1 AAE2 F66C 59B5 34CA  C415 6D35 E847 0118 A3D2
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20050315/60c2fb28/attachment.bin