5 ms·

Yeah, ideas and projects are often dismissed due to coming from the systemd group. For this very reason, I'm rather bothered that gummiboot was renamed into sy

Yeah, ideas and projects are often dismissed due to coming from the systemd group. For this very reason, I'm rather bothered that gummiboot was renamed into systemd-boot. It's a very simple, nice tool, that's usable in plenty of non-systemd environments... but the naming just makes it unpopular with the crowd that doesn't like systemd.

VancouverMan 5y ago
Considering the massive amount of unnecessary and unjustifiable trouble that so many people have experienced over the years with systemd and PulseAudio, it's no wonder people would distrust everything coming from the developers and proponents responsible for such software.
dogleash 5y ago
>usable in plenty of non-systemd environments That's really unfortunate naming then. Any systemd-foo that "works on it's own" is (rightly) assumed to be tightly coupled to the rest of the systemd ecosystem.
Beltalowda 5y ago
I didn't even realize you could use it outside of systemd. I never looked at it in detail, but if something is named systemd- then I think "part of the systemd suite and intended to be used with systemd" is a fairly reasonable assumption. I'd still be hesitant to use it to be honest, as systemd has on several occasions broke people's systems and the response was "you're holding your phone^H^H^H^H^H systemd wrong". Well, maybe, but you broke my system and before it was perfectly fine, and that's kind of an issue for me. Especially with something as critical as booting my system, I want to be able to just rely on it without breakage "because I was using it wrong". Linus' "we don't break userland"-policy was a great piece of insight. I wish systemd had a similar attitude. Some of the systemd criticism has gone off the rails (...and then some...), but there's a number of things one could reasonably criticize about the project and development style, IMHO.
- throw0101a 5y ago
  > I didn't even realize you could use it outside of systemd. I never looked at it in detail, but if something is named systemd- then I think "part of the systemd suite and intended to be used with systemd" is a fairly reasonable assumption. The tight coupling of systemD is a popular criticism of it.
  - rektide 5y ago
    And this is another fine case demonstrating how very very wrong that criticism is. All in all extremely few systemd subsystems require systemd. Systemd's pid1 requires only one subsystem, journald, which one can mostly disable/defang if they really dislike it. It's much more like a monorepo than monolith. There's standard practices & libraries between the projects- unit files, ability to ask for machine readible outputs, others. But these cross cutting concerns mostly get compiled in. The actual interdependencies between subsystems are few & far between. Feels like the critics dont really understand what they are trying to criticize.
    - CameronNemo 5y ago
      You say this, but systemd-udevd at one point would sigkill every process on the system if it was not started under systemd (or otherwise in its own cgroup).
      - throw0101a 5y ago
        And udevd used to be it's own stand-alone daemon which didn't need systemd at all, but for some reason it is now essentially tied to it. * https://en.wikipedia.org/wiki/Udev#History https://en.wikipedia.org/wiki/Udev#History * https://en.wikipedia.org/wiki/Eudev https://en.wikipedia.org/wiki/Eudev
    - throw0101a 5y ago
      So I can take systemd-timesyncd and run it on systemd-less Devuan or FreeBSD? systemd-resolved? systemd-networkd?

VancouverMan 5y ago

Considering the massive amount of unnecessary and unjustifiable trouble that so many people have experienced over the years with systemd and PulseAudio, it's no wonder people would distrust everything coming from the developers and proponents responsible for such software.

dogleash 5y ago

>usable in plenty of non-systemd environments That's really unfortunate naming then. Any systemd-foo that "works on it's own" is (rightly) assumed to be tightly coupled to the rest of the systemd ecosystem.

Beltalowda 5y ago

I didn't even realize you could use it outside of systemd. I never looked at it in detail, but if something is named systemd- then I think "part of the systemd suite and intended to be used with systemd" is a fairly reasonable assumption. I'd still be hesitant to use it to be honest, as systemd has on several occasions broke people's systems and the response was "you're holding your phone^H^H^H^H^H systemd wrong". Well, maybe, but you broke my system and before it was perfectly fine, and that's kind of an issue for me. Especially with something as critical as booting my system, I want to be able to just rely on it without breakage "because I was using it wrong". Linus' "we don't break userland"-policy was a great piece of insight. I wish systemd had a similar attitude. Some of the systemd criticism has gone off the rails (...and then some...), but there's a number of things one could reasonably criticize about the project and development style, IMHO.

throw0101a 5y ago
> I didn't even realize you could use it outside of systemd. I never looked at it in detail, but if something is named systemd- then I think "part of the systemd suite and intended to be used with systemd" is a fairly reasonable assumption. The tight coupling of systemD is a popular criticism of it.
- rektide 5y ago
  And this is another fine case demonstrating how very very wrong that criticism is. All in all extremely few systemd subsystems require systemd. Systemd's pid1 requires only one subsystem, journald, which one can mostly disable/defang if they really dislike it. It's much more like a monorepo than monolith. There's standard practices & libraries between the projects- unit files, ability to ask for machine readible outputs, others. But these cross cutting concerns mostly get compiled in. The actual interdependencies between subsystems are few & far between. Feels like the critics dont really understand what they are trying to criticize.
  - CameronNemo 5y ago
    You say this, but systemd-udevd at one point would sigkill every process on the system if it was not started under systemd (or otherwise in its own cgroup).
    - throw0101a 5y ago
      And udevd used to be it's own stand-alone daemon which didn't need systemd at all, but for some reason it is now essentially tied to it. * https://en.wikipedia.org/wiki/Udev#History https://en.wikipedia.org/wiki/Udev#History * https://en.wikipedia.org/wiki/Eudev https://en.wikipedia.org/wiki/Eudev
  - throw0101a 5y ago
    So I can take systemd-timesyncd and run it on systemd-less Devuan or FreeBSD? systemd-resolved? systemd-networkd?