3 ms·

I think in both cases, there's a similar switch of philosophy. We went from "there are a bunch of components glued together, and with enough glue you can solve

I think in both cases, there's a similar switch of philosophy. We went from "there are a bunch of components glued together, and with enough glue you can solve anything (except an excess of glue)" (shell scripts for sysvinit vs declarative unit files for systemd; X11 apps that can do almost anything, vs the privileged compositor for wayland), to a model of "we wanted things to just work without having to install glue, so we integrated more functionality people wanted, if you want to swap it out you have to swap out the whole thing and keep up enough with all the other features people want" (e.g. you have to actually get the things you want into unit file directives, or get the features you want into the compositors people use; or you have to build a completely separate compositor or a separate init). That's a tradeoff. For my part, I'm thrilled that so many more things just work out of the box; however, it's discouraging for people whose features aren't covered yet, since they have to go work on integration rather than writing a specialized tool and encouraging people to glue that tool in. But the benefit of that is that once something is integrated, it just works, with no glue required.

WhatIsDukkha 4y ago
You are presenting this in certain way that I think veers into inaccurate and misleading in an attempt to smooth things over and be nice. What we had before systemd was - 90% glue code, reimplemented quite badly across X distributions. That glue code was, in practice, extremely brittle and very very unfun to attempt to keep even simple daemons running "portably" distribution to distribution. The other 10% was increasingly aging and ill maintained c code snippets. That was not a nice world for people actually using it. For people making stuff up about "the old days" that didn't actually participate in the misery of making basic systemv scripts, yeah it was composable and we lost something.
- zozbot234 4y ago
  The internals of systemd are just as brittle, and the model of unit file configuration does not really apply cleanly beyond the simplest cases. So editing unit files becomes an undocumented dark art.
  - dijit 4y ago
    Chiming in here to say that systemd seems to cover the 80% (or even 90%) case pretty nicely, however that last 10-20% is now really difficult. Anyone who has really delved into systemd knows this but they get shouted down as halting progress and hugging bash scripts, which is disingenuous as bash scripts (as per sysvinit) were painful and had great difficulties in areas such as determinism and parallel execution. If you ever want an example of what I mean: look at how systemd starts mysql. Someone (not me) spent at least a man month making that work. I do begrudge the all or nothing approach that systemd is taking (even if it claims to be modular), but I will admit openly: that 80% case is a lot nicer.
    - haileys 4y ago
      > If you ever want an example of what I mean: look at how systemd starts mysql. Someone (not me) spent at least a man month making that work. I was curious, so I cracked open the mariadb.service unit that ships with Arch Linux. Other distros might ship different unit definitions, but this is the one I'm looking at. It's large, yes, but very well commented and seems quite clear to me. Much of the complexity seems to be around sandboxing: PrivateNetwork, CapabilityBoundingSet, PrivateDevices, ReadWritePaths, ProtectHome, PrivateTmp. These are all settings to do with hardening the service. They're totally optional, and can be removed without impacting functionality. There is some extra complexity in the ExecStartPre and ExecStartPost commands. This appears to be something to do with the Galera cluster functionality. I'm not entirely sure what's happening with those, but I imagine these commands would also be present in a SysV init script implementing the same functionality. The rest is pretty standard stuff: the user/group is set, along with the umask and some ulimits. LD_PRELOAD is set to load jemalloc. There's also some start/stop timeouts configured, with a comment explaining that these same timeout values were used in the SysV init scripts in the past. Essentially, I'm not really sold that any of this complexity is caused by systemd. The hardening strikes me as a little unusual, and at a guess I'd say that this probably wouldn't be present in a SysV init script. If it were, the configuration would live in executable code, not in strictly declarative config directives.
    - dale_glass 4y ago
      This? https://gist.github.com/thomasfr/e4e4bb64352ee574334a https://gist.github.com/thomasfr/e4e4bb64352ee574334a I don't see anything out of the ordinary there.
- JoshTriplett 4y ago
  I was attempting to acknowledge, in good faith, that there are valid tradeoffs between models, even for folks who prefer one model over the other. I'm happy in the current model as well. But I also acknowledge what it traded off to get there.
yyyk 4y ago
X11 offers a lot of functionality on the server - a lot of it unused, but still. Wayland technically specifies little but the protocol. So here the philosophy switch is the other way around.

WhatIsDukkha 4y ago

You are presenting this in certain way that I think veers into inaccurate and misleading in an attempt to smooth things over and be nice. What we had before systemd was - 90% glue code, reimplemented quite badly across X distributions. That glue code was, in practice, extremely brittle and very very unfun to attempt to keep even simple daemons running "portably" distribution to distribution. The other 10% was increasingly aging and ill maintained c code snippets. That was not a nice world for people actually using it. For people making stuff up about "the old days" that didn't actually participate in the misery of making basic systemv scripts, yeah it was composable and we lost something.

zozbot234 4y ago
The internals of systemd are just as brittle, and the model of unit file configuration does not really apply cleanly beyond the simplest cases. So editing unit files becomes an undocumented dark art.
- dijit 4y ago
  Chiming in here to say that systemd seems to cover the 80% (or even 90%) case pretty nicely, however that last 10-20% is now really difficult. Anyone who has really delved into systemd knows this but they get shouted down as halting progress and hugging bash scripts, which is disingenuous as bash scripts (as per sysvinit) were painful and had great difficulties in areas such as determinism and parallel execution. If you ever want an example of what I mean: look at how systemd starts mysql. Someone (not me) spent at least a man month making that work. I do begrudge the all or nothing approach that systemd is taking (even if it claims to be modular), but I will admit openly: that 80% case is a lot nicer.
  - haileys 4y ago
    > If you ever want an example of what I mean: look at how systemd starts mysql. Someone (not me) spent at least a man month making that work. I was curious, so I cracked open the mariadb.service unit that ships with Arch Linux. Other distros might ship different unit definitions, but this is the one I'm looking at. It's large, yes, but very well commented and seems quite clear to me. Much of the complexity seems to be around sandboxing: PrivateNetwork, CapabilityBoundingSet, PrivateDevices, ReadWritePaths, ProtectHome, PrivateTmp. These are all settings to do with hardening the service. They're totally optional, and can be removed without impacting functionality. There is some extra complexity in the ExecStartPre and ExecStartPost commands. This appears to be something to do with the Galera cluster functionality. I'm not entirely sure what's happening with those, but I imagine these commands would also be present in a SysV init script implementing the same functionality. The rest is pretty standard stuff: the user/group is set, along with the umask and some ulimits. LD_PRELOAD is set to load jemalloc. There's also some start/stop timeouts configured, with a comment explaining that these same timeout values were used in the SysV init scripts in the past. Essentially, I'm not really sold that any of this complexity is caused by systemd. The hardening strikes me as a little unusual, and at a guess I'd say that this probably wouldn't be present in a SysV init script. If it were, the configuration would live in executable code, not in strictly declarative config directives.
  - dale_glass 4y ago
    This? https://gist.github.com/thomasfr/e4e4bb64352ee574334a https://gist.github.com/thomasfr/e4e4bb64352ee574334a I don't see anything out of the ordinary there.
JoshTriplett 4y ago
I was attempting to acknowledge, in good faith, that there are valid tradeoffs between models, even for folks who prefer one model over the other. I'm happy in the current model as well. But I also acknowledge what it traded off to get there.

yyyk 4y ago

X11 offers a lot of functionality on the server - a lot of it unused, but still. Wayland technically specifies little but the protocol. So here the philosophy switch is the other way around.