> Journald starts eating a ton of RAM, ~100 MB upon boot, and keeps growing.

You must subtract shared from resident to determine how much memory has been "eaten".

Journald uses mmap() for random access within the journal files. These pages are accounted for as shared because they are file-backed and may be paged out by the kernel behind the scenes if memory is needed - they'll just be paged back in from the filesystem if accessed later by journald.

Systemd is still a mess.

I've currently one machine that hangs on reboots because systemd is unable to shut down some service and another that gets its journals corrupted periodically.

see newnewpdro's comment.

I just built a headless armv7h system (using Arch Linux ARM) with 1GB of RAM, and after being up for 3 days running nginx, ssh, and some other bare services, the total RAM usage, for all applications, is 70-100MB. Systemd is complex, but it really doesn't seem to add a lot of resource drain for the power it give you... I'm happy with that tradeoff.

Out of curiosity, to start nginx and sshd you need like 2 lines of shell code in a BSDish rc.conf - one for starting each service. Why do you think systemd bringing in 10s and 100s of megabytes of black magic binary code is a trade-off worth making, especially on a non-desktop without a need for reacting on up/down events of network interfaces?

Systemd isn't one component, so you'd be mistaken assuming everything in the systemd project is necessary to start a service. But second to that, I'm not sure why you think nginx_enable='YES' is fundamentally less opaque than an nginx.service file. Both are parsed by another application. As for why someone would make that 'trade-off' - I much prefer being able to add "Restart=on-failure" than using daemontools, and I don't have the luxury of working with one single distribution and remember the faff involved with initscripts differing between CentOS and Debian.

My reasons aside, I'd think a more sensible question would be "why would you actively avoid using the init system that's shipping by default on what constitutes at least 90% of the Linux server market when you're using Linux?". I don't think eyes equate to quality and stability, but I do think Red Hat, and SUSE, and Canonical and Oracle selling server solutions using it will.

> I'm not sure why you think nginx_enable='YES' is fundamentally less opaque than an nginx.service file. Both are parsed by another application.

My guess: because the "another application" that parses nginx_enable=YES is a (rc) shell script instead of an ELF blob, so you can track its execution.

That is not actually true. It is of course parsed by a shell, not by a shell script, which is indeed an "ELF blob".

Moreover, that shell is, on some operating systems, only one of the parsers. OpenBSD, for example, introduced a rule a few versions ago that rc.conf is not shell script. It is a set of key=value assignments that can be written and read by other programs too, not just by a full shell parser and not requiring a shell script parser.

One such program is rcctl. Another is FreeBSD's sysrc.

But do you need to?

Yes, when something goes awry with the initscripts system. And systemd is not exactly famous for its transparency of execution and stability of options' behaviour.

> But second to that, I'm not sure why you think nginx_enable='YES' is fundamentally less opaque than an nginx.service file. Both are parsed by another application.

That's true of both plain-text configuration files and Windows Registry keys ;-).

> you need like 2 lines of shell code in a BSDish rc.conf

... and then 223 lines of actual scripts, since those two lines in rc.conf merely enable/disable the services and do not denote how to actually invoke them. (Equivalently, the systemd people could say that they need just two symbolic links, one for enabling each service.)

    % wc -l /usr/local/etc/rc.d/nginx /etc/rc.d/sshd
         136 /usr/local/etc/rc.d/nginx
          87 /etc/rc.d/sshd
         223 total
    % 

... and of course another 2090 lines of shell function library for those shell scripts to rely upon.

    % wc -l /etc/rc.subr 
        2090 /etc/rc.subr
    % 

Mewburn rc is a fairly elegant system in comparison to van Smoorenburg rc (although it has its fair share of exceptions, sometimes quite bad ones) but it does not involve only 2 lines.

> Devuan is basically Debian without systemd.

You can already run Debian without systemd today. There's absolutely no need in the fragmentation Devuan creates.

I'm under the impression that Devuan's purpose is to actually progress into the future without systemd.

I am not under the impression that Debian strives to make progress on the systemd-less use case, it seems more like a minimally supported mode.

But it's not something I've investigated, so take that with a big grain of salt.