DVM - D Version Manager 0.2.0

Steven Schveighoffer schveiguy at yahoo.com
Wed May 18 08:20:48 PDT 2011


On Wed, 18 May 2011 10:47:02 -0400, Daniel Gibson <metalcaedes at 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


More information about the Digitalmars-d-announce mailing list