7 ms·

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,

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.]
    - JoshTriplett 7y ago
      > The same sort of thing is described on the pro-systemd crowd. I wasn't commenting on that here one way or another. I was observing that this would hand one crowd a new weapon, in the form of a mandatory 6-12 month delay. (In general, I think the vast majority of the pro-systemd crowd is not interested in actively killing alternatives; they're just interested in actually using features that other alternatives don't have. Problems and disputes certainly happen, as well as people getting frustrated or burnt out trying to deal with the constant battles, as well as people just trying to get things done.) (I also think many of the anti-systemd crowd is just interested in trying to maintain what they care about, but that in practice it's become evident that "keep up" would require than the available development resources, while the far more acrimonious "slow others down" requires less. I suspect it's a survival/threat response, but that still doesn't make it the right one.) > Debian only does a release every 2 years. Many people run the testing or unstable distributions. And in any case, that's not the issue here: > 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, That's not what that proposal said. What it said was that if you want to use any new feature, you'd have to ask first, document it in Policy first (which is not the norm, usually Policy follows experimentation and documents what has become existing practice), make sure it's something that could theoretically work not just on non-systemd but also on non-Linux, then wait "at least 6 months, preferably at least 12 months" to see if someone bothers to make an alternative implementation, before you can actually use it. And any further enhancement to such a mechanism needs another 6-12 months. That might have sounded reasonable to the developers of software like sysvinit that doesn't actually change anymore, and is mostly in permanent maintenance mode with its current set of features. It doesn't sound at all reasonable regarding actively developed software.
- johnr2 7y ago
  > if you want to run Debian with Gnome Considering the small minority of Linux installations on desktops and laptops (compared to servers and other network infrastructure), and the fact that only some of those will be using Gnome, I think this has been overemphasised. It's unfortunate that a minority has dictated policy for everyone else. Having said that, I think Debian has made a rational decision. It would be unreasonable to expect package maintainers to provide multiple sets of init scripts due to the extra work. (FWIW I've used Debian for ~20 years and still use sysvinit).
- belorn 7y ago
  I am not sure how much power Debian have if projects start to depend on systemd outside of initialization. Things like socket handoff, service discovery, logging and so on is choices of upstream and can be quite convenient depend on which ever third party library that is most common in use. Good programming practice is to make it easy to change components like that, and doing it also helps testing. In theory it should just be a matter of replacing a few components to get gnome running without systemd, depending on how hard coupled those are.
- sudosysgen 7y ago
  You can run gnome desktop no matter which login system you use. You just have go launch it accordingly.
- despera 7y ago
  Most of elogind code is taken out of systemd and living standalone, even following systemd version. Thus has been showcased that it is possible and there's no reason why this shouldn't be a separate library in first place according to all those great UNIX and programming philosophical motto out there.

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.]
  - JoshTriplett 7y ago
    > The same sort of thing is described on the pro-systemd crowd. I wasn't commenting on that here one way or another. I was observing that this would hand one crowd a new weapon, in the form of a mandatory 6-12 month delay. (In general, I think the vast majority of the pro-systemd crowd is not interested in actively killing alternatives; they're just interested in actually using features that other alternatives don't have. Problems and disputes certainly happen, as well as people getting frustrated or burnt out trying to deal with the constant battles, as well as people just trying to get things done.) (I also think many of the anti-systemd crowd is just interested in trying to maintain what they care about, but that in practice it's become evident that "keep up" would require than the available development resources, while the far more acrimonious "slow others down" requires less. I suspect it's a survival/threat response, but that still doesn't make it the right one.) > Debian only does a release every 2 years. Many people run the testing or unstable distributions. And in any case, that's not the issue here: > 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, That's not what that proposal said. What it said was that if you want to use any new feature, you'd have to ask first, document it in Policy first (which is not the norm, usually Policy follows experimentation and documents what has become existing practice), make sure it's something that could theoretically work not just on non-systemd but also on non-Linux, then wait "at least 6 months, preferably at least 12 months" to see if someone bothers to make an alternative implementation, before you can actually use it. And any further enhancement to such a mechanism needs another 6-12 months. That might have sounded reasonable to the developers of software like sysvinit that doesn't actually change anymore, and is mostly in permanent maintenance mode with its current set of features. It doesn't sound at all reasonable regarding actively developed software.
johnr2 7y ago
> if you want to run Debian with Gnome Considering the small minority of Linux installations on desktops and laptops (compared to servers and other network infrastructure), and the fact that only some of those will be using Gnome, I think this has been overemphasised. It's unfortunate that a minority has dictated policy for everyone else. Having said that, I think Debian has made a rational decision. It would be unreasonable to expect package maintainers to provide multiple sets of init scripts due to the extra work. (FWIW I've used Debian for ~20 years and still use sysvinit).
belorn 7y ago
I am not sure how much power Debian have if projects start to depend on systemd outside of initialization. Things like socket handoff, service discovery, logging and so on is choices of upstream and can be quite convenient depend on which ever third party library that is most common in use. Good programming practice is to make it easy to change components like that, and doing it also helps testing. In theory it should just be a matter of replacing a few components to get gnome running without systemd, depending on how hard coupled those are.
sudosysgen 7y ago
You can run gnome desktop no matter which login system you use. You just have go launch it accordingly.
despera 7y ago
Most of elogind code is taken out of systemd and living standalone, even following systemd version. Thus has been showcased that it is possible and there's no reason why this shouldn't be a separate library in first place according to all those great UNIX and programming philosophical motto out there.