3 ms·

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 tha

by marios 10y ago

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.

notalaser 10y ago
> 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.

by marios 10y ago

notalaser 10y ago

> 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.