8 ms·

Sysvinit is still around, you can always go back to it if you really want. The package is even still in debian.

AnthonyMouse 6y ago
The problem is not that sysvinit doesn't exist, it's that other packages now have dependencies on systemd, so it doesn't just swap out.
- cycloptic 6y ago
  I don't see how that is the problem. It's exactly what you asked for. If you're replacing a low-level component with something else that hasn't been updated in years and doesn't implement features that other packages do then yeah, you have to be prepared to accept that some newer things will break, and you'll have to revert a lot of other packages to older versions too. What else can we do? This isn't even a systemd-specific thing.
  - AnthonyMouse 6y ago
    They didn't used to break if you wanted to switch from one init system to another. What you could do is to reduce unnecessary interdependencies. And where there is inherently interaction between separate packages, use a stable interface and publish the standard so that alternative implementations can replace a single package in a standard way without breaking several others.
    - cycloptic 6y ago
      Yes, they did. It they didn't break it was because those inits were compatible with sysvinit scripts. You lose that once you start porting your init scripts over to rc or whatever it is you replaced your init with, and now your system will break if you try to switch to something else.
      - AnthonyMouse 6y ago
        Your init scripts would have to be replaced, that's to be expected, and when multiple ordinary init systems are popular, packages could easily support more than one since an init script is generally only a few lines. I'm talking about all the things that now break not related to the normal function of init at all.
        cycloptic 6y ago
        If those inits supported newer features, the init scripts would easily grow longer than a few lines and become incompatible once they use those features. I don't see how that's any different from what's going on here. If your complaint is that the scope of init systems has been expanded, I don't know what to tell you other than that it was inevitable. Systemd is not the first project to try and do this.
  - lmm 6y ago
    Systemd deliberately refused to conform to standardised interfaces and got other packages to be changed to explicitly depend on it instead (e.g. RedHat made changes to Gnome to make it break under non-systemd). This was not necessary to achieve the technical things that systemd wanted to achieve - competing alternatives (e.g. runit) didn't need that. (Though it probably was necessary to force adoption).
    - cycloptic 6y ago
      This is not true in any way. Gnome still works on non-systemd systems but you have to install elogind. And, there were valid technical reasons to have gnome depend on a login manager, in particular supporting multi-seat securely is very difficult without one. I should also mention that the previous "standardised interface" for this was ConsoleKit which was also written by the same developers as gnome and systemd. So this is not a matter of some developers going around and raiding projects and "forcing adoption", it's all stuff that happened under the same umbrella anyway. If the "competing alternatives" don't need it then I would advise those projects to put their money where their mouth is and either start making improvements to elogind, or develop a new login manager that better fulfills the needs of gnome. In particular the solution used by elogind to deal with cgroups is to just disable them entirely, or at least it was last time I checked. I don't know what runit does for cgroups but a good step would be to make elogind compatible with that.
      - lmm 6y ago
        > This is not true in any way. Gnome still works on non-systemd systems but you have to install elogind. elogind is a stub piece of systemd and systemd refuses to make any commitment to maintain compatibility. It's like saying that windows programs work on Linux, you just have to use wine - it's sort of true for now, but it's not something you can rely on. > And, there were valid technical reasons to have gnome depend on a login manager, in particular supporting multi-seat securely is very difficult without one. I should also mention that the previous "standardised interface" for this was ConsoleKit which was also written by the same developers as gnome and systemd. I remember multi-seat working fine long before either systemd or ConsoleKit, so that seems pretty questionable. > I would advise those projects to put their money where their mouth is and either start making improvements to elogind, or develop a new login manager that better fulfills the needs of gnome. "The needs of gnome" are a constantly moving set of goalposts under the control of RedHat. Gnome worked fine long before systemd and systemd has not noticeably improved it (if anything the opposite); there was no technical consensus that the current hard-dependency was necessary, it was forced through because RedHat wanted it that way. So they're not going to accept patches to offer compatibility with non-systemd, and if they do then they'll just find a different way to hard-depend on a different part of systemd.
  - kelnos 6y ago
    I think the point is that a software platform that imposes these requirements is inherently brittle and prone to ossification.
- tannhaeuser 6y ago
  Exactly, and to prevent this from happening is what Devuan is all about (as I'm sure you know): to keep all the maintenance work going into Debian, while remaining mostly bullshit-free. It's what I'm about to be installing after a decade on the Ubuntu desktop. The recent snap fiasco is just the final nail in the coffin. The trifecta of SystemD, Gnome3, and SnapD means that I can just use Windows with WSL if I wanted a distro that is maximally intransparent and pushing things onto me (saying this without satire). Actually, gnome3 is really the worst regression here, and it being so strongly tied in to SystemD makes it an easy target to get rid of. Other contenders I've been looking into: Void Linux, Slackware, and the BSDs (I used to run FreeBSD in the late 1990s/early 2000s). At one point there was even a variant of Debian (userspace) running on FreeBSD, which however was abandonded due to SystemD and cgroups/namespaces invading too much of Debian.
  - aerique 6y ago
    Good luck with Devuan (I have no experience with it). If it doesn't work out I can recommend Void Linux. I've been using it for years as my daily driver since Debian switched to SystemD, both at work and at home.
  - deleted 6y ago
    [deleted]
- AsyncAwait 6y ago
  And why do you think that is? It's because systemd offers convenient functionality that those dependent packages want to hook into, because previously they were either maintaining all that themselves and seriosly lacking the manpower to do so or it wasn't being maintained at all and just rotting, (i.e. consolekit)
xfs 6y ago
This is the kind of false argument being thrown around often in OSS discourse that ignores the structural power differential. Don't like it? Write your own/Leave. The fact is you can't go back to it as an individual, because the system has changed and as an individual you're powerless to change the situation at all, especially against an army of developers paid full-time. The latest news from Debian is sysvinit support is no longer guaranteed.
- cycloptic 6y ago
  If you can't pull your own weight and don't want to try anymore then yes, you should leave and come back when you can. Sorry if that sounds rude but this is the way it is. OSS (and software in general) has always been driven by people who are fortunate enough to have access to expensive computers and who have the free time and motivation to spend programming. You can't let what they do bother you, and there's nothing wrong with taking a break and coming back later when you're ready. I'm sure the companies who employ these armies of developers are hiring so you could probably work there too if you really wanted. If anything the power differential has gotten much smaller in recent years with things like github, and last time I checked systemd was accepting pull requests. And even though they won't guarantee it, it sounds like Debian also will continue to accept contributions from those who want to spend time trying to support sysvinit. What exactly is the barrier you're having?
  - rezonant 6y ago
    Before I comment here: I am a fan of systemd in many ways, and I happily use it on my systems. That being said, you do really have to think about the systemic factors at play here. As noted in the original article, Debian found itself in a position where the amount of work to sustain a non-systemd path in a systemd-dominated ecosystem would be too much work _for them_. If you personally have more development time then the entirety of the Debian project, then by all means. Let's just not assume that this is a feasible thing for a single person to handle, and really for all intents and purposes, trying to maintain a Linux distribution (or even just a personal Linux system) without using systemd at this point is folly, no matter how much you dislike it. That being said, SysV init is (in fact) terrible. I'd say put the effort into something that can supercede systemd some day. That part of the problem is tractable, though success is quite a long-shot given its entrenchment.

The problem is not that sysvinit doesn't exist, it's that other packages now have dependencies on systemd, so it doesn't just swap out.

cycloptic 6y ago
I don't see how that is the problem. It's exactly what you asked for. If you're replacing a low-level component with something else that hasn't been updated in years and doesn't implement features that other packages do then yeah, you have to be prepared to accept that some newer things will break, and you'll have to revert a lot of other packages to older versions too. What else can we do? This isn't even a systemd-specific thing.
- AnthonyMouse 6y ago
  They didn't used to break if you wanted to switch from one init system to another. What you could do is to reduce unnecessary interdependencies. And where there is inherently interaction between separate packages, use a stable interface and publish the standard so that alternative implementations can replace a single package in a standard way without breaking several others.
  - cycloptic 6y ago
    Yes, they did. It they didn't break it was because those inits were compatible with sysvinit scripts. You lose that once you start porting your init scripts over to rc or whatever it is you replaced your init with, and now your system will break if you try to switch to something else.
    - AnthonyMouse 6y ago
      Your init scripts would have to be replaced, that's to be expected, and when multiple ordinary init systems are popular, packages could easily support more than one since an init script is generally only a few lines. I'm talking about all the things that now break not related to the normal function of init at all.
      - cycloptic 6y ago
        If those inits supported newer features, the init scripts would easily grow longer than a few lines and become incompatible once they use those features. I don't see how that's any different from what's going on here. If your complaint is that the scope of init systems has been expanded, I don't know what to tell you other than that it was inevitable. Systemd is not the first project to try and do this.
- lmm 6y ago
  Systemd deliberately refused to conform to standardised interfaces and got other packages to be changed to explicitly depend on it instead (e.g. RedHat made changes to Gnome to make it break under non-systemd). This was not necessary to achieve the technical things that systemd wanted to achieve - competing alternatives (e.g. runit) didn't need that. (Though it probably was necessary to force adoption).
  - cycloptic 6y ago
    This is not true in any way. Gnome still works on non-systemd systems but you have to install elogind. And, there were valid technical reasons to have gnome depend on a login manager, in particular supporting multi-seat securely is very difficult without one. I should also mention that the previous "standardised interface" for this was ConsoleKit which was also written by the same developers as gnome and systemd. So this is not a matter of some developers going around and raiding projects and "forcing adoption", it's all stuff that happened under the same umbrella anyway. If the "competing alternatives" don't need it then I would advise those projects to put their money where their mouth is and either start making improvements to elogind, or develop a new login manager that better fulfills the needs of gnome. In particular the solution used by elogind to deal with cgroups is to just disable them entirely, or at least it was last time I checked. I don't know what runit does for cgroups but a good step would be to make elogind compatible with that.
    - lmm 6y ago
      > This is not true in any way. Gnome still works on non-systemd systems but you have to install elogind. elogind is a stub piece of systemd and systemd refuses to make any commitment to maintain compatibility. It's like saying that windows programs work on Linux, you just have to use wine - it's sort of true for now, but it's not something you can rely on. > And, there were valid technical reasons to have gnome depend on a login manager, in particular supporting multi-seat securely is very difficult without one. I should also mention that the previous "standardised interface" for this was ConsoleKit which was also written by the same developers as gnome and systemd. I remember multi-seat working fine long before either systemd or ConsoleKit, so that seems pretty questionable. > I would advise those projects to put their money where their mouth is and either start making improvements to elogind, or develop a new login manager that better fulfills the needs of gnome. "The needs of gnome" are a constantly moving set of goalposts under the control of RedHat. Gnome worked fine long before systemd and systemd has not noticeably improved it (if anything the opposite); there was no technical consensus that the current hard-dependency was necessary, it was forced through because RedHat wanted it that way. So they're not going to accept patches to offer compatibility with non-systemd, and if they do then they'll just find a different way to hard-depend on a different part of systemd.
- kelnos 6y ago
  I think the point is that a software platform that imposes these requirements is inherently brittle and prone to ossification.
tannhaeuser 6y ago
Exactly, and to prevent this from happening is what Devuan is all about (as I'm sure you know): to keep all the maintenance work going into Debian, while remaining mostly bullshit-free. It's what I'm about to be installing after a decade on the Ubuntu desktop. The recent snap fiasco is just the final nail in the coffin. The trifecta of SystemD, Gnome3, and SnapD means that I can just use Windows with WSL if I wanted a distro that is maximally intransparent and pushing things onto me (saying this without satire). Actually, gnome3 is really the worst regression here, and it being so strongly tied in to SystemD makes it an easy target to get rid of. Other contenders I've been looking into: Void Linux, Slackware, and the BSDs (I used to run FreeBSD in the late 1990s/early 2000s). At one point there was even a variant of Debian (userspace) running on FreeBSD, which however was abandonded due to SystemD and cgroups/namespaces invading too much of Debian.
- aerique 6y ago
  Good luck with Devuan (I have no experience with it). If it doesn't work out I can recommend Void Linux. I've been using it for years as my daily driver since Debian switched to SystemD, both at work and at home.
- deleted 6y ago
  [deleted]
AsyncAwait 6y ago
And why do you think that is? It's because systemd offers convenient functionality that those dependent packages want to hook into, because previously they were either maintaining all that themselves and seriosly lacking the manpower to do so or it wasn't being maintained at all and just rotting, (i.e. consolekit)

xfs 6y ago

This is the kind of false argument being thrown around often in OSS discourse that ignores the structural power differential. Don't like it? Write your own/Leave. The fact is you can't go back to it as an individual, because the system has changed and as an individual you're powerless to change the situation at all, especially against an army of developers paid full-time. The latest news from Debian is sysvinit support is no longer guaranteed.

cycloptic 6y ago
If you can't pull your own weight and don't want to try anymore then yes, you should leave and come back when you can. Sorry if that sounds rude but this is the way it is. OSS (and software in general) has always been driven by people who are fortunate enough to have access to expensive computers and who have the free time and motivation to spend programming. You can't let what they do bother you, and there's nothing wrong with taking a break and coming back later when you're ready. I'm sure the companies who employ these armies of developers are hiring so you could probably work there too if you really wanted. If anything the power differential has gotten much smaller in recent years with things like github, and last time I checked systemd was accepting pull requests. And even though they won't guarantee it, it sounds like Debian also will continue to accept contributions from those who want to spend time trying to support sysvinit. What exactly is the barrier you're having?
- rezonant 6y ago
  Before I comment here: I am a fan of systemd in many ways, and I happily use it on my systems. That being said, you do really have to think about the systemic factors at play here. As noted in the original article, Debian found itself in a position where the amount of work to sustain a non-systemd path in a systemd-dominated ecosystem would be too much work _for them_. If you personally have more development time then the entirety of the Debian project, then by all means. Let's just not assume that this is a feasible thing for a single person to handle, and really for all intents and purposes, trying to maintain a Linux distribution (or even just a personal Linux system) without using systemd at this point is folly, no matter how much you dislike it. That being said, SysV init is (in fact) terrible. I'd say put the effort into something that can supercede systemd some day. That part of the problem is tractable, though success is quite a long-shot given its entrenchment.