Hacker News Reader

Comment by craftyguy | Hacker News Reader

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.

View on HN

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.

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.

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

Reply on news.ycombinator.com