Slashdot Mirror
Ask Slashdot: Can You Say Something Nice About Systemd?
ewhac writes: "I'm probably going to deeply deeply regret this, but every time a story appears here mentioning systemd, a 700-comment thread of back-and-forth bickering breaks out which is about as informative as an old Bud Light commercial, and I don't really learn anything new about the subject. My gut reaction to systemd is (currently) a negative one, and it's very easy to find screeds decrying systemd on the net. However, said screeds haven't been enough to prevent its adoption by several distros, which leads me to suspect that maybe there's something worthwhile there that I haven't discovered yet. So I thought it might be instructive to turn the question around and ask the membership about what makes systemd good. However, before you stab at the "Post" button, there are some rules...
Bias Disclosure: I currently dislike systemd because — without diving very deeply into the documentation, mind — it looks and feels like a poorly-described, gigantic mess I know nothing about that seeks to replace other poorly-described, smaller messes which I know a little bit about. So you will be arguing in that environment."
Nice Things About systemd Rules:
Bias Disclosure: I currently dislike systemd because — without diving very deeply into the documentation, mind — it looks and feels like a poorly-described, gigantic mess I know nothing about that seeks to replace other poorly-described, smaller messes which I know a little bit about. So you will be arguing in that environment."
Nice Things About systemd Rules:
- Post each new Nice Thing as a new post, not as a reply to another post. This will let visitors skim the base level of comments for things that interest them, rather than have to dive through a fractally expanding tree of comments looking for things to support/oppose. It will also make it easier to follow the next rule:
- Avoid duplication; read the entire base-level of comments before adding a new Nice Thing. Someone may already have mentioned your Nice Thing. Add your support/opposition to that Nice Thing there, rather than as a new post.
- Only one concrete Nice Thing about systemd per base-level post. Keep the post focused on a single Nice Thing systemd does. If you know of multiple distinct things, write multiple distinct posts.
- Describe the Nice Thing in some detail. Don't assume, for example, that merely saying "Supports Linux cgroups" will be immediately persuasive.
- Describe how the Nice Thing is better than existing, less controversial solutions. systemd is allegedly better at some things than sysvinit or upstart or inetd. Why? Why is the Nice Thing possible in systemd, and impossible (or extremely difficult) with anything else? (In some cases, the Nice Thing will be a completely new thing that's never existed before; describe why it's good thing.)
We will assume out of the gate that systemd boots your system faster than ${SOMETHING_ELSE}, so no points for bringing that up. Bonus points are awarded for:
- Personal Experience. "I actually did this," counts for way more than, "The docs claim you can do this."
- Working Examples. Corollary to the above — if you did a Nice Thing with systemd, consider also posting the code/script/service file you wrote to accomplish it.
- Links to Supporting Documentation. If you leveraged a Nice Thing, furnish a link to the docs you used that describe the Nice Thing and its usage.
Using the information gleaned from this year old bug I was able to create a Tower of Hanoi solver using the dependency resolver's attempts to determine whether a NFS filesystem should be mounted after the network comes up or not. Every attempt to start Apache (which depended on the filesystem) represents moving a disc to the middle tower.
Are you trying to imply that all the hatred I've heard about pulseaudio was also unjustified?
Only if you have a setup like Potterings, since he rewrote the pulseaudio configuration to work on his computer and just deleted features he wasn't using to "keep it easy".
Sort of like how if you're using systemd in an NFS world you're going to have a bad day, since he still hasn't made their dependency resolution work correctly with networked filesystems. Funny that rc dealt with that ages ago by having S01mount S05network S10networkmount but I'm sure there's a very good reason systemd is incapable of using mount -a -t nfs,cifs,smb,afs,etc, I suppose we'll need the kernel rewritten to support a systemd-mount program to solve this problem, which will of course be incompatible with standard mount.
In which case a nanny process restart is useless. Thanks for making my point, idiot.
Your logic is flawed. Random bit flips sometimes happen. They don't necessarily take down the whole machine.
Funny that rc dealt with that ages ago by having S01mount S05network S10networkmount but I'm sure there's a very good reason systemd is incapable of using mount -a -t nfs,cifs,smb,afs,etc,
Really? I confess I haven't looked at how to configure systemd much, but from what I have seen, that sort of setup could be supported easily enough by writing the right unit files (or whatever they're called) and specifying the dependencies.
Yes, exactly. So, by developing a clear understanding of systemd syntax and dependency specification, you should be able to solve the dependency problem that rc/sysvinit solved fifteen years ago by specifying that dependent processes start after their requirements.
This is actually a silly example. If all of the start-up processes are loaded sequentially, then order is really not a hard thing to sort out. You can do it manually, in your head, and your brain can process what's going to happen. Systemd introduces a massive complication by allowing init processes to happen in parallel. So, now you've got this horrible optimization to do, where you separate all of the separate init processes into mutually independent sequences that start in parallel. So, your brain can tell that you should start network file systems only after you've started the network, but how about the audio driver? Can you start named in one process while starting apache in another?
My point is that the dependency issue is really something that systemd introduces, and the benefit of its automatic dependency resolution is only relevant in the context of systemd. If it's really important to you that your computer be able to start multiple daemons in parallel, rather than wait the 5 seconds it takes to start bind before starting apache or samba or whatever, then systemd does that and solves the problems it introduces. If you'd rather understand what happens as your system starts up and not trust someone else's optimization, then systemd is not for you.
We've had problems a few times with systemd (usually the next boot after an upgrade to a package). Without exception, the failed boot occured with next-to-no meaningful error on the console and was more difficult to debug than if it had been using sysvinit. I personally, as a sysadmin for ~16 years, don't see a problem with sysvinit that justifies tearing it out of Linux for a more complicated, more opaque replacement.