8 ms·

I hope it does involve removing sysvinit. Compared to alternatives like runit or s6, sysvinit increases bloat (because every service needs to include it's own d

I hope it does involve removing sysvinit. Compared to alternatives like runit or s6, sysvinit increases bloat (because every service needs to include it's own daemonising and logging code) and makes systems brittle and difficult to debug (because the classic daemonisation process is subtle and easy to get wrong). If I had to build a stripped-down, ultra-stable, long-running system, I definitely wouldn't want to build it on sysvinit.

m4rtink 7y ago
Indeed! Comming from Fedora, I can't really imagine the overhead maintaining two sets of init files would bring. Such a waste of already scarse maintainer resources.
- alxlaz 7y ago
  Debian is a volunteer project. It's not a commercial enterprise. Volunteers work on whatever they think is worth their time and whatever they think it benefits them and their users. It's not a "waste" of "maintainer resources". "Resources" don't get bossed around in a community project. It's a bit unsettling that people in the open source community need to work on this particular thing, but it's unfair to blame them for that. There are plenty of init systems other than systemd, and plenty of desktop projects other than Gnome, but most of them don't require so much downstream work. The amount of time that has to be spent by downstream projects to make systemd useful for as many people as possible, and to make Gnome available to as many users as possible, says a lot about how these projects are developed, too.
  - Macha 7y ago
    And this vote here is maintainers collectively deciding they want to stop requiring sysvinit, but people who want to are free to support it.
  - cipherboy 7y ago
    > Debian is a volunteer project. It's not a commercial enterprise. Volunteers work on whatever they think is worth their time and whatever they think it benefits them and their users. What you've described also applies to Fedora. Fedora is community run and non-commercial. The results of the latest FESCO vote shows that. It is very much a volunteer-run distribution. Yes, many Red Hatters have a personal interest in Fedora, and many others have professional interests. But nobody (from the Fedora community leadership) is going around selling it... :-) > It's a bit unsettling that people in the open source community need to work on this particular thing, but it's unfair to blame them for that. I think OP's point, coming from Fedora, is that the package maintainer (of say, apache-httpd) would need to ship unit files for all init systems and support them. The latter is a large task when you never use said alternative init system, especially if a drive-by contributor gave you the initial script. (And yes, you're free to ask for help, post on mailing lists, &c. but fundamentally it'd still come down to you, as the maintainer, to fix it). At any rate, that's likely how Fedora would behave. Source: Red Hatter and Fedora contributor.
  - mannykannot 7y ago
    > "Resources" don't get bossed around in a community project. True, but if you insist on persuing something that the consensus is uninterested in, you can end up maintaining your own personal fork. Whether by consesus or fiat, every project of the size and complexity of Debian needs to make choices and live with them. Here, it appears to have chosen Systemd, while, in time-honored fashion, offerering the vague prospect of an alternative to blunt the opposition.
  - babarock 7y ago
    You can be a volunteer project and still strive for having uniformity across packages in your project. The fact that you're volunteering doesn't mean you get to do whatever you want. That's exactly the reason Debian holds such votes.
- pojntfx 7y ago
  As a Fedora user myself as well, this indeed seems like a massive waste; I can see the point of different distros having different init systems (i.e. Devuan for SysV init, Debian for systemd, Alpine for openrc, ...) but multiple init systems per distro are just unnecessary and hinder true innovation IMHO.
hazeii 7y ago
Well, seems to have worked for us for 20+ years. I wonder where gnome and systemd will be in 20 years? Horses for courses.
- xyproto 7y ago
  Systemd can do things that were not relevant 20 years ago.
  - evgen 7y ago
    Like introducing an RCE into your init system.
    - bonzini 7y ago
      Link?
      - corprew 7y ago
        CVE-2017-15908
        the_why_of_y 7y ago
        https://nvd.nist.gov/vuln/detail/CVE-2017-15908 https://nvd.nist.gov/vuln/detail/CVE-2017-15908 says this is a infinite loop DoS in systemd-resolved, so it can't be the (hypothetical) bug described by the GP since it's neither a RCE nor in systemd PID1.
      - hazeii 7y ago
        Possibly the IPv6 packet one, CVE-2018-15688? [0] A basic buffer overflow in systemd meant oversized network packets could be used for DoS or "potential code execution". [0] https://www.theregister.co.uk/2018/10/26/systemd_dhcpv6_rce/ https://www.theregister.co.uk/2018/10/26/systemd_dhcpv6_rce/
        7y ago
StuffedParrot 7y ago
It seems very counter intuitive that you’d ADD reliability with additional features and surface area for bugs.
- thristian 7y ago
  Every POSIX service needs to be daemonised, write logs, etc. The question is, do you have one bullet-proof implementation in the service-manager, or do you have N independent and less-tested implementations in the N managed services? Adding code to one codebase isn't an "additional feature" if it means you can delete that code from half a dozen other codebases.
petre 7y ago
Runit is also inside Busybox, only it's not usually enabled. So it can be readily used for embedded systems.

m4rtink 7y ago

Indeed! Comming from Fedora, I can't really imagine the overhead maintaining two sets of init files would bring. Such a waste of already scarse maintainer resources.

alxlaz 7y ago
Debian is a volunteer project. It's not a commercial enterprise. Volunteers work on whatever they think is worth their time and whatever they think it benefits them and their users. It's not a "waste" of "maintainer resources". "Resources" don't get bossed around in a community project. It's a bit unsettling that people in the open source community need to work on this particular thing, but it's unfair to blame them for that. There are plenty of init systems other than systemd, and plenty of desktop projects other than Gnome, but most of them don't require so much downstream work. The amount of time that has to be spent by downstream projects to make systemd useful for as many people as possible, and to make Gnome available to as many users as possible, says a lot about how these projects are developed, too.
- Macha 7y ago
  And this vote here is maintainers collectively deciding they want to stop requiring sysvinit, but people who want to are free to support it.
- cipherboy 7y ago
  > Debian is a volunteer project. It's not a commercial enterprise. Volunteers work on whatever they think is worth their time and whatever they think it benefits them and their users. What you've described also applies to Fedora. Fedora is community run and non-commercial. The results of the latest FESCO vote shows that. It is very much a volunteer-run distribution. Yes, many Red Hatters have a personal interest in Fedora, and many others have professional interests. But nobody (from the Fedora community leadership) is going around selling it... :-) > It's a bit unsettling that people in the open source community need to work on this particular thing, but it's unfair to blame them for that. I think OP's point, coming from Fedora, is that the package maintainer (of say, apache-httpd) would need to ship unit files for all init systems and support them. The latter is a large task when you never use said alternative init system, especially if a drive-by contributor gave you the initial script. (And yes, you're free to ask for help, post on mailing lists, &c. but fundamentally it'd still come down to you, as the maintainer, to fix it). At any rate, that's likely how Fedora would behave. Source: Red Hatter and Fedora contributor.
- mannykannot 7y ago
  > "Resources" don't get bossed around in a community project. True, but if you insist on persuing something that the consensus is uninterested in, you can end up maintaining your own personal fork. Whether by consesus or fiat, every project of the size and complexity of Debian needs to make choices and live with them. Here, it appears to have chosen Systemd, while, in time-honored fashion, offerering the vague prospect of an alternative to blunt the opposition.
- babarock 7y ago
  You can be a volunteer project and still strive for having uniformity across packages in your project. The fact that you're volunteering doesn't mean you get to do whatever you want. That's exactly the reason Debian holds such votes.
pojntfx 7y ago
As a Fedora user myself as well, this indeed seems like a massive waste; I can see the point of different distros having different init systems (i.e. Devuan for SysV init, Debian for systemd, Alpine for openrc, ...) but multiple init systems per distro are just unnecessary and hinder true innovation IMHO.

hazeii 7y ago

Well, seems to have worked for us for 20+ years. I wonder where gnome and systemd will be in 20 years? Horses for courses.

xyproto 7y ago
Systemd can do things that were not relevant 20 years ago.
- evgen 7y ago
  Like introducing an RCE into your init system.
  - bonzini 7y ago
    Link?
    - corprew 7y ago
      CVE-2017-15908
      - the_why_of_y 7y ago
        https://nvd.nist.gov/vuln/detail/CVE-2017-15908 https://nvd.nist.gov/vuln/detail/CVE-2017-15908 says this is a infinite loop DoS in systemd-resolved, so it can't be the (hypothetical) bug described by the GP since it's neither a RCE nor in systemd PID1.
    - hazeii 7y ago
      Possibly the IPv6 packet one, CVE-2018-15688? [0] A basic buffer overflow in systemd meant oversized network packets could be used for DoS or "potential code execution". [0] https://www.theregister.co.uk/2018/10/26/systemd_dhcpv6_rce/ https://www.theregister.co.uk/2018/10/26/systemd_dhcpv6_rce/
      - 7y ago

StuffedParrot 7y ago

It seems very counter intuitive that you’d ADD reliability with additional features and surface area for bugs.

thristian 7y ago
Every POSIX service needs to be daemonised, write logs, etc. The question is, do you have one bullet-proof implementation in the service-manager, or do you have N independent and less-tested implementations in the N managed services? Adding code to one codebase isn't an "additional feature" if it means you can delete that code from half a dozen other codebases.

petre 7y ago

Runit is also inside Busybox, only it's not usually enabled. So it can be readily used for embedded systems.