4 ms·

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 re

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?

falcolas 9y ago
> Is this because the data being passed around is represented in binary form rather than text form None of my complaints relate to binary vs. text. Both have their strengths and weaknesses, and while binary data requires new set of tooling, I intentionally did not mention it because of how contentious it is to even bring up. > Sure, but this doesn't strike me as neccessarily bad. It's just not necessary. This all worked before. Not always perfectly, and sometimes even poorly... but it worked. And importantly, it worked without requiring the authentication system, message bus (tied into the kernel), custom logging, and init all to be tied together. > What advantages do you gain from having a unified layer that provides the services that systemd provides? Personally? None - no advantages. Consider where I'm coming from - I've run Linux on the desktop and server for years (perhaps even before systemd was a glimmer in Pottering's eye). I've written software which ran on startup (including the sysvinit scripts), done init troubleshooting... and it all just worked. Without reasonable gains in speed, and without resolving the determinism problem, and given a world in which supervisord, daemontools, and LXC exist... systemd just doesn't bring anything to the table that I've been asking for. Instead, it's brought a whole new toolset I have to now learn, and a ton more complexity and opacity.

falcolas 9y ago

> Is this because the data being passed around is represented in binary form rather than text form None of my complaints relate to binary vs. text. Both have their strengths and weaknesses, and while binary data requires new set of tooling, I intentionally did not mention it because of how contentious it is to even bring up. > Sure, but this doesn't strike me as neccessarily bad. It's just not necessary. This all worked before. Not always perfectly, and sometimes even poorly... but it worked. And importantly, it worked without requiring the authentication system, message bus (tied into the kernel), custom logging, and init all to be tied together. > What advantages do you gain from having a unified layer that provides the services that systemd provides? Personally? None - no advantages. Consider where I'm coming from - I've run Linux on the desktop and server for years (perhaps even before systemd was a glimmer in Pottering's eye). I've written software which ran on startup (including the sysvinit scripts), done init troubleshooting... and it all just worked. Without reasonable gains in speed, and without resolving the determinism problem, and given a world in which supervisord, daemontools, and LXC exist... systemd just doesn't bring anything to the table that I've been asking for. Instead, it's brought a whole new toolset I have to now learn, and a ton more complexity and opacity.