On Wed, 18 May 2011 10:47:02 -0400, Daniel Gibson <metalcae...@gmail.com> wrote:

Am 18.05.2011 14:21, schrieb Steven Schveighoffer:

At my previous company, we integrated software from pure software
companies into their required OSes and hardware, and did all the
OS/hardware dirty work for them (i.e. we turned pure software into an
appliance).  One of the *worst* problems was when the customer wanted
some version of Linux, and let's say they had a specific kernel build.
Because of the expectation from the Linux kernel that you just recompile
all your drivers, any RAID card (a very common requirement) which had
proprietary driver code would require us to contact the hardware vendor,
and have them rebuild the RAID driver on their specific kernel (for a
not-so-nominal fee of course, with very little support).


That's why you should use hardware that doesn't rely on proprietary
drivers on Linux. If the driver is integrated in the Kernel you don't
have to worry if it still works after minor or major upgrades.
On Windows you may have hardware that is supported on Windows XP, but
not on Win7 etc.

I don't want to get into a philosophical debate here, but this is truly unrealistic. I think it's one of the main reasons many hardware companies don't support Linux. Opening the source does not mean you will not support it, and then you have to deal with 8 million configuration options for the kernel to test against your driver. As a hardware company whose main purpose is not writing drivers, that sounds like a QA nightmare.

Yes, XP drivers don't work on Windows 7, but they work on XP, and there is only *one* XP. Furthermore, Microsoft *purposely* does not invalidate existing drivers. Compare that to Linux, where not only do the interfaces in the kernel change from revision to revision, but someone is *rebuilding* the entire kernel and all the drivers on every revision. I'm surprised it works as well as it does.

Case in point, while I was using Linux as my main OS, an upgrade of the Fedora kernel simply broke my sound card driver. There was no changes to the driver, and I really never figured out what happened, but an upgrade to the next major release fixed the problem. There is absolutely no reason for existing drivers to break on a minor upgrade.

I think using hardware with free/open drivers is realistic for about any
hardware besides video cards - although the open drivers for AMD/Ati are
getting better. And the proprietary drivers for them are compatible to
any recent kernels (apart from maybe the most recent one, but you won't
find that in distributions anyway). You just have to be a bit careful
and choose your hardware accordingly.

Printer support is woefully missing. My 2-year old printer still isn't supported on Linux.



I fantasized about building my own linux kernel that had zero
configuration options, and would never break driver compatibility
between point revisions.  Such a kernel would allow hardware companies
to release one driver and have it work for any system that used their
hardware and that kernel.

Like Redhats 2.6.18 fork they maintained forever?

Not really. I mean freeze the configuration options for the kernel -- they can never change except for a major release. Then, don't recompile the drivers for every kernel update. Maintain *binary* compatibility for drivers, so one never has to recompile them unless the driver itself has a bug.

I can't imagine hardware companies love
supporting umpteen driver versions multiplied by umpteen linux vendors
(generally they only pick one vendor and support that).

Yeah, they should just donate the driver to the kernel (or at least
release HW specs so somebody else can write an open driver) and let the
kernel developers maintain it.

This isn't always possible, many companies do not own all the software in their drivers, and especially many of the RAID card companies put a lot of the RAID code into their drivers -- that's their IP, and they would be giving away their trade secrets to make it open source.

-Steve

Reply via email to