4 ms·

My problem with systemd is that it is not just a init system. It goes further than that and it exposes apis that third parties use. It is tempting to use system

My problem with systemd is that it is not just a init system. It goes further than that and it exposes apis that third parties use. It is tempting to use systemd functionality as developer, but then you are no longer portable to bsd, darwin or other systems. I think systemd is bad because it will break links between the various unixes. That being said, as system administrator, I found systemd mostly to be ok, but sometimes you run in non reproducable problems. I have sometimes that servers don't come up, because the network unit didn't get started. Restarting fixes it. I haven't been able to reproduce it and the logs are also not very helpful.

jbverschoor 7y ago
I don't know.. your application can and should be portable.. But if you want to support systemd, sysvinit, launchd, windows-services or whatever, that's up to you. It's this tiny part where you need to commit to some piece of technology. I don't see the difference between creating a systemd config file, which is super clear and managed properly and to create a bunch of init scripts that depend on pid-files which might be stale and where those directories are abitrary.
- kdmccormick 7y ago
  If I understand correctly, GP is saying that systemd also provides non-init-related functionality. If a package you develop relies on only systemd's init capabilities, it'd probably be pretty straightforward for someone to port it to an OS with a different init system (like BSD). If your package relies on other systemd capabilities, though, the task of porting gets much harder.
  - majewsky 7y ago
    > If your package relies on other systemd capabilities Such as? Which other "systemd capability" besides the init system part exposes an API to general user-space applications? The only one I can think of is logind, for which an alternative implementation (elogind) exists.
    - Null-Set 7y ago
      Logging, login, network configuration, and more. https://en.wikipedia.org/wiki/Systemd#Ancillary_components https://en.wikipedia.org/wiki/Systemd#Ancillary_components
      - majewsky 7y ago
        These are not APIs, they are UIs. They will not cause vendor lock-in for general user-space applications.

jbverschoor 7y ago

I don't know.. your application can and should be portable.. But if you want to support systemd, sysvinit, launchd, windows-services or whatever, that's up to you. It's this tiny part where you need to commit to some piece of technology. I don't see the difference between creating a systemd config file, which is super clear and managed properly and to create a bunch of init scripts that depend on pid-files which might be stale and where those directories are abitrary.

kdmccormick 7y ago
If I understand correctly, GP is saying that systemd also provides non-init-related functionality. If a package you develop relies on only systemd's init capabilities, it'd probably be pretty straightforward for someone to port it to an OS with a different init system (like BSD). If your package relies on other systemd capabilities, though, the task of porting gets much harder.
- majewsky 7y ago
  > If your package relies on other systemd capabilities Such as? Which other "systemd capability" besides the init system part exposes an API to general user-space applications? The only one I can think of is logind, for which an alternative implementation (elogind) exists.
  - Null-Set 7y ago
    Logging, login, network configuration, and more. https://en.wikipedia.org/wiki/Systemd#Ancillary_components https://en.wikipedia.org/wiki/Systemd#Ancillary_components
    - majewsky 7y ago
      These are not APIs, they are UIs. They will not cause vendor lock-in for general user-space applications.