[nasoieu]

That chart with the growth of the Linux kernel discredits everything. The Linux kernel continues to grow because they are obsessed with keeping all drivers in mainline instead of having a stable API for them as any sane project would.

[rhencke]

I believe one of the reasons Linux continues to be successful today is _because_ they keep the drivers in mainline _without_ a stable API.

It is a key motivator to ensure drivers remain available and supported well into the future of Linux.

[pjmlp]

Which given the way legacy AMD drivers story has been handled on Ubuntu, it is quite far from actually being so.

My Asus Netbook no longer gets all the acceleration options that it used to have pre 16.04.

Linux is successful because it is a free beer UNIX clone.

[monocasa]

You still have the source to the old drivers. It's just not a priority for others to support anymore, but you have the means to go add that support yourself, or pay a third party to do it for you.

Contrast with when windows changed the video driver architecture in Vista, and the only option you had was to pound sand.

[bunderbunder]

Seems like a pretty easy cost/benefit analysis to me:

I can either spend thousands of dollars worth of my time on updating the driver, or I can pay someone else thousands of dollars to do it. Or I can spend a fraction of that on a new video card.

Seems like the only solution for Vista users is the only solution I'd ever have gone with, anyway.

[monocasa]

Sure the cost/benefit works out the same for you (which is why no one has done the work), but that's different from the full set of options available to you in both cases.

[bunderbunder]

How expansive do we want to be about what the full set of options is, though?

I tend to fall on the side of the root poster - if having a stable driver API means Linux gets more commercial driver support, then that's the one that has the highest cost/benefit in my book.

In practical terms, being able to hack on open-source drivers isn't particularly useful to me, but having an easier user experience with Linux on the desktop (and, more generally, having Linux on the desktop be something more than an also-ran) would benefit me immensely.

[pjmlp]

I skipped Vista, however my XP drivers were fully supported on the upgrade to 7.

[iforgotpassword]

Some xp drivers work on 7, most don't. Also unlike user space, you cannot run 32 bit drivers on 64 bit windows, so unless you were running 32 bit win7 you needed 64 bit xp drivers, which were rare. Are you sure you explicitly installed xp drivers and didn't just happen to have hardware where windows shipped matching drivers or could download them from the windows driver database? (Or downloaded an installer bundle from the manufacturer's website that just contained drivers for all supported platforms..)

[core-questions]

Womp womp. Most of those netbooks are unusably slow anyhow, and were when they were brand new too. Run an older kernel on there and call it a day.

[pjmlp]

Sorry but a DirectX 11 class dual core APU is good enough for general purpose gaming.

And runnig legacy kernels? No thanks.

[monocasa]

Which GPU is it specifically?

[pjmlp]

AMD Fusion Brazos APU, Radeon HD 6250

[nasoieu]

Linux on the desktop would have succeeded with a stable driver API. Having hardware with closed source drivers supported could have being a walk in the park for OEMs. Bad 3D, wireless, etc. support is what killed Linux. OEMs would have probably made more and better drivers if they didn't have to make changes to them every few months or go through the effort of releasing and mainlining the source.

[btilly]

This is your opinion. The opinion of informed observers who are actually doing the work is the opposite - OEMs produce buggy, incomplete drivers and don't care to fix the bugs. In fact, given the choice, they don't want to allow anyone else to dig into their drivers because doing so can only lead to embarrassment. Plus exploits that are discovered are likely to be cross-platform exploits.

Any operating system that wishes stability therefore has to put barriers between themselves and the driver. And, preferably, should use drivers that they can audit themselves rather than trusting OEMs.

As an example of this outside of the open source world, the biggest reason why Windows used to have a reputation for BSODs is that they were dependent on third party drivers. Windows made it harder for third parties to take down their OS, shipped tools to audit drivers for bugs, and forced OEMs to clean up their act. (Which they didn't do voluntarily.)

[hinkley]

Three words:

Creative Fucking Labs.

Someone told me back then that the sound blaster drivers were responsible for more crashes than the next several causes combined, so I started watching and I’ll be damned if I didn’t see the same thing.

[renox]

If I remember well, there was a sound card which talked on the PCI bus after it should have stopped talking, these kind of bugs can break any OS, microkernel or not..

[nasoieu]

It's better to have buggy, incomplete drivers than no drivers at all.

[Dylan16807]

If you control the desktops and take strong measures to stop horribly-buggy drivers from working, 95% of manufacturers will fix the drivers because they want to sell the product.

In that tradeoff, I'll easily pick the marginally smaller market with vastly better drivers.

[iforgotpassword]

This is your opinion. I prefer using hardware with stable drivers, working reliably.

[jonny_eh]

That's why I use a Mac. Seems like a good solution is to have the OS and HW manufacturer to be one and the same.

[nasoieu]

That's not what I said. Would you rather have no hardware or hardware that BSODs once a month?

[AnIdiotOnTheNet]

> Linux on the desktop would have succeeded with a stable driver API.

I doubt it. Linux desktop's problems run far, far deeper than that one questionable choice.

[agumonkey]

So we should have two numbers, actual kernel, whole tree.

I am quite convinced that if they kept it that way it was because some unplanned property caused worse driver status with an API; too many delays, improper usage I don't know.

If there's no solid reason, then I'd be happy to have split codebases.

[drewg123]

RHEL does provide a stable kernel ABI (kABI) that can be and is used by vendors to ship binary drivers. See https://elrepo.org/tiki/FAQ

When I worked for a NIC hardware vendor, we would ship our driver in 4 forms:

1) source tarball

2) upstream kernel

3) RHEL/Centos kABI compliant source and binary rpms

4) Debian pkg using dkms

The upstream kernel driver wasn't good enough for a variety of reasons. For example, on Ubuntu LTS and RHEL, the in-tree driver was often based on a kernel that was several years old and which lacked support for recent hardware or features.

[Jweb_Guru]

It's not misleading because most Linux kernel drivers run in kernel space; hence compromising them indeed potentially compromises the whole system, which is exactly the article's point. The fact that they're often buggy and poorly supported, unlike the "real" kernel, makes things worse and doesn't invalidate anything.

[hinkley]

Nobody seems to understand that it’s possible to have one source tree and multiple binaries.

You can have hybrid systems where the code runs in isolation but the pull requests are still self contained instead of split into multiple pieces that have to be coordinated.

[naasking]

> That chart with the growth of the Linux kernel discredits everything.

What claim does it discredit exactly?

[AnIdiotOnTheNet]

If you insist that all drivers must be a part of the kernel, then it is perfectly fair to count all driver code as part of the kernel code.

[digi_owl]

While equally obsessed with maintaining a stable API towards userspace. Sadly much of userspace is an unstable churn of API changes.