4 ms·

It seems the systemd hate mostly comes from a philosophical position these days than anything grounded in real user impact. You either agree or disagree with wh

It seems the systemd hate mostly comes from a philosophical position these days than anything grounded in real user impact. You either agree or disagree with what systemd does, or do not care because you are not aware of it (which I would argue is a good thing). Personally I think it is great. Sysvinit scripts were terrible to write and frequently had bugs because the scripts were usually afterthoughts "Oh yea... I guess we need one of those things". The nice integrations between systemd and journald is well worth it in my mind as well.

lmm 7y ago
> Sysvinit scripts were terrible to write and frequently had bugs because the scripts were usually afterthoughts "Oh yea... I guess we need one of those things". There were alternative solutions to that problem that didn't require replacing a long and ever-growing list of system components with tightly-coupled (and often buggy) systemd versions. In fact people who really cared about their init system were already using them.
NikkiA 7y ago
sysvinit was at least a thousand times easier than bsd init scripts, and I occasionally see people that are opposed to both systemd and sysvinit and think rc.local was 'it'. shakes head slowly
- JdeBP 7y ago
  BSD rc scripts haven't worked in the way that you think that they have, for decades. Mewburn rc, which reduced many rc scripts to a couple of shell function calls and a handful of variable declarations, has been used by NetBSD since 2001, and FreeBSD started using it about a year later. OpenBSD, furthermore, reinvented Mewburn rc around 8 years ago. Project Trident (formerly TrueOS formerly PC-BSD) has also since then switched from Mewburn rc to OpenRC. * https://news.ycombinator.com/item?id=10357589 https://news.ycombinator.com/item?id=10357589 * https://news.ycombinator.com/item?id=11550802 https://news.ycombinator.com/item?id=11550802 * https://news.ycombinator.com/item?id=14736175 https://news.ycombinator.com/item?id=14736175 /etc/rc.local was first declared obsolete in the BSD world and replaced by a system of drop-in files in a directory back in 1995. * http://jdebp.info./FGA/rc.local-is-history.html http://jdebp.info./FGA/rc.local-is-history.html
  - yellowapple 7y ago
    > /etc/rc.local was first declared obsolete in the BSD world and replaced by a system of drop-in files in a directory back in 1995. OpenBSD still documents it as an implicitly-recommended way to start programs (though if it's possible to start it via e.g. rc.(local.)conf, then that's obviously preferable).
- yellowapple 7y ago
  > sysvinit was at least a thousand times easier than bsd init scripts ¿Qué? I guess we'll have to beg to differ here, but I prefer OpenBSD's (for example) init system over sysvinit or systemd any day. rc.subr is a godsend for eradicating all the boilerplate that "justified" switching to systemd. Enabling/disabling a daemon is as easy as adding a line to /etc/rc.conf.local (or just running "rcctl enable mydaemond", which does that for me). No fiddling with symlinking scripts to runlevel-specific folders (or, in fact, dealing with runlevels at all; if I need single-user mode, that's what bsd.rd is for). One of these days I'd love to start ripping out the initscripts on my Slackware machines and replace them with something closer to OpenBSD (or hell, I wonder if I can just port OpenBSD's init to Linux?).
marcosdumay 7y ago
Well, just excuse my philosophical stance of not liking my computers breaking by a new random cause every couple of months.
- creeble 7y ago
  This is my experience as well. Suddenly logins take 30s. Why? Some new systemd problem with reverse DNS. Suddenly reboots don't happen. Why? Systemd is spinning on a task that didn't used to spin. Yes, probably fixable, but not discovered until trying to reboot. Can't login at coffee shop WiFi suddenly. Why? Some random systemd DNS issue. Is my system more secure? Maybe, but possibly because it breaks so often that low uptime keeps it safe! For my servers, I seriously have to cross my fingers and have the colo phone number handy whenever I reboot, fearful that they won't restart because of some random systemd interaction that happened on some previous upgrade. It's gotten that bad.
tux1968 7y ago
Well systemd service files are great and represent a nice improvement. But I detest journalctl with its arcane query commands and binary storage; much prefer ability to use standard unix tools and my favorite editor for adhoc inspection at least. It's still is an annoyance on a pretty regular basis.
- eropple 7y ago
  You can tell journald to forward everything to rsyslogd and grep to your heart's content. https://wiki.archlinux.org/index.php/Rsyslog#journald's_syslog-forward_feature https://wiki.archlinux.org/index.php/Rsyslog#journald's_sysl...
  - yarrel 7y ago
    How do I remove this buggy attack surface from that workflow and why should I have to?
    - eropple 7y ago
      "How do I remove" - I dunno, because I don't care to remove it. Somebody's probably done it. Search on Google? It's open source, so look at the code, submit a patch, fork if you gotta? "Buggy attack surface" - I am unaware of attacks that target journald; can you point me to a practicable PoC attack? "Why should I have to" - because other people are building your distros, expending their effort on open source projects, and as part of doing that they made decisions on your behalf. Feel free to not use those distros for ones that make decisions you prefer; the choice is yours.
      - silversconfused 7y ago
        Then you are commenting on the wrong post. This post is about the systems that do not use systemd. Justifying your own use by demanding examples of failure is... odd here.
        7y ago
yarrel 7y ago
I don't hate it, but it has wasted more of my time as a sysadmin than anything else over the last few years.

lmm 7y ago

> Sysvinit scripts were terrible to write and frequently had bugs because the scripts were usually afterthoughts "Oh yea... I guess we need one of those things". There were alternative solutions to that problem that didn't require replacing a long and ever-growing list of system components with tightly-coupled (and often buggy) systemd versions. In fact people who really cared about their init system were already using them.

NikkiA 7y ago

sysvinit was at least a thousand times easier than bsd init scripts, and I occasionally see people that are opposed to both systemd and sysvinit and think rc.local was 'it'. shakes head slowly

JdeBP 7y ago
BSD rc scripts haven't worked in the way that you think that they have, for decades. Mewburn rc, which reduced many rc scripts to a couple of shell function calls and a handful of variable declarations, has been used by NetBSD since 2001, and FreeBSD started using it about a year later. OpenBSD, furthermore, reinvented Mewburn rc around 8 years ago. Project Trident (formerly TrueOS formerly PC-BSD) has also since then switched from Mewburn rc to OpenRC. * https://news.ycombinator.com/item?id=10357589 https://news.ycombinator.com/item?id=10357589 * https://news.ycombinator.com/item?id=11550802 https://news.ycombinator.com/item?id=11550802 * https://news.ycombinator.com/item?id=14736175 https://news.ycombinator.com/item?id=14736175 /etc/rc.local was first declared obsolete in the BSD world and replaced by a system of drop-in files in a directory back in 1995. * http://jdebp.info./FGA/rc.local-is-history.html http://jdebp.info./FGA/rc.local-is-history.html
- yellowapple 7y ago
  > /etc/rc.local was first declared obsolete in the BSD world and replaced by a system of drop-in files in a directory back in 1995. OpenBSD still documents it as an implicitly-recommended way to start programs (though if it's possible to start it via e.g. rc.(local.)conf, then that's obviously preferable).
yellowapple 7y ago
> sysvinit was at least a thousand times easier than bsd init scripts ¿Qué? I guess we'll have to beg to differ here, but I prefer OpenBSD's (for example) init system over sysvinit or systemd any day. rc.subr is a godsend for eradicating all the boilerplate that "justified" switching to systemd. Enabling/disabling a daemon is as easy as adding a line to /etc/rc.conf.local (or just running "rcctl enable mydaemond", which does that for me). No fiddling with symlinking scripts to runlevel-specific folders (or, in fact, dealing with runlevels at all; if I need single-user mode, that's what bsd.rd is for). One of these days I'd love to start ripping out the initscripts on my Slackware machines and replace them with something closer to OpenBSD (or hell, I wonder if I can just port OpenBSD's init to Linux?).

marcosdumay 7y ago

Well, just excuse my philosophical stance of not liking my computers breaking by a new random cause every couple of months.

creeble 7y ago
This is my experience as well. Suddenly logins take 30s. Why? Some new systemd problem with reverse DNS. Suddenly reboots don't happen. Why? Systemd is spinning on a task that didn't used to spin. Yes, probably fixable, but not discovered until trying to reboot. Can't login at coffee shop WiFi suddenly. Why? Some random systemd DNS issue. Is my system more secure? Maybe, but possibly because it breaks so often that low uptime keeps it safe! For my servers, I seriously have to cross my fingers and have the colo phone number handy whenever I reboot, fearful that they won't restart because of some random systemd interaction that happened on some previous upgrade. It's gotten that bad.

tux1968 7y ago

Well systemd service files are great and represent a nice improvement. But I detest journalctl with its arcane query commands and binary storage; much prefer ability to use standard unix tools and my favorite editor for adhoc inspection at least. It's still is an annoyance on a pretty regular basis.

eropple 7y ago
You can tell journald to forward everything to rsyslogd and grep to your heart's content. https://wiki.archlinux.org/index.php/Rsyslog#journald's_syslog-forward_feature https://wiki.archlinux.org/index.php/Rsyslog#journald's_sysl...
- yarrel 7y ago
  How do I remove this buggy attack surface from that workflow and why should I have to?
  - eropple 7y ago
    "How do I remove" - I dunno, because I don't care to remove it. Somebody's probably done it. Search on Google? It's open source, so look at the code, submit a patch, fork if you gotta? "Buggy attack surface" - I am unaware of attacks that target journald; can you point me to a practicable PoC attack? "Why should I have to" - because other people are building your distros, expending their effort on open source projects, and as part of doing that they made decisions on your behalf. Feel free to not use those distros for ones that make decisions you prefer; the choice is yours.
    - silversconfused 7y ago
      Then you are commenting on the wrong post. This post is about the systems that do not use systemd. Justifying your own use by demanding examples of failure is... odd here.
      - 7y ago

yarrel 7y ago

I don't hate it, but it has wasted more of my time as a sysadmin than anything else over the last few years.