4 ms·

> does ONE thing and does it well: it manages the system "managing the system" is not "ONE [problem]". A big part of the problem with systemd is this presuppos

by pdkl95 7y ago

> does ONE thing and does it well: it manages the system "managing the system" is not "ONE [problem]". A big part of the problem with systemd is this presupposition that management of something as large and complex as a modern OS is a single monolithic[1] problem. > it's complex because it does a complex work. See, you agree that it's a complex problem! It's so complex with so many different use cases it isn't even possible to have one solution, because some of those use cases are mutually exclusive. Hench why a modular design is important, so it isn't too difficult to replace the management of different areas if needed. > It's the missing layer between kernel space and user space. That "missing layer" isn't well defined. There certainly wasn't any "missing layer" on my old server, or the compute boxen we used at ${research_lab}. If you're talking about desktop system, I agree that there was a gap between traditional system management and the GUI, but that isn't really a new "layer" between kernal and user space (it might involve GUI userspace programs with perhaps some of them being SETUID or a privileged daemon). [1] Any objections trying to claim systemd isn't a tightly coupled, monolithic design will be ignored. If you think the number of binary program files is in any way useful as an objection, see: https://news.ycombinator.com/item?id=19024256 https://news.ycombinator.com/item?id=19024256

ninkendo 7y ago
> it isn't even possible to have one solution, because some of those use cases are mutually exclusive Could you elaborate? What of systemd’s use cases conflict with one another?
AsyncAwait 7y ago
You still have s6, openRC etc. as choices, but it's funny that nobody of the anti-systemd folk was willing to pick up the work needed to maintain consolekit, yet when logind came around, had lots of strong things to say. How about picking up the work as well? And none of the alternatives seem to really get away from the bash script paradigm & more towards the declarative side of things, which doesn't feel like much beyond keeping all that was terrible about sysvinit around in thin wrappers. Maybe GuixSD is the one exception to this.
- pdkl95 7y ago
  > nobody of the anti-systemd folk was willing to pick up the work needed to maintain consolekit Why would I want to start working on software I don't use or need? Why do systemd advocates always insist that every implementation must include the features they think are important? The entire point of designing for modularity is that different people have different requirements; operating systems cannot be "one size fits all". > yet when logind came around, had lots of strong things to say. Yes, we had strong things to say about software requiring logind, because it is a terrible (and poorly documented, at least at the time) design. If you want to use logind, go right ahead, that's your choice. We were (and are) only angry about software that we used to be able to use adding dependencies to logind (or other systemd components). > And none of the alternatives seem to really get away from the bash script paradigm That probably won't happen, because shell scripting is the easiest/simplest solution for certain types of problems. Some of us have tried a lot of variatio9ns, and keep returning to openrc/bash because it's easier and has fewer problems, at least in some situations. However, on a traditional system (or openrc) nothing is stopping you from replacing the bash init scripts with another language or replacing the entire init subsystem with something else (like upstart, s6, something new?). The complaint isn't that your should use my favorite tools (like bash) instead of systemd; it's that we should strive for modular software so we can all use the components that work best for our different needs,
  - AsyncAwait 7y ago
    > Why would I want to start working on software I don't use or need? Why do systemd advocates always insist that every implementation must include the features they think are important? If you don't care about multi-user session management, sure, but considering practically every window manager/DE relied on consolekit and now logind to provide that functionality, I find it hard to believe it's not desirable by a large majority of users, some of which would belong to the group I was talking about. I love how people who are obliviously not the target audience feel the need to chime in. > Yes, we had strong things to say about software requiring logind, because it is a terrible (and poorly documented, at least at the time) design. I agree about the lacking documentation, but in terms of design it seems quite solid. Any technical specifics as to why it is terrible? It's interesting that systemd's detractors always seem to be rather vague in this regard, makes me suspicious as to whether they did more than have a knee-jerk reaction to a tool that is different than what they used before. > because it's easier and has fewer problems, at least in some situations Am going to need specifics, because in my experience, the bash scripts always ended up being a hot mess of variable quality as per the individual author's scripting skills with inconsistent behavior across scripts. Not to mention that none of the alternatives give me the functionality I want, because their authors strictly focus on the init part, whereas systemd's much more useful even after the system is up and running due to its event driven nature. Now I realize that not everybody needs some of the extra features, but for those of us that do, (like container management), s6, openRC etc. is even less of an alternative in a real sense. > nothing is stopping you from replacing the bash init scripts with another language The init system needs to be designed to support declarative services from the get go, am not simply talking about using Perl instead of bash here, am talking more along the lines of the Nix vs apt paradigm. > or replacing the entire init subsystem with something else And is something stooping you? This is my biggest gripe with the anti-systemd crowd, am personally happy with systemd, so it's not me who needs to look for alternatives. It's you. And there are plenty, so please pick one that suits you. The constant anti-systemd bashing every time the name is mentioned from people who seem to barely know much about what it's trying, (rather successfully), to do is rather annoying.
znpy 7y ago
A nice talk that might change your view of the subject is the following: https://www.youtube.com/watch?v=6AeWu1fZ7bY https://www.youtube.com/watch?v=6AeWu1fZ7bY . It's a video from BSDCan, the Canadian BSD conference. Even some BSD people are realizing that systemd has a good point to exist!

by pdkl95 7y ago

ninkendo 7y ago

> it isn't even possible to have one solution, because some of those use cases are mutually exclusive Could you elaborate? What of systemd’s use cases conflict with one another?

AsyncAwait 7y ago

You still have s6, openRC etc. as choices, but it's funny that nobody of the anti-systemd folk was willing to pick up the work needed to maintain consolekit, yet when logind came around, had lots of strong things to say. How about picking up the work as well? And none of the alternatives seem to really get away from the bash script paradigm & more towards the declarative side of things, which doesn't feel like much beyond keeping all that was terrible about sysvinit around in thin wrappers. Maybe GuixSD is the one exception to this.

pdkl95 7y ago
> nobody of the anti-systemd folk was willing to pick up the work needed to maintain consolekit Why would I want to start working on software I don't use or need? Why do systemd advocates always insist that every implementation must include the features they think are important? The entire point of designing for modularity is that different people have different requirements; operating systems cannot be "one size fits all". > yet when logind came around, had lots of strong things to say. Yes, we had strong things to say about software requiring logind, because it is a terrible (and poorly documented, at least at the time) design. If you want to use logind, go right ahead, that's your choice. We were (and are) only angry about software that we used to be able to use adding dependencies to logind (or other systemd components). > And none of the alternatives seem to really get away from the bash script paradigm That probably won't happen, because shell scripting is the easiest/simplest solution for certain types of problems. Some of us have tried a lot of variatio9ns, and keep returning to openrc/bash because it's easier and has fewer problems, at least in some situations. However, on a traditional system (or openrc) nothing is stopping you from replacing the bash init scripts with another language or replacing the entire init subsystem with something else (like upstart, s6, something new?). The complaint isn't that your should use my favorite tools (like bash) instead of systemd; it's that we should strive for modular software so we can all use the components that work best for our different needs,
- AsyncAwait 7y ago
  > Why would I want to start working on software I don't use or need? Why do systemd advocates always insist that every implementation must include the features they think are important? If you don't care about multi-user session management, sure, but considering practically every window manager/DE relied on consolekit and now logind to provide that functionality, I find it hard to believe it's not desirable by a large majority of users, some of which would belong to the group I was talking about. I love how people who are obliviously not the target audience feel the need to chime in. > Yes, we had strong things to say about software requiring logind, because it is a terrible (and poorly documented, at least at the time) design. I agree about the lacking documentation, but in terms of design it seems quite solid. Any technical specifics as to why it is terrible? It's interesting that systemd's detractors always seem to be rather vague in this regard, makes me suspicious as to whether they did more than have a knee-jerk reaction to a tool that is different than what they used before. > because it's easier and has fewer problems, at least in some situations Am going to need specifics, because in my experience, the bash scripts always ended up being a hot mess of variable quality as per the individual author's scripting skills with inconsistent behavior across scripts. Not to mention that none of the alternatives give me the functionality I want, because their authors strictly focus on the init part, whereas systemd's much more useful even after the system is up and running due to its event driven nature. Now I realize that not everybody needs some of the extra features, but for those of us that do, (like container management), s6, openRC etc. is even less of an alternative in a real sense. > nothing is stopping you from replacing the bash init scripts with another language The init system needs to be designed to support declarative services from the get go, am not simply talking about using Perl instead of bash here, am talking more along the lines of the Nix vs apt paradigm. > or replacing the entire init subsystem with something else And is something stooping you? This is my biggest gripe with the anti-systemd crowd, am personally happy with systemd, so it's not me who needs to look for alternatives. It's you. And there are plenty, so please pick one that suits you. The constant anti-systemd bashing every time the name is mentioned from people who seem to barely know much about what it's trying, (rather successfully), to do is rather annoying.

znpy 7y ago

A nice talk that might change your view of the subject is the following: https://www.youtube.com/watch?v=6AeWu1fZ7bY https://www.youtube.com/watch?v=6AeWu1fZ7bY . It's a video from BSDCan, the Canadian BSD conference. Even some BSD people are realizing that systemd has a good point to exist!