Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm convinced that splitting out management logic and pipewire-pulse was the wrong choice so far for desktops. It exposes regular users to the failure modes of race conditions (https://bugs.kde.org/show_bug.cgi?id=438565#c21, likely https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues..., https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/24...) and inscrutable wireplumber "100% CPU burning" bugs deep in Lua interpreter call stacks, as the price of complexity which only benefits complex users like cars.


  and inscrutable wireplumber "100% CPU burning"
This one sucks hard, been an issue for me for ages.


> wrong choice so far for desktops

Isn't there value in having a single universal media routing framework that works across desktops, automobiles, and other applications? Consistency is a virtue.

> failure modes of race conditions

Race conditions in distributed systems are tricky. A global 64-bit sequence number incremented on every mutation to the PW graph would help, I think. You'd have the server reply with the latest serial number on every query operation, and mutators would supply their last-known serial numbers along with every mutation operation. If a client attempted to mutate the PW graph using an out-of-date serial number, the server would make the mutation fail. In this case, clients would re-query the PW graph state, figure out whether the intended mutation still made sense, and, if so, try again, this time with the latest sequence number. It's hard to imagine PW graph mutations being frequent enough for this approach to generate livelock too.


> Isn't there value in having a single universal media routing framework that works across desktops, automobiles, and other applications? Consistency is a virtue.

Software development isn't about virtues, it's about making computers do useful stuff for us humans. Consistency can help or detract from that ; there's no such thing as an absolute virtue, only technical choices that happen in a specific set of circumstances. Audio is simple enough that it does not seem to cause too much problems but for instance Wayland is absolutely and entirely made worse by trying to shoehorn it both on cars UI (where you want something locked down) and on desktop UIs (where you want random software downloaded from the internet to be able to control the whole thing for e.g. screen recording, global hotkeys, window management mods, etc etc) which are wildly different use cases


> where you want random software downloaded from the internet to be able to control the whole thing for e.g. screen recording, global hotkeys, window management mods, etc etc

I don't want "random software" to be able to do those things. I want to grant these powers to a few select applications and not to everyone else. X11 has no intra-session security model. This lack of security doesn't make it better for desktop or form a case for maintaining X and Wayland in parallel.

To the extent Wayland still has trouble with clients that want to manage windows, it's a matter of missing protocol extensions, not architectural flaws in Wayland that make it and X11 fundamentally suited for different use-cases.

You've chosen a poor example if you're trying to use Wayland to show that we need different software stacks for different use cases. Cross-use-case software stacks are common, work well, and are fundamental parts of the computing universe.


> I want to grant these powers to a few select applications and not to everyone else.

it's more-or-less fine to have a prompt on first app launch (although I have a few times worked with elderly users who literally could not use their computer to do what they wanted because of such prompts, especially on macOs which prompts left and right and trains users to blindly click "yes" or "no")

> it's a matter of missing protocol extensions

there is an infinite amount of missing protocol extensions. As long as it isn't able to fully emulate the win32 API (which is basically what "desktop" means in terms of features) it's not enough


> Audio is simple enough that it does not seem to cause too much problems

Audio is not simple and causes tons of problems.


As proven by OpenGL and Vulkan, consistency only happens on paper, then there is the actual hardware, drivers, OS specific issues,...


Sure. Different GPU setups have different performance characteristics (e.g. tiled vs non-tiled architectures), different sets of supported extensions, and differently intriguing and exciting bugs --- but isn't it still better that, at a basic level, that we talk to them over a common set of APIs (DirectX, OpenGL, and now Vulkan) instead of having vendor- or use-case-specific whole API surfaces?


Not really, because the amount of workarounds, and extension loading, tends to increase to the point that the multiple code paths are hardly any different from having a plugin architecture, and slowly one gets a middleware engine that only uses "one" API.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: