5 ms·

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 har

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.

danlitt 4mo ago
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 4mo ago
  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/ https://lwn.net/Articles/1025560/
  - danlitt 4mo ago
    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/msg00144.html 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 4mo ago
      > 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.
ChocolateGod 4mo ago
> 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 4mo ago
  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 4mo ago
    > 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 4mo ago
      > An alternative service manager could I guess we would care if one showed up, no?
- 4mo ago
maxloh 4mo ago
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_g4qyev https://lobste.rs/s/gfbpgq/flatpak_will_depend_on_systemd#c_...
- fc417fc802 4mo ago
  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 4mo ago
  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
sinpif 4mo ago
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 4mo ago
  ... have you ever tried to customize a systemd based distro for something they haven't thought of originally?
  - sinpif 4mo ago
    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 4mo ago
    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 4mo ago
      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 4mo ago
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_ 4mo ago
  Wayland is different, they pretended nothing except compositing and window positioning matters.
  - ChocolateGod 4mo ago
    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.
  - Jnr 4mo ago
    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.
shevy-java 4mo ago
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 ...
bryanlarsen 4mo ago
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 4mo ago
  How do I install only systemd-appd?
  - bryanlarsen 4mo ago
    systemd-appd doesn't exist yet.
    - bigbadfeline 4mo ago
      > 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.
      - bryanlarsen 4mo ago
        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.
      - 4mo ago

danlitt 4mo ago

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 4mo ago
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/ https://lwn.net/Articles/1025560/
- danlitt 4mo ago
  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/msg00144.html 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 4mo ago
    > 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.

ChocolateGod 4mo ago

> 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 4mo ago
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 4mo ago
  > 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 4mo ago
    > An alternative service manager could I guess we would care if one showed up, no?
4mo ago

maxloh 4mo ago

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_g4qyev https://lobste.rs/s/gfbpgq/flatpak_will_depend_on_systemd#c_...

fc417fc802 4mo ago
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 4mo ago
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

sinpif 4mo ago

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 4mo ago
... have you ever tried to customize a systemd based distro for something they haven't thought of originally?
- sinpif 4mo ago
  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 4mo ago
  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 4mo ago
    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 4mo ago

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_ 4mo ago
Wayland is different, they pretended nothing except compositing and window positioning matters.
- ChocolateGod 4mo ago
  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.
- Jnr 4mo ago
  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.

shevy-java 4mo ago

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

bryanlarsen 4mo ago

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 4mo ago
How do I install only systemd-appd?
- bryanlarsen 4mo ago
  systemd-appd doesn't exist yet.
  - bigbadfeline 4mo ago
    > 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.
    - bryanlarsen 4mo ago
      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.
    - 4mo ago