First, non-desktop uses of Linux significantly outnumber uses of Windows and macOS in general, and a large majority of drivers and functionality is shared there.
Second, drivers not made by the usual giants are, as I mentioned earlier and experienced first hand, written and shipped once, maybe with a few updates for obvious issues, but this shit is harder than you think, with obscure uncaught bugs littered all over the place. Drivers need pretty much perpetual maintenance for all but the simplest blinkenlights.
Third, even "desktop" drivers are run through their places in server environments, through e.g. workloads like Stadia.
Fourth, proprietary drivers are not subject to any scrutiny whatsoever, whereas you won't get past the gatekeepers if you don't pull your shit together for the open source kernels.
Popularity does not fix unmaintained code. Giving even just one annoyed and skilled person the ability to change the code does. And sometimes, external companies like Collabora will decide to overhaul things, which they again can't do for a proprietary driver.
Go to your favorite computer store. Randomly pick 5 laptops, regardless of the price. So no cherry picking.
Use these laptops with Windows installed on them, for a reasonably long period, for example 1 month, as your daily driver. Perform varied tasks on them, such as printing, connecting to external displays, to projectors, other peripherals, playing modern 3D games on them, etc.
Then do the same with Linux.
I'm willing to bet $100 that on average Windows will run better on them, have a longer lasting battery life, better network connectivity, etc.
And if you're trying to tell me that on average Linux runs better than MacOS on Apple laptops and desktops, then this discussion is not worth continuing, we both probably have better things to do with our time.
You're very right that there is no value in continuing a discussion if that's the level of debate you're presenting. I'm off.
Linux as a personal operating system got WAY better over the last years, sure, but you can't seriously argue that it got Windows AND MacOS beat.
Now, a mac on its own tends to work quite well out of the box, but this does not hold for peripherals, and I feel like the machines always end up developing... quirks.
I always felt that the path you picked just gives you the sum of all problems with few of the benefits. I could maybe do the other way around for compat, but the laptop wouldn't be able to stay on this side of the balcony railing for long if I did it the way suggested... :|
Apples, oranges.
But I guess that's kinda in-line with this thread, that Macs are a pain to run Linux on.
And actually, Windows 10 is also approaching this state, but it is not there yet.
I last installed drivers on Windows late last year.
So your example seems to be completely unrelated to the question.
Based on...? Apple is pretty straightforward: they support hardware until they don't. And they're quite explicit about ending support and it's almost always a major release. You might be able to hack support after that, but I've literally never had it be a "toss-up" about when Apple was or wasn't supporting their own hardware.
As for Windows... I've got a 10 year old 2600k based desktop that runs the latest version of windows flawlessly. I guess if you go back 20? 30? 40? years you might find something that can't run the latest version of windows, but you're going to be down a really, REALLY obscure rabbit hole. I can't say I ever recall it being a coin toss, it was about 10 seconds on google of finding or not finding a driver.
Linux on the other hand... the support of hardware is awesome, but determining if something is or isn't supported is generally an afternoon of reading mailing lists.
My favourite example is one that the OP mentioned - not supporting multiple stream transport on Displayport. For those who aren't familiar, Displayport MST is a feature that allows multiple streams over one Displayport cable. Some monitors support this directly, meaning you can have
Macbook -> Display1 -> Display2
Macbook -> Display1
Macbook -> Display2
Except they don't support it for this.
What they support MST for is to allow vastly-higher-resolution displays on macOS, such as 5K displays, by splitting the display image over multiple stream transports to bypass the limit on resolutions and refresh rates that Displayport provides (or provided at the time).
For some reason, they just haven't bothered to implement MST to allow for multiple displays; it exists and is supported, but only for high-resolution displays. This is great if you're googling around and see that macOS supports MST, then you buy monitors which support MST and hey surprise it doesn't work and there's literally no indication why.
Dell makes some Displayport monitors which support daisy chaining.
Linux, however, is another story. Bad sleep support, forget about printing, scanning, GPGPU computing, etc. We use it when we have to.
I upgraded from thinkpad x240 on which sleep worked perfectly too.
What phone are you having issues with? Every android phone I’ve used will communicate with adb. iPhone has never used USB mass storage, and support for that has nothing to do with MacOS.
Can’t comment on the daisy chain issue, I just learned that was a thing.
Screen will remain black. Or, screen will power on, display nothing. Or, screen will power on, mouse cursor will appear, but no password prompt.
No such problem with Linux.
Yeah there are things Linux doesn't support but just don't buy them. The things that it does support generally don't require any driver installation.
macOS does support MST! It actually does! But it only supports it for splitting one display image over multiple streams, to overcome bandwidth limits on Displayport streams.
For providing a signal to very-high-pixel-count displays, macOS uses MST.
For providing multiple displayport signals to multiple displays? Nope, not implemented.
Imagine my frustration after a day of googling and finding out that macOS supports the feature we wanted, but not the use that we wanted.
MST is supported specifically for early 4k displays that had scalers that couldn't handle 4k60, but could handle half the resolution, so they sent two streams. But that wasn't a bandwidth limitation; old MST 4k displays and modern SST 4k displays both used a single HBR2 link.
MSTs primary usecase today is multiple displays, by "daisy-chaining" through built-in MST bridges, dual DP dongles or docks.
Support for hacky displays is less interesting, and hopefully not relevant today.
The screens light up from the same DP stream, which is also why you can have, say, 2x 4k@60hz monitors in this configuration where true MST would need to drop it to at least 30Hz, or lower res.
May I ask how you learned how to do this? I'd like to learn too! I had a great experience developing a Linux user space driver for my own laptop's LEDs. Couldn't figure out how to control the fans though.
2. Play around with embedded. You can use an arduino, but get rid of the Arduino IDE. Once you've ridded yourself from their weird environment and code in C, you're pretty close to what kernel programming is: Direct hardware control, debugging over a serial console, and if you mess up you don't get saved by a segfault.
You can upgrade to playing with ARM boards later if you want. Things like a Raspberry Pi can also be useful to boot random kernels you've built later on for HW stuff, otherwise you can use VMs. QEMU can boot a kernel file directly, which makes debugging easier.
3. Look at one of the tutorial for writing hello-world kernel modules. There's also usually smaller cleanup tasks you can do to get started submitting work. Looking at Linux and FreeBSD both can be useful, and things like Plan9 have very small kernels that can be used as reference. Linux and FreeBSD are not that different. (Windows is a pain with really weird interfaces, but it can be made to work.)
4. Find something you want to do with the kernel or fix in it.
Kernel developers aren't that common, so I imagine a lot of places are willing to train people. The first job I had doing kernel work was pretty open, and just threw minor stuff to begin with at me, e.g. "things stopped working after kernel X.Y, figure out what happened". Bisecting, testing in VMs, printk'ing a lot to compare state, stuff like that. I later ended up being the owner of the kernel drivers of all our platforms, so I guess I did okay. :)
But not having the right documentation was a challenge. MSDN is okay, but the weird mechanics of MDL chains don't really get discussed on Stack Overflow.
How do people overcome this? I managed to reverse my laptop's LED commands: they were implemented via USB so I used wireshark to intercept and analyze the data sent by the proprietary vendor software. What if it's some ACPI thing though? Or some memory mapped I/O chip? How do people figure out how it works?
I grab a machine and install Linux, and it works more or less out of the box. Maybe a few fixable quirks. And I don't use Thinkpads.
I try to use Windows or macos, and it's a coin toss. Windows handling USB like hot garbage (hub balancing/buffer sizes leading to devices unable to activate, webcams glitching, input lagging at random intervals), display issues (macos doesn't support displayport MST), dock connectivity problems (macos freezing or crashing when connected except when it suddenly works for a day, Windows playing disconnect/reconnect sounds in a loop when the machine goes idle), and more, including just today out inexplicable crashing.
Install Linux or plug all the "made for windows/macOS" hardware into a Linux box, and all the problems went away.
My conclusion, supported by having been a proprietary kernel driver developer for Windows, FreeBSD and Linux, is that any hardware and driver combo tends to be a coin toss, irrespective of platform.
But with Linux, drivers that would otherwise be abandoned after a project was shipped, get a chance at being fixed and improved that their proprietary counterparts can never even dream of.