[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Closest to Debian



On Tue, 29 Jan 2002 00:18, Jason Lim wrote:
> > The Red Hat version only supports kernel 2.4.2, expect it to fail on
>
> 2.4.17+
>
> > because there have been significant changes.  Also expect it to work on
>
> the
>
> > Red Hat 2.4.2 kernel but not a standard 2.4.2 kernel because Red Hat
>
> apply
>
> > significant patches to their kernels.
>
> Sigh. Do we know exactly what kernel patches/modifications Redhat makes to
> their default kernels?

As Michael suggested, you could download the source RPM and then compile a 
Debian package from it.

> > I recommend that you avoid purchasing from companies that only provide
>
> binary
>
> > kernel modules.  When you use such modules you taint your kernel (thus
>
> making
>
> > the kernel developers unwilling to look into any bug reports you might
>
> file),
>
> > and you make it very difficult for yourself when it comes time to
>
> upgrade.
>
> > I suggest doing one of two things:
> >
> > 1)  Download a kernel rpm for Red Hat and use alien to install it.
> >
> > 2)  Use another hardware supplier.
>
> Sigh... are we going to become like the Mac... where the rest of the world
> supports OTHER software that we don't use? That is... it seems like more
> and more hardware/software producers are making stuff FOR Redhat, and not
> supporting anything else except that. What happens to the rest of us? If
> we don't also use Redhat we either have compatibility problems, or have to
> hack away at it to get it to work (and even if it DOES work, it may be
> flaky).

Not at all.

If you use that hardware on Red Hat and have a kernel Oops then what happens? 
You post a message on the linux-kernel list and everyone says "your kernel is 
tainted, boot without that non-free kernel module and then try and reproduce 
it".  You ask Red Hat but I doubt that they'll support kernel Oops debugging 
unless you send them a moderate amount of money.  You ask the hardware vendor 
but they say "our driver is perfect, it's because we don't want to share this 
perfect code for our rivals to copy that we release it as binary-only not 
because we are trying to hide hundreds of bugs, perhaps your motherboard is 
broken", so you end up being forced to replace the device with a Mylex DAC960 
or some other hardware RAID device with proper support.

One of my clients has a binary-only kernel module on one of their servers.  
It has caused me more pain than you want to imagine.  Every time I want to 
upgrade their kernel it's an upgrade on all machines but that one because the 
crappy vendor never supports recent kernels.  The author of the device driver 
in question used to be on one of the Linux mailing lists, until his posts of 
"Linux sucks you should use BSD" got him flamed off the list.

If you install hardware that requires a binary-only driver then that's a 
mistake you will probably regret for years.  Use software RAID, spend more 
money to get a Mylex DAC960 with SCSI drives, do anything but using a 
binary-only driver.

-- 
http://www.coker.com.au/bonnie++/     Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/       Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/     My home page



Reply to: