News for hackers. Stuff that matters.
Re:Debian votes for Proposal B, “Systemd but we support expl... by pinopinopino on Saturday December 28, 2019 @08:03AM (#21898664)
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.
Re:Debian votes for Proposal B, “Systemd but we support expl... by jbverschoor on Saturday December 28, 2019 @09:15AM (#21898986)
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.

Re:Debian votes for Proposal B, “Systemd but we support expl... by kdmccormick on Saturday December 28, 2019 @10:33AM (#21899370)
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.

Re:Debian votes for Proposal B, “Systemd but we support expl... by majewsky on Saturday December 28, 2019 @12:52PM (#21900393)
> 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.

Re:Debian votes for Proposal B, “Systemd but we support expl... by Null-Set on Saturday December 28, 2019 @01:12PM (#21900545)
Logging, login, network configuration, and more. https://en.wikipedia.org/wiki/Systemd#Ancillary_components
Re:Debian votes for Proposal B, “Systemd but we support expl... by majewsky on Saturday December 28, 2019 @01:53PM (#21900845)
These are not APIs, they are UIs. They will not cause vendor lock-in for general user-space applications.