4 ms·

No cgroups = no systemd. Windows: a better linux than linux.

redpanda_ua 11y ago
I am a new-ish Linux user. Can someone explain to me why systemd is so bad? Is it because it monopolized so many features? So it's not UNIX way of tiny programs working together? I feel like I am missing something.
- girvo 11y ago
  You basically answered it yourself :) that's the typical argument, yeah. I personally really like systemd, and it's made our infrastructure at work easy to manage and deal with.
- digi_owl 11y ago
  Its complicated. Unix was built around the human readable output of one binary being the input of another. dbus, the carrier for much of the traffic between systemd parts, is far from human readable. Also, one reason they give for developing everything in a single blob of code is that they can then change the protocol as they see fit. This in turn makes it hard for third parties to replace a component, as they will constantly play catch up with the systemd developers. Take logind for example. It depends on systemd-init being there and handling cgroups. Consolekit, what logind replaced, could be used on top of any init. Gentoo forked udev into eudev after the former was merged with systemd, because it became a right pain to extract udev from the larger systemd code, even though at the time of merging it was promised that udev would still be usable separately. This because at every systemd release, the extraction process changed in some way or other. With the traditional unix tools i can probably pipe some output from a GNU binary into busybox into a BSD binary and get the expected result. And if i don't i can break down the chain into parts, look at what they produce, and make adaptions right there in the terminal. Anything similar for systemd will require a compiler and specialized tools for debugging dbus and whatsnot. Maybe all this is fine in a devops environment where everything is in containers or virtual machines. But Linux got where it is because it was not just flexible, but also field repairable thanks to its unix heritage.
JdeBP 11y ago
There are lots of reasons that systemd will probably never run on the Windows NT Linux subsystem, a few reasons that upstart won't run, and the possibility that one could run daemontools family toolsets with a fair degree of success; but a likely overall problem with invoking a service manager such that it is in a daemon context (outwith a login session) in the first place. * https://news.ycombinator.com/item?id=11416376 https://news.ycombinator.com/item?id=11416376
- kchoudhu 11y ago
  Very informative linked post. Would recommend everyone click through and read it!

I am a new-ish Linux user. Can someone explain to me why systemd is so bad? Is it because it monopolized so many features? So it's not UNIX way of tiny programs working together? I feel like I am missing something.

girvo 11y ago
You basically answered it yourself :) that's the typical argument, yeah. I personally really like systemd, and it's made our infrastructure at work easy to manage and deal with.
digi_owl 11y ago
Its complicated. Unix was built around the human readable output of one binary being the input of another. dbus, the carrier for much of the traffic between systemd parts, is far from human readable. Also, one reason they give for developing everything in a single blob of code is that they can then change the protocol as they see fit. This in turn makes it hard for third parties to replace a component, as they will constantly play catch up with the systemd developers. Take logind for example. It depends on systemd-init being there and handling cgroups. Consolekit, what logind replaced, could be used on top of any init. Gentoo forked udev into eudev after the former was merged with systemd, because it became a right pain to extract udev from the larger systemd code, even though at the time of merging it was promised that udev would still be usable separately. This because at every systemd release, the extraction process changed in some way or other. With the traditional unix tools i can probably pipe some output from a GNU binary into busybox into a BSD binary and get the expected result. And if i don't i can break down the chain into parts, look at what they produce, and make adaptions right there in the terminal. Anything similar for systemd will require a compiler and specialized tools for debugging dbus and whatsnot. Maybe all this is fine in a devops environment where everything is in containers or virtual machines. But Linux got where it is because it was not just flexible, but also field repairable thanks to its unix heritage.

JdeBP 11y ago

There are lots of reasons that systemd will probably never run on the Windows NT Linux subsystem, a few reasons that upstart won't run, and the possibility that one could run daemontools family toolsets with a fair degree of success; but a likely overall problem with invoking a service manager such that it is in a daemon context (outwith a login session) in the first place. * https://news.ycombinator.com/item?id=11416376 https://news.ycombinator.com/item?id=11416376

kchoudhu 11y ago
Very informative linked post. Would recommend everyone click through and read it!