SuSe 9.3 / Re: [conspire] s MEPIS 3.3.1 t2 Gnu / Linux

[Rick Moen]

Quoting david at localcomputermart.com (david at localcomputermart.com):

> I have a bootable CentOS DVD which I was using..  and pored over the
> linuxmafia SATA/RAID/IDE resources as well as Garzik's site.. even
> went so far as to join the dmraid eList (now THAT is 'low traffic' ;)
> Learned a lot, but not enuff (yet) to coerce full SATA/PATA support
> from the ICHR6 & current CentOS (like RHEL4) distro.  No problem, glad
> to have made the efforts, glad to have failed and stumbled onto SuSe,
> which seems more suited to newbie me and my newbie client whom I built
> that box for.

SUSE's very nice, and I'm delighted it worked out for you.  I'm just
suffering from a detective's curiosity, about why the RHEL4 kernel (used
by CentOS) would have a problem.  ICH6/ICH6R is a pretty important
chipset, these days.

> Yes, I gathered that information from many sources & laboriously
> proved it to myself :) (but thanks for reiterating anyhow) The Promise
> SX6000 is UN-fakeraid; is suitably old <g> and even better, has an
> open source driver
> http://www.promise.com.tw/support/download/download2_cht.asp?productId=86&category=All&os=100

Excellent detective work, there.  You may have already seen this page,
which has further information: 
http://www.hyperborea.org/journal/archives/2005/03/15/sx6000-freebsd-linux/

A third-party GPLed driver is certainly good to have, but in the long
term, you want where possible to move to drivers shipped by, and
maintained by, the Linux community (e.g., the kernel maintainers, in the
case of ATA RAID cards).  It looks like the Promise SX6000 problem is
temporary, judging by that page.

The reason I say you "want to" do that over the long term is pragmatic:  
Drivers outside the main development trees -- even sometimes the open
source ones -- tend to become unmaintained over time.  Given changing
kernel programming interfaces, third-party kernel-level drivers will
thus cease to function on newer kernels at some point.  (The ones that
are open-source or at least source-available can be fixed; the
binary-only ones simply die.)

> -though I'll be using SuSe 9.3 and praying to the Computer Godz for
> compliance from the SuSe 9.0 driver on the site..  Since this is all
> based on SCSI layer, I don't expect a problem(?)

To clarify:  _Garzik's_ driver collection (libata) uses the kernel's
SCSI layer.  From a quick glance at Promise's pti_st driver source code,
that particular driver appears not to.

> Thanks for all the resources, including moral support (though I'm
> still not completely won over to the PC-ness of open source..) I mean,
> yeah, it seems like a good idea, but I think it'll be a while before
> I'll refuse to use a proprietary driver (although that azx sound
> module on the Intel site for their 'bleeding edge' ICH6R's sound was
> total shit) hmmm..  I guess maybe if that particular piece of dreck
> HAD been open-source, someone would'a fixed it by now .. ?

Heh.  ;->

It's been somewhat amusing to realise that one of the _real_ reasons why
codebases sometimes remain binary-only is that the authors [/owners]
realise their coding standards were laughably bad and that their source
code probably _shouldn't_ see the light of day.

Sometimes, the code that does get opened up has to be studied very
carefully (working around lack of comments, etc.) and then rewritten
from scratch, before Torvalds and co. would consider accepting it.

On the other hand, nobody with common sense denies that occasionally a
proprietary driver is your only realistic option.  E.g., I imagine there
are still sound cards for which the "Open Sound Systems" drivers (not
open source, BTW) are the only option that won't drive you mad doing
setup and debugging:  http://www.opensound.com/