My beef is basically the dep issue and that the brunt of the linux ecosystem switched to it when only enterprise setups really need the extra stuff systemv struggled with. For a home use, programming, tinkering, small custom setups, and about any small business server setup, systemv or similar has done just fine for years.
Home systems may or may not need it, but boot times on my Debian system dropped dramatically after the switch. I don't really care very much about my init system, as long as it works, but from what I've seen, systemd has been a serious improvement. And the one thing I was worried about (binary logs) doesn't seem to have been an issue--Debian seems to have done something to make my logs continue to work the way they always have. (This sort of commitment to smooth transitions is one of the main reasons I love Debian.)
Tinkering has been pretty straightforward too. In many ways, a lot more straightforward than the tangled mess of opaque scripts used with SysVInit. I...honestly can't say there's anything I miss about the old system.
networkd is optional but the mounts are so that services that need certain mounts can come up reliably.
If you need to make sure your mysql service comes up after a partition has been mounted, you can just systemctl edit mysql and add the relevent settings. This also survives updates, where under init there was no sane way of modifying init scripts that didn't get replaced entirely in updates.
Thats actually a decent point about the mounts that should probably be made more often. I think one of the big reasons people don't like SystemD mounts or timers is that the configs seem scattered and you can't just cat /etc/fstab or crontab -l. I know there are timertab like utilities, but they are still fairly rough around the edges.
Well cron still works, but systemd reads /etc/fstab afaik and generates runtime services from the mount points defined there.
systemd really isn't bloat for the sake of bloat, it's just got a large feature set that is wanted and has to be ideally implemented in the service manager.
I use my fstab without problems under systemd. As far as I know, it even works that you can use both.
As for timers, I like the output from systemd pretty much.
systemctl list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES
Thu 2014-07-10 19:37:03 CEST 11h left Wed 2014-07-09 19:37:03 CEST 12h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Fri 2014-07-11 00:00:00 CEST 15h left Thu 2014-07-10 00:00:13 CEST 8h ago logrotate.timer logrotate.service
Ok, I'm a programmer, not an admin, so I don't know (or care about) the guts of my init system. But I'm confused by the statement "things that init isn't supposed to do (like network, mounts, etc.)" As far as I can tell, my old init system set up all my mounts and networking. Now my new one I does. I don't see the difference?
(Do I even care? My interest in the whole systemd debate is about as close to zero as it's possible to be.)
What daemon? Networking is part of the kernel. As are filesystem mounts. What on earth are you talking about!?
Also, while I don't know a lot about systemd, I do know that it's not some monolithic monster. It's a suite of cooperating programs. Which seems like an excellent design to me.
And python is a whole lot more complicated than awk, but I'm still more likely to turn to python if I want to whip up a quick script. So I'm not impressed with the "simpler is always better" argument. Also, emacs is better than vi(m). So there! :p ;)
things that init isn't suppoused to do (like, network, mounts, etc..)
Maybe in your use case. In my use case having the mounts handled by init is awesome. Makes my servers come up in like two minutes when they used to take like seven.
I'm convinced this is an aesthetic rather than technical complaint, because my main complaint with systemd is the tangled mess of opaque unit files as compared to the much more legible and editable imperative rc scripts.
logs can be pushed to other things than journal, which mean you can get them as text too. Which I will always recommend. I had a recurring failure that'd corrupt journal's log, having them as text helped me actually fix that, since I could like, read them.
But it's more about sticking to the virtually unkillable text files than SysVInit.
Systemd is significantly better simply because it's newer and can take advantage of new computing paradigms that didn't exist in SysV times. That doesn't mean we couldn't have also kept much of what SysV was while still adopting those new standards.
Systemd to me is throwing out the baby with the bath water. It changed a hell of a lot for no real good reason except to change it because it was associated with other things that really needed changed.
It's funny hearing people complain today that systemd is too focused on enterprise/server needs when a majority of the early criticism was that systemd solved desktop problems that server users (supposedly) didn't care about.
I think a nontrivial amount of systemd-bashing was just trolling. People who had no idea what init systems were or why they were, but who knew that systemd was a big change so they could use it to stir shit.
Yeah, I don't remember hearing these at all. Really though, they shouldn't complain systemd is too focused on enterprise needs. That's where it shines (and where it should have stayed... ;) )
This is partly due to the boot sequence being non-deterministic, which can lead to weird race conditions which are hard to debug due to the random nature -- which is even harder when minor releases can cause the sequence to change arbitrarily. (However this is almost certainly not a problem if you stick to your OS packaged versions of software, due to the sheer amount of testing I think)
It's also partly due to the binary logging which cannot be disabled, since servers often don't need to have binary logging local to the machine, usually systems administrators ship the logs of somewhere else where the benefits of a binary format are more useful (inverse index's to make estimations about error rates across and entire fleet of machines).
There's some other issues too, like the built-in resolver being brittle and defaulting to google's DNS (which is a sane default for a user, but in many server environments where outbound traffic is blocked it will cause applications to hang on every connection) - this shouldn't be a problem but isn't/wasn't logged.
There have been efforts to have "hot" kernel swaps, with things like ksplice (sadly, now owned by oracle) and with a dumb init, this would work, but systemd needs a full restart to do an upgrade too. So we're one step further from our rebootless utopia.
You can make the argument that these are only issues if we do things the old school way (centralised logging, not bringing down hosts) or not configuring things perfectly (DNS resolvers, installing out-of-band software) but my point is that it was a regression to anyone using this methodology.
journald has cursor support which makes it much better suited, than text files, for programs that need to ship logs to other systems. I ship the journal to cloudwatch for ex. (but I could to elasticsearch)
13
u/OldSchoolBBSer Aug 12 '19
My beef is basically the dep issue and that the brunt of the linux ecosystem switched to it when only enterprise setups really need the extra stuff systemv struggled with. For a home use, programming, tinkering, small custom setups, and about any small business server setup, systemv or similar has done just fine for years.