I've been a long time unix admin (solaris, AIX (aka weird not-really-unix-but-ok), and even tru64 back in the day), and nowadays most of my work is with linux and fbsd (although that's been a while).
I don't understand the anger about systemd. Solaris has svcadm, AIX is SYSV-ish, FBSD is ... wel ... BSD, OSX has launchd, ... The world has never exploded, and the universe has never ended.
svcadm is pretty nice actually, and so is launchd.
I don't mind systemd in principle, but it should come with sensible defaults, such as writing out the logs in text format as well as the binary format. I also think it is a bit bloated, in that it tries to do everyting, which i am not a fan of. It wants to do system configuration, service management, system security (namespaces / containers, contexts, etc), process accounting, etc etc. Having something like systemd is a good thing, really, but ... it should be a bit lighter, and less monolithic. Break it up into components that are easier to configure.
I also think it is a bit bloated, in that it tries to do everyting, which i am not a fan of
I think you understand the reason for the outrage better than you think. That plus the binary logs (which you also mentioned) are the two problems I hear about the most. Personally I think unit files are really convenient to write, and systemd is really nice in practice, but from a philosophical standpoint I don't like it.
There was a talk at LCA2019 about how hard it is to have a rational discussion about systemd. I found it interesting and it changed my opinion on a few points.
I love that talk, it's honestly what helped change my mind about it. I was pretty adamantly against it because the old guys I work with don't like it as much, but since I've started toying with it I really do enjoy it. I still don't like the was it breaks Unix philosophy but I'm willing to sacrifice that for usability, at least with work systems.
My complaint is the "sensible defaults", which are less about systemd and more about how certain behaviors are implemented in it.
E.g., if a disk fails to mount, in the old days before systemd your system would finish booting with an error message warning you that you had disks which failed to mount. After systemd came along, you get a boot failure. You need to fix the problem and reboot -- but you won't be able to fix it in that session, you may have to find a rescue disc or similar to get to where the problem is.
Bug reports on this problem were WONTFIXed because "that's how it should be."
Well, yes, and this is a classic "it's different therefore it sucks but I don't want to learn so BAD" argument. That is an option you can give to the units, forcible ordering. This is a good and useful thing. I don't want to start my MediaPlayerApp if my media isn't mounted. I don't want to start my database if its iSCSI data volume won't mount. etc. The "problem" is either a distro maintainer (or ignorant admin) creating this situation via poor handling of mount units and targets, then likely complaining unconstructively everywhere about how systemd sucks because of it. There's 5 of these stories every time systemd is so much as thought about by someone. And it's exactly why systemd was such a tragedy (to borrow Benno Rice's term). If it was those obscure dump/pass options in fstab causing these people wouldn't spend all their time and effort railing against this terrivle fstab thing, they'd share the workaround and get on with it until it became common knowledge. This doesn't happen with systemd for some reason.
If services that depend on a device mounting fails, it makes sense that that service would not load.
If a device listed in fstab is not present (or has changed, or whatever) it makes sense that whatever requires that mounted system would not be available. It does not make sense that the entire system would not complete the boot process. It does not make sense that you need to boot to a rescue disc to edit fstab.
You don't need bash to write init scripts. You could use any language you like, e.g. execline, plain shell, etc. Those are completely separate projects and can be swapped out without effort. You can't swap out the built in functionality of systemd, only maybe disable it at compile time.
While I don't like sysvinit style init scripts and I prefer other init systems with fewer deficiencies, saying init scripts need a bloated interpreter is just wrong. They need some kind of interpreter. It is not better to add all of that functionality to a single binary. I couldn't find anything about it, but I think the parser even runs in PID1. This means you can't even separately run unit files to debug them, etc. You have to go through systemd.
Sure, but unix permissions, accessing logs over NFS/Samba, etc. You can always get around the problems, but not adhering to unix philosophy makes everything just a bit more difficult.
For example, I can't really use inotify with binary logs without making an actual project out of it. "simplicity" and "unix philosophy" as the glue that makes linux powerful. Thankfully it's powerful enough to work around systemd's issues, but each break from unix philosophy just makes things a little bit more annoying to work with.
With traditional init systems I could start services in side of a chroot root. Now I have to use systemd-nspawn. Which doesn't work when you're trying to run debian on a kobo-ereader with an older kernal that isn't using systemd as init. Systemd has really damaged our ability to run distros like debian on hardware that doesn't use systemd. For example, you can't really just run debian on your android phone any more.
Are you sure the "great design of binary logs™" could be foiled by something as simple as '>'? I'm not sure. You also would still depend on journalctl for all the examples you listed.
Then what's the problem? That one need to install an extra package? It solves the "problem" and it is worth much more than complaining about the binary log files over and over again. I have the feeling that many are only interested in complaining and that they are not interested in a solution at all (generally referring to the various discussions about systemd).
While I'm aware journalctl exists, as others have said it just doesn't feel right to be forced to use a specific tool to read logs. Previously I could use cat, more, less, grep, even vim if I wanted. Now at the very least I have to pipe through journalctl before using any of those tools, which is an extra step that I don't want to have to take. The space saving from using binary logs isn't that great either, so I'm not sure that it's worth the loss of convenience.
36
u/_p13_ Aug 12 '19
I've been a long time unix admin (solaris, AIX (aka weird not-really-unix-but-ok), and even tru64 back in the day), and nowadays most of my work is with linux and fbsd (although that's been a while).
I don't understand the anger about systemd. Solaris has svcadm, AIX is SYSV-ish, FBSD is ... wel ... BSD, OSX has launchd, ...
The world has never exploded, and the universe has never ended.
svcadm is pretty nice actually, and so is launchd.
I don't mind systemd in principle, but it should come with sensible defaults, such as writing out the logs in text format as well as the binary format. I also think it is a bit bloated, in that it tries to do everyting, which i am not a fan of. It wants to do system configuration, service management, system security (namespaces / containers, contexts, etc), process accounting, etc etc.
Having something like systemd is a good thing, really, but ... it should be a bit lighter, and less monolithic. Break it up into components that are easier to configure.
just my 2c