Hacker News new | ask | show | jobs
by kfwhp 2672 days ago
Define "technical requirement". It's not really technical, it's political. As an end user, I couldn't care less about being able to inspect how the code works. What I would like is for Linux to have a stable API for drivers, so out-of-tree drivers could work on every release without DKMS or crap like that. Windows could do it, so it's definitely not a "technical requirement".

If they are afraid of getting bug reports from guys running out-of-tree drivers, they can still keep using the "tainted" mechanism. It is not incompatible with having a stable API.

3 comments

I believe that the Linux folks don't want a stable ABI because they want to be able to smoothly redesign the internal architecture of their kernel whenever they want. Once you have a stable ABI, you have to worry about continuing to support the model of that ABI for a long time (or, if something akin to the "don't break userspace" policy were adopted, forever), which ossifies your design & blocks you from adding certain features. Additionally, by applying technical and political pressure to move drivers in-tree, the kernel devs gain the power to self-maintain over time (even Windows breaks its ABIs every once in a while and causes havoc: see Vista)
That's the rationale Linux people give. But FreeBSD has managed to maintain much stronger backwards compatibility (with older ABIs gradually moved into -compat modules and eventually removed entirely) than Linux without it noticeably damaging kernel development speed. Linux is the only major platform where hardware that worked frequently stops working (not just because of closed-source drivers; the same problems exist for open-source drivers that are out-of-tree for whatever reason - there are plenty of high-quality open-source drivers that the kernel doesn't accept in-tree or that don't want to be in-tree), and what do you actually gain for that high price?
> What I would like is for Linux to have a stable API for drivers, so out-of-tree drivers could work on every release without DKMS or crap like that. Windows could do it, so it's definitely not a "technical requirement".

Quit the rage and just stick to Windows then. I'm using NVIDIA card and don't want to have this supposedly "stable API" which would leave me at the mercy of their whimsy. NVIDIA as a company deserves much more shame than the middle finger which Linus gave them. And there's no politics here, it's simply their business decision not to support Linux, not the other way around. Once you make an exception for one company you ought to do this for everyone else, it's not how that works in the Kernel community. So yeah it is a "technical requirement", technically it is how drivers get their stable implementation there.

Windows developers have access to the source code under NDA. This is much less feasible for Linux developers, obviously.
That's got nothing to do with having a stable API. There are thousands of device drivers that were written over 10 years ago which work perfectly well on current versions of Windows and which will keep working for years to come.

Linux made the political decision not to allow this, at the expense of end users.

That seems the exact opposite of my experience. Most hardware drivers break after one or two Windows versions once the vendor stops updating the driver, eg. audio hardware, printers. On Linux things generally keep working. As an end user, having drivers in-tree is one of Linux's best features.
Having drivers in-tree is great, but a lot of drivers can't or won't be in-tree. My webcam (using qc-usb), PDA (using synce) and TV capture card (I can't remember what the project that supports those was called) all stopped working on Linux, even though the drivers were open-source and seemingly high-quality, because that's not enough for Linux - you have to be in-tree or you'll get broken.
At the time when I had TV capture card (Hauppage PVR250; it was analog TV tuner with MPEG-2 hw encoder), it stopped working in Windows way before Linux: in XP, the driver installation was showing HRESULT errors, but once a blue moon it would succeed. Forget anything newer. With Linux, I think it should work with the current ivtv driver, but I don't have it anymore to try.

Another example are scanners. Does your driver for Windows use TWAIN? Well, then it won't work in Windows 10 anymore, which made WIA the only option. Lot of fun for folks, who were automatically updated.

Tell that to my Brazos GPU that lost capabilities with AMD driver's reboot.

Being open source didn't help at all.

> thousands of device drivers that were written over 10 years ago which work perfectly well on current versions of Windows

Is that really true? A couple months ago I bought a USB to serial adapter that advertised Windows Vista support on the packaging. It did not work with Windows 10 at all, and I ended up returning it.

I have plenty of hazy memories of printers that worked fine under Windows 9x not playing nice with Windows XP.

It's unfair to use printers as an example. For one, they're still a huge problem in Linux, but for two they're universally regarded as some of the crappiest things to work with in all of IT.
Printers under Linux have also one positive feature: if the specific model is supported, it is really plug and play.

The hard part is to choose, which model to purchase.

In my experience that is not true. The few printers I've had to set up on a Linux device required me to go find PPDs.
Well, 9x and XP were two completely different operating systems that just implemented similar user space APIs. That was a one time transition. Drivers written for NT or 2k might have worked.
> Linux made the political decision not to allow this, at the expense of end users.

There are many pros and cons of having a stable API, and it can be technical and political and more. Saying it's just a "political decision" is plain wrong.