[nechuchelo]

While I think systemd is a great init system (as well as some other components under the systemd umbrella), I really dislike when components up in the stack hard-depend on it. We can't use GNOME, plasma-login-manager, and soon Flatpak without systemd.

Maybe systemd should have been an API + a spec instead of an unportable implementation.

[bryanlarsen]

The headline is inflammatory and misleading. IIUC, flatpak is not depending on systemd as a whole, they're depending on a new component called systemd-appd, which does permissions stuff. This will allow alternate implementations, like how elogind grew out of systemd-logind.

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.

[gatlin]

How do I install only systemd-appd?

[bryanlarsen]

systemd-appd doesn't exist yet.

[bigbadfeline]

> systemd-appd doesn't exist yet.

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.

[ecnahc515]

> The problem with systemd is that it's purposefully designed to be a viral monolith

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.

[bryanlarsen]

It's not a monolith, which is obviously true because there is no distribution that ships all of it turned on by default. Fedora comes close, but most other distros pick and choose which parts of systemd to use.

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.

[sinpif]

I'm all for integration of system services if it helps bring a more cohesive OS. Interchangeability is a nice thing when building a system but I don't need it as a user.

[nottorp]

... have you ever tried to customize a systemd based distro for something they haven't thought of originally?

[sinpif]

No. From your tone it sounds like it's probably not as easy as you'd like. I don't really have a response to that. System customization is not something I'm interested in.

[bboozzoo]

Can you share what was that thing that didn't work with systemd? I've seen pretty crazy setups and can't quite imagine how horrid of a mess those would have been if a large rc.init shell script ridden with sleeps was used instead.

[nottorp]

Last time? Getting pppoe to automatically start and restart if it dies. Or not that, but setting up everything for a custom router with proper dns, firewall and all the other crap, without using crippled systemd versions for services that i couldn't even uninstall because of dependencies.

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 :)

[Jnr]

Like wayland?

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.

[sam_lowry_]

Wayland is different, they pretended nothing except compositing and window positioning matters.

[Jnr]

I doubt that. But they clearly thought that people should have a choice. And it is great. But fractured community using different tools for the same task makes slower progress. Each approach has its positives and negatives. I think it is great that we have wayland and systemd. It will eventually lead to something greater in the future.

[ChocolateGod]

I don't believe Wayland makes any decisions about compositing, it's up to compositors to decide how (and if) they want to do that.

Wayland at it's core is an IPC for sharing memory buffers containing surfaces around and details about those surfaces.

[ChocolateGod]

> Maybe systemd should have been an API + a spec instead of an unportable implementation.

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"

[shevy-java]

But why would they do so? That makes no objective sense.

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.

[ChocolateGod]

> Systemd never was "merely" only an init system

There is systemd the service manager/init system and systemd the project. An alternative service manager could add support for the formers unit files.

[bboozzoo]

> An alternative service manager could

I guess we would care if one showed up, no?

[eqvinox]

This really isn't about the unit spec, it's about the 100 other things systemd does.

(Some it does well, some it doesn't, and some it shouldn't.)

[maxloh]

Maybe this statement actually holds in reverse?

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.

https://lobste.rs/s/gfbpgq/flatpak_will_depend_on_systemd#c_...

[fc417fc802]

That is a good point but it isn't mutually exclusive with the idea that systemd ought to be a standardized API as opposed to a reference implementation without a standard.

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.

[guilhas]

This is I think false

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

[danlitt]

FWIW GNOME can be used without systemd, and this is how Guix System does it. I think over time more and more components are depending on systemd, but at the current moment it is still feasible to swap them out for replacements that don't.

[nechuchelo]

Can it still? IIRC Guix still has GNOME 48 while GNOME said they'll be increasing they dependence on systemd after version 49 or 50[1]. I'd be happy if Guix can support future version as this seems like an end game distro for me, and I'm (slowly) looking into moving there but my understanding is I'd need to stay with KDE Plasma in the long-term.

[1] https://lwn.net/Articles/1025560/

[danlitt]

You are right, work on packaging GNOME 49 is still ongoing & may take a while (it is a hard job and not many people are working on it). It is not considered a dead end yet, as far as I can tell:

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.

[nechuchelo]

> gnome-session-shepherd

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.

[shevy-java]

A gentoo dev actually showed that GNOME can work without systemd. The gentoo wiki explained it.

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 ...