Linux Desktop is starting to smell a lot like Android now judging by how vertically integrated it is becoming. With the push for a permissively-licensed (MIT, BSD etc.) userland and concentration of developers within a small group of companies and orgs sponsored by them, they might eventually do what Google is doing and start delaying releases for sourcecode, or stop altogether. (MIT, BSD and other licenses do not ma…
Luckily “Linux desktop” is not a single thing. There are many options to choose from. I’d dial the FUD down just a bit.
Which is a big reason why the Year of Linux Desktop has been delivered in WSL and Virtualization Framework, eventually Googlebooks.
It's already an issue now because "best" is subjective but SystemD developers only care about their own views.
Why would they care about any other views but their own and those who contribute either financially or through code? Seems like all people can do these days is complain on github, X, mastodon, reddit, HN. It's only talk, talk and more talk, but no do.
Why should the community accept them as a mandatory dependency for every desktop if they don't? This is RedHat shitting up the Linux desktop we're talking about, not some hobby developers releasing things in their free time.
Well, for ALSA and pulseaudio, the latter more or less just surfaced the tons of bugs in the underlying, at the time very shitty audio drivers. Remember, only pulseaudio is a sound server, so ALSA wasn't even exercising many of the more "advanced" features, and drivers were only supporting the most basic stuff.
Considering pipewire was a drop-in replacement for pulseaudio with (almost*) full compatibility and none of the stability issues (you can even use the pulseaudio commands to control it), the problem was definitely in the pulseaudio code. * I do remember reading there was one feature they intentionally dropped because it was extremely rarely useful and could be handled in a different way, but don't remember what it wa…
So one audio server managed to provide a shim for another audio server, great.
But it absolutely doesn't follow from that that pulseaudio was somehow bad. There was more than a decade where audio drivers were slowly getting bug fixes to get to a state where they are working okay for the most part. Pipewire would have experienced many of the same issues as pulseaudio, and we would similarly attribute those errors incorrectly to the audio server.
Considering pipewire was a drop-in replacement for pulseaudio with (almost*) full compatibility and none of the stability issues (you can even use the pulseaudio commands to control it), the problem was definitely in the pulseaudio code. * I do remember reading there was one feature they intentionally dropped because it was extremely rarely useful and could be handled in a different way, but don't remember what it wa…
So one audio server managed to provide a shim for another audio server, great. But it absolutely doesn't follow from that that pulseaudio was somehow bad. There was more than a decade where audio drivers were slowly getting bug fixes to get to a state where they are working okay for the most part. Pipewire would have experienced many of the same issues as pulseaudio, and we would similarly attribute those errors inco…
My laptop would regularly freeze and need a hard reboot, and I never could figure out why. One day for a completely unrelated reason I decided to try switching from pulseaudio to pipewire, with no other changes (including no other upgrades; I'm lazy and like stability), and months later I realized it hadn't frozen at all. Still hasn't, years later. The problem was definitely pulseaudio making the whole system unstable, not just causing audio issues.
> Systemd the init service is excellent. When it's not actively going against decades of convention and breaking solid programs everyone has used forever: https://superuser.com/questions/1372963/how-do-i-keep-system... (screen was also affected, not just tmux) I'm not sure if it was linked from there, but somewhere in the discussions the systemd devs' recommended fix was for screen/tmux/anything else affected to add…
I've been impacted by this particular "issue" and while it's changing the way "decades of convention" it's not really a bad thing imo. Running things via screen and tmux as a solution to background tasks has always been a huge hack imo. Not only that but the alternative approaches with nohup and disown also have their own issues. Imo it's actually pretty reasonable to need to work work the OS service manager to run b…
Those were just the most prominent things, which were immediately noticed because it's completely normal to leave them open remotely to maintain context for something and quickly pick it back up when reconnecting. It's kind of their whole purpose. But the change affected everything, including for example the "daemonize" program.
While I think systemd is a great init system (as well as some other components under the systemd umbrella), I really dislike when components up in the stack hard-depend on it. We can't use GNOME, plasma-login-manager, and soon Flatpak without systemd. Maybe systemd should have been an API + a spec instead of an unportable implementation.
Maybe this statement actually holds in reverse? Quoting vbernat's comment on Lobsters: systemd was a "gift" for people running alternative desktop systems. Previously, many services were bundled with GNOME and you had to go through many hops to use them on a non-GNOME desktop (for example, GNOME Power Manager). systemd replaced many of these GNOME-only piece of software that were constantly breaking when you tried to…
This is I think false
Even if some gnome specific tool didn't work there, guides would point to xfce's tools or lxde or kde or some independent
Or some cli command that I would personally prefer
And even recently these tools were quite bad, so CLI commands, file changes, or extra packages are normally necessary
Because systemd confuses a lot of things by having two projects with the same name. Systemd the init service is excellent. Systemd the catch all for trying to rewrite all services to come up with a baseline version of everything is a strange and NIH project. They would have been far better off politically by coming up with a spec and seeing if they could submit patches to get the current services to use the APIs they…
> Systemd the init service is excellent. When it's not actively going against decades of convention and breaking solid programs everyone has used forever: https://superuser.com/questions/1372963/how-do-i-keep-system... (screen was also affected, not just tmux) I'm not sure if it was linked from there, but somewhere in the discussions the systemd devs' recommended fix was for screen/tmux/anything else affected to add…
I think this points out my reasoning perfectly.
Systemd the init didn't do any of this. This is systemd-logind that is doing this.
Conflating multiple projects with the same name is a terrible idea.
Because systemd confuses a lot of things by having two projects with the same name. Systemd the init service is excellent. Systemd the catch all for trying to rewrite all services to come up with a baseline version of everything is a strange and NIH project. They would have been far better off politically by coming up with a spec and seeing if they could submit patches to get the current services to use the APIs they…
> Systemd the init service is excellent. When it's not actively going against decades of convention and breaking solid programs everyone has used forever: https://superuser.com/questions/1372963/how-do-i-keep-system... (screen was also affected, not just tmux) I'm not sure if it was linked from there, but somewhere in the discussions the systemd devs' recommended fix was for screen/tmux/anything else affected to add…