From GNU/Linux to SystemD/Linux, but which are the alternatives?

Since its introduction in 2010 by Lennart Poettering and Kay Sievers, systemd has become the de facto standard init system for Linux. What started as a replacement for SysVinit has grown into a sprawling suite of over 1.4 million lines of code, touching nearly every layer of the operating system. This expansion — often called "feature creep" by critics — has sparked one of the most heated and enduring debates in Linux history.

This article examines what systemd actually is, what components it provides vs. what alternatives exist, and why systemd keeps absorbing functionality that was previously handled by standalone tools.

What Is systemd?

systemd is a software suite for system and service management on Linux. Its main component is PID 1 (the init process), but it ships with dozens of additional daemons, utilities, and libraries that cover:

• Service supervision and lifecycle management
• Device management
• Logging
• Login session management
• Network configuration
• DNS resolution
• Time synchronization
• Boot loading
• Container management
• Home directory management
• Cron-like task scheduling
• Temporary file management
• Credential management
• Cryptography for encrypted storage
• And more

The name "systemd" plays on the Unix convention of appending "d" for daemons, and on the French phrase "Système D" — the ability to improvise solutions.

Systemd Components and Their Alternatives

Below is a comprehensive breakdown of systemd's major components and what the ecosystem offered (and still offers) as alternatives.

1. Init System / PID 1

Why systemd replaced them: SysVinit's serial execution made boot slow. Shell scripts were fragile, had unpredictable dependency handling, and couldn't properly track or kill service processes. systemd introduced aggressive parallelization, declarative unit files, and cgroup-based process tracking — guaranteeing that killing a service kills every child process, something SysVinit could never do reliably.

2. Device Manager

Why: udev was already a standalone project. systemd absorbed it to tightly integrate device events with service activation and cgroup management.

3. Service Supervision

Why: systemd integrates sandboxing features into the service manager, allowing security policies (e.g., "no network access", "read-only filesystem") to be declared in the same unit file as the service configuration. This unification is impossible with external supervisors.

4. Logging

Why: journald captures stdout/stderr from services before they start, ensuring no log is lost. It enriches every log entry with metadata (PID, UID, boot ID, priority, code location). Critics argue that binary logs are harder to parse with traditional Unix tools (grep, sed, awk), though journalctl and export to text are available.

5. Login Manager / Session Management

Why: logind solved a real problem: coordinating user sessions across displays, devices, and power management. Previously each desktop environment had its own solution, leading to fragmentation. elogind exists precisely because the functionality is genuinely useful, but critics wanted it without the rest of systemd.

6. Networking

Why: systemd-networkd was created for servers and embedded systems where NetworkManager (which depends on D-Bus and is desktop-oriented) is overkill. It integrates directly with systemd's link management and provides link-level control via .network and .link unit files.

7. DNS Resolution

Why: DNS resolution in Linux was historically a mess — each application or desktop environment managing /etc/resolv.conf independently, often overwriting each other. systemd-resolved provides a unified resolver with an API (D-Bus, nss-resolve, and resolvectl), along with modern features like DNS-over-TLS. Controversial because early versions were buggy and broke existing setups.

8. Time Synchronization

Why: A minimal SNTP client is sufficient for most desktop and mobile users. systemd-timesyncd is trivial to configure and just works. Full NTP servers (chrony, ntpd) are still recommended for servers.

9. Task Scheduling (Cron)

Why: systemd timers integrate with journald for logging, can depend on other units, and handle missed executions (e.g., OnCalendar= with Persistent=true catches up missed runs after boot). Unit files are declarative and testable, unlike cron's single-line syntax.

10. Bootloader

Why: systemd-boot is simple, follows the UEFI boot specification, and reads kernel parameters from the same environment as the running system. No scripting, no complex configuration — just drop a kernel, a initrd, and a config file.

11. Container Manager

Why: nspawn doesn't compete with Docker. It's designed for system-level containers (similar to LXC) and integrates with systemd's own service and resource management. It's used by tools like machinectl to manage lightweight virtual machines (containers) that boot with their own systemd instance.

12. Home Directory Management

Why: homed solves a genuinely hard problem: portable home directories that can be moved between systems, with encryption, automatic filesystem resizing, and identity management. It's one of the newer components and has no direct alternative — critics point to this as proof of scope creep.

The Complete Replacement Map

Why Does systemd Keep Expanding?

The question at the heart of the controversy: why does systemd keep integrating functionality that already exists as standalone tools?

The answer has multiple dimensions:

1. The "Integrated Platform" Philosophy

Poettering has been explicit since the beginning: systemd is not "just an init system". It is a platform for Linux system management. His 2011 FOSDEM interview and the famous "Rethinking PID 1" blog post lay out a vision where PID 1 is the natural, best place to manage all system-level concerns because:

• It runs first, before anything else
• It has access to all kernel facilities (cgroups, namespaces, mount points)
• It has a complete view of the system state (process tree, resource usage, dependencies)

From this perspective, it's not "feature creep" — it is building out the platform to its logical conclusion.

2. Real Problems With the Existing Tools

The Unix ecosystem before systemd was genuinely fragmented:

• Each desktop environment had its own session manager
• Each distro had its own init scripts, log configuration, and network setup
• There was no standard way to discover or manage services programmatically
• No consistent interface for system administration across distributions
• Cross-distro packages had to support multiple init systems, loggers, and session managers

systemd replaced this chaos with a unified API surface: unit files, D-Bus interfaces, systemctl, journalctl, logind DBus API, etc. For developers of desktop environments (GNOME, KDE), this was a godsend — they could target one interface instead of five.

3. Technical Integration Enables New Features

Some features are only possible because of tight integration:

Example 1: Socket activation. systemd can listen on a socket and start a service only when a connection arrives. This requires the init system to manage sockets. Traditional inetd/xinetd did this, but systemd integrates it with dependency management, cgroup tracking, and journal logging.

Example 2: Process tracking. systemd guarantees that when you systemctl stop nginx, all of nginx's child processes are terminated, because they all share the same cgroup. No other init system could do this reliably.

Example 3: Service sandboxing. systemd allows declaring ProtectHome=yes, PrivateNetwork=yes, CapabilityBoundingSet=~CAP_NET_ADMIN in the same file as the service definition. This unifies service configuration and security policy into a single source of truth.

Example 4: Boot performance. Aggressive parallelization via socket and D-Bus activation (services can start as soon as their sockets are ready, not after dependencies finish). This reduced boot times from 30-40 seconds to 5-10 seconds on modern hardware.

4. Corporate Backing and Network Effects

systemd was developed by Red Hat (now IBM) engineers. Red Hat made it the default in Fedora (2011) and RHEL (2014). Once the most influential enterprise Linux vendor adopted it, the ecosystem followed:

• Debian voted to adopt systemd in 2014 (triggering the Devuan fork)
• Ubuntu switched from Upstart to systemd in 2015
• Arch Linux adopted it in 2012
• openSUSE adopted it in 2012

Once the majority of distributions used systemd, a network effect kicked in:

• Third-party software began assuming systemd's presence
• Documentation, tutorials, and tooling standardized on systemd commands
• Desktop environments (GNOME, KDE) integrated with logind, journald, and timedated
• Orchestration tools and cloud images assumed systemd

This makes it increasingly difficult for any alternative to gain traction, regardless of technical merit.

5. The "Open/Closed" Integration Strategy

Historically, systemd components are designed to be replaceable in theory but default-integrated in practice:

• You can replace journald with rsyslog (and many do, forwarding journal to syslog)
• You can replace networkd with NetworkManager
• You can replace resolved with unbound
• You can replace timesyncd with chrony

But the default installation ships with all of them, and other services may depend on them. GNOME software depends on logind. Package managers depend on journald. The default path of least resistance is systemd-everywhere.

6. Solving Linux Desktop Problems

Poettering's background is in the Linux desktop (PulseAudio, Avahi). systemd was, in part, a response to the chronic fragmentation that held back the Linux desktop:

• Linux desktop adoption stalled partly because basic system administration was inconsistent across distributions
• Writing a cross-distro application that managed power, sessions, or devices required supporting multiple backends
• systemd provided a single "Linux userspace operating system" abstraction

The Criticism

The most common arguments against systemd's scope:

1. Violation of Unix Philosophy

"Write programs that do one thing and do it well." — Doug McIlroy, Bell Labs

systemd deliberately does many things. Systemd-free.org's manifesto: "An init system should start processes, supervise them, and stop them. Not manage DNS, log daemons, network configuration, login sessions, time synchronization, and device events under a single monolithic binary with 1.4 million lines of code."

2. Monoculture Risk

systemd runs on virtually every major Linux distribution. If a critical vulnerability is found in PID 1, it affects nearly the entire ecosystem. The lack of diversity in init systems is seen as a security and resilience risk.

3. Portability Loss

systemd is Linux-only, using kernel-specific APIs (cgroups, namespaces, signalfd, timerfd). This means software that depends on systemd cannot run on BSD, Solaris, or other Unix systems. This fragments the broader Unix ecosystem.

4. Gnome/systemd Codependency

GNOME now requires systemd-logind (or elogind). This means choosing a desktop environment limits your init system choices. Artix Linux dropped GNOME support entirely in 2025 because of this increasing dependency.

5. Corporate Control

systemd's development is primarily funded by Red Hat (IBM). Critics argue that a single corporation should not control such a critical piece of Linux infrastructure. The response is that systemd is LGPL-licensed and developed in the open with contributions from hundreds of developers.

Living Without systemd: Distro Alternatives

For those who prefer the traditional approach, functional alternatives exist:

These distributions replace systemd's components with the alternatives listed earlier in this article. They demonstrate that the traditional modular approach is still viable, though it requires more manual configuration and some software assumes systemd.

Conclusion

systemd's expansion is not accidental — it is a deliberate architectural choice driven by:

1. A vision of Linux as an integrated platform, not a collection of tools
2. Real technical problems in the pre-systemd ecosystem (boot speed, process management, log reliability, fragmentation)
3. Corporate backing that created network effects difficult for alternatives to overcome
4. A feedback loop where more components create more integration possibilities, which creates demand for more components

Whether this is "progress" or "empire-building" depends on your perspective. The traditional Unix camp sees a monolith that violates the project's founding principles. The pragmatic camp sees a system that undeniably works, simplifies administration, and has driven meaningful improvements to Linux.

What is clear: systemd is here to stay as the default for most distributions. But the alternatives survive, maintain their communities, and serve as a reminder that Linux's core strength — choice — remains intact, even if it now requires more effort to exercise.