4 ms·

Drawing a clear line is difficult, and the fact that many people are enraged with systemd for the opposite reason (systemd is too desktop-oriented, it has no pl

Drawing a clear line is difficult, and the fact that many people are enraged with systemd for the opposite reason (systemd is too desktop-oriented, it has no place on servers) just proves that systemd does a lot to cater for different use cases (which in some case may even overlap), but I guess some features that may be useful in cloud settings are: * service lifetime tracking, restarting them if they go down * lots of resources-tracking knobs thanks to cgroups * support for read-only root filesystem * strong integration with containers: http://0pointer.net/blog/systemd-for-administrators-part-xxi.html * many batteries included (no need to ship ntp on VMs thanks timesyncd, journald can replace syslogd for basic usage, networkd tries to do the right thing without any manual setup when run in a VM, etc.) I'm sure there are more, these are just the few ones I could think off the top of my head.

digi_owl 12y ago
I think part of the "desktop orientation" compliant is because of the heavy reliance on dbus as the signaling path between the various sub-daemons.
- EmanueleAina 12y ago
  Probably. That said, other than having "desktop" in the name, D-Bus is just a nice IPC system and inventing yet-another-IPC systems would have been worse (not counting kdbus as a new IPC system but rather an evolution of D-Bus).
  - felixgallo 12y ago
    wait, you're saying that inventing D-Bus rather than using existing IPC systems would have been better than inventing yet another IPC system?
    - EmanueleAina 12y ago
      D-Bus replaced CORBA in GNOME by improving the IPC system originally used by KDE, DCOP. Unless you're a CORBA aficionado, yes, I'm glad D-Bus exist. If you feel that D-Bus duplicates existing functionality can you please elaborate?
    - XorNot 12y ago
      Have you used CORBA? Replacing CORBA with anything else was a good decision for everyone.
cthalupa 12y ago
>lots of resources-tracking knobs thanks to cgroups I'm already tracking these at the orchestration level. I don't need my init system to do it. >support for read-only root filesystem Nice, I guess, but not sure why it's a particular win for cloud. My stuff is already stateless by design. I don't care if anything gets written to the root volume or not, since it will go away when the stateless vm goes away anyway >many batteries included (no need to ship ntp on VMs thanks timesyncd, journald can replace syslogd for basic usage, networkd tries to do the right thing without any manual setup when run in a VM, etc. Well, I could strip out NTP thanks to the systemd SNTP client, but I could also just use NTP and not use the systemd SNTP. The ephemeral nature of cloud makes journald absolutely useless, unless you just don't care about logs. (Why don't you care about logs?) Restarting services, containers, and networkd are nice, but I think the other stuff is probably reaching in a lot of ways.

digi_owl 12y ago

I think part of the "desktop orientation" compliant is because of the heavy reliance on dbus as the signaling path between the various sub-daemons.

EmanueleAina 12y ago
Probably. That said, other than having "desktop" in the name, D-Bus is just a nice IPC system and inventing yet-another-IPC systems would have been worse (not counting kdbus as a new IPC system but rather an evolution of D-Bus).
- felixgallo 12y ago
  wait, you're saying that inventing D-Bus rather than using existing IPC systems would have been better than inventing yet another IPC system?
  - EmanueleAina 12y ago
    D-Bus replaced CORBA in GNOME by improving the IPC system originally used by KDE, DCOP. Unless you're a CORBA aficionado, yes, I'm glad D-Bus exist. If you feel that D-Bus duplicates existing functionality can you please elaborate?
  - XorNot 12y ago
    Have you used CORBA? Replacing CORBA with anything else was a good decision for everyone.

cthalupa 12y ago

>lots of resources-tracking knobs thanks to cgroups I'm already tracking these at the orchestration level. I don't need my init system to do it. >support for read-only root filesystem Nice, I guess, but not sure why it's a particular win for cloud. My stuff is already stateless by design. I don't care if anything gets written to the root volume or not, since it will go away when the stateless vm goes away anyway >many batteries included (no need to ship ntp on VMs thanks timesyncd, journald can replace syslogd for basic usage, networkd tries to do the right thing without any manual setup when run in a VM, etc. Well, I could strip out NTP thanks to the systemd SNTP client, but I could also just use NTP and not use the systemd SNTP. The ephemeral nature of cloud makes journald absolutely useless, unless you just don't care about logs. (Why don't you care about logs?) Restarting services, containers, and networkd are nice, but I think the other stuff is probably reaching in a lot of ways.