Artem Tashkinov: Independent Hardware Vendors Hate Linux

[duby229]

I don't know about most people but to me, having stable drivers is the bare minimum requirement. Why would I buy a $300+ GPU just to have it perform underwhelmingly and with very limited GL compatibility? MESA has only in the last year or two started to support modern GL at decent speeds. Just by the sheer excitement after the last RadeonSI-benchmarks you can tell that this is not only a recent developement but also that hardly anyone expected this to ever come true.

That's not true either, I predicted it ten years ago, and honestly I'm surprised it took this long. Even though r600g compatible hardware didn't quite beat the poorly performing proprietary drivers, they were solid as a rock and the proprietary drivers were unusably buggy. Then came radeonsi and from that moment on everybody knew what was going to happen. It was plainly obvious during the OpenGL 4.x bring up that the then unoptimized radeonsi driver was performing incredibly well. We all knew at that time that once OpenGL was complete, driver optimizations would begin.

[starshipeleven]

Put yourself in the position of Intel, AMD, or Apple. The old hardware that you're not manufacturing any more? Anyone that is going to buy it already did. So what financial benefit do you get from every dollar spent on updating the drivers?

That is bad PR for PC market, as most people expect their hardware to still work for 5 years if not more (usually more) there.
People that know you'll drop support of your shit in a year is less likely to buy stuff from you, in PC market.

I mean, even NVIDIA that is the quintessential Evil Closed Source Motherfucker That Eats Babies does not really drop support of anything that isn't really obsolete bullshit.

Besides, keeping old drivers maintained isn't terribly expensive in the grand scheme of things, it's what 10, 20 devs total? Intel has like 50 devs for all their hardware drivers on Linux. Even assuming they all are rockstars that get paid 100k per year that's still like 5 millions for a company that makes tens of billions per year... (Also for NVIDIA the situation is similar) I'm sure that none will even notice they are there.

If we were talking of other markets like embedded (or mobile that is a subset of it), then it's 100% ok and everyone did that since the dawn of times.

[birdie]

Nice story about a douche who closed his comment wall to avoid any critic/review of his analysis.

Not sure what you're talking about. Comments are perfectly allowed and there's already almost a dozen of them.

Edit: Disqus has technical issues at the moment. Perhaps all the websites which employ the Disqus comments are run by douche bags.

Edit 2: if you wait for a minute the comments will load and you're free to add yours.

[NotMine999]

Not only in cloud, servers, and professional workstations - also in switches, routers, firewalls, and other embedded devices. Things you wouldn't think of, like Fibre Channel SAN switches, as well as consumer set-top TV boxes, are all running on Linux nowadays. Linux has been displacing VXworks and other embedded operating systems for many years now.


1. Lack of control is a bogus argument. These vendors are free to examine the source code, and submit patches upstream, which is more control than they have over a closed source black-box OS like Windows.
2. Kernel API breakage is addressed by a number of LTS releases. RHEL/CentOS, SLES, etc. all maintain a consistent and compatible API and ABI for the life of the release. For more cutting edge distros, yes, you need to update your code to be compatible with the latest kernel API. Is it really that hard? It's normally only a few lines worth of changes.
3. Inability to publish documentation sounds like a personal problem. This has nothing to do with the Linux kernel or community.

I think the "lack of control" question for some IHV is more like this: "How do I exert maximal control over the customer so I can maintain my revenue stream from said customer?" In other words, "vendor lock-in" and "closed source, never upgrade" software.

My own opinion of some IHV is something like this: "You use what I say you can use and you can never upgrade." That suggests to me that some OHV "products are no different than commercial consumer "schlock" that's focused on "mass market sales", and if it's "Linux based" it's is commonly based on some ancient Linux kernel version that has been customized beyond recognition and never upgraded.

[birdie]

I think the "lack of control" question for some IHV is more like this: "How do I exert maximal control over the customer so I can maintain my revenue stream from said customer?" In other words, "vendor lock-in" and "closed source, never upgrade" software.

It's not about vendor lock-in, it's about "Your code sucks we'll not accept it for certain reasons - go rewrite everything according to our guide lines. Also you're misusing these interfaces and that's not OK with us. Also this, this and that are suboptimal and need to be rewritten (from scratch). Or and your #defines also suck".

In certain ways kernel developers are correct (no doubt about that) but instead if playing nice, they often alienate 3d party developers. Or and that happens even between Torvalds and his close kernel maintainers.

And then when it's all done and the OEM washes their hands of maintaining the code (after all they cannot afford employing people to support every new major kernel release), the code might be ... excluded from the kernel on the grounds that it's ... no longer maintained.

[birdie]

This mindset of putting something that barely works together, ship and forget is what got us smartphones full of security holes that no one can fix. This is also the reason most ARM SBCs are a no-go from the start, you are stuck in time with some crappy drivers that work with the one specific kernel version.

There is a good solution for this, stop reinventing the damn wheel every single time, write good code and get it accepted in the kernel. I'm sure it will be a lot cheaper long term than keeping on doing everything from scratch every time - and doing a piss poor job at that too.

You still do not get it. Linux fanboys just cannot understand one simple thing - in most cases only the companies creating the hardware have the resources and the knowledge to maintain their hardware drivers in the kernel. The fact that you've open sourced your drivers means shat if this code is not properly supported. In your magical world open source drivers are the solution to all problems - fuck no! You have to keep supporting your hardware until your last breath - that's how the Linux kernel works.

Everyone here is so amazed by open source radeon drivers but they are so good only because AMD spends quite a lot of money and resources to make it possible.

[birdie]

The dude is already wrong because linux is already deployed on huge scales in multiple industries. Of course it is true that desktop linux isn't, but I very seriously doubt that has anything at all to do with IHVs. The bottom line fact is that linux has -the- single largest selection of out of box hardware support than any other OS kernel. Period. Literally tens of thousands of supported configurations.)

Literally thousands of semi-supported configurations.

FTFY.

Find me a set of common and popular enough hardware produced in the past two years which doesn't have at least a few warnings and errors on kernel boot. Huh? "Supported" configurations, my a$$. None of you still understand the point of the article - it's not about declaring "support", it's about fully supporting something without warnings, errors, quirks, unsupported features and undefined behavior. My six years old motherboard is still not fully supported by kernel 4.12. The motherboard itself. There are unsupported ACPI features, software suspend doesn't always work, a lot of hardware sensors are not detected. Certain bluetooth features are not exposed. Hardware RAID is not supported at all(!).

Again, a six years old consumer class motherboard which I bought for $200.

[chithanh]

What Linux folks do not want is that some companies throw substandard code over the wall and tell them to suck it.

The kernel has precise formal coding guidelines, and non-mainlined drivers often do not conform to this minimal level of quality! I mean, how hard can this be? This is not somehow surprising to the coder, this is wilful ignorance of how things work in Linux land. And those people are rightly given harsh words by Linus and the other kernel maintainers.

And the quality guidelines are precisely because of the experience that hardware vendors lose interest and the community will be stuck with maintaining the drivers sooner or later.

[duby229]

Literally thousands of semi-supported configurations.

FTFY.

Find me a set of common and popular enough hardware produced in the past two years which doesn't have at least a few warnings and errors on kernel boot. Huh? "Supported" configurations, my a$$. None of you still understand the point of the article - it's not about declaring "support", it's about fully supporting something without warnings, errors, quirks, unsupported features and undefined behavior. My six years old motherboard is still not fully supported by kernel 4.12. The motherboard itself. There are unsupported ACPI features, software suspend doesn't always work, a lot of hardware sensors are not detected. Certain bluetooth features are not exposed. Hardware RAID is not supported at all(!).

Again, a six years old consumer class motherboard which I bought for $200.

Sounds to me like you need to upgrade and buy AMD products my friend. Not all, but most of what you just bitched about will suddenly disappear from your life.

[bvbfan]

Stupid man, he don't want to know how it works, he want a black box and a "magic". The problem is most of programmers are stupid Windows one, that is it.