It has been praised by developers and users of distributions that adopted it for providing a stable, fast out-of-the-box solution for issues that had existed in the Linux space for years.

[11][12][13] At the time of adoption of systemd on most Linux distributions, it was the only software suite that offered reliable parallelism during boot as well as centralized management of processes, daemons, services and mount points.

[14] Concerns have also been raised about Red Hat and its parent company IBM controlling the scene of init systems on Linux.

Lennart Poettering and Kay Sievers, the software engineers then working for Red Hat who initially developed systemd,[2] started a project to replace Linux's conventional System V init in 2010.

They wanted to improve the software framework for expressing dependencies, to allow more processes to run concurrently or in parallel during system booting, and to reduce the computational overhead of the shell.

The reasoning at the time was that systemd provided extensive parallelization during startup, better management of processes and overall a saner, dependency-based approach to control of the system.

[21] Some of them thought that the criticism towards the implementation of systemd was not based on actual shortcomings of the software, rather the disliking of Lennart from a part of the Linux community and the general hesitation for change.

In February 2014, after Debian's decision was made, Mark Shuttleworth announced in his blog that Ubuntu would follow in implementing systemd, discarding its own Upstart.

Following its integrated approach, systemd also provides replacements for various daemons and utilities, including the startup shell scripts, pm-utils, inetd, acpid, syslog, watchdog, cron and atd.

systemd not only uses cgroups, but also augments them with systemd-nspawn and machinectl, two utility programs that facilitate the creation and management of Linux containers.

In December 2019, the Debian project voted in favour of retaining systemd as the default init system for the distribution, but with support for "exploring alternatives".

Ubuntu provided a separate logind binary, but systemd became a de facto dependency of GNOME for most Linux distributions, in particular since ConsoleKit is no longer actively maintained and upstream recommends the use of systemd-logind instead.

[104] The developers of Gentoo Linux also attempted to adapt these changes in OpenRC, but the implementation contained too many bugs, causing the distribution to mark systemd as a dependency of GNOME.

Critics regard systemd as overly complex and suffering from continued feature creep, arguing that its architecture violates the Unix philosophy.

[109][110] In a 2012 interview, Slackware's lead Patrick Volkerding expressed reservations about the systemd architecture, stating his belief that its design was contrary to the Unix philosophy of interconnected utilities with narrowly defined functionalities.

[112] In January 2013, Lennart Poettering attempted to address concerns about systemd in a blog post called The Biggest Myths.

[113] In March 2014, Eric S. Raymond commented that systemd's design goals were prone to mission creep and software bloat.

[118] The article also characterizes the architecture of systemd as similar to that of svchost.exe, a critical system component in Microsoft Windows with a broad functional scope.

[118] In a September 2014 ZDNet interview, prominent Linux kernel developer Theodore Ts'o expressed his opinion that the dispute over systemd's centralized design philosophy, more than technical concerns, indicates a dangerous general trend toward uniformizing the Linux ecosystem, alienating and marginalizing parts of the open-source community, and leaving little room for alternative projects.

While not ruling out the possibility of reviving the original repository in the long term, the main developer considers ConsoleKit2 a temporary necessity until systembsd matures.

[128] In 2014, a Google Summer of Code project named "systembsd" was started in order to provide alternative implementations of these APIs for OpenBSD.

The project sought to remove features and programs deemed unnecessary for an init system, as well as address other perceived faults.

The uselessd project had planned further improvements on cross-platform compatibility, as well as architectural overhauls and refactoring for the Linux build in the future.