Michael Stapelberg, a Debian developer, writes about systemd, Debian tooling, Debian Code Search, and performance work.
Commenters link it in systemd debates, where one calls his bloat argument FUD. It is also cited for the survey results and Debian manpage changes.
This honestly seems like FUD. Currently the Sys-V like serialisation of services at startup hasn't been efficient, and sysvinit doesn't handle event based kernel features at all well. And it's definitely not modular.
As for this argument that it's monolithic in its code organisation - lolwut? You don't need to have a seperate repository for each binary, hardly anyone does that. When you talk about clearly and vigorously defined interfaces, it seems to already have them - and I hardly consider sysvinit to be a great example of such a thing - a bunch of cobbled together shell scripts serialised into a particular order isn't particularly clean or elegant. Heck, it's not even necessarily easy to troubleshoot if things go wrong. The systemd source is in one git repo, sure, but I can't see why maintenance will be a burden. What in particular concerns you?
You do realize that there are only a few binaries? Let's look at them:
networkd: handles network events - when a network device is created it handles setup. No, it does not supplant udev. Read here an overview: https://coreos.com/blog/intro-to-systemd-networkd/
Not a bad idea here: and very sensible aspect of systemd.
journald - collects log data from a variety of sources and puts it into a binary indexed data file. The most controversial aspect of systemd, but of course as is overlooked all the log data can be forwarded to syslog, kmsg, the console or wall via a simple configuration change.
Or, you can swap out the…
Just my two cents as I haven't seen it mentioned in this thread:
launchd is the init system used by Mac OSX and has been ported to FreeBSD a few years ago with a recent resurgent effort for improvements [1]. It has been suggested that launchd could one day be the new FreeBSD init system due to speed and feature improvements, but many FreeBSD users think that the init system is a non-issue and efforts could be better spent elsewhere. launchd has also been criticized as to have been developed for OSX and not BSD (e.g. it depends on CoreFoundation features).
There is growing concern that applications will become more reliant on systemd and therefore Linux-only features [2], reducing or eliminating portability to the BSDs. Unfortunately, most conversations about init systems and FreeBSD degenerate into flame wars [3].
[1]: https://github.com/rtyler/openlaunchd
[2]: http://people.debian.org/~stapelberg//2013/07/13/systemd-not-portable.html?utm_medium=App.net&utm_source=PourOver
[3]: http://forums.freebsd.org/viewtopic.php?t=35770
Not everything of systemd is in PID 1. And yes, what some people consider necessary and important or even essential features missing from sysvinit, others consider bloat.
Just to ensure we're all talking about the same thing, here's an overview of systemd's footprint:
http://people.debian.org/~stapelberg/docs/systemd-dependencies.html
From the article:
"On most machines, systemd will bring from 236 KiB to 550 KiB of additional libraries to be loaded into memory. When recompiling systemd without its optional dependencies (e.g. for embedded systems), this shrinks to 368 KiB in the worst case.
The RSS (Resident Set Size) of systemd is 1.8 MiB, whereas sysvinit uses 0.8 MiB — both measured on typical Debian wheezy installations."
> This blog post is the third of a series of posts
> dealing with the results of the Debian systemd survey
Previous posts in the series
http://people.debian.org/~stapelberg//2013/06/09/systemd-bloat.html
http://people.debian.org/~stapelberg//2013/07/01/systemd-transition.html
I suggest investigating systemd then. It isn't bloated. See for instance http://people.debian.org/~stapelberg/2013/06/09/systemd-bloat.html. There are a lot of different parts to it.
Note the time of the blog. Saying systemd is bloated is IMO so 2013 :P
It is! https://github.com/Debian/dcs/commit/e1c04a3c0cfbfc11a0e8eaac505775ed1b612619
Check out https://people.debian.org/~stapelberg//2016/08/08/debian-codesearch-latency.html for details on the most recent bigger change.