Without Systemd

The root cause of all the complexity is (was?) the lack of standardization for hardware interfaces. The lack of some globally usable way of dealing with latency at the OS level is another issue. A thing like Pulseaudio is a natural reaction to the current situation in that it tries to both hide the complexity of the hardware interfaces and deals with the latency issue entirely in one program.

So the problem isn't Pulseaudio. The problem is the environment that media is forced to exist in.

What is it that makes uselessd attractive? And why do you consider systemd to be bloated?

I think what the parent poster meant is that despite being modularized into several components, systemd has interdependencies between them, its individual subsystems not being able to be seamlessly swapped out. Indeed, many components (nspawn included) depend on systemd-as-PID1. As such it is monolithic.

...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.

You're confusing sysvinit with sysv-rc.

You do realize that there are only a few binaries?

Have you actually compiled systemd? The binaries probably exceed a hundred at this point. The count given for 204 was 69.

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.

With two caveats: Forwarding to other sources has a priority loss and doesn't have the same reliability/ordering/completeness guarantees (even if the claim is they "try hard": https://wiki.freedesktop.org/www/Software/systemd/syslog/), journald hijacks /dev/log and expects all syslogd implementations to conform to its own standard.

logind handles logins

Far more than that. It handles user sessions, seats, suspend/hibernate, some device enumeration, gettys and as of recent, system shutdown. It's basically an extension from system init to session init.

it handles sockets for socket activation

Do you even understand what socket activation is? It's a marketing buzzword for an old and simple concept, and the systemd definition in particular conflates multiple use cases. See this commentary by Laurent Bercot: https://forums.gentoo.org/viewtopic-t-994548-postdays-0-post...

It handles devices via udev, mount points (a key aspect to initialising systems), automount, swap, path-based activation and timers.

Mount points and swaps are just small unit wrappers around the mount and swapon/swapoff binaries. It's oversold. Once again, path-based activation is a buzzword for reacting to file system changes, which you can do by leveraging inotify(7) or fanotify(7) independently.

There's pretty powerful cron replacements these days that can take the place of timer units.

I can't see how any of the above should NOT be part of an init system. Init systems should be capable of handling dynamic events.

Those features could be part of a process manager or a process supervisor, not init(8) itself. init(8)'s duties are reaping orphaned processes and handling high-level global system state at best (like SAK, shutdown, halt, etc.) It should not entangle the state of the system with the state of the OS processes, which systemd does quite egregiously. For example, even Apple had the engineering sense to separate their launchd plist configuration parser from the launchd PID1 itself.

How do you define a "dynamic event"?

Have a look at the dependency list here...

Your list is for systemd-204, which is heavily outdated. systemd moves really fast.

There's a lot of bashing of systemd, but most of it (if not all of it!) is unwarranted and can be verified with even a modicum of research.

Too bad it's apparent that you didn't do much of it yourself.

> Unfortunately, the traditional SysV init system was not particularly fast.

> Another thing we can learn from the MacOS boot-up logic is that shell scripts are [...] slow in execution.

> it is also our plan to experiment with systemd not only for optimizing boot times

It seems like the real motivation was exactly reversed from your comment - speed first, and correctness as a happy accident.

He does put up a later post (biggest myths about systemd) some three years later which tries to change this impression, but that reads much more like an attempt to move the goalposts than an actual design goal.

http://0pointer.de/blog/projects/systemd.html