Flatpak Will Depend on Systemd

Original Article ↗ Hacker News Discussion ↗

Flatpak’s Planned Systemd Dependency

  • Thread centers on Flatpak “Next” / 2.0 planning to move permission management into a new systemd service (systemd-appd).
  • Several note this is only planning; no code exists yet. Some call the article title misleading or premature.
  • Others argue this is exactly the kind of gradual, “viral” dependency critics of systemd warned about.

Impact on Non‑systemd Distros & “Universal” Packaging

  • Users of non‑systemd systems (Alpine, Void, Devuan, etc.) worry Flatpak will cease to be a truly cross‑distro format.
  • Some hope systemd-appd will be specified as an API that alternative daemons can implement, similar to elogind.
  • Concern that if core features require systemd-appd, Linux again “has no universal packaging format.”
  • AppImage and Snap are discussed:
    • AppImage is seen as more ad‑hoc, less robustly cross‑distro (libc/musl issues, manual dependency handling).
    • Snaps already depend on systemd and are viewed as Ubuntu‑centric.

Systemd’s Role and Controversy

  • Many see systemd as no longer “just an init system” but a broad management layer for Linux, with growing reach.
  • Supporters highlight:
    • Better standardization and integration compared to pre‑systemd “duct tape” init setups.
    • Easier implementation for desktops and tools that can offload process/session/cgroup handling to systemd.
  • Critics argue:
    • It is effectively monolithic and discourages competition and component swapping.
    • It violates traditional Unix “small pieces” philosophy and centralizes control.
    • Growing scope (boot loader, app permissions, etc.) is seen as “embrace and extend.”

Desktop Environments and Ecosystem Lock‑in

  • GNOME and some KDE components already lean on systemd; non‑systemd usage is described as increasingly difficult but not yet impossible.
  • Some see systemd as a “gift” to non‑GNOME desktops by replacing GNOME‑specific daemons with shared systemd services.
  • Others view these dependencies as locking the desktop stack to a single implementation, pressuring distros toward systemd.

Security, Permissions, and systemd-appd

  • Proponents welcome moving permissions into a shared service, enabling per‑app identifiers, richer permission models, and subsandboxing.
  • They argue this is needed to move beyond “anything running as my user can access all my data.”
  • Skeptics fear expanded systemd data collection and increasingly intrusive control, and question why Flatpak must rely on systemd for this at all.