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.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)