7 ms·

A central point of their thesis is that Systemd folks bullied others into accepting it. That's not really the case, though. The Debian folks had a very transpa

A central point of their thesis is that Systemd folks bullied others into accepting it. That's not really the case, though. The Debian folks had a very transparent discussion and vote about using it: https://www.debian.org/vote/2019/vote_002 https://www.debian.org/vote/2019/vote_002

o11c 2y ago
Related, it's also blatantly ignoring that it's the first software that even allows interoperability in its space, and was thus in huge demand by both developers and administrators. (Edit: Other anti-systemd rant sites sometimes mention these obliquely as "upstream dependencies" and "workplace-mandated", while ignoring the fact that those people have reasons to demand those things) But HN really doesn't need to litigate this all again.
- unsnap_biceps 2y ago
  what do you mean by interoperability?
  - jeyernhg 2y ago
    in the bad old times, every linux distro implemented its init scripts in a slightly different way, often with distro specific tooling and commands for accomplishing most management tasks
    - westurner 2y ago
      systemd unit files require minimal modification by distro repackagers. With SysV-init, it was/is necessary to modify /etc/init.d/servicenamed shell scripts to get consistent logging and respawning behavior. With SysV init it's not possible to add edges between things to say that networkd must be started before apached; there are 6 numeric runlevels and filenames like S86apache, which you then can't diff or debsums against because the package default is S80apache and Apache starts with A which alphabetically sorts before the N in networkd. And then add cgroups and namespaces to everything in /etc/init.d please
      - michaelmrose 2y ago
        There were and are other options other than systemd and SysV years prior in fact. OpenRC and upstart predate it and s6 was not much later.
        westurner 2y ago
        It's possible to pipe stdout to syslog through logger by modifying the exec args. But I'd rather take journald's word for it. Supervisord (and supervisorctl) are like s6. I don't think any of these support a config file syntax for namespaces, cgroups, seccomp, or SyscallFilter. Though it's possible to use process isolation with any init system by modifying the init script or config file to call the process with systemd-nspawn (which is like chroot, which most SysV-init scripts also fail to do at all, though a process can drop privs and chroot at init regardless of init system). systemd works in containers now without weird setup. Though is it better to run a 'sidecar' container (for e.g. certbot) than to run multiple processes in a container?
  - o11c 2y ago
    I (and this applies both with my dev hat and with my admin hat) can now write a unit file, depending on a different unit file, that works the same across all distros (note that this includes random end users whose systems I don't directly have access to). This even works for services that start per-user; no more write-only modifications to user startup files or DE-specific autostart dirs. Pre-systemd this was unthinkable. (similar stories apply to non-systemd-proper parts of the systemd project, but I personally haven't used them as much)
- michaelmrose 2y ago
  Upstart and OpenRC both came years prior. As a matter of course anything which was self contained and standardized could have allowed interoperability. Systemd just actually convinced everyone to standardize not least because its integration with other parts of systemd provided both a carrot: standardization and simplicity for distro maintainers and a stick: the extra work required to use only part of it or especially if one used none of it and was expected to both write ones one unit files AND integration with stuff like gnome which was and remains the most popular singular GUI.
- yjftsjthsd-h 2y ago
  Conformity is not interoperability. If anything, systemd is like Chrome, so popular that it persuades people to drop interoperability outright and just run with its nonstandard APIs.
  - rcxdude 2y ago
    what standard is systemd replacing? One of the big reasons it's popular is that there was no standard way to do most of the things it does.
akerl_ 2y ago
I have to wonder if this is some kind of statistical bias based on the type of engagement. There are some people who are vehemently opposed to systemd, for a variety of reasons with varying degrees of merit. I think it's fair to say that systemd's developers broadly ignored those people, figuring out (correctly) that if they convinced a majority of distribution maintainers, and made the user experience for the average user smooth enough, that was actually going to be successful. As it should be: distro maintainers get to pick how their distros work, and users determine which distros they use. And systemd has a clear sell for those groups: distro maintainers can standardize their service scripts, often just using what an upstream package author can write agnostically to distro, and users can handle the majority of base system functionality without having to pick things like "which of these cron daemons should I install".
- theamk 2y ago
  I'd also add that systemd appeals to application developers (no daemon code, one file for all distros). And it appeals to sysadmins too (no more /etc conflicts on any package update! Modify any system service! etc..) Which brings me to the question of which category systemd does not appeal to? I am guessing "minimalists" and "people who like things done the old way" - and those are simply not that numerous compared to others.
- egorfine 2y ago
  > broadly ignored those people, figuring out (correctly) that if they convinced a majority So, politics at its worst. Being ignored on a matter, especially when there is merit involved, can make someone a highly motivated hater.
  - akerl_ 2y ago
    Surely for each individual distro, they get to make their own decision about how to build their system. I can’t stop you from hating, but if your pitch is that distros shouldn’t be allowed to make their own choices about what to include if you disagree… I guess your option is to start your own distro. No linux distro was forced to adopt systemd. They did it on the merits, from their determination.
happymellon 2y ago
Didn't Arch also adopt it as the defaults before anyone else. I can't see that being a project that would be bullied easily. Especially not "bullied so that it was adopted before almost everyone else".

o11c 2y ago

Related, it's also blatantly ignoring that it's the first software that even allows interoperability in its space, and was thus in huge demand by both developers and administrators. (Edit: Other anti-systemd rant sites sometimes mention these obliquely as "upstream dependencies" and "workplace-mandated", while ignoring the fact that those people have reasons to demand those things) But HN really doesn't need to litigate this all again.

unsnap_biceps 2y ago
what do you mean by interoperability?
- jeyernhg 2y ago
  in the bad old times, every linux distro implemented its init scripts in a slightly different way, often with distro specific tooling and commands for accomplishing most management tasks
  - westurner 2y ago
    systemd unit files require minimal modification by distro repackagers. With SysV-init, it was/is necessary to modify /etc/init.d/servicenamed shell scripts to get consistent logging and respawning behavior. With SysV init it's not possible to add edges between things to say that networkd must be started before apached; there are 6 numeric runlevels and filenames like S86apache, which you then can't diff or debsums against because the package default is S80apache and Apache starts with A which alphabetically sorts before the N in networkd. And then add cgroups and namespaces to everything in /etc/init.d please
    - michaelmrose 2y ago
      There were and are other options other than systemd and SysV years prior in fact. OpenRC and upstart predate it and s6 was not much later.
      - westurner 2y ago
        It's possible to pipe stdout to syslog through logger by modifying the exec args. But I'd rather take journald's word for it. Supervisord (and supervisorctl) are like s6. I don't think any of these support a config file syntax for namespaces, cgroups, seccomp, or SyscallFilter. Though it's possible to use process isolation with any init system by modifying the init script or config file to call the process with systemd-nspawn (which is like chroot, which most SysV-init scripts also fail to do at all, though a process can drop privs and chroot at init regardless of init system). systemd works in containers now without weird setup. Though is it better to run a 'sidecar' container (for e.g. certbot) than to run multiple processes in a container?
- o11c 2y ago
  I (and this applies both with my dev hat and with my admin hat) can now write a unit file, depending on a different unit file, that works the same across all distros (note that this includes random end users whose systems I don't directly have access to). This even works for services that start per-user; no more write-only modifications to user startup files or DE-specific autostart dirs. Pre-systemd this was unthinkable. (similar stories apply to non-systemd-proper parts of the systemd project, but I personally haven't used them as much)
michaelmrose 2y ago
Upstart and OpenRC both came years prior. As a matter of course anything which was self contained and standardized could have allowed interoperability. Systemd just actually convinced everyone to standardize not least because its integration with other parts of systemd provided both a carrot: standardization and simplicity for distro maintainers and a stick: the extra work required to use only part of it or especially if one used none of it and was expected to both write ones one unit files AND integration with stuff like gnome which was and remains the most popular singular GUI.
yjftsjthsd-h 2y ago
Conformity is not interoperability. If anything, systemd is like Chrome, so popular that it persuades people to drop interoperability outright and just run with its nonstandard APIs.
- rcxdude 2y ago
  what standard is systemd replacing? One of the big reasons it's popular is that there was no standard way to do most of the things it does.

akerl_ 2y ago

I have to wonder if this is some kind of statistical bias based on the type of engagement. There are some people who are vehemently opposed to systemd, for a variety of reasons with varying degrees of merit. I think it's fair to say that systemd's developers broadly ignored those people, figuring out (correctly) that if they convinced a majority of distribution maintainers, and made the user experience for the average user smooth enough, that was actually going to be successful. As it should be: distro maintainers get to pick how their distros work, and users determine which distros they use. And systemd has a clear sell for those groups: distro maintainers can standardize their service scripts, often just using what an upstream package author can write agnostically to distro, and users can handle the majority of base system functionality without having to pick things like "which of these cron daemons should I install".

theamk 2y ago
I'd also add that systemd appeals to application developers (no daemon code, one file for all distros). And it appeals to sysadmins too (no more /etc conflicts on any package update! Modify any system service! etc..) Which brings me to the question of which category systemd does not appeal to? I am guessing "minimalists" and "people who like things done the old way" - and those are simply not that numerous compared to others.
egorfine 2y ago
> broadly ignored those people, figuring out (correctly) that if they convinced a majority So, politics at its worst. Being ignored on a matter, especially when there is merit involved, can make someone a highly motivated hater.
- akerl_ 2y ago
  Surely for each individual distro, they get to make their own decision about how to build their system. I can’t stop you from hating, but if your pitch is that distros shouldn’t be allowed to make their own choices about what to include if you disagree… I guess your option is to start your own distro. No linux distro was forced to adopt systemd. They did it on the merits, from their determination.

happymellon 2y ago

Didn't Arch also adopt it as the defaults before anyone else. I can't see that being a project that would be bullied easily. Especially not "bullied so that it was adopted before almost everyone else".