4 ms·

Systemd has always been hyper focused on the desktop/laptop experience, and then justified for other use cases. Desktop is by a rediculously huge margin the lea

Systemd has always been hyper focused on the desktop/laptop experience, and then justified for other use cases. Desktop is by a rediculously huge margin the least important use case. So something like systemd-homed does not make any sense in a server setup but I can basically guarantee it will be forced upon server setups, just like systemd-resolvd was. Ironically the very small percentage of users that use Linux on the desktop tend to be of the more die-hard variety that don't welcome systemd's view of the world. In the end systemd is an extremely bad steward of Linux.

nightfly 7y ago
My organization has been very happy with using systemd on servers. Having an init system that can automatically restart failed services, and with decent sdependency management is a big win. We've also been able to replace many 50-100 line long init scripts with systemd unit definitions that are 10 lines long, and considerably more readable than the bash init scripts they replaced. We've had some bad experiences too, logins being "slow" because something went wrong and left 1000s of leftover session units in a weird state, systemd vulnerabilities requiring reboots occasionally. But systemd has had a net-positive impact.
- cat199 7y ago
  nothing precludes a reasonable shell library from making initscripts 10 lines long: http://cvsweb.netbsd.org/bsdweb.cgi/src/etc/rc.d/cron?rev=1.6&content-type=text/x-cvsweb-markup&only_with_tag=MAIN http://cvsweb.netbsd.org/bsdweb.cgi/src/etc/rc.d/cron?rev=1.... this does not require systemd cruft and all of it's over-opinionated facebook-youth narcissistic my-use-case is all that matters tentacles.
  - CameronNemo 7y ago
    OpenRC is similarly concise. The runit run scripts used on Void Linux are too, but they rarely take into account complicated dependencies so they are fragile.
  - theamk 7y ago
    Aren’t you replacing systemd with run_rc_command? This is just as opinionated, but with less features. (In particular, will the error be logged if the program fails to start due to bad config file? And how do I describe “only start once “volume X” is mounted?j)
    - cat199 7y ago
      > Aren’t you replacing systemd with run_rc_command? This is just as opinionated, but with less features. sure, but this is a 'reasonable shell library' rather than the 'systemd cruft + tentacles' that I mention. want it to do something else? write your own functions. want "an init system that can automatically restart failed services, and with decent dependency management" here you go: # cat /etc/daemoncheck #! /bin/sh docheck() { initscript="/etc/rc.d/$1"; if [ -x "$initscript" ]; then $initscript check > /dev/null \ || $initscript start fi } docheck ntpd docheck inetd docheck dhcpd docheck tftpd & throw that, or similar in cron or make it run in a while loop. Nothing precludes some rudimentary shell script being bundled as part of a simple shell-style init system out of the box. I don't need 5000 lines of C code, multiple binaries, 10 layers of symlinks, and all of the rest of it. a few hundred lines of shell that anyone who knows shell and how to read manual pages (that are kept up to date on the actual system, not bad HTML needing 10 tools to render the last time someone thought to update the documentation) can understand the entierty of in literally one sitting.
      - theamk 7y ago
        Thanks for the example -- because this is exactly why I am glad we had systemd! I do remember using the gentoo's rc system, and writing the script very much like you wrote here, and it always "kinda works". Specifically, how is "$initscript check" will work? I have seen three approaches: - Sometimes, "check" searches for the process with the given name. That can fail if you are on multi-user system, and a user runs a server on non-standard port. - Sometimes, "check" checks for .pid file, and that process with given pid exists. This can fail if you have high process churn, and your PID got reused. - Sometimes, "check" does completely strange things. Like check that PID file exists, but not the contents -- so it would work fine if you use start/stop commands, but will not notice if the server crashes. So yes, you can do it in shell, and it will work.. most of the time. And hey, you can always fix it -- the first time you discover that your server did not restart, you'd edit the script and add port checking... and then upgrade it to better kill runaway processes.. you can keep going and going. In the end, I think it all brings you back to old pets vs cattle debate. If your server is manually provisioned, each process is carefully tuned, then shell scripts are for you. If you just want to say "install something_d" and have things work, across thousands of systems, at the expense of uglier config and non-optimal file layout -- then more advanced inits are way better.
- Mave83 7y ago
  I can agree, since we switched to systemd, a lot of work is simply no longer necessary and the reliability due to new features where increased. Overall a big win against the old init system. Don't hate new stuff, it's OK to have same changes and sorry to say, the old home directory is awful. Maybe the new will bring something good as well (don't know yet, but I try to stay open minded). For example I would love to see roaming home profiles in Linux, not only for the desktop but for servers as well.
m45t3r 7y ago
> Systemd has always been hyper focused on the desktop/laptop experience No, most features of systemd are focused in Servers (systemd-resolved itself is one example, it can be used by Desktops, however the reason for its creation was containers that needed to have faster DNS resolution). Actually, systemd-homed is the first systemd feature that I know that the reason to exist is for Laptop users (and Desktop users somewhat less). Most new features of systemd are created for either servers or embedded users. For example: - Portable services (user case: servers): http://0pointer.net/blog/walkthrough-for-portable-services.html http://0pointer.net/blog/walkthrough-for-portable-services.h... - IP Accounting (user case: servers): http://0pointer.net/blog/category/projects.html http://0pointer.net/blog/category/projects.html - Dynamic users (user case: servers): http://0pointer.net/blog/dynamic-users-with-systemd.html http://0pointer.net/blog/dynamic-users-with-systemd.html - SD-event (user case: all): http://0pointer.net/blog/introducing-sd-event.html http://0pointer.net/blog/introducing-sd-event.html - SD-bus (user case: all): http://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html http://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html - Stateless systems (user case: embedded): http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html http://0pointer.net/blog/revisiting-how-we-put-together-linu... For all of those features, only SD-bus is more relevant to Desktop user case since it is where DBus is more common. However Dbus is also used in server/embedded user cases sometimes. The rest of features may be interesting for Desktop however they mostly are used for either servers or embedded systems. > it will be forced upon server setups I am really curious of which systemd features are being forced in any distro. systemd-resolved for example is not used by default in any distro that I know (Debian, Ubuntu, Arch, NixOS).
- twothumbsup 7y ago
  I'm pretty sure Ubuntu 18.04 uses systemd-resolved by default, not that it matters all that much to me.
johnny22 7y ago
even Fedora doesn't use systemd-resolvd, so NOTHING was forced
- tomatocracy 7y ago
  Debian added it ‘behind people’s backs’ in buster / Debian 10 when you updated from the previous stable. On one laptop I have I was still running systemd and it took me quite a while to figure out why my dns resolution broke (I block port 53 outbound at my router and it was trying to use 8.8.8.8 despite my resolv.conf saying something else). It’s not just that they added their own caching resolver - it’s that it then ignores the decades old standard resolv.conf and hijacks system name resolution by default. That finally prompted me to remove systemd from the one machine I had it on.

nightfly 7y ago

My organization has been very happy with using systemd on servers. Having an init system that can automatically restart failed services, and with decent sdependency management is a big win. We've also been able to replace many 50-100 line long init scripts with systemd unit definitions that are 10 lines long, and considerably more readable than the bash init scripts they replaced. We've had some bad experiences too, logins being "slow" because something went wrong and left 1000s of leftover session units in a weird state, systemd vulnerabilities requiring reboots occasionally. But systemd has had a net-positive impact.

cat199 7y ago
nothing precludes a reasonable shell library from making initscripts 10 lines long: http://cvsweb.netbsd.org/bsdweb.cgi/src/etc/rc.d/cron?rev=1.6&content-type=text/x-cvsweb-markup&only_with_tag=MAIN http://cvsweb.netbsd.org/bsdweb.cgi/src/etc/rc.d/cron?rev=1.... this does not require systemd cruft and all of it's over-opinionated facebook-youth narcissistic my-use-case is all that matters tentacles.
- CameronNemo 7y ago
  OpenRC is similarly concise. The runit run scripts used on Void Linux are too, but they rarely take into account complicated dependencies so they are fragile.
- theamk 7y ago
  Aren’t you replacing systemd with run_rc_command? This is just as opinionated, but with less features. (In particular, will the error be logged if the program fails to start due to bad config file? And how do I describe “only start once “volume X” is mounted?j)
  - cat199 7y ago
    > Aren’t you replacing systemd with run_rc_command? This is just as opinionated, but with less features. sure, but this is a 'reasonable shell library' rather than the 'systemd cruft + tentacles' that I mention. want it to do something else? write your own functions. want "an init system that can automatically restart failed services, and with decent dependency management" here you go: # cat /etc/daemoncheck #! /bin/sh docheck() { initscript="/etc/rc.d/$1"; if [ -x "$initscript" ]; then $initscript check > /dev/null \ || $initscript start fi } docheck ntpd docheck inetd docheck dhcpd docheck tftpd & throw that, or similar in cron or make it run in a while loop. Nothing precludes some rudimentary shell script being bundled as part of a simple shell-style init system out of the box. I don't need 5000 lines of C code, multiple binaries, 10 layers of symlinks, and all of the rest of it. a few hundred lines of shell that anyone who knows shell and how to read manual pages (that are kept up to date on the actual system, not bad HTML needing 10 tools to render the last time someone thought to update the documentation) can understand the entierty of in literally one sitting.
    - theamk 7y ago
      Thanks for the example -- because this is exactly why I am glad we had systemd! I do remember using the gentoo's rc system, and writing the script very much like you wrote here, and it always "kinda works". Specifically, how is "$initscript check" will work? I have seen three approaches: - Sometimes, "check" searches for the process with the given name. That can fail if you are on multi-user system, and a user runs a server on non-standard port. - Sometimes, "check" checks for .pid file, and that process with given pid exists. This can fail if you have high process churn, and your PID got reused. - Sometimes, "check" does completely strange things. Like check that PID file exists, but not the contents -- so it would work fine if you use start/stop commands, but will not notice if the server crashes. So yes, you can do it in shell, and it will work.. most of the time. And hey, you can always fix it -- the first time you discover that your server did not restart, you'd edit the script and add port checking... and then upgrade it to better kill runaway processes.. you can keep going and going. In the end, I think it all brings you back to old pets vs cattle debate. If your server is manually provisioned, each process is carefully tuned, then shell scripts are for you. If you just want to say "install something_d" and have things work, across thousands of systems, at the expense of uglier config and non-optimal file layout -- then more advanced inits are way better.
Mave83 7y ago
I can agree, since we switched to systemd, a lot of work is simply no longer necessary and the reliability due to new features where increased. Overall a big win against the old init system. Don't hate new stuff, it's OK to have same changes and sorry to say, the old home directory is awful. Maybe the new will bring something good as well (don't know yet, but I try to stay open minded). For example I would love to see roaming home profiles in Linux, not only for the desktop but for servers as well.

m45t3r 7y ago

> Systemd has always been hyper focused on the desktop/laptop experience No, most features of systemd are focused in Servers (systemd-resolved itself is one example, it can be used by Desktops, however the reason for its creation was containers that needed to have faster DNS resolution). Actually, systemd-homed is the first systemd feature that I know that the reason to exist is for Laptop users (and Desktop users somewhat less). Most new features of systemd are created for either servers or embedded users. For example: - Portable services (user case: servers): http://0pointer.net/blog/walkthrough-for-portable-services.html http://0pointer.net/blog/walkthrough-for-portable-services.h... - IP Accounting (user case: servers): http://0pointer.net/blog/category/projects.html http://0pointer.net/blog/category/projects.html - Dynamic users (user case: servers): http://0pointer.net/blog/dynamic-users-with-systemd.html http://0pointer.net/blog/dynamic-users-with-systemd.html - SD-event (user case: all): http://0pointer.net/blog/introducing-sd-event.html http://0pointer.net/blog/introducing-sd-event.html - SD-bus (user case: all): http://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html http://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html - Stateless systems (user case: embedded): http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html http://0pointer.net/blog/revisiting-how-we-put-together-linu... For all of those features, only SD-bus is more relevant to Desktop user case since it is where DBus is more common. However Dbus is also used in server/embedded user cases sometimes. The rest of features may be interesting for Desktop however they mostly are used for either servers or embedded systems. > it will be forced upon server setups I am really curious of which systemd features are being forced in any distro. systemd-resolved for example is not used by default in any distro that I know (Debian, Ubuntu, Arch, NixOS).

twothumbsup 7y ago
I'm pretty sure Ubuntu 18.04 uses systemd-resolved by default, not that it matters all that much to me.

johnny22 7y ago

even Fedora doesn't use systemd-resolvd, so NOTHING was forced

tomatocracy 7y ago
Debian added it ‘behind people’s backs’ in buster / Debian 10 when you updated from the previous stable. On one laptop I have I was still running systemd and it took me quite a while to figure out why my dns resolution broke (I block port 53 outbound at my router and it was trying to use 8.8.8.8 despite my resolv.conf saying something else). It’s not just that they added their own caching resolver - it’s that it then ignores the decades old standard resolv.conf and hijacks system name resolution by default. That finally prompted me to remove systemd from the one machine I had it on.