> Windows as an OS is not as resilient as Linux when it comes to non-ideal operating conditions.
macOS, for example, operates a comparatively limited set of hardware platforms.
And it runs on super underpowered boards too, on which windows doesn't even have any chance of booting
The Windows ecosystem supports a ridiculous variety of hardware.
The Windows that comes preinstalled with most computers truly "supports a ridiculous variety of hardware", but that happens because some professional has already spent some time with the installation of Windows together with all the device drivers provided by the vendors of the various weirder components included in that computer.
When I had to install Windows on embedded computers I had countless problems. I had to use frequently some complicated methods to give device drivers to the Windows installer at an early phase, because it was not able to boot on those computers. Their BIOS/UEFI lacked many legacy features, while Windows lacked drivers for some modern features, so they were mismatched.
Even after Windows was eventually installed, some of those computers had SSDs with low writing speeds, which made them unbelievably slow in Windows due to some stupid and useless Windows services, which by default were writing continuously the SSD and it was very difficult to disable them. Fortunately, that was Windows Enterprise, so it was possible to disable Windows Updates. On some of the computers with problematic SSDs, after the initial installation, booting required more than an hour, because that much was required every day to perform Windows Updates. Only disabling both Windows Updates and various indexing and swapping services has lowered the booting time to normal values.
On the other hand, Linux booted immediately on any of those computers, without having to do anything, and in comparison with Windows it was blindingly fast. Obviously, because those computers were intended to be used as embedded computers they did not have any of the peculiar peripheral devices that are usually included in laptops and for which their vendors provide neither documentation nor Linux device drivers, so they are unusable in Linux unless successfully reverse-engineered, while working fine in the preinstalled Windows.
Yes it does. RedHat deprecates older drivers, but it's their problem. I connect too many stupid things to my Debian box, and they're enumerated and initialized instantly. These drivers get bug fixes too.
That kernel runs on cheapest phones, and on largest supercomputers. With a similarly wide diversity of software. A much more heterogeneous environment than Windows can dream of.
> With container workloads, "Linux" is just the kernel; userland can be largely absent.
It supports the $200 junkbox your gran bought from Walmart to $20,000 enterprise racks and is expected to support all of those different workloadsFair, but let's not forget a couple of facts.
First of all, most of the early Linux woes stemmed from two main roots. Drivers, and bad implementations of standards (ACPI & APIC most prominently). Lower cost Windows machines always needed "vendor drivers" to workaround what sins vendors committed with bottom of the barrel hardware, so these drivers handled the non-standard things they did with the already crippled hardware.
Let's also not forget that Microsoft tried their best to weaponize standards to break Linux (in a similar fashion they broke Dr. DOS). See: Halloween Documents [0].
So given your hardware implements the standards correctly, and you have drivers for your hardware, Linux works way better on the same hardware than Windows. This brings us to
> It supports the $200 junkbox your gran bought from Walmart to $20,000 enterprise racks and is expected to support all of those different workloads and insane variety of software that can be installed.
I have two Intel N100 boxes. One is running W11, the other one is running Debian Testing w/KDE. Former is my parents', latter is mine. Mine is using less RAM, running way cooler, and uses less CPU cycles to accomplish harder tasks, while supporting all the hardware on it, at full speed. So, given your hardware implements the standards, and you have drivers, there's no difference in support. It's not a design/kernel issue. It's a support/willingness issue.
I just remembered that Valve's Source Engine ran 25% faster on Linux after porting without any post-port optimizations, which is a great example how Linux is generally lighter and how well it can perform if given proper drivers for any piece of hardware.
> In contrast, I'd make the case that the majority of Linux distros are running in large data centers like AWS, Azure, and GCP where there's a relatively high degree of homogeneity of the underlying hardware and the operating environment on top of that.
I'm an HPC admin managing clusters close to two decades. The problems you encounter on these systems when something goes wrong is way complex than you see on desktop systems. All of these resiliency features create tons of complexity while helping you. Linux runs on these systems better for a longer time, because these systems are implementing standards correctly for a longer time, and you pay for expensive hardware and correct implementation of it, so kernel bundled drivers work correctly 99.9% of the time when you change the hardware.
> macOS, for example, operates a comparatively limited set of hardware platforms.
XNU is for all intents and purposes is BSD kernel, and macOS can be considered a BSD. Give proper drivers, macOS can also run on from your spoon to a satellite. It's POSIX compliant. They even contribute back to BSDs.