I think "highly-integrated" and "first class" are the key terms here.
Linux supports much more consumer hardware out of the box than it did a decade ago, but if you ever do encounter a driver issue, you'll need to know your way around the terminal and be able to google-fu your way around some forums. The people on this site might be able to get through it without too much pain, but we're in the minority.
Windows definitely supports more hardware out of the box, and even when something doesn't work, it gives you some nice GUIs to manage the drivers. At the end of the day writing drivers sucks, and it's tough to provide support for the virtually endless supply of components and periphs without paying people to write those drivers.
I'd argue that Linux is moreso 1 and 2 ("highly-integrated first-class hardware support" and support for all third-party components under the sun").
You rarely have to install any drivers. The kernel comes with drivers for almost every driver under the sun.
On the other hand, there are a lot of CVEs for Linux, and while they do get fixed quickly, the security vulnerability surface area is quite large. Especially considering the sheer size of kitchen sink kernel that is.
Re: #1, when I said “highly-integrated”, I was referring to base-OS features that depend tightly on things (maybe third-party) drivers do. I.e., having more kernel or userland code, on the OS side of the fence, that calls into untrusted driver code through specialized (rather than generic “device-class” API) interfaces. Things like kernel serial-debugger-over-USB support, or how Windows elevation prompts interact with screen-reader software. Another example, not from desktop OSes, is how Android/iOS treat being plugged into a car.
In all these cases, a third-party driver is essentially being given the the reins to the system, intentionally, as part of the user’s expected workflow. Windows and macOS (and, I would suspect, any OS solving for enterprise requirements) both have places where they allow third-party drivers to participate in these elevated APIs; while Linux doesn’t really (Linux only has third-party driver-blobs that fit to specific isolated in-kernel sandboxes.)
My thought re: #3 was that:
• with Linux (and disregarding the few large corporate binary blobs for wi-fi and GPU), mostly corporate-sponsored FOSS devs write PRs for the kernel, and then the kernel maintainers “take receipt” of that code by merging it, taking all further responsibility for that merged code, making it essentially equivalent to code they wrote themselves (and at that point, the code is now owned by the kernel project, such that new development should not occur out-of-tree against the original development, but as in-tree patches against the merged code);
• with Windows, corporate third-parties (but often fly-by-night Shenzhen ones, if that’s the hardware you buy) maintain most drivers, and Microsoft just certifies them, like apps in an app-store (which ensures mostly that they don’t crash Windows, and isn’t a security audit);
• with macOS, Apple writes most drivers. Of the drivers third-parties do write, Apple takes ultimate control and responsibility for QAing that code and customizing it for macOS—Apple does their own builds, hardware-matrix testing, packaging/deployment, etc., essentially making each particular point-release of a driver into a part of the base OS. However, they don’t take ownership of this code; the driver will rot unless the third-party sends them a new version to start integration on all over again.
• with Hackintosh’ed macOS, random FOSS hobbyist developers write the (extra required-for-your-build) drivers, and nobody is guaranteed to be maintaining or QAing them.
A security-vulnerability surface isn’t just about surface area, but also about how much control and visibility—essentially, trust—the OS maintainer has into that surface area.
Windows forces updates as often as it does, because Microsoft doesn’t have good visibility into which third-party drivers will be affected by which updates (which they could use to bunch together all driver updates addressing a particular CVE); nor do they have control of those third-party drivers enough to structure them such that their updates can be woven into a seamless, non-restarting update process. Security-critical updates just... show up, on their doorstep, coded in arbitrary silly ways (to deal with the arbitrary silliness of the original background services and/or tray utilities that talk to the driver) and they have to deal with that.
Linux—at least where the base OS is concerned—doesn’t have any such “opaque-to-the-maintainers” surface area, so Linux can get away with fewer “restart required” conditions. They have both visibility and control.
macOS—because Apple demands ultimate control of all macOS drivers (to the chagrin of companies like Nvidia)—can demand that drivers take a particular form (i.e. microkernel daemon servers with activation ports) where Apple are easily able to just in-place upgrade many drivers as part of a package installation, without restarting the OS. The fact that they’re already in relationships with these driver developers also gives them visibility into the progress of addressing CVEs.
(macOS does want to restart for point-release updates pretty often, but that’s down more to Apple’s BSDish philosophy of “the base OS is a whole that should be replaced with a new whole, rather than getting into a state where both old and new components are running.”)
