3 ms·

No more problems with overflowing logfiles Not quite. The journal is prone to fragmentation, though it can be capped just as most sane loggers like multilog ca

No more problems with overflowing logfiles Not quite. The journal is prone to fragmentation, though it can be capped just as most sane loggers like multilog can. no more debugging undocumented shell scripts for booting no more writing init scripts no more debugging undocumented 200+ line init scripts Redundant complaints, and irrelevant. Not all script-based init systems are created equal, and many init systems throughout history have eschewed shell scripts [1]. no more minute-long boot delays Incorrect. Boots can still stall from dependency loops, cyclical transactions, stuck start/stop jobs, an improperly calculated service ordering in the parallel dependency graph, etc. no more brittle, half-assed distribution-specific networking solutions (also undocumented shell scripts) Incorrect. networkd is tailored to specific purposes (largely containers) and not a general-purpose NetworkManager replacement, nor does it necessarily deprecate any ad-hoc network configuration scripts (which aren't even intrinsically bad). [1] http://blog.darknedgy.net/technology/2015/09/05/0/ http://blog.darknedgy.net/technology/2015/09/05/0/

creshal 11y ago
Why, yes, I could clobber together my own server distribution with multilog and obscure init systems and whatnot, or… I could just use the distribution default, which massively improved over the old status quo with the introduction of systemd. > The journal is prone to fragmentation, though it can be capped just as most sane loggers like multilog can. So my choices are a) systemd + journald, which Just Works™ by always feeding units' stdout to it without any further configuration, b) syslog and logrotate and oh I have to patch software to use syslog in the first place and make sure logrotate rotates the files correctly if a daemon still its logfile open and… yeah, screw that, I've wasted enough of my life with that, c) something where I manually set up everything to use multilog. > Redundant complaints, and irrelevant From your ivory tower, maybe. Meanwhile I'm sitting in the trenches and banging my head against the wall because someone again managed to break their 300+ line init script (hi, MySQL!). > Incorrect. I did not mean failure cases. The average case, where every service starts up in a correct order on sysvinit/systemd, went from ~60 seconds to <20. Now, a reboot is usually faster than the failover timeout. And unlike with Debian's "dependency-based sysvinit", systemd works. I've yet to see a failure case that wasn't caused by either hardware failure or gross operator error (e.g. referencing /var wrong in the fstab). > Incorrect. Well, it looks I have to throw away my perfectly working networkd setups then, if you say so. > NetworkManager I wasn't even talking about that. I was mainly referring to Debian's networking scripts (which have been broken and unfixed for half a decade now) and Arch's netcfg/netctl which all three never worked as advertised. If NetworkManager was actually usable on headless devices, I might prefer it over networkd, too (assuming I find a use case where either it or connman are insufficient).

creshal 11y ago

Why, yes, I could clobber together my own server distribution with multilog and obscure init systems and whatnot, or… I could just use the distribution default, which massively improved over the old status quo with the introduction of systemd. > The journal is prone to fragmentation, though it can be capped just as most sane loggers like multilog can. So my choices are a) systemd + journald, which Just Works™ by always feeding units' stdout to it without any further configuration, b) syslog and logrotate and oh I have to patch software to use syslog in the first place and make sure logrotate rotates the files correctly if a daemon still its logfile open and… yeah, screw that, I've wasted enough of my life with that, c) something where I manually set up everything to use multilog. > Redundant complaints, and irrelevant From your ivory tower, maybe. Meanwhile I'm sitting in the trenches and banging my head against the wall because someone again managed to break their 300+ line init script (hi, MySQL!). > Incorrect. I did not mean failure cases. The average case, where every service starts up in a correct order on sysvinit/systemd, went from ~60 seconds to <20. Now, a reboot is usually faster than the failover timeout. And unlike with Debian's "dependency-based sysvinit", systemd works. I've yet to see a failure case that wasn't caused by either hardware failure or gross operator error (e.g. referencing /var wrong in the fstab). > Incorrect. Well, it looks I have to throw away my perfectly working networkd setups then, if you say so. > NetworkManager I wasn't even talking about that. I was mainly referring to Debian's networking scripts (which have been broken and unfixed for half a decade now) and Arch's netcfg/netctl which all three never worked as advertised. If NetworkManager was actually usable on headless devices, I might prefer it over networkd, too (assuming I find a use case where either it or connman are insufficient).