5 ms·

Well, that's a lot of text to read. My (high-level) thoughts as a systemd user for 10 years is that it improved some things, made a few things worse, but I woul

Well, that's a lot of text to read. My (high-level) thoughts as a systemd user for 10 years is that it improved some things, made a few things worse, but I would not want to go back to the init.d days. Having a daemon around to manage the lifecycle of services is actually a good idea and most of the *ctl programs are preferable to the manual configuring they replace.

CameronNemo 6y ago
I think one of the more interesting takeaways is that Lennart and Kay set out to accomplish some specific goals: - universal IPC-based activation of services - kdbus with systemd being the userspace management layer for that - single writer group hierarchy with systemd being the single writer And that these goals have not (yet) been realized. My perspective is that: - socket activation was never that useful to begin with and complicates the build process for lots of services. - kdbus could have been something real, but Lennart and Kay were unwilling to compromise and listen to the kernel devs criticisms. They tried to sidestep the network maintainer by making it a character device, but forgot they did not have the clout that Google/Android does that allowed binder to get pushed through. - systemd turned out to be the worst container runtime on the market (systemd the supervisor is fundamentally that, a container runtime) and having all cgroup operations flow through its opinionated dbus api was simply unacceptable for docker, kubernetes, lxc, runc, and everybody else maintaining quality container runtimes. So many of these goals will never come to fruition. What systemd excels at is being a dependency based service supervisor with an opinionated and half functional logging layer.
- JoshTriplett 6y ago
  > - socket activation was never that useful to begin with and complicates the build process for lots of services. One thing people often don't realize: socket activation wasn't just about simplifying daemons (though it does simplify writing daemons if you don't have to deal with the non-activation case). It was also about simplifying the boot process. There exist many different system boot configurations that are difficult to express in terms of dependencies between services; for instance, depending on your particular system configuration, you might need to launch two services in different orders, because in one configuration service A will depend on service B, and in another configuration service B will depend on service A. Socket activation means you can launch the two services simultaneously, and they'll have access to each others' sockets.
  - CameronNemo 6y ago
    Do you have an example of such cross-dependent services?
- bonzini 6y ago
  I am not sure about socket activation, I myself have seen it added to two programs I maintain, because there was actually someone requesting it. I also have used it a few times in inetd mode, to configure network services (even sshd runs like this on my laptop) entirely within systemd.
- cycloptic 6y ago
  >having all cgroup operations flow through its opinionated dbus api was simply unacceptable for docker, kubernetes, lxc, runc, and everybody else maintaining quality container runtimes. I think you're off-base on this. Work is being done to get support for cgroupsv2 in all the major container runtimes. Source: https://medium.com/nttlabs/cgroup-v2-596d035be4d7 https://medium.com/nttlabs/cgroup-v2-596d035be4d7 In any case single-writer was not an explicit goal of systemd, it was an intentional design decision that came from the kernel. TFA even mentions this, although it is somewhat lost within the pages of ranting. You also don't even have to use systemd's D-Bus APIs to deal with this. Container managers can if they want to provide additional integrations. Source: https://systemd.io/CGROUP_DELEGATION/ https://systemd.io/CGROUP_DELEGATION/
  - CameronNemo 6y ago
    >Work is being done to get support for cgroupsv2 in all the major container runtimes. That work is done for LXC. It does not go through systemd's dbus api.
    - cycloptic 6y ago
      Yes, that was the point of my second paragraph. It doesn't have to. The systemd d-bus api is only if you want your containers to show up in systemd as well. From the perspective of a container manager, all you have is your own little hierarchy sitting somewhere in the tree, the parent leaf is not particularly important. This distinction is relevant for ANY combination of container managers under cgroupsv2, for example if you try to run it multiple levels deep (systemd within an lxc container within a docker container or something like that). The situation with LXC is basically the same anyway. You just dump your containers in a sub-hierarchy and if you decide you want to integrate further with that, you have to use liblxc. It's funny that systemd still for some reason gets these long rants directed at it though.
- ColanR 6y ago
  Lennart had other stated goals besides what you laid out there. Below is from the systemd-devel mailing list in 2010. [1] "Well, it is definitely our intention to gently push the distributions in the same direction so that they stop supporting deviating solutions for these things where there's really no point at all in doing so. "Due to that our plan is to enable all this by default in "make install". Packagers may then choose to disable it by doing an "rm" after the "make install", but we want to put the burden on the packagers, so that eventually we end up with the same base system on all distributions, and we put an end to senseless configuration differences between the distros for the really basic stuff. "If a distro decides that for example the random seed save/restore is not good enough for it, then it's their own job to disable ours and plug in their own instead. Sooner or later they'll hopefully notice that it's not worth it and cross-distro unification is worth more." [1] https://lists.freedesktop.org/archives/systemd-devel/2010-September/000391.html https://lists.freedesktop.org/archives/systemd-devel/2010-Se...
  - CameronNemo 6y ago
    Sure, but all that could have happened without systemd too. The big radical changes were what mostly fell flat.
    - ColanR 6y ago
      I don't think there's anything 'falling flat' about their big radical changes, because they aren't pushing them through via big radical changes. They're simply making it more and more difficult with the thousand-pinpricks approach to deviate from the systemd defaults. I don't think there's any evidence to indicate linux was doing anything but becoming more fragmented. Which was a good thing for diversity of thought, and the ability to evolve better designs. Here, Lennart explicity stated he was using non-overt methods to force cohesion in a non-organic fashion, which to me indicates he valued his design over good design.
      - cycloptic 6y ago
        >They're simply making it more and more difficult with the thousand-pinpricks approach to deviate from the systemd defaults. I don't know what you mean by this. Even on systemd systems you can still install all your old tools and sidestep the systemd approach. >[fragmentation] .... was a good thing for diversity of thought, and the ability to evolve better designs. Here, Lennart explicity stated he was using non-overt methods to force cohesion in a non-organic fashion, which to me indicates he valued his design over good design. I didn't get that at all, the post you linked explicitly mentioned discouraging distros that deviate from the base setup for senseless reasons. You can see why this approach has caught on with distro maintainers, their job has been stuffing square pegs into round holes from the beginning. The idea of fragmentation just for the sake of fragmentation was never popular there.
- throw0101a 6y ago
  > ... opinionated and half functional logging layer. And I still have to to run rsyslog to send things off-machine to a centralized logging server.
sansnomme 6y ago
Well, had Microsoft hopped on to the extend & embrace wagon for Linux earlier they could have open sourced Registry and Sysinternals. Probably would have taken the place of Systemd. It took them too long to open source PowerShell and now they are playing catch up with Ubuntu and Red Hat.

CameronNemo 6y ago

I think one of the more interesting takeaways is that Lennart and Kay set out to accomplish some specific goals: - universal IPC-based activation of services - kdbus with systemd being the userspace management layer for that - single writer group hierarchy with systemd being the single writer And that these goals have not (yet) been realized. My perspective is that: - socket activation was never that useful to begin with and complicates the build process for lots of services. - kdbus could have been something real, but Lennart and Kay were unwilling to compromise and listen to the kernel devs criticisms. They tried to sidestep the network maintainer by making it a character device, but forgot they did not have the clout that Google/Android does that allowed binder to get pushed through. - systemd turned out to be the worst container runtime on the market (systemd the supervisor is fundamentally that, a container runtime) and having all cgroup operations flow through its opinionated dbus api was simply unacceptable for docker, kubernetes, lxc, runc, and everybody else maintaining quality container runtimes. So many of these goals will never come to fruition. What systemd excels at is being a dependency based service supervisor with an opinionated and half functional logging layer.

JoshTriplett 6y ago
> - socket activation was never that useful to begin with and complicates the build process for lots of services. One thing people often don't realize: socket activation wasn't just about simplifying daemons (though it does simplify writing daemons if you don't have to deal with the non-activation case). It was also about simplifying the boot process. There exist many different system boot configurations that are difficult to express in terms of dependencies between services; for instance, depending on your particular system configuration, you might need to launch two services in different orders, because in one configuration service A will depend on service B, and in another configuration service B will depend on service A. Socket activation means you can launch the two services simultaneously, and they'll have access to each others' sockets.
- CameronNemo 6y ago
  Do you have an example of such cross-dependent services?
bonzini 6y ago
I am not sure about socket activation, I myself have seen it added to two programs I maintain, because there was actually someone requesting it. I also have used it a few times in inetd mode, to configure network services (even sshd runs like this on my laptop) entirely within systemd.
cycloptic 6y ago
>having all cgroup operations flow through its opinionated dbus api was simply unacceptable for docker, kubernetes, lxc, runc, and everybody else maintaining quality container runtimes. I think you're off-base on this. Work is being done to get support for cgroupsv2 in all the major container runtimes. Source: https://medium.com/nttlabs/cgroup-v2-596d035be4d7 https://medium.com/nttlabs/cgroup-v2-596d035be4d7 In any case single-writer was not an explicit goal of systemd, it was an intentional design decision that came from the kernel. TFA even mentions this, although it is somewhat lost within the pages of ranting. You also don't even have to use systemd's D-Bus APIs to deal with this. Container managers can if they want to provide additional integrations. Source: https://systemd.io/CGROUP_DELEGATION/ https://systemd.io/CGROUP_DELEGATION/
- CameronNemo 6y ago
  >Work is being done to get support for cgroupsv2 in all the major container runtimes. That work is done for LXC. It does not go through systemd's dbus api.
  - cycloptic 6y ago
    Yes, that was the point of my second paragraph. It doesn't have to. The systemd d-bus api is only if you want your containers to show up in systemd as well. From the perspective of a container manager, all you have is your own little hierarchy sitting somewhere in the tree, the parent leaf is not particularly important. This distinction is relevant for ANY combination of container managers under cgroupsv2, for example if you try to run it multiple levels deep (systemd within an lxc container within a docker container or something like that). The situation with LXC is basically the same anyway. You just dump your containers in a sub-hierarchy and if you decide you want to integrate further with that, you have to use liblxc. It's funny that systemd still for some reason gets these long rants directed at it though.
ColanR 6y ago
Lennart had other stated goals besides what you laid out there. Below is from the systemd-devel mailing list in 2010. [1] "Well, it is definitely our intention to gently push the distributions in the same direction so that they stop supporting deviating solutions for these things where there's really no point at all in doing so. "Due to that our plan is to enable all this by default in "make install". Packagers may then choose to disable it by doing an "rm" after the "make install", but we want to put the burden on the packagers, so that eventually we end up with the same base system on all distributions, and we put an end to senseless configuration differences between the distros for the really basic stuff. "If a distro decides that for example the random seed save/restore is not good enough for it, then it's their own job to disable ours and plug in their own instead. Sooner or later they'll hopefully notice that it's not worth it and cross-distro unification is worth more." [1] https://lists.freedesktop.org/archives/systemd-devel/2010-September/000391.html https://lists.freedesktop.org/archives/systemd-devel/2010-Se...
- CameronNemo 6y ago
  Sure, but all that could have happened without systemd too. The big radical changes were what mostly fell flat.
  - ColanR 6y ago
    I don't think there's anything 'falling flat' about their big radical changes, because they aren't pushing them through via big radical changes. They're simply making it more and more difficult with the thousand-pinpricks approach to deviate from the systemd defaults. I don't think there's any evidence to indicate linux was doing anything but becoming more fragmented. Which was a good thing for diversity of thought, and the ability to evolve better designs. Here, Lennart explicity stated he was using non-overt methods to force cohesion in a non-organic fashion, which to me indicates he valued his design over good design.
    - cycloptic 6y ago
      >They're simply making it more and more difficult with the thousand-pinpricks approach to deviate from the systemd defaults. I don't know what you mean by this. Even on systemd systems you can still install all your old tools and sidestep the systemd approach. >[fragmentation] .... was a good thing for diversity of thought, and the ability to evolve better designs. Here, Lennart explicity stated he was using non-overt methods to force cohesion in a non-organic fashion, which to me indicates he valued his design over good design. I didn't get that at all, the post you linked explicitly mentioned discouraging distros that deviate from the base setup for senseless reasons. You can see why this approach has caught on with distro maintainers, their job has been stuffing square pegs into round holes from the beginning. The idea of fragmentation just for the sake of fragmentation was never popular there.
throw0101a 6y ago
> ... opinionated and half functional logging layer. And I still have to to run rsyslog to send things off-machine to a centralized logging server.

sansnomme 6y ago

Well, had Microsoft hopped on to the extend & embrace wagon for Linux earlier they could have open sourced Registry and Sysinternals. Probably would have taken the place of Systemd. It took them too long to open source PowerShell and now they are playing catch up with Ubuntu and Red Hat.