13 ms·

I hope that "exploring alternatives" isn't code for dropping sysvinit. Even with the latest debian, switching away from systemd is easy as:- apt-get install

by hazeii 7y ago

I hope that "exploring alternatives" isn't code for dropping sysvinit. Even with the latest debian, switching away from systemd is easy as:- apt-get install sysvinit-core sysvinit-utils cp /usr/share/sysvinit/inittab /etc/inittab reboot apt-get remove --purge --auto-remove systemd Our reasons for doing this are we run stripped-down systems that go for years (even decades), but which we absolutely must be able to fix ourselves with the proverbial rusty hairclip. The general bloat of linux distros (due to gnome/systemd and others) really doesn't suit our use case (although obviously it suits others, even the majority).

ckastner 7y ago
> I hope that "exploring alternatives" isn't code for dropping sysvinit. It's not about dropping, it's about how much effort the invididual maintainer must put into a package to support sysvinit, with the answer now being "none". The burden of work is shifted to from the maintainer those wishing to support sysvinit (or any other alternative).
- japanoise 7y ago
  That's probably for the best. Writing init scripts is easy enough for that small percentage of users (like gp) who really need it. Good choice on Debian's part, imho.
  - gwd 7y ago
    The issue isn't actually so much about writing init scripts, as about all the other bits of functionality that systemd has been aquiring. One example apparently is logind. Important key packages have (as I understand it) started depending on functionality provided by logind; I think something like "Gnome Desktop". Which would mean, if you want to run Debian with Gnome, you have to run systemd. The non-systemd crowd wrote elogind in response to this. But of course, now elogind is in a situation like WordPerfect was with Microsoft Word back in the 90's -- trying to remain compatible with a moving target. So the point of this vote is to answer the question: How does a package manager of a package like the "Gnome desktop" interact with the non-systemd crowd, when they want to depend on a new feature that's in logind but not in elogind? Option F is basically, "The package manager says, 'systemd is our primary init system; we depend on systemd's logind period.'" Option B is, "The package manager says, 'I'm making this dependency change. Hope you can manage to get elogind up to scratch before the release; otherwise your package will be broken, but that's not my problem.'" Options D and H were variants on, "The non-systemd people have 6 months to get elogind up to parity with logind. Before 6 months, a breaking change would have to be reverted before release; after 6 months, a breaking change is allowed in a release." Personally I think H was the best option; the fact is they're all actually quite close. 425 people voted, and the deltas between them are 22, 31, and 34. The community is really quite divided still.
    - JoshTriplett 7y ago
      > Personally I think H was the best option Despite its editorialized name of "support portability without blocking progress", it had a mandatory 6-12 month waiting period before using any piece of new functionality, and the anti-systemd crowd has demonstrated repeatedly that they'll use any weapon to slow down systemd usage, which means in practice every single new mechanism or upgrade would likely have incurred a 12-month delay. I think the winning option was optimal: it firmly says "if you want a non-systemd init to work you have to do all the work or convince (not force) others to help you". It means that if people materialize to do the work for a new init (whether a better-than-sysvinit alternative, or some future better-than-systemd alternative), they can do that work, and encourage (but not force) others to do the same. So, if something comes along that people are excited about because it's actually better, or meaningfully different and not worse, nothing stops developers from rallying behind it and adding support for it.
      - gwd 7y ago
        > the anti-systemd crowd has demonstrated repeatedly that they'll use any weapon to slow down systemd usage, which means in practice every single new mechanism or upgrade would likely have incurred a 12-month delay. The same sort of thing is exhibited by the pro-systemd crowd. Here's an example where a maintainer completely refused to engage with someone trying to fix a component required to work with non-systemd systems: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930869 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930869 And the issue I have with 'B' is that it doesn't actually do anything concrete to address this kind of behavior. > Despite its editorialized name of "support portability without blocking progress", it had a mandatory 6-12 month waiting period before using any piece of new functionality Debian only does a release every 2 years. If that number were set to '6 months', in practice what that would mean is that if you want to introduce a breaking dependency, you have to introduce it in the first 18 months of a release development, so that the other people in your community have some chance of getting things working before the release. That seems like a basic level of consideration and cooperation. [Minor edits for clarity.]
        7y ago
blihp 7y ago
It's basically saying that nothing is changing. 'Exploring alternatives' is a nebulous phrase that says they're sticking with the status quo and keeps the options open but doesn't commit anyone to actually doing anything.
- sheepdestroyer 7y ago
  Hum, not exactly : It assesses that those interested in having other init working for a package where that support is not directly provided by upstream nor the maintainer can do the work themselves and they will get the community's help by having their patches reviewed and discussed in a timely manner. Which was not a given.
  - JdeBP 7y ago
    Not by Ian Jackson's analysis. By M. Jackson's analysis, it is still not a given. > A,B,F (#3,2,1) > Maintainers do not have to write them and do not need to accept them. * https://diziet.dreamwidth.org/3999.html https://diziet.dreamwidth.org/3999.html
    - sheepdestroyer 7y ago
      Only Patch "reviewing" is guaranteed, not patch acceptance. Reviewing and discussion were not a given before this vote. This proposition at least ensure that. The maintainer will not be forced to accept patches that he deems unfit just for the sake of supporting other init systems though.
  - blihp 7y ago
    Fair point. I was more referring to the fact that the Debian project itself isn't actively looking at / working on anything to replace systemd.
thristian 7y ago
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.
ailideex 7y ago
> The general bloat of linux distros (due to gnome/systemd and others) I would say categorizing systemd as "general bloat" is not entirely fair - I would say it is far more stable and easier to debug and fix (with the proverbial rusty hairclip) than debian's sysv init mess was last I looked at it and I would say systemd is actually quite lean both in absolute size, resource consumption and complexity.
- johnr2 7y ago
  > categorizing systemd as "general bloat" is not entirely fair - I would say it is far more stable and easier to debug and fix (with the proverbial rusty hairclip) than debian's sysv init mess I find it easier to debug and edit shell scripts than wade through large amounts of C code (and possibly recompile) in the event of a problem that can't be fixed by a simple reconfiguration. I guess it depends on what you're used to.
  - growse 7y ago
    So... Don't use it?
  - sgtcodfish 7y ago
    Do you have an example of a situation where a problem in systemd required you to patch the source and recompile, or are you just making a general statement? Specifically a problem that couldn't be fixed by changing systemd unit files? (I don't mean for this to sound in bad faith; I'm genuinely curious as a user of systemd)
    - johnr2 7y ago
      > Do you have an example of a situation where a problem in systemd required you to patch the source and recompile, or are you just making a general statement? General statement.
      - PlutoIsAPlanet 7y ago
        You could use that argument and say do you need to look at all the code for the dozen shell programs you're calling in that init file to diagnose problems.
cosmojg 7y ago
Alpine Linux sounds perfect for your use case. Have you considered it? If so, why'd you decide against it?
- hazeii 7y ago
  Cowardice. What we have works, and the only time it gets broken is by 'upgrades'.
TwoNineFive 7y ago
"exploring alternatives" absolutely means dropping support for sysvinit in many cases, which is what was already happening. Maintainers were failing to fix bugs in their init scripts, or even ship init scripts for critical services. The resolution was about trying to force them to include a very small shell script to do the job, and they balked. There are a frightening number of maintainers who couldn't write a bash script to save their job, and even more maintainers who don't actually use or understand the package they are responsible for. I suspect the long term damage here is going to be embedded and all the little projects that base off Debian.

by hazeii 7y ago

ckastner 7y ago

> I hope that "exploring alternatives" isn't code for dropping sysvinit. It's not about dropping, it's about how much effort the invididual maintainer must put into a package to support sysvinit, with the answer now being "none". The burden of work is shifted to from the maintainer those wishing to support sysvinit (or any other alternative).

japanoise 7y ago
That's probably for the best. Writing init scripts is easy enough for that small percentage of users (like gp) who really need it. Good choice on Debian's part, imho.
- gwd 7y ago
  The issue isn't actually so much about writing init scripts, as about all the other bits of functionality that systemd has been aquiring. One example apparently is logind. Important key packages have (as I understand it) started depending on functionality provided by logind; I think something like "Gnome Desktop". Which would mean, if you want to run Debian with Gnome, you have to run systemd. The non-systemd crowd wrote elogind in response to this. But of course, now elogind is in a situation like WordPerfect was with Microsoft Word back in the 90's -- trying to remain compatible with a moving target. So the point of this vote is to answer the question: How does a package manager of a package like the "Gnome desktop" interact with the non-systemd crowd, when they want to depend on a new feature that's in logind but not in elogind? Option F is basically, "The package manager says, 'systemd is our primary init system; we depend on systemd's logind period.'" Option B is, "The package manager says, 'I'm making this dependency change. Hope you can manage to get elogind up to scratch before the release; otherwise your package will be broken, but that's not my problem.'" Options D and H were variants on, "The non-systemd people have 6 months to get elogind up to parity with logind. Before 6 months, a breaking change would have to be reverted before release; after 6 months, a breaking change is allowed in a release." Personally I think H was the best option; the fact is they're all actually quite close. 425 people voted, and the deltas between them are 22, 31, and 34. The community is really quite divided still.
  - JoshTriplett 7y ago
    > Personally I think H was the best option Despite its editorialized name of "support portability without blocking progress", it had a mandatory 6-12 month waiting period before using any piece of new functionality, and the anti-systemd crowd has demonstrated repeatedly that they'll use any weapon to slow down systemd usage, which means in practice every single new mechanism or upgrade would likely have incurred a 12-month delay. I think the winning option was optimal: it firmly says "if you want a non-systemd init to work you have to do all the work or convince (not force) others to help you". It means that if people materialize to do the work for a new init (whether a better-than-sysvinit alternative, or some future better-than-systemd alternative), they can do that work, and encourage (but not force) others to do the same. So, if something comes along that people are excited about because it's actually better, or meaningfully different and not worse, nothing stops developers from rallying behind it and adding support for it.
    - gwd 7y ago
      > the anti-systemd crowd has demonstrated repeatedly that they'll use any weapon to slow down systemd usage, which means in practice every single new mechanism or upgrade would likely have incurred a 12-month delay. The same sort of thing is exhibited by the pro-systemd crowd. Here's an example where a maintainer completely refused to engage with someone trying to fix a component required to work with non-systemd systems: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930869 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930869 And the issue I have with 'B' is that it doesn't actually do anything concrete to address this kind of behavior. > Despite its editorialized name of "support portability without blocking progress", it had a mandatory 6-12 month waiting period before using any piece of new functionality Debian only does a release every 2 years. If that number were set to '6 months', in practice what that would mean is that if you want to introduce a breaking dependency, you have to introduce it in the first 18 months of a release development, so that the other people in your community have some chance of getting things working before the release. That seems like a basic level of consideration and cooperation. [Minor edits for clarity.]
      - 7y ago

blihp 7y ago

It's basically saying that nothing is changing. 'Exploring alternatives' is a nebulous phrase that says they're sticking with the status quo and keeps the options open but doesn't commit anyone to actually doing anything.

sheepdestroyer 7y ago
Hum, not exactly : It assesses that those interested in having other init working for a package where that support is not directly provided by upstream nor the maintainer can do the work themselves and they will get the community's help by having their patches reviewed and discussed in a timely manner. Which was not a given.
- JdeBP 7y ago
  Not by Ian Jackson's analysis. By M. Jackson's analysis, it is still not a given. > A,B,F (#3,2,1) > Maintainers do not have to write them and do not need to accept them. * https://diziet.dreamwidth.org/3999.html https://diziet.dreamwidth.org/3999.html
  - sheepdestroyer 7y ago
    Only Patch "reviewing" is guaranteed, not patch acceptance. Reviewing and discussion were not a given before this vote. This proposition at least ensure that. The maintainer will not be forced to accept patches that he deems unfit just for the sake of supporting other init systems though.
- blihp 7y ago
  Fair point. I was more referring to the fact that the Debian project itself isn't actively looking at / working on anything to replace systemd.

thristian 7y ago

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.

ailideex 7y ago

> The general bloat of linux distros (due to gnome/systemd and others) I would say categorizing systemd as "general bloat" is not entirely fair - I would say it is far more stable and easier to debug and fix (with the proverbial rusty hairclip) than debian's sysv init mess was last I looked at it and I would say systemd is actually quite lean both in absolute size, resource consumption and complexity.

johnr2 7y ago
> categorizing systemd as "general bloat" is not entirely fair - I would say it is far more stable and easier to debug and fix (with the proverbial rusty hairclip) than debian's sysv init mess I find it easier to debug and edit shell scripts than wade through large amounts of C code (and possibly recompile) in the event of a problem that can't be fixed by a simple reconfiguration. I guess it depends on what you're used to.
- growse 7y ago
  So... Don't use it?
- sgtcodfish 7y ago
  Do you have an example of a situation where a problem in systemd required you to patch the source and recompile, or are you just making a general statement? Specifically a problem that couldn't be fixed by changing systemd unit files? (I don't mean for this to sound in bad faith; I'm genuinely curious as a user of systemd)
  - johnr2 7y ago
    > Do you have an example of a situation where a problem in systemd required you to patch the source and recompile, or are you just making a general statement? General statement.
    - PlutoIsAPlanet 7y ago
      You could use that argument and say do you need to look at all the code for the dozen shell programs you're calling in that init file to diagnose problems.

cosmojg 7y ago

Alpine Linux sounds perfect for your use case. Have you considered it? If so, why'd you decide against it?

hazeii 7y ago
Cowardice. What we have works, and the only time it gets broken is by 'upgrades'.

TwoNineFive 7y ago

"exploring alternatives" absolutely means dropping support for sysvinit in many cases, which is what was already happening. Maintainers were failing to fix bugs in their init scripts, or even ship init scripts for critical services. The resolution was about trying to force them to include a very small shell script to do the job, and they balked. There are a frightening number of maintainers who couldn't write a bash script to save their job, and even more maintainers who don't actually use or understand the package they are responsible for. I suspect the long term damage here is going to be embedded and all the little projects that base off Debian.