3 ms·
The number of binaries isn't in and of itself a good measure. It says nothing about the tight coupling and poorly documented interfaces which tie them all toge
by rleigh 8y ago
The number of binaries isn't in and of itself a good measure. It says nothing about the tight coupling and poorly documented interfaces which tie them all together.
There are two major things to consider here:
- how easy is it to replace each of these with an independent third-party implementation
- if it is possible, why should the design of that component be dictated by the systemd upstream
A huge amount of the value of Linux was the fact that the system was a loosely-coupled collection of parts. Much of that flexibility has been lost, and with it the utility which drove a lot of the adoption of Linux in the first place.
- theamk 8y agoRe "how easy is it to replace each of these with an independent third-party implementation" What did you have in mind when you were talking about hard-to-replace implementation? I find the replacing all those components to be pretty easy. Those things are all loaded via regular unit files, and they need just one symlink to be completely disabled. In particular, systemd-networkd is entirely optional, and ifupdown is still supported in ubuntu (even if not installed by default). systemd-timesyncd is a regular service, and can be disabled directly, or via timedatectl. ntpdate still works when it is disabled. Many other services, like systemd-hostnamed, do not even run by default. You could disabled them by default and things would still work. The worst offender is probably systemd-logind, but luckily I did not have to deal with it. Looks like it only needed for GUI logins, not ssh one -- so most sysadmins would not have to care. That said, I did try to use it's predecessor, ConsoleKit, and it was pretty horrible as well.