Besides being a multi-role-somewhat-messy-blob, what are the grief points of systemd in 2018?
Edit: carified the question.
My biggest personal grievance is how it handles DNS or rather how unpredictable and undocumented the process is. If everything fails, e.g., they actually hard coded usage of 8.8.8.8. Not sure if that’s still there or configurable. The handling of actual security reports and CVEs is rather bad and you can see many examples of that on Github.
I’m not anti systemd and overall I welcome lots of contributions Lennard made in the past (pulseaudio, e.g.). With systemd it’s just too much functionality in one place. Do we really need an NTP alternative in systemd?
We'd really like to revive it, as there is demand for a lighter NTP client.
BTW, how can I contribute? I might get interested if I have time.
administration differences is the most direct effect of systemd, but after learning its various compatibility layers and watchdog functions, it can be tamed to a great helper.
not being designed according to UNIX principles (composition of single-role small applications, which are doing their jobs very very well) is also bothering me, but we need to be pragmatic here. inter-process-communication cannot replace in-memory-communication in all cases it seems.
The hate towards the developer(s) is stemming from his attitude, history (he's also developer of pulseaudio IIRC) and somewhat from his coding style. It seems like he's a kind of guy who can defend his work, do this in an unorthodox way, make it work and got it accepted. At the end of the day, the hate is a feeling and is personal. I think we need to be pragmatic here too. Not that better communication from both parties will benefit everyone and everything in the long run.
At the end of the day, we are using systemd, and it's working. If we want a better system, we need to improve it. systemd is the state of the art right now, and we should either write something better or improve it if we have any beef with systemd itself.
OTOH, Beef with developers is something that should stay out of software and community in general.
My original comment was trying to explore whether there are more reasons to dislike it besides the original points that I stated above.
It's both a negative and a positive. It's a change for sure but nowadays I can log into an ArchLinux, Fedora, Ubuntu, Debian,... machine and just leverage systemd instead of whatever local idiom (and its various assorted corner-cases) the distro decided to use. It's becoming the happy path of the XKCD comic about standards.
I also like the loginctl and service auto-recovery functions TBH.
It's also not 'the unix way' to have tightly bound, large blobs, and the team behind it seemed to take pains to say that lots of other things would rely on it, like udev, so there really was no choice.
So the hate comes from the idealogical side, largely.
Personally, having worked with it, I've rather liked writing service files and timers to get stuff done, it's much quicker to get something up and running than the old system.
It wasn't just a feeling, it really was just like that. Had the architecture of Systemd been different, it would have been possible to decouple it from other components and be able too choose an init system just like in the not so distant past. As it is now, practically speaking there is no choice.
Over time, the number of packages that do will fall, because engineer convenience and cognitive bandwidth are incredibly high priorities; "that's the crusty old way while this is the new hotness"; and, "oh, but we need this one little thing systemd offers," &c.
And before you know it, those of us on the ops side are stuck supporting something we loathe, and having to rewrite a bunch of scripting and tooling in response to discovering new and exciting ways the "new hotness" ends up breaking things that worked perfectly well until it came along.
Literally, we're facing another iteration of that very cycle right now: our non-production environment refresh process suddenly fails to complete without being manually thumped at multiple points. Why? System fucking d.
But no: "It works fine for us, so it can't be a problem for anyone else, right? Right?"
However, dividing teams into developers and (Dev)Ops sides like warring factions is not healthy. I'm also an ops guy (more precisely a sysadmin who supports a lot of users and servers) in my day job, and a I develop stuff for academic world and for my own pleasure in my free time, so I know both sides of the so-called moat.
Using features because they're hot is not also OK for any application, but not using features which can solve real problems is unwise in my book. We also had hacks which were working perfectly fine until systemd came. We evolved, changed how we do things and moved along.
> "It works fine for us, so it can't be a problem for anyone else, right? Right?"
I didn't want to tell or imply anything resembling this. I just gave my own opinion, based on my experience.
The thing that many people don't understand about systemd is that they don't have to sell to users or developers, they have to sell to (and design for) distributors. Lennart and Kay know that because they are both working for distributors (Redhat and Suse, respectively).
To distributors, the promise of systemd is the promise of less integration work. It paves over a ton of useless idiosyncracies in distributions (e.g. compare systemd's /etc/os-release with the previous /etc/*-release files that you cannot even call by name because they were called something else on each distribution). Initscripts is the biggest bullet point in that list: Initscripts were always written by the distribution because each distribution had their own scripting layer on top of sysvinit to make it a bit nicer, and each of these was incompatible with those of other distributions. Systemd units, on the other hand, can be maintained by the application developers themselves, and several distros (e.g. the patch-hating Arch Linux) actively pushes systemd units upstream.
When the application developer takes care and has only one target (the de-facto standards forced by systemd), life gets a whole lot easier for distributors. And that's why distributors choose systemd.
[0] https://people.debian.org/~stapelberg/2013/05/27/systemd-sur...
SystemD caused problems at the time and there was no reason not to postpone the decision to Jessie+1, which is what Debian usually does in such cases: "more discussion needed".
Debian broke their social contract, showing that their priority was no longer with their users.
I didn't know that. I thought the poll was open to anyone to vote for the relevant time window.
> Debian broke their social contract, showing that their priority was no longer with their users.
Isn't this a little bold claim? AFAICS, the poll has spotted the potential problems and general grievances pretty well (like binary logs, etc.), and concluded that these reservations should be addressed before systemd has included in Debian?
I'm not trying to defend systemd here. As I said in my comments, I disliked it first, and then I learnt and got used to it. My teammates has shown bigger reactions to it, and then they liked it too, after we configured it to behave the way we like. I didn't migrate to systemd voluntarily. It fell from above on me in a pretty hard way.
There was a whole Hoo-Hah. It was years long. People resigned over it. The votes and discussions are often misrepresented by people recounting the tale. (Common misrepresentations: presenting it as a two-way contest between van Smoorenburg init+rc and systemd, when OpenRC and Upstart were both included, and both favoured over van Smoorenburg init+rc; presenting it as a single vote when there were several, including some votes on Debian General Resolutions by all of the club members; presenting the wiki pages written by the partisans and ignoring the lengthy technical reports from the TC members.)
During this period, I was a developer and so-called tech lead of a Debian derivative distro. We were working on some absurd requirement about generating system responses on some events, pulling continuous all-nighters. One day systemd packages arrived to Debian (sid or testing, I don't remember), and using it solved our problem. This is how I became aware that Debian packaged systemd, and it's gonna be the next default init, that's all.
As I said before, I don't blindly support systemd or anything. I'm just using Debian for 14 years or so, and I'm riding on what comes along. I don't have time to devote serious development time to them, however I wish I was able to contribute into Debian or any serious FOSS project. Hmprhf.
Systemd has not given me any trouble, yet, but I run Void in a VM, and it boots extremely fast.
[1] I believe one can also use different init systems on Gentoo, after all it is Gentoo, but I have not touched it in years, so I do not know for sure.
Yes, it feels awkward at first, but systemd's behavior is not wrong.
edit: oh, downvoted, OK. This is actually an outcome of rule of silence, which is part of the UNIX philosophy [0].
[0]: https://en.wikipedia.org/wiki/Unix_philosophy#Rule_of_Silenc...
otherwise i don't care what's under the hood.
[1] https://www.reddit.com/r/linux/comments/2nhkx9/freebsds_jord...
Personally, I never found startup time to be much of a problem, on any OS. But having an init system that automatically restarts crashed services and is able to properly shutdown services including any child process they might have spawned sounds nice.
One thing I do like a lot about the BSD init system is that the interface is a text file with a simple format. I hope when they replace good old rc, they keep the interface as simple as that.
Well, start up problem is a matter of convenience, it's not a fatal problem, but I just like that my laptop with arch+systemd+systemd-boot starts instantly (3 seconds + 6 seconds for firmware), while bsd on my other laptop starts soo damn slow. (btw slow shutdown pisses me off even more)
Though the real issues with rc are much more serious, and eloquently described here (aka you don't have proper login management, service management, device and policy management, and better in a unified way):
* https://lists.debian.org/debian-user/2018/11/msg00616.html
So let me rephrase my statement, I hope that if they replace the good _new_ rc, they keep the interface as simple. For all I care, it would not have to be exactly the same, but I sure hope it stays as simple. The fact that on FreeBSD, I just need to look at a single text file with an easy-to-read-and-edit format to see what is going on, is one of FreeBSD's greatest virtues, IMHO.