leonardo wrote on 2023-08-24, 09:53:
I think you have a fair counterpoint - some, if not most, of the blame for crappy support has to be the result of the third parties themselves. My take is based on years of subjective experience where you take "crappy hardware", install Linux on it, and suddenly it seems to not be so crappy any more. This has happened with enough consistency that at some point I began to question the other side. Why are drivers on Linux for most hardware inherently so much better? Especially since a lot of them are put together with volunteer effort? Surely the hardware vendor should have the strongest incentive to get their drivers right for paying customers for their primary target platform?
One big difference is that by-and-large, in Linux, the drivers are built into the kernel (or modules) and when you boot up, the kernel looks to see what hardware it's running on and loads those drivers into memory and off you go. This is why you can take a Linux hard drive, especially one without a custom kernel (and while compiling custom kernels made you cool 20-25 years ago, I don't know if it still does), plonk it in any system, and it will generally boot. (GUI stuff, at least in the old days, would be a different story and you'd need to edit some config files. I don't know if that's still the case with recent versions of Xorg though.)
Meanwhile, on Windows, drivers are actually installed, then you have all kinds of stuff in the registry referencing the drivers, you update the drivers separately, etc, so it starts to be very easy to install things out of order, for an upgrade to leave some references to the old version behind, etc. And the buggier the drivers, the more you update them, which means the more stuff accumulates and the higher the likelihood of problems. Take a Windows hard drive from system A to a completely different system B, and there's an overwhelming chance it will BSOD on boot as it tries to load all the drivers for system A's components - I think the newer versions are better at this, but certainly XP and before, you were in deep trouble.
Hell, just switching a SATA controller from legacy to AHCI or the other way around is enough to brick many versions of Windows, whereas Linux will just laugh it off (unless your fstab breaks because you switch from hdX to sdX, but even that is easier to fix if you know what you're doing than trying to revive a Windows install after switching SATA modes). Let's not talk about taking, say, an AMD system with an AMD/nvidia/VIA chipset and trying to boot that system's Windows on an Intel chipset or vice versa.
Put another way, if you have Ubuntu 23.04 and I have Ubuntu 23.04 with the same updates, and we have the same hardware, the exact same stuff will load in memory on both our systems. If we both start off with Windows, any version of Windows, there's all kinds of possibilities where we may install things in different orders, we may install different versions of drivers (e.g. if I plugged my system into a network earlier than you did yours, mine might have downloaded a driver from Windows Update first, whereas if you kept your system offline until installing a specific driver from a CD or flash drive, your system won't have traces of the Windows Update driver), etc, and as a result, a week later, when you boot your Windows install and I boot mine, different code is actually loading at different times and giving different results.
The other thing I would probably guess is that the Linux stuff is managed by a much smaller group of people and there is much less potential conflicts. The driver for thing X only needs to play nicely with the drivers for thing Y and the rest of the OS in the particular kernel build where both are included. Meanwhile, in Windows, the driver for thing X needs to play with a range of Windows versions and has no guarantee about the drivers for thing Y. If someone changes the driver for X and that requires a change to the driver for Y, in Linux, the maintainers just need to make sure that the two changes go into the kernel at the same time (or as closely as the problem is discovered); in Windows, well, good luck trying to reach the author of the driver for thing Y, then getting them to fix their code, then making sure that people who install the new driver for X also have the new driver for Y.
Also, another final point - in Linux, you have the distro vendors in the middle. Mr. Torvalds and his team of maintainers may release a new kernel with new drivers and new bugs for stuff next week, but Ubuntu or Debian won't be giving you that kernel the week after. They'll backport some urgent things to their stable kernel, but otherwise, they'll sit back for a few months and see what happens. So if something got broken in one kernel update... well, there's a good chance it gets detected and fixed long before that kernel makes it to the major distros. The flip side of that, of course, is that if AMD releases revolutionary thing X in September, who knows whether the kernel used in Ubuntu 23.10 will have support for it (in which case you might be waiting until 24.04 or later), whereas if you're running Windows, you can just download the driver from their web site and off you go.