Maybe systemd should have been an API + a spec instead of an unportable implementation.
IOW, it is an API + a spec, just like what you're asking for. But it's implementation first, because any API + spec designed by committee rather than being driven by an implementation universally sucks.
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.
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.
Maybe it's Ubuntu's fault since they seem to want to run in containers not on bare metal lately.
I switched that box to Devuan in the mean time :)
Where none of the desktop environments offer the same feature set. And the more compositors there are the harder it is for apps to use those new protocols, and guaranteeing a ton of bug reports from users using an unsupported compositor. That just hinders Linux desktop app development.
Wayland at it's core is an IPC for sharing memory buffers containing surfaces around and details about those surfaces.
There's nothing really stopping other init systems from implementing it's unit spec, some hobby ones have done so.
In the case of GNOME, KDE etc depending on it, the reason mainly boils down to "we could implement our own manager for handling desktop daemons etc or just get systemd to do it for us"
Systemd never was "merely" only an init system. And it makes no sense for init systems to grow to systemd-size either, in order to solve non-init related issues.
> In the case of GNOME, KDE etc depending on it, the reason mainly boils down to "we could implement our own manager for handling desktop daemons etc or just get systemd to do it for us"
That's not quite true. GNOME always was close to systemd devs due to funding. KDE was less close, but even within KDE some people lobbied for it such as dave edmunson or however you spell the name, and "me-needs-a-donate-daemon" Nate, who you are not allowed to critisize on #kde reddit. But I agree that they could simplify some code by depending on systemd. Of course this now means that KDE is sold in a dead-lock with systemd. I wonder if I can still use konsole without systemd. I tend to use iceWM since it is so much faster than KDE or GNOME, but when konsole depends on systemd I may indeed need to switch to another terminal. That will be painful though, but there is no stopping systemd - it infects and taints.
There is systemd the service manager/init system and systemd the project. An alternative service manager could add support for the formers unit files.
I guess we would care if one showed up, no?
(Some it does well, some it doesn't, and some it shouldn't.)
Quoting vbernat's comment on Lobsters:
systemd was a "gift" for people running alternative desktop systems. Previously, many services were bundled with GNOME and you had to go through many hops to use them on a non-GNOME desktop (for example, GNOME Power Manager). systemd replaced many of these GNOME-only piece of software that were constantly breaking when you tried to use them outside of GNOME. Alternative desktop environments didn't need to write their own version of system-related tools.
So, while this may be seen as centralization, I don't think we would have seen so many desktop environments without systemd. In the past (15+ years), systems were simpler and there was not many things to abstract.
Also despite all its convenience it's not without its drawbacks. Among other things you can no longer just launch a daemon from a chroot now you need a full blown container sporting its own init.
Even if some gnome specific tool didn't work there, guides would point to xfce's tools or lxde or kde or some independent
Or some cli command that I would personally prefer
And even recently these tools were quite bad, so CLI commands, file changes, or extra packages are normally necessary
https://lists.gnu.org/archive/html/guix-devel/2026-02/msg001...
> my understanding is I'd need to stay with KDE Plasma in the long-term
Has KDE committed not to hard-depend on systemd in the future? I would be glad to discover that.
Very nice, hope they can get it working.
> Has KDE committed not to hard-depend on systemd in the future? I would be glad to discover that.
I was reading somewhere some KDE developers were saying that while some of the components (like plasma-login-manager) might depend on systemd, the core Plasma will not. They're the only major DE remaining on FreeBSD after all.
I never tested this myself, as I also dislike GNOME3 from a UI view (I am fine with mate-desktop though), but I found this to be epic from the Gentoo folks - a single man flipping a finger to the systemd devs. The underdog winning the fight.
A shame gentoo kind of went into its own hole for years ...