On Sat, 18 Jun 2016, Stefan Skoglund (lokal anv?ndare) wrote: > What i don't like about systemd is: the fud about how easy it is to > write systemd unit files vs old shell script init.d/ditos .
In most simple cases, their argument is that it's easier to write a unit file because you don't need to know shell script. However, as you point out, that all starts to fall apart when the unit files, which ARE basically the same format as Windows INI files (square bracket section header with key-value pairs following). That's because INI files aren't a Turing complete language and what you start seeing is edge cases where, even using unit files, you still need management scripts. So, that leaves you shaking your head asking why did Linux do all this crap in the first place, if most of their "benefits" start to disintegrate as soon as your init-need gets the least bit complicated. > Writing correct unit files for something as complicated as NFS and > especially if running in an split NFS3/NFS4 environment with > Kerberos-authenticated id mapping between server and client is NOT > simple. That's a great example, but only one that someone who digs in and discovers things at a low level will notice. Most of the loud voices on the pro-systemd side are people who don't interact with Linux at that level. They are just overjoyed that it boots 2 seconds quicker. Nevermind that ALL of the other alternative init systems boot faster than init. It's easy to do once you bootgraph everything (and init could easily be extended to do the same, and has been in some experimental cases). > Systemd doesn't ease the complexity of describing dependencies, As you know, you have to trace each unit-file's "wants" back to another unit file and keep going until you hit one without any dependencies. It's about the same turd hunt as looking at LSM tags (nothing lost, nothing gained). That's just my opinion based on working with both. As you say, it doesn't ease the process, nonetheless. > and i also have a suspicion that the systemd design wasn't enough well > defined for something else to happen (good and consistent design results > in better documentation) - so the users got to have to do a bit of > frustrating trial-and-error while writing their own unit files. I've heard that before from RHEL customers who were a bit shocked (and didn't know anything about the systemd controversy). > > > forcing a cgroup policy on everything. Okay, perhaps systemd is the > > > first program to actually *use* cgroups but if at some point in the > > > future you want to play around with it, well ... sorry. systemd is > > > in control there. Also, just for fun, my comment on cgroups is that they were just fine and working great well before systemd. Systemd forces everything to be potentially managed by cgroups (ie.. systemd is process ID 1). So, some would say this is better & easier. Me? I preferred the method of dorking with the cgconfig, cgcreate, cgset, and raw control interfaces where needed in /sys. That works great for /proc and the utilities that use it. I don't need systemd to mitigate this process for me (and I don't like it). Zero of the benefits of cgroups are tied directly to systemd (but boy, don't ask the systemd guys to admit that), nor do they need to be, nor is it impossible to put init under cgroups control (in fact it's quite easy). Putting an abstraction layer around something means that someone who's an "expert" now has to learn the abstraction layer AND the actual tool. Having now done both, I at least feel comfortable stating my position. > Which also affects something which i'm working with now namely cfengine, > cgroup's requires cfengine's performer cf-agent if it wan't to rerun > cf-serverd (the policy file server in cfengine, but cf-serverd has other > usage too) to start cf-serverd via systemctl enable/start. Yep, so you end up having to bifurcate your unit files, write scripts, or some other "ugly" method (ugly in the eyes of systemd folks) that systemd didn't really factor into reality before rolling out. > GNOME's adoption of systemd helps a bit. They've adopted each other. I, for one, always hated GNOME anyway, (as Liam suspected). Birds of a feather sure flocked together in this case. However, that's a good thing. I like when things I dislike clump together. It makes them easier to avoid. > It isn't good enough if the host is an virtual machine on esv4, that > really requires something which can handle clock drift in a sane way ie > ntpd. Well, some of the freakout is over the fact that parts of NTP are some magical stuff and the maintainer is attempting to bow out. However, it doesn't detract from your very valid point. > One functionality of questionable (or not so much) functionality is the > hails and whistles socket activation. IN the cause of NFS it would > require a new network protocol. Well, it wouldn't surprise me if Lennart just plunged ahead and wrote a new protocol (as long as it only works on Linux and has plenty of suck). The guy isn't short on energy. I'll give him that. > The CFengine developers has discussed using socket activation for > cf-serverd but it is really infeasible. As you know, the method for socket activation is completely different from inetd/xinetd and as you point out, requires devs to maintain *both* now, if they want to be relevant outside of Linux. > It would basically force them to maintain two completely different > cf-serverd implementations one for UNIX,systemd-less Linux and Windows > and one for systemd-ified Linux. Great example. So, we end up with a significant portion of the open source software world being forced into a choice they never signed on for. Do they focus on Linux and thus use extra cycles to create unit files and other systemd cruft or do they stick with init scripts and get "left behind" by folks who claim there is no problem whatsoever with using init scripts with systemd (yeah, they work, but it drives the systemd guys crazy). > Systemd-style socket activation in new applications/servers is an > possibility if a hard dependency on systemd is ok. Yep. It just creates more work for folks wanting to write really open software. Now they have to include extra crap for Linux users or face the wrath of the Potteringites and possible exclusion from all the distros who drank the whole bottle of systemd koolaid. Of course, they can always maintain both bits, and waste time they could be putting into their core software, but hey, it's "progress" right? Yah, I'm sure they won't mind. :-< -Swift
