Post #1378965 · Elektrine

2026-02-20 17:53 UTC

It uses a completely different paradigm of process chaining and management than POSIX and the underlying Unix architecture. That’s not to say it’s bad, just a different design. It’s actually very similar to what Apple did with OS X. On the plus side, it’s much easier to understand from a security model perspective, but it breaks some of the underlying assumptions about how scheduling and running processes works on Linux. So: more elegant in itself, but an ugly wart on the overall systems architecture design.

Replies (2)

@hoppolito@mander.xyz 2026-02-20 18:23

> It uses a completely different paradigm of process chaining and management than POSIX and the underlying Unix architecture. I think that's exactly it for most people. The socket, mount, timer unit files; the path/socket activations; the `After=`, `Wants=`, `Requires=` dependency graph, and the overall architecture as a more unified 'event' manager are what feels really different than most everything else in the Linux world. That coupled with the ini-style VerboseConfigurationNamesForThatOneThing and the binary journals made me choose a non-systemd distro for personal use - where I can tinker around and it all feels nice and unix-y. On the other hand I am really thankful to have systemd in the server space and for professional work.

Open ##1378979
@MonkderVierte@lemmy.zip 2026-02-21 12:07

> On the plus side, it’s much easier to understand from a security model perspective Lol, no. Way more code in Systemd. Also more CVE *per year* than in some bad (now dead) init/svc' lifetime.

Open ##1378980