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.
The thing is, many more people are using Windows, than Macs and many more people are using Macs, than desktop Linuxes. So your anecdata goes against a mountain of anecdata from people using those platforms.
You are incorrectly assigning platform popularity as equal to driver maintenance.
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.
I know all of that, but it does not square up with real life.
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 will pay me just $100 to out of my own pocket buy five random laptops regardless of price, some of which will be several thousand dollars, from the local electronics store.
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.
I am arguing just that, with a reasonably large and varied sample-size, although heavily biased towards macs over windows-powered machines. I get a lot of machines from clients.
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... :|
The thing is, many more people are using phone and tablets, than Windows and many more people are using Windows, than Macs and many more people are using Macs, than desktop Linuxes and many more people are using desktop Linuxes, than desktop BSDs. So the anecdata goes against your mountain of anecdata that goes against a world of anecdata from people using those platforms.
I don't remember installing any drivers in Linux in last... I don't even know how many... years. For the hardware I happened to use, it was Mac-like experience.
And actually, Windows 10 is also approaching this state, but it is not there yet.
The great thing about Linux is that almost every driver is included with the kernel itself, so you don't need to worry about installing drivers. Of course, there are vendors who don't like to cooperate with Linux developers, and release kernel-tainting drivers outside of the mainline kernel.
I've had to on Linux for a very common wireless networking chip. Also for a scanner from a very common printer brand (that ironically has excellent support for printers on Linux). And this is Debian on a ThinkPad--a very common combination. Almost as good as Windows but given I had to load my wireless drivers via USB I still consider Windows the gold standard when it comes to built in drivers. It at least does well with networking drivers which is the most important and essential drivers to have. Everything else windows can easily download and install automatically over the network. I last did a manual install for drivers on Windows years ago cos it just does it by itself now.
Hm? Debian is famous for not including nonfree wireless firmware on purpose (drivers are an entirely different thing). They also provide an optional installer with these included.
So your example seems to be completely unrelated to the question.
There is no choice in OS for mobile. Its strictly tied to the hardware so I don't see how that could show any kind of user preference without being dominated by hardware preference.
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.
I'm a huge apple fanboy, but there are still issues that crop up on macOS, like it or not.
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
rather than
Macbook -> Display1
Macbook -> Display2
This is great, and it really helps clean up your desk in multi-monitor setups and maintain that "one cable" philosophy that I, personally, love. And macOS supports MST too, which is great.
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.
Huh, I've only ever heard of MST in the context of too-high-res displays o_0 Never heard of raw DP supporting daisy chaining, I thought only Thunderbolt does that.
Thunderbol/USB C use displayport signal to drive monitors. I have a apple "thunderbolt" display which happily runs from laptops that don't do thunderbolt.
Dell makes some Displayport monitors which support daisy chaining.
I run all three here. On Windows 10, if I say on the "happy path" everything "just works". I have a Lenovo laptop, and our desktops are Xeon boxes with Supermicro motherboards. No weird USB problems, etc.
Linux, however, is another story. Bad sleep support, forget about printing, scanning, GPGPU computing, etc. We use it when we have to.
For fixing sleep look for an option in Lenovo's BIOS. I had it set to windows sleep mode by default. Switched it to Linux mode and it has been working reliably on my x13 AMD.
I upgraded from thinkpad x240 on which sleep worked perfectly too.
MacOS a coin toss and Linux being robust regarding drivers/hardware support on desktop? Are you talking about Hackintosh, or do we not live on the same planet?
It's the smaller things. Obviously MacOS won't have trouble with mac hardware, but my work macbook can't wake up my monitor through HDMI, or chain DP displays, or connect to my phone's storage through USB, etc...
I’ve never experienced the wake issue, but I always use usb-c to DP or HDMI and apparently those aren’t affected? Assuming it’s the same issue, a little googling shows the problem was fixed a year ago.
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.
Things like printers/scanners can be a problem. With Mac, I cannot scan on Samsung M2070w MFP in color (with the Samsung/HP driver installed, which must be done manually).
I've had far less problems with Linux. Just an hour ago I was dealing with someone whose Roboteq motor controller wouldn't work in Windows or Mac without additional drivers but it's basically plug-and-play on 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.
i miss the golden days of the Hackintosh! Would love to see someone bring this back somehow. Running linux on a machine like an m1 macbook pro would be a dream.
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.
You're mostly wrong; MST does not increase bandwidth, it splits the bandwidth of a single DisplayPort link. To increase raw bandwidth for 5k/6k they combine multiple HBR2/HBR3 links (over Thunderbolt or with multiple cables), which is the opposite of MST.
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.
That is basically what happens when you don't support MST.
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.
> having been a proprietary kernel driver developer for Windows, FreeBSD and Linux
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.
1. Accept that printf (preferably over serial) is The One True Debugger. It is the tool you always have - if you can't get a print over serial, you're in too deep to use a debugger anyway.
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. :)
I got to build a driver once, making an NDIS LWF encap/decap driver for Windows. I found it extremely soothing, and kind of old school - I had to use a real machine in my office with firewire debugging, and use windbg like a greybeard.
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.
> But not having the right documentation was a challenge.
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.