Systemd v259

Original Article ↗ Hacker News Discussion ↗

New features in v259

  • Noted changes include: DHCP hostname resolve hooks in systemd-networkd, expanded varlink IPC, musl libc support, and cgroup2’s memory_hugetlb_accounting option (with clarification it falls back gracefully on older kernels).
  • musl support is highlighted as important for musl-based distros, though some see it as eroding their previous “small and simple” character.

SysV / rc.local deprecation and migration

  • Support for SysV init scripts is deprecated and slated for removal in v260, prompting concern that old, forgotten services will silently stop starting.
  • Others respond that wrapping init.d scripts in systemd units is trivial, and auto-generated wrapper units already exist under /run/systemd/system.
  • The removal is framed as extractable logic that could live as a separate project for those who still need it.
  • rc.local is also being dropped; some say replacing it with custom .service units is easy and avoids long shutdown hangs caused by rc-local’s infinite timeout.

Complexity, scope, and resource usage

  • One camp considers systemd too complex and “monolithic,” suitable mainly for paid server administration and overkill for small or embedded systems.
  • Others argue basic unit files are simpler than bespoke SysV scripts, offer a clear “gradient of complexity,” and bring standardized behavior, introspection, and strong sandboxing features.
  • Debate over resource usage includes anecdotes of pre-systemd systems using ~300MB vs modern Ubuntu VMs using ~1GB, countered by examples of small Debian installs where systemd itself adds only a few MB.
  • Some criticize systemd’s ever-expanding scope (“OS of its own”), with jokes about it doing everything, up to email or Wayland integration.

Networking and configuration control

  • Complaints focus on systemd’s interaction with resolv.conf and conflict between systemd-networkd and NetworkManager, especially on servers where static, never-changing configs are preferred.
  • This is used as an example of “desktop-ish” dynamism being an anti-feature on stable servers.

Containers, game servers, and K8s

  • A hobbyist game developer describes using systemd plus cgroups as a local game-server process manager instead of containers, valuing that dev and prod look the same.
  • Replies recommend systemd-nspawn, portable services, and podman “quadlets” to combine containers with systemd units and ease migration toward Kubernetes if needed.
  • Several comments argue that even with Kubernetes, systemd remains essential (e.g., for booting nodes and non-K8s workloads).

Alternatives and philosophy

  • Some users happily avoid systemd via Devuan or OpenBSD, though others call non-systemd paths a “dead end” given ecosystem standardization.
  • There is resignation from some who “submitted” to systemd while still preferring cron over systemd timers and viewing frequent behavior changes as breaking “perfectly working systems.”