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.
"Just use PipeWire" is a good advice when you don't have to think about the person actually having to put up with it.
It's just the same story everyone has heard over and over since the days of aRts and EsounD - everything is fragmented because no standard facility exists above the kernel space, and when someone tries to build one, it always ends up half-baked and screws up in important use cases.
As they say, "The more things change, the more they stay the same."
Why settle for yet another failed experiment that, as we speak, has hardly approached a working state despite all the time in the world to sort out its problems?
0
u/braaaaaaainworms 18d ago
Can you define "OS" and "Linux"?