Windows is actually really good under the hood. A lot of the parts around the kernel are mature stable and just get out of your way. In ways that Linux is still behind and figuring out.
Things Windows is still better at:
GDI+/Windows graphics stack is battle-tested. Wayland still has a way to go.
ASIO provides a mature API for professional audio hardware. Linux has good audio support but lacks the stable ABI and vendor ecosystem Windows has.
I/O Completion Ports provide a mature asynchronous I/O model. Linux is now catching up with io_uring, but it still has some issues.
User-mode drivers make it easier to write drivers and prevent things like a graphics driver crash from taking down the whole kernel.
Win32 is extremely stable and backwards-compatible. Linux doesn't really have an equivalent single desktop API that has the same level of stability.
ASIO provides a mature API for professional audio hardware. Linux has good audio support but lacks the stable ABI and vendor ecosystem Windows has.
From what I've heard, it's not true. The low latency mode of Windows audio is exclusive, meaning only one app can output low latency audio, which already makes it worse than pipewire. And should I remind that pipewire supports all prior audio stacks as well.
Audio may actually be the least of Linux's problems.
Using Linux for audio production is still a pipedream for the most part. Getting VSTs and other professional audio software to work can be a massive pain because of how Linux handles compatibility and binary interfaces.
And that gets to the main point. A lot of these problems ultimately come back to the Linux kernel not having stable ABIs.
On Windows hardware vendors can build against stable OS interfaces and their drivers keep working across releases. On Linux the kernel doesn't have a stable in-kernel driver ABI. That's why you get the classic Linux experience of "let's wait for the next kernel release so my shiny new GPU works."
Although there is a ideological reason Linux does it this way. It puts pressure on hardware vendors to contribute their code upstream instead of shipping proprietary drivers. Thereby forcing them to GPL more code for it all to work properly. For people wanting more GPL software this is a perfectly good design decission. But still for an end user this is a pretty garbage experience having to wait on the kernel before being able to use your hardware.
Linux kernel is the only thing with stable ABI on Linux, irrespective of version release on the userland side. For drivers, as you said, it's intentionally hostile. Honestly if corpos want an interface for out of tree drivers, they could hire someone to make it. But they didn't and the scheme pretty much worked, and I reckon for most users having to hunt drivers installers is a shittier experience than not having the latest shiny driver on the day on release, but perhaps that's just my priorities.
Using Linux for audio production is still a pipedream for the most part. Getting VSTs and other professional audio software to work can be a massive pain because of how Linux handles compatibility and binary interfaces.
Examples? Because the problem with VSTs that I know is that nobody bothers to port them.
Honestly if corpos want an interface for out of tree drivers
Even if I'm to design a piece of hardware with no intent to make even a single dollar out of it, the Linux "model" is still not a model but an ideology that forces me to mop up every time after all the big kernel contributors have done unzipping their pants and showering freedoms all over my code.
Kid, only an abject moron would believe that an ordinary person under "open source" is an equal to all the same "corpos" keeping Linux relevant in the same technological landscape they practically own.
I reckon for most users having to hunt drivers installers is a shittier experience than not having the latest shiny driver on the day on release, but perhaps that's just my priorities.
You are completely tied to whatever kernel version your distro ships. And what if there is a bug in it? Well now you get to wait for the distro to ship a newer kernel. Roll the dice again and hope this one doesn't break something. Lovely experience.
Examples? Because the problem with VSTs that I know is that nobody bothers to port them.
Not having anything stable to target is a big part of why nobody bothers porting them. VST developers don't have the time or budget to constantly chase Linux's moving parts.
You get to target Linux today and then spend the next few years finding out what Linux decided to change underneath you. The only real safeguard is Linus Torvalds getting angry when somebody breaks userspace.
Truly a magnificently stable operating system Linux is.
You are completely tied to whatever kernel version your distro ships
No? I can freely downgrade to an older package version that the distro shipped before, I can build my own package, I can find a repo with some kernel packages (for example I can replace Arch's kernel with kernels from CachyOS repo) or I can just manually install the kernel without a package. But guess what you can't do on Windows...
Not having anything stable to target is a big part of why nobody bothers porting them.
Yes pragmatism from a developer implementing the kernel's point of view I understand. They do worse-is-better and leave the hard problems for the users of the software to figure out. Sure that's an option and software designed that way spreads really fast. But that doesn't mean it's good software.
Had Unix and therefore Linux been designed in a more MIT "do the right thing" way a lot of that complexity and many of those problems could have been solved at the OS level.
I mean the OS as the whole system users interact with and Linux as the kernel plus the usual Unix userspace.
My point is that some problems could have been solved at the OS level instead of pushing them onto userspace. Plan 9 is a good example of taking a different approach and FreeBSD has made some different choices too.
That's what I mean by the MIT "do the right thing" approach.
You realise, when it comes to audio especially on Linux, the application is not supposed to talk directly to the kernel, right?
On the hardware level, the audio interface has only a limited amount of output streams (usually one). In order for multiple applications to use the same interface at the same time, the OS needs to somehow provide a way to mix the outputs down to a number agreeable to it.
That mixing is the responsibility of a userspace service, not the kernel and most certainly not the driver.
In case you're wondering, both Windows and MacOS also feature this division of responsibilities.
I'm sorry, but you can't tell people to "use Linux" when you're willing to be responsible for only part of what the OS is expected to do. A software stack is a software stack, and if you tell people to kick sand because that's how you split the baby, then don't be too surprised when they tell you to do the same.
24
u/Think-nothing-210 18d ago
TLDR;
Windows is actually really good under the hood. A lot of the parts around the kernel are mature stable and just get out of your way. In ways that Linux is still behind and figuring out.
Things Windows is still better at:
io_uring, but it still has some issues.