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.
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.
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.
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"
(Some it does well, some it doesn't, and some it shouldn't.)
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?
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.
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 ...
This is fantastic news! As I've argued here on HN many times over the years, proper permission management is probably the single most important piece that's been keeping us from sandboxing everything by default, like on Android and iOS.
There were some early attempts in mobile Linux distros, like original Ubuntu Touch or even Nokias MeeGo and it turns out the main issue is actually improving security while not blocking whole categories of applications from working.
In the early Ubuntu Touch case I remember that you had to as a user allow your image viewer access to individual pictures from SD card, one by one, to see them in the app. This made it basically useless.
In the MeeGo use case IIRC third party chroot/shell environments like Termux were impossible due to the way their security/sandboxing system was setup. At the same time all apps had internet and microphone access & it was impossible to disallow it per app.
> It’s important to note that everything discussed during the talk is planning, and not a single line of code has been written yet
I remember the old discussions from a few years, aka KDE will not depend on systemd. Back then I predicted it will happen.
Lo and behold - it happened.
Isn't it fascinating how naysayers ended up being right, later down the road? This happens often because they tend to be more critical in their thinking than the three seconds memory folks.
It's may get harder in the future to have a Linux desktop that keeps up with the times and also does not include third-party cruft or spyware in the future.
Systemd is a mix of GPL2 and LGPL. Flatpak is LGPL. Neither has a CLA. Many other parts of the ecosystem are GPLs. It makes no sense for this ecosystem to start serving up primarily FOSS applications with FOSS ethos-es as a proprietarified storefront.
Who is "they" here? There's no value to gain from closing the freedesktop ecosystem: no company has a distribution chokepoint like Google does with Play Store, the overall PC market is in decline and everyone would switch to existing anti-systemd alternatives.
That seems like a long series of pessimistic stretches.
I don't love churn but this slow plumbing unification around systemd is delivering a better experience for most. And I don't recognise the push away from copyleft, certainly not in this context.
the evolutionarily optimal ratio of predator:prey fluctuates based on how close/far are we to ZIRP.
I love using Alpine, and for the few packages that don't have a musl version available (e.g. Steam), flatpak has been a great way to run them.
Hopefully someone will maintain a fork.
Systemd the init service is excellent.
Systemd the catch all for trying to rewrite all services to come up with a baseline version of everything is a strange and NIH project. They would have been far better off politically by coming up with a spec and seeing if they could submit patches to get the current services to use the APIs they were planning.
Instead they just have a bundle of things they have tried to reinvent, some more successfully than others. Hence the divisions in the communities.
When it's not actively going against decades of convention and breaking solid programs everyone has used forever: https://superuser.com/questions/1372963/how-do-i-keep-system...
(screen was also affected, not just tmux)
I'm not sure if it was linked from there, but somewhere in the discussions the systemd devs' recommended fix was for screen/tmux/anything else affected to add some systemd integration for their new API.
As far as I'm aware the complaints about this stopped only because distros override the setting, while it's still the default for stock systemd.
Jump forward to systemd and absolutely none of trust Poettering farther than we can throw him. At the same time systemd basically did the job of half a dozen programs which offends a lot of people on philosophical grounds. Simultaneously a bunch of things start hard requiring this program that people neither trust nor like.
That's fine for basic audio but completely excludes any higher demand application, including high quality A/V sync. Best you can do is work around and best effort guess.
* I do remember reading there was one feature they intentionally dropped because it was extremely rarely useful and could be handled in a different way, but don't remember what it was.
And he complained about a lot of dependencies but then went and actually wrote fixes/solutions for them that was so good that nearly everyone started using and even depending on it.
It sounds like the people who were sitting on the sidelines complaining about his complaining had ample opportunities to write better alternatives than the programs he wrote but didn’t do so. Instead they relied on character attacks and FUD (well, except the folks who developed pipewire), while Poettering wa engage in elite hacking by implementing solutions and letting users and distro makers decide whether they wanted to use those solutions.
I don’t see how Poettering is the villain here.
Poettering seems to be good at politics. Where politics means having his way.
Not so much at writing working code, or interoperability.
A son of GDR diplomats, according to an old version of his Wikipedia page. That information seems to be memory-holed now. Now you only find that he grew up in South America without any hint of a reason.
I don't know about the philosophical aspects, but from pure technical point of view systemd brought some order into the mess. Before systemd it seemed like most distros were barely holding together with duct tape. Systemd standardized a lot of things.
I am fine with a little bit of controversy if the result is a much better desktop OS experience for the user. And as a relatively long time Linux user, I can certainly say it is much better now than it was 20 years ago.
Also having a bunch of things barely held together with duct tape is part of the philosophy.
Yes, I'm very happy that it mutes my audio when I accidentally unplug my headphones (something which I never asked for) and then often fails to unmute them when plugging them back in, something which requires digging up alsamixer to fix because pulse/pipeware-based GUI tools are being lied to about the output not being muted.
I'm also especially fond of having to open the audio settings app to change audio from one display output to another because some very smart person decided to group all display audio (which are separate ALSA sinks) into one output with different profiles.
But lets not forget that it at least simplified configuration. So much that GUI tools basically don't let you configure shit at all and you need to use one of two (yes, one was not enough) turing-complete configuration languages to accomplish anything slightly non-standard like giving outputs are better name than what your display manufactures cat produced while walking over his keyboard or hiding some of the bazillion useless audio devices that you might end up with somewhere in your PC.
And then of course it still has the PA-innovations like audio randomly stopping for no reason at all until you restart the daemon.
Meanwhile ALSA with an up to date default dmix configuration worked just fine.
Before that I did have custom config, it was not that hard to set up, there are great examples and explanations on Arch wiki: https://wiki.archlinux.org/title/PipeWire
Due to this design they often have underspecified interaction between the different components, since the assumption is that everyone will use largely the same baseline systemd environment and as long as it works, who cares what it does underneath. If the different parts were more independent, they would be forced to develop a cleaner API contract between them.
I had a nightmare last week wherein I read a headline that systemd was writing its own kernel. When I woke up I realized it was a possibility, after all it has replaced GRUB. https://wiki.archlinux.org/title/Systemd-boot
And to be perfectly honest, it's nothing more than a philosophy - it's not some universal truth, e.g. a browser by definition is not doing "one small thing" and complex workloads are better organized by monolithic software to a certain degree.
How? This is really where it's basically a marketing fail.
Even your own link for system-boot shows that it is it's own rebranding of gummi-boot. It's not part of the init system, they just have an identically named project which has 100 utilities in it. It's dumb and it's community hostile.
With unified kernel images there is no need for grub or any other bootloader anymore. And UKI simplifies boot configuration and helps improving security in some aspects.
It seems to me that the real differentiator is not the number of features but software release date :)
And as anyone could have expected, systemd broke a lot of things, and sometimes very badly with their shitty code. Like this time that they wiped the nvram memory of laptop transforming them into bricks...
Nit: on "decades-old", Flatpack is from ~2016 only.
Systemd came out in ~2010 and maybe it was not clear if it will stay around for long enough and gain as much popularity as it did?
And if you look at the history page of Flatpak, you'll see that the project has been in development in some form or another for roughly 20 years https://github.com/flatpak/flatpak/wiki/Flatpak's-History
The article contains only a vague half paragraph of architecture:
> they want to move the permission management from Flatpak into the service layer, through a new service called systemd-appd. Systemd-appd gives applications an identifier and stores their permissions, and then this data can be queried by the rest of the system. In turn, this enables a slew of other features, not least of which is subsandboxing.
And what other speculated Flatpak features introduce other dependencies from systemd? Discussing whether unwanted dependencies can be made optional or eliminated requires technical details.
Now the direction changed with the new team/leadership towards integration, security and control instead of "it works everywhere".
Hopefully basic features will still work without systemd-appd, otherwise we would be back to "Linux desktop has no universal packaging format" considering that:
* Most appimages often rely on specific libc of the base system;
* Snap does not fully work outside of Ubuntu ecosystem.
systemd-appd sounds like it could make some inroads in the threat model that Windows and Linux still have in 2026 (and macOS is still reeling from): anything that runs as my user, can access anything running as _my_ user. I don't think this threat model was tenable in 2016, much less in 2026. But moving away from that also breaks with the Unix tradition.
Systemd as the system management layer is becoming a centerpoint for moving Linux forward, on servers but especially so on the desktop, and it does so at the cost of breaking with traditional views. It's kind of hard to watch: I want Linux to move forward, and there's just a lot of good ideas there. But it will be painful for a large Linux community to break with traditions.
Are we talking about open source operating systems hero or app delivery mechanisms?
Exactly. If you look back at the old discussions, you see how people tried to claim systemd is merely an init system, but it never was. So all comparisons to e. g. sysinit and what not, were unfair. Dishonest. The systemd devs were not interested in fair discussions. They wanted more control. And they very ruthlessly went forward with it - also thanks to corporate support. Just look at Poettering censoring discussions and stopping them whenever he could.
> But moving away from that also breaks with the Unix tradition.
Systemd never cared about UNIX. Poettering does not even understand UNIX on top of that.
> Systemd as the system management layer is becoming a centerpoint for moving Linux forward
Forward to ...? I don't really see it as moving "forward". I see it as more top-down control singularized into one crew that manages the software here.
> on servers but especially so on the desktop, and it does so at the cost of breaking with traditional views
Well, I would not call it "traditional", as the name is loaded. I see it more as a way to gain more control over the whole ecosystem. We see the same happen with wayland, but on a smaller scale, as wayland does not try to integrate a billion features and functionality.
> It's kind of hard to watch: I want Linux to move forward, and there's just a lot of good ideas there. But it will be painful for a large Linux community to break with traditions.
I don't like systemd, but I view this more realistic. I saw how the non-systemd distributions struggled and eventually most went extinct or were converted into systemd. Only few remain strong, and those few are often also dead - like slackware. And yes I know the spin-offs, but seriously, slackware is a dead man walking. Void is not dead, but yikes, it's not moving forward either.
It is not only systemd though. The whole linux stack got a lot bigger and more complicated. Nowadays you often need python, meson, llvm, mesa and so forth to compile things. Everything got bigger too. A lot of software was abandoned downstream, such as fluxbox - may be irrelevant to most folks, but this is one example of sooo many more. At the base of this problem sits the funding issue. Corporations have a lot more net-control over the ecosystem nowadays. Due to the funding. I think we need to solve this issue of funding, because otherwise we'll end up with systemd-like projects sitting at the key areas.
I wouldn't recommend reading that comment thread, it immediately jumps into "this is fascism!" which is why it's hard to take people seriously sometimes.
Looking at you, DaVinci Resolve.
I'm not sure how AppImage beats Flathub, it's gotten so damn good.
Systemd is a great example of embrace and extend that was actually succesful.
Microsoft should have just hired Poettering.
Just kidding!
And just in the end, we will finish with the same kind of monolith that we can experience with Windows.
Soon systemd will sniff more data - such as the age:
https://github.com/systemd/systemd/pull/40954#issuecomment-4...
And the usual copium aka this is very harmless, nothing evil is done, nothing bad can happen. That'll cover the age.
In the future systemd will sniff for more private data. For those who think this is a conspiracy theory, well - look at the last some decade or so, and query which claims made early on, about systemd, suddenly become true at a later point in time.
The systemd folks are kind of smart, though, because they provide "merely an init system" (right? Or was the comparison always unfair, because e. g. sysinit never was about adding layer of layer on top of layers) and they build on top of it, for other applications to tap into systemd - at the cost of adding a dependency.
Even LFS/BLFS succumbed recently and now only offers systemd-builds. Personally I think this is kind of betrayal to the spirit of LFS, but Bruce gave an objective argument, which is the time investment for maintaining non-systemd and systemd, and on this particular point he is quite correct. Time is a finite ressource.
What we kind of see here is that systemd keeps on growing and growing. It is the ultimate virus. You can't get rid of it. Now flatpak fell for it too, though objectively speaking I fail to see why flatpaks should have a dependency on systemd to begin with. Thankfully I use versioned AppDirs (similar to GoboLinux) so I could not care any less about flatpaks (don't need them, I already use any version of a program I want to), but flatpak also betrayed its original vision. For some reason those grand visions always become worse over time.
But no worries folks - we know one thing is true, and that is that systemd will grow even bigger. It will not stop until it has swallowed EVERYTHING.
Maybe systemd should have been an API + a spec instead of an unportable implementation.