6 ms·

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, ye

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.
  - makomk 7y ago
    Not many users care about multi-user session management. An even tinier number of users care about multi-seat session management (which is when you have mutiple users on the same machine at the same time, with their own screen and input devices). Pretty much every desktop Linux user cares about being able to click options like "shutdown", "restart" and "suspend" in the user interface and have them work. As it currently stands, anyone who wants that basic functionality on Linux - something that's been supported on all other platforms since forever - has to drag along all the baroque undocumented complexity of multi-seat, multi-user support. Why? Well, it seems Red Hat has some customers who sell solutions based on that, or at least used to once upon a time... With the current price of a docking station used to support a single seat in such a setup being comparable to that of a fairly decent refurbished SFF PC, I can't see a huge market for this.
StreamBright 7y ago
I think that you are missing the point. I was quite happy without systemd. What work has to be picked up really? You are trying to make it sound we could not live without systemd and we must replace the systems. If you want to write a better init system, go for it. Many people tried and succeeded none of them became the standard for linux (partially because there are no standards in linux). https://unix.stackexchange.com/questions/5877/what-are-the-pros-cons-of-upstart-and-systemd https://unix.stackexchange.com/questions/5877/what-are-the-p... As I said in other comments, if you want to replace inis scripts with systemd format service descriptors I will support your efforts becuase using shell script is broken. If you in the making of replacing init with something better also replace logging, ntp, dns, dhcp and a bunch of more then I will say no. This is exactly what systemd does. Rewriting rock solid, CPU efficient code with something shaky and CPU intensive. No thanks. >>> And none of the alternatives seem to really get away from the bash script paradigm. Factually incorrect. There are many init alternatives that got away from the shell script paradigm. Including SMF in Solaris. https://www.thegeekdiary.com/a-beginners-guide-to-service-management-facility-smf-in-solaris/ https://www.thegeekdiary.com/a-beginners-guide-to-service-ma...
- AsyncAwait 7y ago
  > I was quite happy without systemd. Good for you then. I am sure you were happy with X11's rotting core & didn't need Wayland in your life, you also likely weren't the one having to maintain its decades old codebase. > If you want to write a better init system, go for it. Am personally happy with systemd, thanks, if you're not, why don't you go ahead and write a better one, instead of complaining every time systemd's name is mentioned? > This is exactly what systemd does. Rewriting rock solid, CPU efficient code with something shaky and CPU intensive. That doesn't seem factual. systemd is a system manager, useful even after the system is booted up, I think people need to understand that first, it's not just an init system, because many modern services fit an event driven model these days. It's written in C and can run fine on tiny embedded systems. > Factually incorrect. There are many init alternatives that got away from the shell script paradigm. Including SMF in Solaris. Yeah, and launchd on macOS, by which systemd was literally inspired by, we're talking about Linux here, since that's where systemd runs, at least I was.

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.
- makomk 7y ago
  Not many users care about multi-user session management. An even tinier number of users care about multi-seat session management (which is when you have mutiple users on the same machine at the same time, with their own screen and input devices). Pretty much every desktop Linux user cares about being able to click options like "shutdown", "restart" and "suspend" in the user interface and have them work. As it currently stands, anyone who wants that basic functionality on Linux - something that's been supported on all other platforms since forever - has to drag along all the baroque undocumented complexity of multi-seat, multi-user support. Why? Well, it seems Red Hat has some customers who sell solutions based on that, or at least used to once upon a time... With the current price of a docking station used to support a single seat in such a setup being comparable to that of a fairly decent refurbished SFF PC, I can't see a huge market for this.

StreamBright 7y ago

I think that you are missing the point. I was quite happy without systemd. What work has to be picked up really? You are trying to make it sound we could not live without systemd and we must replace the systems. If you want to write a better init system, go for it. Many people tried and succeeded none of them became the standard for linux (partially because there are no standards in linux). https://unix.stackexchange.com/questions/5877/what-are-the-pros-cons-of-upstart-and-systemd https://unix.stackexchange.com/questions/5877/what-are-the-p... As I said in other comments, if you want to replace inis scripts with systemd format service descriptors I will support your efforts becuase using shell script is broken. If you in the making of replacing init with something better also replace logging, ntp, dns, dhcp and a bunch of more then I will say no. This is exactly what systemd does. Rewriting rock solid, CPU efficient code with something shaky and CPU intensive. No thanks. >>> And none of the alternatives seem to really get away from the bash script paradigm. Factually incorrect. There are many init alternatives that got away from the shell script paradigm. Including SMF in Solaris. https://www.thegeekdiary.com/a-beginners-guide-to-service-management-facility-smf-in-solaris/ https://www.thegeekdiary.com/a-beginners-guide-to-service-ma...

AsyncAwait 7y ago
> I was quite happy without systemd. Good for you then. I am sure you were happy with X11's rotting core & didn't need Wayland in your life, you also likely weren't the one having to maintain its decades old codebase. > If you want to write a better init system, go for it. Am personally happy with systemd, thanks, if you're not, why don't you go ahead and write a better one, instead of complaining every time systemd's name is mentioned? > This is exactly what systemd does. Rewriting rock solid, CPU efficient code with something shaky and CPU intensive. That doesn't seem factual. systemd is a system manager, useful even after the system is booted up, I think people need to understand that first, it's not just an init system, because many modern services fit an event driven model these days. It's written in C and can run fine on tiny embedded systems. > Factually incorrect. There are many init alternatives that got away from the shell script paradigm. Including SMF in Solaris. Yeah, and launchd on macOS, by which systemd was literally inspired by, we're talking about Linux here, since that's where systemd runs, at least I was.