Artem Tashkinov: Independent Hardware Vendors Hate Linux

[phoronix]

Phoronix: Artem Tashkinov: Independent Hardware Vendors Hate Linux

Independent commentator Artem S. Tashkinov is back at it again with his latest thoughts on GNU/Linux and its problems in a post entitled "Why Linux/GNU might never succeed on a large scale"...

http://www.phoronix.com/scan.php?page=news_item&px=Tashkinov-2017-Linux

[tildearrow]

Sorry if this heats up this thread, but:

The "IT guy" argues that hardware vendors hate dealing with the Linux kernel over the lack of control

Couldn't they just write their own drivers?

[duby229]

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

[GruenSein]

" ... will never succeed ... " is already killing any serious discussion on this topic because the Linux-friendly community will go ballistic since his statement is definitely wrong in the generality he puts it in. The desktop is another story completely and the points he's mentioning are worth considering at the very least. Anyway, I'll get the popcorn..

[L_A_G]

The "IT guy" argues that hardware vendors hate dealing with the Linux kernel over the lack of control, the...

Come again? The only way you can have more control than you have on Linux is if you develop your own OS and the only hardware vendors that still develop their own OS and sell their own hardware that I can think of are Apple, Microsoft and Cisco.

[andrei_me]

Can someone elaborate on the part that he says that the AMD open source drivers don't support some hardware features.

Is he talking about freesync, for example?

[89c51]

Can someone elaborate on the part that he says that the AMD open source drivers don't support some hardware features.

Is he talking about freesync, for example?

depending on what card you have opengl might not be the latest. Opencl might not work etc etc.

[zorro]

Not being a developper myself, I was surprised to see the statement that the Linux kernel doesn't have a stable API/ABI, seeing how Linus was using strong language to state that "WE DO NOT BREAK USERSPACE!" (https://lkml.org/lkml/2012/12/23/75). Are these two different things or is one of the two statements wrong?

[Opossum]

I forget where I read this, and I have switched between 3-4 different computers since I last read it so digging out the bookmark is near impossible, but if I recall correctly:

The linux kernel cannot and will not support a stable API/ABI across multiple releases because it's a security hazard, encourages poor support, performance bottleneck, and mainly so a flexibility restraint. The idea here is that even if the biggest companies spent millions of dollars developing the best API+ABI for a kernel ever, bugs design flaws will inevitably be shown. Sure, they could be fixed/improved but only to a certain degree.

It is inevitable that there will come a time when a new technology is invented that would technically work with the API/ABI, but would otherwise be faster/easier/simpler/less confusing if the API/ABI was changed.It is inevitable that an unforeseen consequence would show up. Perhaps a performance bottleneck due to jumping through hoops to be compatible, or a fundamental security flaw that is otherwise needs to stay unfixed (but duct-tape-patched like blocking specific use cases) due religiously supporting a specification. Perhaps a new API/ABI technology that is faster, simpler, more secure, designed a decade from now but couldn't be implemented because it breaks spec.

A way around is to support multiple API/ABI's and guarantee support for drivers written a decade ago. And that too comes with its own faults: you are suddenly needing to make sure all of them work, doesn't break all of them when you want to fix/change the implementation of just one, all of them are secure, and are reasonably fast. Just so you can support 5+ year old drivers (that are possibly unmaintained because if it worked 5 years ago, and you got a guarantee that it will work 5 years from then, why change it? Why fix what's not broken?)

Tl;dr: new technology is invented, flaws are found, new ideas are made, a new specification is warranted.


All that said, take everything I said very lightly. I am not a kernel developer, and not even a driver developer. I could easily be wrong on some, most or even all of this. I'm just reiterating something that blew my mind 5 years ago.

[Nille]

Couldn't they just write their own drivers?

ofc, but you has to maintain this driver. Thats a big effort with no payback.