121–130 of 141 posts
I love using Alpine, and for the few packages that don't have a musl version available (e.g. Steam), flatpak has been a great way to run them.
Hopefully someone will maintain a fork.
Earlier quoted context omitted.
systemd-appd doesn't exist yet.
> systemd-appd doesn't exist yet. This avoids the question, apparently because the design of this part makes it certain that when it does come into existence, it will depend on the rest of systemd. The problem with systemd is that it's purposefully designed to be a viral monolith, without this it's got no purpose. We've been with this long enough to pretend otherwise.
systemd-appd will likely depend on some but not all of the rest of the systemd system.
But the original question is beside the point -- systemd-appd will provide an API that can be implemented by others. I doubt the questioner actually cares much about how much of systemd systemd-appd pulls in, they want none of it.
Earlier quoted context omitted.
systemd-appd doesn't exist yet.
> systemd-appd doesn't exist yet. This avoids the question, apparently because the design of this part makes it certain that when it does come into existence, it will depend on the rest of systemd. The problem with systemd is that it's purposefully designed to be a viral monolith, without this it's got no purpose. We've been with this long enough to pretend otherwise.
Is it though?
Systemd is a project, not just a piece of software. It's got a lot of libraries that are reused across the different components that the systemd project ships. It's not that different from how most C/C++ projects have their own standard library built on top of stdlib/boost/etc. Any new "systemd project" could be done as a completely standalone piece of software, but it would mean recreating a lot of the libraries that already exist.
The biggest piece of coupling to systemd isn't really specifically systemd itself but how systems rely on how systemd does certain things, namely, cgroups. No one wants to manage cgroups themselves, so they use systemd to start services and put them into the cgroup hierarchy, etc. This is exactly one reason desktop environments "rely on systemd" (among others).
Why does everyone want to use cgroups (and thus systemd)? Because it makes managing groups of processes easier, which is directly tied to handling user sessions, which as it turns out, is something most applications want, since typically they deal with users!
Now, systemd's own sub-projects, (eg appd), are likely to be yet another consumer of systemd for similar reasons.
Using systemd, and building on top of it makes it much easier to implement features without having to do everything yourself.
As a Linux normie, I've never understood why systemd is/was so much opinioned about.
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…
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 some systemd integration for their new API.
As far as I'm aware the complaints about this stopped only because distros override the setting, while it's still the default for stock systemd.
Earlier quoted context omitted.
Okay so back in ~2000 the audio system in Linux was ALSA and it kinda sucked so along come a guy named Lennart Poettering who wrote pulseaudio which improved things in a lot of ways but also kinda constantly didn't work. Poettering in those years constantly blamed everything on other software in the stack and became kinda wildly disliked. We all had to use pulseaudio though because everything important decided to int…
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.
* 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 was.
As a Linux normie, I've never understood why systemd is/was so much opinioned about.
And as anyone could have expected, systemd broke a lot of things, and sometimes very badly with their shitty code. Like this time that they wiped the nvram memory of laptop transforming them into bricks...
And just in the end, we will finish with the same kind of monolith that we can experience with Windows.
Earlier quoted context omitted.
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…