News for hackers. Stuff that matters.
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.