systemd is a convenient service manager (and much more!!).
It provides too many things, which work well... for standard windows-like use
cases.
Seeing my post title, a question you might get is "Why not just use systemd? It
just works better!..."
(Please read below, then this; It is just a TL;DR)
TL;DR by analogy =
- X, which like systemd, did eevrything in a giant sphagettified mess. (But
still missed out on the sound... and used VTs)
- wayland (library + compositor) + libinput + pipewire + wireplumber +
whatever-else is the future.
- We needed a desparate solution like X(systemd), but the *real* solution is
wayland(split-up components)
- We need to learn from systemd, but be more "clean" and "agnostic".
- Initially the systemd replacement will be broken just like wayland was and X
was fine, but it will improve, to be better (not for everyone).
- That's it. Period. "text-only => X => wayland" is (almost) exactly analogus
to "sysVrc => systemd => dinit + 66 + turnstiled + (a new acpid) + seatd +
whatever-else"
See some issues (NOT THE UNIX PHILOSOPHY)...
- See `xz-utils` secutiry issue for example..
- And `systemd-tmpfiles` fail to run in a package postinst (of sddm) because I
don't mount my `/` etc... the systemd way (because I was bootstrapping my
system in a chroot).
- Same issue with `kernel-install`
- In general, while it integrates well from within, (`user@`, `logind`,
etc...), it *doesn't* do things cleanly, it's just hacks (moved internal to
show external clean). I needn't explain this, just see how the whole thing
works.
- A clear example is how `dbus-broker` "activates" systemd units using a
bespoke undocumented interface, while it could just `systemctl start
${SystemdService}` (not the command, it's DBUS equivalent). See the issues
caused due to it.
-
- Lock-in into systemd:
* See how `sd_notify` works, it *can't* be "shim"'d by another service
manager except dinit, as it is practically feasable only if the entire
supervision infrastructure in in the *same* process.
* Every "distro-agnostic" tool by systemd meant to replace distro-isms is
made highly systemd-specific.
* D-Bus is **not** tied to systemd, kdbus failed, now they have `varlink`,
which is a *new* IPC. It is part of systemd, and it's API is `sd_varlink()`
I am packaging the `66` service management suite for gentoo in my overlay:
<https://github.com/pramodvu1502/66-svmgr-gentoo-overlay>
I will also package an alternate `tmpfiles.d` parser written in
`app-shells/fish` interpreter. (Package name not yet decided)
The opentmpfiles CVE issue, BTW, could have been fixed by adding a `-h` to all
`chown` calls. AND `sysctl` `fs.protected{sym,hard}lniks=1` (but this is
default anyways).
The *real* issue was lack of maintenance, many new features weren't supported.
I will write `kernel-install` similarly, once that is done.
`sys-apps/obsysusers` is a replacement for `systemd-sysusers` (It doesn't
support the `r` identifier, although that's never used in practice as far as I
know.)
I am also packaging [turnstiled](https://github.com/chimera-linux/turnstile), a
service-manager-agnostic session daemon, with user-services support. (No
functionality covered by `seatd` and `acpid` BTW...)
The rest of systemd:
- `systemd-boot` (maybe `systemd-ukify` too) and `systemd-udevd` are pretty
much the *only* pieces of systemd which have any requirement without a
replacement needed.
- All the TPM-related tools... well... are needed too...
- `systemd-journald` is a nice concept, but poorly implemented. Re-implement is
properly or throw it out of the window.
- `systemd-networkd` and `systemd-resolved` IDK, *might* be needed. I use
`NetworkManager`, `iwd`, and `unbound` (and `openresolv`) for my purposes.
- `systemd-nspawn`, well, is a wrapper around `unshare` but with too much of
systemd-isms. `nspawn` is a good name for a svmanager-agnostic script too...
- `systemd-sbsign` and `systemd-keyutils` are there just because "the code is
already there"; The developer forgot that the no. of bugs in the systemd
project is growing, so he wasted time here.
- `sysext` might be needed for immutable systems...
- `sysupdate` etc... is for windows, not here.
- The misc "standards" etc... in 100s of markdown files in the repo, well, are
useless, the developer could fix the bugs instead. (Some are useful BTW)
- Maybe some other internal tool might be needed, useful. But the other useless
tools...
Missing pieces:
- CGroups, well... can be implemented using a helper command...
- `openrc-settingsd` needs to follow the "standard" files... and needs a CLI.
- `turnstiled` is yet to have a session-info-query library, and a CLI
- A new `acpid` is needed with support for simpler configuration and modern
features like inhibits...
* And a configuration interface to avoid hacks like in systemd-logind (A DE
like KDE inhibits *all* ACPI functions in logind, as logind has no other way of
allowing someone else handle it (logind.conf is not a suitable thing for
KDE-plasma to "handle"; Logind has no way of showing a power-menu to the user
on power-button-press) ).
- `66-dbus-launch` is for `66`, a replacement for `dbus-broker-launcher`. A
similar but service-manager-agnostic thing (or service-manager-specific things)
- Similar service activation framework for `udevd`...
- Maybe a "svactivator ${SVCNAME}" command, managed by `eselect svactivator` to
allow multiple to co-exist. The command is used for activation by *all*
activation-related things. (You can use it in `cron` too...)
- What else? Please let me know.
Fact: Other projects related to RedHat/Fedora, which modernise the Linux
distros, actually *follow* the proper clean methods, (but they unfortunately
depend on systemd-isms for now; but fixable):
- `tuned` is a power-profile-daemon which provides only mechanism and "default"
policies are just supplied like external policies. It uses existing systems
like `powertop` rather than to replace them. It's "profiles" can be extended by
shell scripts in the profile directory.
- `cockpit` is a system for remotely managing servers via web, it uses SSH,
existing D-Bus interfaces, is easily extendable, and *doesn't* replace any
existing thing.
- `pipewire`: Just provides an API ("mechanism") for managing audio and video
devices, in a highly advanced way. `wireplumber` does the actual work of
"managing" them, that too highly policy-configurable.
- wayland: You know, it's just an IPC. *Every* thing is just "protocols" which
the compositors have freedom to mess with.
- * But systemd, you know...
Irrelevant fact: `synit` is a "core OS framework" which provides from the init,
IPC, network-config, upto a really high level. Basically
systemd+D-Bus+NetworkManager+iwd+everything-else-at-that-level-including-mostly-the-libc-too-but-IDK.
Alteast the internals are clean and no sphagetti as far as I know.
NOTE: This is also posted in r/Gentoo on reddit, under the same title as the
subjec of this mail.
