3 ms·

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 developer

• 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.