37 ms·

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 s

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.

tannhaeuser 9y ago
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?
- pmden 9y ago
  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.
  - dozzie 9y ago
    > 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.
    - andrewshadura 9y ago
      But do you need to?
      - dozzie 9y ago
        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.
    - JdeBP 9y ago
      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.
  - alxlaz 9y ago
    > 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 ;-).
- JdeBP 9y ago
  > 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.

tannhaeuser 9y ago

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?

pmden 9y ago
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.
- dozzie 9y ago
  > 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.
  - andrewshadura 9y ago
    But do you need to?
    - dozzie 9y ago
      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.
  - JdeBP 9y ago
    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.
- alxlaz 9y ago
  > 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 ;-).
JdeBP 9y ago
> 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.