6 ms·

How can people replace SysVinit without "doing their own take on EEE"? Your alternative approach is still not going to be compatible with SysVinit either, not t

How can people replace SysVinit without "doing their own take on EEE"? Your alternative approach is still not going to be compatible with SysVinit either, not to mention it being strikingly similar to systemd.

welterde 6y ago
Archlinux had their own non-sysvinit system (which went away in favor of systemd) as does voidlinux (runit based) and alpine (OpenRC) today. The problem is less the init system itself, but applications that depend on a specific init system [1] (gnome used to be a major source of contention in that regard). [1] https://wiki.gentoo.org/wiki/Hard_dependencies_on_systemd https://wiki.gentoo.org/wiki/Hard_dependencies_on_systemd
- soraminazuki 6y ago
  Is applications depending on systemd particularly a bad thing? If we don't want applications to use non-SysVinit features, we might as well keep using SysVinit.
  - na85 6y ago
    Why should my window manager dictate what programs are allowed to start it?
    - AsyncAwait 6y ago
      For the same reason every piece of software 'dictates' its dependencies.
  - welterde 6y ago
    If you don't care about portability at all.. (regardless if it's just within linux or to *BSD). And like I already mentioned in my previous post.. there are other alternatives around than just SysV-init..
- Valmar 6y ago
  What apps depend on a specific init system? Gnome does not depend on systemd, but rather logind. KDE used to be the same, until someone started maintaining ConsoleKit2 again, proper, at which point they were happy to support it. ConsoleKit was dropped because it just wasn't being maintained, and had various limitations.
  - traverseda 6y ago
    Why does logind depend on systemd?
    - Valmar 6y ago
      It's part of the systemd project umbrella? It's part of the systemd monorepo? It uses libsystemd? Maybe it's simply easier to maintain this way? elogind exists, if you care. It exposes the DBus interfaces that logind supports for applications to call. Thus, environments like Gnome can be supported on non-systemd systems if they emulate and/or expose and implement the required DBus interfaces.
      - traverseda 6y ago
        That's sort of the complaint, why I accused them of "doing their own weird version of EEE". When faced with a choice of "make everybody else do a whole bunch of work so that they're not forced to use your entire project-umbrella" or "make some minor changes to our architecture so things aren't as tightly coupled" they almost always choose the one that forces you to use systemd.
        AsyncAwait 6y ago
        logind has a stable API, it is possible to build alternative implementations not coupled to systemd, yet so far I don't see much on that front. See also https://lwn.net/Articles/586141 https://lwn.net/Articles/586141
        the_why_of_y 6y ago
        To the extent that you believe that free software development should work such that random people on internet forums dictate the architecture to the people who are doing the work, and instead of writing their software to solve problems that actual users have, they should comply with these whims, you better prepare to be disappointed.
traverseda 6y ago
>How can people replace SysVinit without "doing their own take on EEE"? By not tightly bundling their init with other OS components, by not having GNOME desktop somehow depend on what init system you're using (as opposed to services running under that init system). Also you know how shell scripts have `#!/usr/bin/env bash` at the top of them? Well the reason why my hypothetical init system would be compatible with SysVinit is because instead of `#!/usr/bin/env bash` it would have `#!/usr/bin/env new_init_language` at the top of it. 'new_init_language" could implement almost all the same features that systemd unit files do.

welterde 6y ago

Archlinux had their own non-sysvinit system (which went away in favor of systemd) as does voidlinux (runit based) and alpine (OpenRC) today. The problem is less the init system itself, but applications that depend on a specific init system [1] (gnome used to be a major source of contention in that regard). [1] https://wiki.gentoo.org/wiki/Hard_dependencies_on_systemd https://wiki.gentoo.org/wiki/Hard_dependencies_on_systemd

soraminazuki 6y ago
Is applications depending on systemd particularly a bad thing? If we don't want applications to use non-SysVinit features, we might as well keep using SysVinit.
- na85 6y ago
  Why should my window manager dictate what programs are allowed to start it?
  - AsyncAwait 6y ago
    For the same reason every piece of software 'dictates' its dependencies.
- welterde 6y ago
  If you don't care about portability at all.. (regardless if it's just within linux or to *BSD). And like I already mentioned in my previous post.. there are other alternatives around than just SysV-init..
Valmar 6y ago
What apps depend on a specific init system? Gnome does not depend on systemd, but rather logind. KDE used to be the same, until someone started maintaining ConsoleKit2 again, proper, at which point they were happy to support it. ConsoleKit was dropped because it just wasn't being maintained, and had various limitations.
- traverseda 6y ago
  Why does logind depend on systemd?
  - Valmar 6y ago
    It's part of the systemd project umbrella? It's part of the systemd monorepo? It uses libsystemd? Maybe it's simply easier to maintain this way? elogind exists, if you care. It exposes the DBus interfaces that logind supports for applications to call. Thus, environments like Gnome can be supported on non-systemd systems if they emulate and/or expose and implement the required DBus interfaces.
    - traverseda 6y ago
      That's sort of the complaint, why I accused them of "doing their own weird version of EEE". When faced with a choice of "make everybody else do a whole bunch of work so that they're not forced to use your entire project-umbrella" or "make some minor changes to our architecture so things aren't as tightly coupled" they almost always choose the one that forces you to use systemd.
      - AsyncAwait 6y ago
        logind has a stable API, it is possible to build alternative implementations not coupled to systemd, yet so far I don't see much on that front. See also https://lwn.net/Articles/586141 https://lwn.net/Articles/586141
      - the_why_of_y 6y ago
        To the extent that you believe that free software development should work such that random people on internet forums dictate the architecture to the people who are doing the work, and instead of writing their software to solve problems that actual users have, they should comply with these whims, you better prepare to be disappointed.

traverseda 6y ago

>How can people replace SysVinit without "doing their own take on EEE"? By not tightly bundling their init with other OS components, by not having GNOME desktop somehow depend on what init system you're using (as opposed to services running under that init system). Also you know how shell scripts have `#!/usr/bin/env bash` at the top of them? Well the reason why my hypothetical init system would be compatible with SysVinit is because instead of `#!/usr/bin/env bash` it would have `#!/usr/bin/env new_init_language` at the top of it. 'new_init_language" could implement almost all the same features that systemd unit files do.