DVM - D Version Manager 0.2.0

[Daniel Gibson]

Am 18.05.2011 17:20, schrieb Steven Schveighoffer:
> 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.
> 

I don't know much about coding for the kernel, but I guess that most of
the configuration options shouldn't affect your driver.
Of course there may still be a lot of options left that could affect
your driver.

> 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.
> 

Are you sure that it wasn't some userspace fuckup?
Also: bugs in the kernel and drivers are always possible, especially
when using a bleeding edge distribution like Fedora.

>> 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.

As I said, you have to choose your hardware accordingly.
There are a lot of printers that have really good Linux support - more
expensive ones via postscript and/or PCL, cheap ones (especially
inkjets) often need some proprietary libs, that are however independent
of the kernel and tend to work, even when they haven't been updated for
some years (cheap HP printers are often supported via HPs open source
hplip driver).

http://www.openprinting.org/printers is pretty helpful and the
proprietary drivers are available from the printer vendors (for example
Brother supports many of their printers), so it's a good idea to look on
that page and on the vendors page for linux support before buying a
printer ;-)

>>
>>> 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.

As far as I know there are RAID cards with kernel support, for example
a lot of HP cards: http://cciss.sourceforge.net/

Another possibility for a vendor is to ship most parts of the driver
precompiled and just a wrapper for the kernel as source code, so you
just have to recompile/change the wrapper for newer kernels. AMD and
nvidia do that for their video card drivers.

> 
> -Steve

Cheers,
- Daniel