Hacker News new | past | comments | ask | show | jobs | submit login

My answer is going to be very skewed towards what I do (embedded systems), but:

- It offers a single, easily-configurable way to define startup tasks, issue various system-level commands (shutdown, suspend etc.), which is immensely helpful when you write a daemon that has to write on a dozen different targets. The official story is that SysV was nice and easy because it was just a shell script and we loved that. Truth is, writing startup scripts was a heart-wrenching adventure in figuring out the subtle differences between distributions. Systemd's solution is not better, IMHO, but it is certainly far, far easier...

* ...which is a big deal when, now that Linux is suddenly the next big thing (especially in make-belief markets like IoT), you have to suddenly convert swarms of Android and Windows programmers to Linux programmers. Especially on platforms where there's a lot of integration and packing work to do (which often gets outsourced to someplace where programmers are cheap and super-specialized), this is useful, because it's a lot easier to teach people to write systemd service files than it is to teach them to write shell scripts.

* Having a unified system for virtually every system-level task reduces the surface on which your customers can exercise their creativity, which reduces support costs.

* For companies that write Linux software, as opposed to "just" integrating it, having a standardized system for virtually every system-level task means that, as long as you stick to using that interface, your software is going to run on whatever distribution or platform you deploy it on. Historically, this was problematic on Linux, as every distro did its subtly different thing and, consequently, you had to test on every distro.

Edit: just to be clear -- these are all good things. My beef with systemd is related to its community's attitude towards reliability and bugs, the abysmal documentation that surrounds not just systemd, but its entire entourage (like D-Bus), its developers' lack of concern for anything that is not systemd or Gnome and runs on something other than their laptops, and the aggressive PR around it, the result of which is that a) now there's a bunch of systemd bigots who keep trying to push it into everything, even where it doesn't belongs, and b) there's another bunch of anti-systemd bigots who insist it's the doom but won't code a damn line to give us something else, and I have to keep explaining why systemd is OK sometimes.




Just one nit about "SysV was nice and easy because it was just a shell script and we loved that". The design behind SysV init was nice and easy and we loved that (i.e.: init is started by the kernel, it starts the scripts that bring the rest of the system up, and after that it takes care of reaping zombies). The init scripts used in Debian (picking that as an example as it's the Linux distro I am most familiar with) were horrible.

Not one or two, all of them. Writing an initscript started with copying the template from /etc/skel, and it was already pretty long. Compare that with the actual init scripts from FreeBSD/OpenBSD. Some are literally 3 lines long.

My issue with systemd is that there is no clearly defined scope. It started as a "SysV init replacement", which it clearly isn't. SysV is an init system, while systemd is more of a service manager that can also run as a system's init. When comparing the two, or even systemd vs {upstart, nosh, you name it} what are we even trying to compare ? systemd does init, service restart, tracks user's process and sessions, manages your network (systemd-network), your logs (systemd-journald), your devices (systemd-udevd), how your system syncs time (systemd-timesyncd) and I'll stop here because the list is long. IMO, it does too many things and it appears the various components are rather tightly coupled.

Others have mentioned the code quality; I can't comment because I haven't looked at the code. One thing that really bothers me though, is the tight coupling with dbus. It doesn't matter how good the systemd-* code is, if dbus is borked then your whole system goes down with it. I can debug a misbehaving init script by starting it with sh -x. With dbus, it's a nightmare.


> Not one or two, all of them. Writing an initscript started with copying the template from /etc/skel, and it was already pretty long. Compare that with the actual init scripts from FreeBSD/OpenBSD. Some are literally 3 lines long.

Unfortunately, a lot of the BSD wisdom is lost on people who try OpenBSD on their laptops, can't figure out how to connect to wifi without NetworkManager or wpa_supplicant, and automatically conclude it's arcane shit from another age. Clean init management is just one of the lessons that Linux could learn from there.

> Others have mentioned the code quality; I can't comment because I haven't looked at the code. One thing that really bothers me though, is the tight coupling with dbus. It doesn't matter how good the systemd-* code is, if dbus is borked then your whole system goes down with it. I can debug a misbehaving init script by starting it with sh -x. With dbus, it's a nightmare.

I've read the systemd source code here and there. At line level, the code is actually pretty good, idiomatic and clean. I don't remember seeing any obvious blunders.

Engineering-wise, I've seen better. The lack of a serious debugging infrastructure is just one of them, and that plagues pretty much any D-Bus application, not just systemd. A lot of features are gratuitous/unneeded, exist just because the developers couldn't bother to read documentation or didn't like the defaults of some tool so they wrapped it in a systemd interface, or simply because of Gnome.

Then again, a lot of things are badly-engineered and we run them. The only thing I very strongly dislike is the deployment/distribution model. It's a huge suite of tools of massive complexity; at any given time, for any given version, at least one of them is basically of beta-level quality, which means that, for any version N, you end up knowing at least one or two workarounds for a set of bugs. Then N+1 pops up. The old bugs are resolved, but now two other tools have been added, another one has been rewritten because reasons, and now there's a new generation of bugs that you have to learn and remember. The fun grows exponentially with the number of platforms that you need to support; I now know about, like, more than a dozen systemd bugs across five versions, because I have to support targets that use five different versions. I'm a walking bug tracker at this moment.

Edit: I know this is technically "the distributions' fault", but sometimes you don't quite have a choice, e.g. when working with whatever SDKs a manufacturer provides, or when dealing with systems where upgrades are difficult and infrequent for various reasons (regulatory, remote access etc.). Devops is not the answer to everything.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: