I would be shocked. As I mentioned above, I wouldn't expect wireshark to run either. From what we gathered so far, this is a syscall translation layer and
> No new system calls are added for cgroups - all support for querying and modifying cgroups is via this cgroup file system.
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.
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.
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.
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.
Microsoft hasn't announced this (yet), but syscall translation seems to be really well positioned for their container push. I fully expect that MS will announce Linux containers running on Windows Server using WSL. Already the perf is there.
> No new system calls are added for cgroups - all support for querying and modifying cgroups is via this cgroup file system.
Per https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.t...