6 ms·

HEADLINE First-class init that is not systemd DESCRIPTION I believe it's notorious that systemd is highly controversial, even spinning off a fork called Devu

HEADLINE First-class init that is not systemd DESCRIPTION I believe it's notorious that systemd is highly controversial, even spinning off a fork called Devuan. It might be more favorable to reunite the community by including one alternative init system that is, fundamentally, a first-class citizen in the Debian ecosystem. "First-class" implies that the user is given a choice on new installations in a specified prompt. The default should be the option "systemd (recommended)". DISTRIBUTION buster+1 given the expected effort ROLE/AFFILIATION Individual and hobbyist system administrator

JoshTriplett 9y ago
Debian is already one of the few distributions that goes out of its way to provide support for non-systemd init systems. Beyond that, it would help if a non-systemd init system as capable as systemd existed; if one did, I'm sure that Debian would include it and support it. This is a case where the problem isn't "please package and support", it's "please develop".
- rxlim 9y ago
  > Debian is already one of the few distributions that goes out of its way to provide support for non-systemd init systems. How does this manifest itself in practice? I don't want to use systemd in Debian 9, what has been done so I can easily change to another init like runit? In practice it's not possible because of so many (unecessary) dependencies on systemd.
  - JoshTriplett 9y ago
    It means that you can install sysvinit or any sysvinit-compatible init, and all daemon packages still provide init scripts, as painful as that is. And Debian still supports installing systemd-shim instead of systemd, so you can have a desktop system with a non-systemd init and it'll still function. > In practice it's not possible because of so many (unecessary) dependencies on systemd. Such as? As far as I can tell, almost nothing depends on systemd. A handful of things depend on libpam-systemd (for session management), which functions with systemd-shim.
    - rxlim 9y ago
      The amount of work that goes into Devuan for pulling out systemd of Debian Jessie is clear evidence that what you are saying is not easily possible.
      - JoshTriplett 9y ago
        As I understand it, much of that work goes into removing any trace of even innocuous things like libsystemd, which is used by applications that want to support systemd if available. All the necessary work to support a non-systemd init is already in Debian, making Devuan fairly pointless in practice.
        eeZah7Ux 9y ago
        That's correct. Debian ships sysvinit as well as systemd and daemons have initscripts/confs for both. A lot of people still use sysvinit and it just works.
        rxlim 9y ago
        If this is really true, I might have to eat my own words.
        JoshTriplett 9y ago
        If you do run into cases where something doesn't work as expected with sysvinit instead of systemd, please do file a bug. For that matter, if this is a use case you care about, systemd-shim could use a maintainer or maintenance team: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832508 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832508
        agwa 9y ago
        Yes, it's true. To replace PID 1 with sysvinit, run: apt-get install sysvinit-core systemd-sysv- reboot To prevent it from coming back, create the file /etc/apt/preferences.d/no-systemd.pref containing: Package: systemd-sysv Pin: origin * Pin-Priority: -1 This works great on servers and lightweight desktops. As others have noted, if you want GNOME you also need to install systemd-shim. I have no experience with this, but I have no reason to doubt that it works.
jameskegel 9y ago
I would love some type of toggle, or "last chance to turn back" during install as far as being able to signal what type of init system I'd like to use.
- JdeBP 9y ago
  The problem is that no-one has incorporated a modification to the Debian installer to have this. There are so-called "preseed" hooks that one can use to manually alter what packages the Debian installer installs. Putting in place pre-seed hooks that permitted something other than systemd to be installed ab initio was one of the first things that the Devuan people did, about two and a half years ago. But no-one to my knowledge has yet done the work to give the Debian installer this capability without the need for pre-seed hooks, as a menu item/checkbox/question for the administrator to pick/tick/answer. Such work is more than merely writing code, note. It involves testing it too. Thoroughly. * https://wiki.debian.org/DebianInstaller/Preseed https://wiki.debian.org/DebianInstaller/Preseed * https://wiki.debian.org/systemd#Installing_without_systemd https://wiki.debian.org/systemd#Installing_without_systemd Ironically, this was once a problem the other way around. Attempted changes to enable administrators to select systemd at install time (and indeed upstart, as you can see) failed to make it past a Debian gatekeeper. * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668001 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668001
  - jlgaddis 9y ago
    Oh man, preseed is a pain in the ass too. I wish they'd support using kickstart files or that there were a kickstart to preseed conversion/migration tool.
ZenoArrow 9y ago
What do you dislike about systemd? Do you disagree with the ideas behind it, or is your discontentment more about the specific implementation of those ideas? Can you give examples?
- JdeBP 9y ago
  beefhash's explicitly stated rationale was reuniting the community. By attempting to derail this into yet another massive thread about the merits/demerits of systemd, rather than a discussion of the desired future and already present capabilities of the Debian installer, and putting words into beefhash´s mouth that xe did not say as you have done here, you are instigating exactly the opposite. * http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ http://uselessd.darknedgy.net/ProSystemdAntiSystemd/
  - ZenoArrow 9y ago
    >"you are instigating exactly the opposite" Not really. In order to 'reunite the community' you need to understand what that will take. Every init system that is supported adds an additional support burden onto the developers and maintainers that work on Debian. In order to minimise that work, it's important to understand the issues with the status quo. At one end of the spectrum, perhaps a few tweaks to systemd would be enough to satisfy most who had issues with it in the past. On the opposite end of the spectrum you have the distro needing to support 5+ init systems if there's little consensus about what a strong alternative to systemd would look like. The questions I asked previously are useful in understanding how much work would be required to 'reunite the community'. Feel free to answer them if you think this is a worthwhile line of inquiry.
  - pwdisswordfish 9y ago
    > http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ Dead link. Copy: http://archive.fo/5Gx8C http://archive.fo/5Gx8C
- falcolas 9y ago
  Not the OP, but: - It's effectively a black box that nobody but the systemd team really understands; and the response by said team to problems with systemd too often defaults to "you're doing it wrong" - Systemd is not just an init system, it's a message bus, authentication system, logging system, container management system, xinitd system, and any other number of highly coupled systems. - Service startup order can still be non-deterministic and fairly slow; hard init problems have been made harder, while easy init problems "only" remain easy. - Unit files can be stored in a minimum of four separate locations on disk, and this can be increased dynamically. - Failures are opaque, and the failure of systemd triggers the failure of the entire system. The original idea that drove systemd's creation is still fairly sound: create a simple, deterministic, and parallel init system which is better than initv. The implementation doesn't live up to those goals, and instead of iterating against that goal, the team's focus has shifted to take over all aspects of the Linux runtime which isn't managed by the kernel.

JoshTriplett 9y ago

Debian is already one of the few distributions that goes out of its way to provide support for non-systemd init systems. Beyond that, it would help if a non-systemd init system as capable as systemd existed; if one did, I'm sure that Debian would include it and support it. This is a case where the problem isn't "please package and support", it's "please develop".

rxlim 9y ago
> Debian is already one of the few distributions that goes out of its way to provide support for non-systemd init systems. How does this manifest itself in practice? I don't want to use systemd in Debian 9, what has been done so I can easily change to another init like runit? In practice it's not possible because of so many (unecessary) dependencies on systemd.
- JoshTriplett 9y ago
  It means that you can install sysvinit or any sysvinit-compatible init, and all daemon packages still provide init scripts, as painful as that is. And Debian still supports installing systemd-shim instead of systemd, so you can have a desktop system with a non-systemd init and it'll still function. > In practice it's not possible because of so many (unecessary) dependencies on systemd. Such as? As far as I can tell, almost nothing depends on systemd. A handful of things depend on libpam-systemd (for session management), which functions with systemd-shim.
  - rxlim 9y ago
    The amount of work that goes into Devuan for pulling out systemd of Debian Jessie is clear evidence that what you are saying is not easily possible.
    - JoshTriplett 9y ago
      As I understand it, much of that work goes into removing any trace of even innocuous things like libsystemd, which is used by applications that want to support systemd if available. All the necessary work to support a non-systemd init is already in Debian, making Devuan fairly pointless in practice.
      - eeZah7Ux 9y ago
        That's correct. Debian ships sysvinit as well as systemd and daemons have initscripts/confs for both. A lot of people still use sysvinit and it just works.
        rxlim 9y ago
        If this is really true, I might have to eat my own words.
        JoshTriplett 9y ago
        If you do run into cases where something doesn't work as expected with sysvinit instead of systemd, please do file a bug. For that matter, if this is a use case you care about, systemd-shim could use a maintainer or maintenance team: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832508 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832508
        agwa 9y ago
        Yes, it's true. To replace PID 1 with sysvinit, run: apt-get install sysvinit-core systemd-sysv- reboot To prevent it from coming back, create the file /etc/apt/preferences.d/no-systemd.pref containing: Package: systemd-sysv Pin: origin * Pin-Priority: -1 This works great on servers and lightweight desktops. As others have noted, if you want GNOME you also need to install systemd-shim. I have no experience with this, but I have no reason to doubt that it works.

jameskegel 9y ago

I would love some type of toggle, or "last chance to turn back" during install as far as being able to signal what type of init system I'd like to use.

JdeBP 9y ago
The problem is that no-one has incorporated a modification to the Debian installer to have this. There are so-called "preseed" hooks that one can use to manually alter what packages the Debian installer installs. Putting in place pre-seed hooks that permitted something other than systemd to be installed ab initio was one of the first things that the Devuan people did, about two and a half years ago. But no-one to my knowledge has yet done the work to give the Debian installer this capability without the need for pre-seed hooks, as a menu item/checkbox/question for the administrator to pick/tick/answer. Such work is more than merely writing code, note. It involves testing it too. Thoroughly. * https://wiki.debian.org/DebianInstaller/Preseed https://wiki.debian.org/DebianInstaller/Preseed * https://wiki.debian.org/systemd#Installing_without_systemd https://wiki.debian.org/systemd#Installing_without_systemd Ironically, this was once a problem the other way around. Attempted changes to enable administrators to select systemd at install time (and indeed upstart, as you can see) failed to make it past a Debian gatekeeper. * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668001 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668001
- jlgaddis 9y ago
  Oh man, preseed is a pain in the ass too. I wish they'd support using kickstart files or that there were a kickstart to preseed conversion/migration tool.

ZenoArrow 9y ago

What do you dislike about systemd? Do you disagree with the ideas behind it, or is your discontentment more about the specific implementation of those ideas? Can you give examples?

JdeBP 9y ago
beefhash's explicitly stated rationale was reuniting the community. By attempting to derail this into yet another massive thread about the merits/demerits of systemd, rather than a discussion of the desired future and already present capabilities of the Debian installer, and putting words into beefhash´s mouth that xe did not say as you have done here, you are instigating exactly the opposite. * http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ http://uselessd.darknedgy.net/ProSystemdAntiSystemd/
- ZenoArrow 9y ago
  >"you are instigating exactly the opposite" Not really. In order to 'reunite the community' you need to understand what that will take. Every init system that is supported adds an additional support burden onto the developers and maintainers that work on Debian. In order to minimise that work, it's important to understand the issues with the status quo. At one end of the spectrum, perhaps a few tweaks to systemd would be enough to satisfy most who had issues with it in the past. On the opposite end of the spectrum you have the distro needing to support 5+ init systems if there's little consensus about what a strong alternative to systemd would look like. The questions I asked previously are useful in understanding how much work would be required to 'reunite the community'. Feel free to answer them if you think this is a worthwhile line of inquiry.
- pwdisswordfish 9y ago
  > http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ Dead link. Copy: http://archive.fo/5Gx8C http://archive.fo/5Gx8C
falcolas 9y ago
Not the OP, but: - It's effectively a black box that nobody but the systemd team really understands; and the response by said team to problems with systemd too often defaults to "you're doing it wrong" - Systemd is not just an init system, it's a message bus, authentication system, logging system, container management system, xinitd system, and any other number of highly coupled systems. - Service startup order can still be non-deterministic and fairly slow; hard init problems have been made harder, while easy init problems "only" remain easy. - Unit files can be stored in a minimum of four separate locations on disk, and this can be increased dynamically. - Failures are opaque, and the failure of systemd triggers the failure of the entire system. The original idea that drove systemd's creation is still fairly sound: create a simple, deterministic, and parallel init system which is better than initv. The implementation doesn't live up to those goals, and instead of iterating against that goal, the team's focus has shifted to take over all aspects of the Linux runtime which isn't managed by the kernel.