- socket activation (as post says, "print from your phone without having CUPS running all the time")
- extra security. Many daemons drop privileges, but how many of them also isolate filesystem and install seccomp filters? With systemd, it could be "every one"
I generally prefer either stopping/starting a service on demand or just keeping it always on, to ensure predictability and prevent buildup of never-stopped services.
For Accept=no, there is no auto-stop. I think it's because once service is activated, systemd no longer has reliable information about socket and thus cannot tell if the service is idle or not.
But what socket/dbus activation does is it enables services to exit on idle. And some services actually do it - systemd-timedated being one example. Any time I enter "timedatectl" I see it start and then exit.
And if that does not work either, you can do privilege dropping twice. For example, systemd isolates filesystem, sets capabilities and NoNewPrivileges bit, but still runs daemon with root access. Daemon does whatever init it needs to do, and then drop the remaining privileges.
Is there a page that lists all of systemd's features?
In other words, systemd is winning because systemd is winning. Not because it's better.
What fancy new features will we get with systemd?
Granular privilege controls
Powerful service dependency and security analysis features
Tight cgroups integration both static and dynamic
Socket activation (so you can print from your phone without having CUPS running all the time!)
Built in boot-time analysis
What's wrong with the polyfills?
corecollector (systemd-coredumpd) 1: Not needed to run KDE and GNOME, but a very useful tool that many developers expect to be able to use to easily retrieve coredumps and associated metadata, without first figuring out how to configure them properly. It is great that there is a polyfill for it, but it is unmaintained since 2020. Plasma Mobile developer Devin wrote: "When debugging crashes, it’s incredibly useful to be able to view coredumps and attach a debugger after the fact with coredumpctl, this can help us obtain backtraces that would otherwise be hard to replicate again with a debugger attached. We can also then enable DrKonqi’s coredumpd integration, which can allow users to get notifications about process crashes and see them from a GUI. DrKonqi also has optional integration with our Sentry instance, which we can enable on developer installs to automatically send crashes to a web dashboard for us." - Granular privilege controls
- Tight cgroups integration both static and dynamic
my advice to pmOS maintainers is to experience at least one systemd upgrade cycle before committing to it in any meaningful sense. that said, if the project has the bandwidth to maintain all of these different service managers/init systems, then yeah absolutely go for it.
Could I trouble you for an example? The only regular connection changes I can see are networking changes that are managed at a different layer, or things that are user-level applications.
While a lot of these also apply to more traditional computing, I'd say on a phone that many of them are more prone to changing rapidly, part of a more integrated device (for instance, turning off your phone screen is usually a very different kind of action that merely turning off your monitor), and generally effect the function of the device to a greater extent. Would you agree?
I do not really need Gnome nor KDE.
> We have shared this blog post with the Alpine devs before this publication, and we hope that they understand our reasoning.
So then they weren't cool with it, huh?
> Our current understanding having spoken to systemd developers is that we should be able to find a path that brings us much closer to upstream, if not entirely.
What’s the path here? Running glibc on Alpine?
Adapt or don't offer GNOME/KDE (get fscked), classic Red Hat!