4 ms·

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? Ca

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.
- ZenoArrow 9y ago
  Thank you for your response falcolas. Addressing your points: > "- 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"" Is this because the data being passed around is represented in binary form rather than text form (e.g. binary logs rather than text-based logs)? > "- 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." Sure, but this doesn't strike me as neccessarily bad. I appreciate the Unix philosophy is based around having a series of tools that serve a single purpose that can be chained together in different ways, but it's still a necessity to have common interfaces over which this chaining takes place. Is this again related to the binary vs. text issue? > "- 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." The non-determinism and speed of start up both strike me as major issues, thank you for mentioning them. Does anyone know if there are there plans to tackle these issues? > "- Unit files can be stored in a minimum of four separate locations on disk, and this can be increased dynamically." Again, this also seems like a reasonable complaint. Is this issue due to the intrinsic design of systemd or is this solely a flaw in the implementation? > "- Failures are opaque, and the failure of systemd triggers the failure of the entire system." Are there no fallbacks in place should a systemd component fail? I see no reason why this couldn't be implemented. > "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." I don't disagree with that assessment, but there must be reasons why systemd is proving popular amongst distro maintainers. Why would you suggest that is? What advantages do you gain from having a unified layer that provides the services that systemd provides?

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.

ZenoArrow 9y ago
Thank you for your response falcolas. Addressing your points: > "- 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"" Is this because the data being passed around is represented in binary form rather than text form (e.g. binary logs rather than text-based logs)? > "- 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." Sure, but this doesn't strike me as neccessarily bad. I appreciate the Unix philosophy is based around having a series of tools that serve a single purpose that can be chained together in different ways, but it's still a necessity to have common interfaces over which this chaining takes place. Is this again related to the binary vs. text issue? > "- 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." The non-determinism and speed of start up both strike me as major issues, thank you for mentioning them. Does anyone know if there are there plans to tackle these issues? > "- Unit files can be stored in a minimum of four separate locations on disk, and this can be increased dynamically." Again, this also seems like a reasonable complaint. Is this issue due to the intrinsic design of systemd or is this solely a flaw in the implementation? > "- Failures are opaque, and the failure of systemd triggers the failure of the entire system." Are there no fallbacks in place should a systemd component fail? I see no reason why this couldn't be implemented. > "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." I don't disagree with that assessment, but there must be reasons why systemd is proving popular amongst distro maintainers. Why would you suggest that is? What advantages do you gain from having a unified layer that provides the services that systemd provides?