The main reason stuff is mostly windows compatible is due to the fact that driver management is a mess (different distros with different drivers and/or linux kernel versions). The ABI/API issues that are complained about are not helping this.
Even if there are drivers, most of the time they are developed by external people that only wanted to get it working _to a certain level_. Manufacturers dont care about Linux, most of the times, because its hard to develop an installer that is compatible with _Linux_.
I have a story about a friend of mine that tried to make a led driver for the Beaglebone Black. He looked for the documentation, and there was some stuff about an old, deprecated way of toggling GPIOs (pass pin ID) and a new interface (gpiod, using pinctrl and identifier). The documentation was also talking about ACPI, which was totally unrelated[1]. He tried to use "the right way" (using the latest and gratest API), but it was not clear on how to implement this api, as he was experienced with switching registers manually, the embedded way, and had little experience with the Device Tree.
Eventually he wanted to use iomap to just do the gpio toggle _manually_ because it was better documented (read chip documentation and done). He got this idea from when he went to this Korean school as an exchange student, and it was _common practice_ to do this by teachers!
Small example about the gpio madness, google for "linux gpio kernel":
1. A generated page of the API, but also some implementation documentation. [2]
2. Readme file from the kernel, telling you that this is not the documentation you are looking for (old api). [3]
3. An actual article that explains the old and new interface, but still all userspace [4]
4. LWN docu from 2013 using the old api [5]
Your argument is rather muddled there to say the least. You start off talking about consumer hardware then bring up an anecdote about a developer writing userland software against a developer board (ie non-consumer hardware) and use that as an argument that the Linux kernel is hard to develop against despite there being nothing in your anecdote discussing kernel development.
"Anacdata" is always going to be pretty sketchy in any technical debate but here it seems especially so since this isn't even your own first hand experiences (let alone relevant to the point you were trying to prove).
The main reason is, as I stated, because Windows is where the market is.
You're categorically wrong about hardware vendors not supporting Linux, in fact many of Linux developers are employed by these companies, be it Intel, AMD, Linaro, Qualcomm etc.
The problem usually is that one needs the right combination of components for things to work well "out of the box" and so for example avoiding certain GPUs or WiFi chipsets, (others work fine).
This is not up to the individual component manufacturers who are already contributing upstream, but up to the OEMs assembling the complete machines to avoid the ones who don't and many do not simply consider Linux when doing so, because customers are accustomed to Windows and they get a good deal on it from Microsoft anyway, so why bother.
In recent years, DELL has stepped up on this front, Lenovo is coming around and you even have dedicated vendors like System76 selling good hardware with Linux pre-installed.
Your "story" is a problem with a specific vendor (Beaglebone) and then ARM in general, which is a bit of a wild west compared to x86, but that's the nature of ARM that Linux tries to accommodate for, not a Linux problem specifically.
I do wonder why your friend did not install Windows on the Beaglebone and did not interact with the hardware that way? It seems like the experience there is so much better.
What is that? The Beaglebone does not support Windows at all? Well, I guess Windows hardware support is rather poor then.
I was mainly talking about how development on Linux Kernel can be tedious, the adoption of the drivers is usually limited and thus the gains are too low. How come that Realtek is one huge manufacturer of network chips, but their drivers on linux are still crap? Everybody knows that, and if they dont yet know, they usually get bitten by it one day, use google, and _accept their faith_. Users are easy to accept how things are and dont bother to improve because its too hard/complicated/not rewarding.
People that are in control of these issues are the developers. The only thing I hear about Intel/Nvidia from Linux people is complaints about how shitty they are, and why they dont open up their stuff. One key thing might be that debugging of kernel things is not easy on Linux, as listed on the Original Post url? Crash a windows box, hook a debugger on it and off you go. If you dont know enough, im sure windows will help you get it running when you pay them. Oh? Linux doesnt work that way? Bummer.
Maybe the abstractions of Linux's core is at the same time its main weak point. Theres nobody governing a stable api and theres not enough telemetry to detect regressions. Yes, i said it. 99% of the people don't care if theres telemetry reported if it can improve the product. As a developer myself, I would _love_ to have _real world issues_ reported to me, automatically.
anyhow. Nothing is perfect. Linux could be better if there was a team behind it that want to get it "production ready". Like, maybe tell the user why something doesnt work, instead of shouting on the internet that they should buy "linux compatible hardware", which is telling the regular user to buy blinker fluid.
> was mainly talking about how development on Linux Kernel can be tedious, the adoption of the drivers is usually limited
You literally provided an example that does not work in your favor to prove your point.
> Realtek is one huge manufacturer of network chips, but their drivers on linux are still crap?
That's not the case for years, rehashing the same arguments you had a decade ago, or simply being this clueless does not help your case.
> the only thing I hear about Intel/Nvidia from Linux people is complaints about how shitty they are, and why they dont open up their stuff.
You don't really know what you're talking about and it shows. Intel is fine, they have dedicated developers supporting Linux with open-source code, the problem is an Intel+NVIDIA laptop combo and this is due to NVIDIA, not Intel.
NVIDIA support is crap, because NVIDIA wants it to be crap, since they sell enough GeForce GPUs to gamers not to care, nothing Linux can really do about that, it seems that Intel and AMD have no problem shipping a kernel driver. It's a culture thing, more than anything.
And yes, we want the driver to be open, caring about free software is one of the major reasons to go with Linux.
> One key thing might be that debugging of kernel things is not easy on Linux, as listed on the Original Post url?
Much, much easier than on Windows, you even get DTrace, get to inspect the code etc. That's not the issue. Anyone who wants to provide a driver has no problem providing one.
ARM is its own beast, but as I said earlier, this is mostly due to there not being a standard way to i.e. probe hardware like there is on x86 and that's ARM, not Linux at fault here.
Does Linux have problems, sure. But as someone who had family members with Windows 10 call me that they lost their files after an update and the internet is full about the latest macOS being the new Vista, I wouldn't be too sure the competition fares better.
> Yes, i said it. 99% of the people don't care if theres telemetry reported if it can improve the product.
Maybe they don't care, but I'd argue they seldom even know about it or understand the implications.
> As a developer myself, I would _love_ to have _real world issues_ reported to me, automatically.
Part of the free software movement is about equality between users and developers because developers have unquestionably more power. This is more of an ideological thing than anything. Nobody's saying telemetry isn't useful, just that one should be up-front, opt-in, full disclosure about it.
A large part of us care about that, about privacy and the future of unrestricted, general-purpose computing.
I am sure many don't and for them Windows and macOS are there. If Linux doesn't work well for you, that's fine, what I find annoying is pretending that Windows/macOS are somehow way less annoying to use, when every time I use them, I come across crappy behavior.
Even if there are drivers, most of the time they are developed by external people that only wanted to get it working _to a certain level_. Manufacturers dont care about Linux, most of the times, because its hard to develop an installer that is compatible with _Linux_.
I have a story about a friend of mine that tried to make a led driver for the Beaglebone Black. He looked for the documentation, and there was some stuff about an old, deprecated way of toggling GPIOs (pass pin ID) and a new interface (gpiod, using pinctrl and identifier). The documentation was also talking about ACPI, which was totally unrelated[1]. He tried to use "the right way" (using the latest and gratest API), but it was not clear on how to implement this api, as he was experienced with switching registers manually, the embedded way, and had little experience with the Device Tree.
Eventually he wanted to use iomap to just do the gpio toggle _manually_ because it was better documented (read chip documentation and done). He got this idea from when he went to this Korean school as an exchange student, and it was _common practice_ to do this by teachers!
Small example about the gpio madness, google for "linux gpio kernel": 1. A generated page of the API, but also some implementation documentation. [2] 2. Readme file from the kernel, telling you that this is not the documentation you are looking for (old api). [3] 3. An actual article that explains the old and new interface, but still all userspace [4] 4. LWN docu from 2013 using the old api [5]
[1] https://www.kernel.org/doc/html/v4.17/driver-api/gpio/board....
[2] https://www.kernel.org/doc/html/v4.17/driver-api/gpio/index.... [3] https://www.kernel.org/doc/Documentation/gpio/sysfs.txt [4] https://embeddedbits.org/new-linux-kernel-gpio-user-space-in... [5] https://lwn.net/Articles/532714/