15 ms·

None of those feature require systemd. > cgroups Works fine on my Gentoo (OpenRC) desktop. This meme that systemd is necessary for cgroups is simply incorrect

by pdkl95 11y ago

None of those feature require systemd. > cgroups Works fine on my Gentoo (OpenRC) desktop. This meme that systemd is necessary for cgroups is simply incorrect. > sockets We stopped using xinetd a loooooong time ago. If you want to use a central point of failure, that's your business. > dbus Isn't necessary in the init process, though you're free to use it if you wish. > didn't used to exist Such as? > replacement for these features The replacement in some cases should be "nothing". You're trying to frame the conversation in a way that presumes features like cgroups or "socket activation" are desired features. The entire point of this "debate" is that you shouldn't be tying extra features to the init process. There are a wide variety of systems in the Linux ecosystem, and there is no one-size-fits-all solution. If you want to run a heavyweight, opinionated, monolithic init like systemd, that's fine. If it makes your life easier, that's great. Just remember that other people have different requirements.

dredmorbius 11y ago
Downvote brigades on factually correct posts you happen not to agree with aren't cricket.
- TheyW0ntL1sten 11y ago
  Except that they are on this site and have been so I quit using a single account to ever post anything. If you are actually a contrarian good luck ever even getting to the point where you can downvote other posts.
  - dredmorbius 11y ago
    I do all right. State my piece, supply evidence, and avoid idiotic fights. There's always someone wrong on the Internet. #386.
tomjakubowski 11y ago
"foo knows about X, Y, and Z" doesn't mean the same thing as "foo is required for X, Y, and Z". > > replacement for these features Did GP edit their comment? The quotes and arguments you're arguing with aren't present in it. > We stopped using xinetd a loooooong time ago. If you want to use a central point of failure, that's your business. An init system that groks socket activation yields more benefits than just lazy service startup. Services which communicate over a socket can be more loosely coupled, and a service need not be a traditional "forking daemon" for dependent services to start up at the correct time (since , say, the dependency's UNIX domain socket is already created, they can all start in parallel). edit: I edited the last paragraph in 20 minutes after posting.
vidarh 11y ago
> Works fine on my Gentoo (OpenRC) desktop. This meme that systemd is necessary for cgroups is simply incorrect. That's not what it's about. The point of cgroups integration in systemd is that it allows systemd to precisely track the processes started under it, which means that e.g. applications where things like double-forking or similar happens can still be completely stopped by systemd even if the parent process des. > You're trying to frame the conversation in a way that presumes features like cgroups or "socket activation" are desired features. They are to me. They massively improves things vs. sysvinit. > The entire point of this "debate" is that you shouldn't be tying extra features to the init process. The entire starting point for systemd is that traditional sysvinit is woefully lacking in the functionality required to build reliable systems. And when you start trying to cobble together something on top of it, it quickly becomes clear that it is not easy. E.g. try to build a reliable process manager outside of pid 1. You still need process restarting functionality in pid 1 for when your process manager dies. What if it fails to restart? How are you going to log those failures reliably? You end up duplicating a lot of functionality of a process manager in pid 1 if you want a reliable system even if you run a separate process manager outside of pid 1. There are parts of the systemd design I don't agree with, and I think they'd benefit from splitting out various components from the project, not least for "political" reasons. But the design for the core parts of systemd-the-init-system largely follow on from a very limited set of core requirements of being able to reliably start, stop and keep services running and reliably log data from them. These are requirements that sysvinit basically throws it hands up at and says "not my table", while by owning pid 1 they make it basically impossible to meet them.
- pdkl95 11y ago
  > The point of cgroups integration in systemd I know why systemd uses cgroups. I was addressing the myth that systemd is required to use cgroups. > They are to me. That's nice. You should use systemd if its features satisfy your requirements better than the other options. Other people have different requirements. Is this concept difficult to understand? We don't want the same features, for a variety of reasons. Disagreement is fine, but systemd advocates often seem to want a monoculture. > the functionality required to build reliable systems That's your opinion, which you're entitled to. I disagree, as I've never had problems like you're describing. I value stability a very strongly, so I consider the methods that worked fine over the past 20+ years. > requirements That's the framing I was talking about. There is more than one way to design a stable system, and your requirement list is only one of those methods. Some of those requirements I consider misfeatures that cause problems, but it's fine if you disagree. > impossible to meet them Then use systemd or some other solution that solves your needs. Is it so hard to understand that we can choose different software?

by pdkl95 11y ago

dredmorbius 11y ago

Downvote brigades on factually correct posts you happen not to agree with aren't cricket.

TheyW0ntL1sten 11y ago
Except that they are on this site and have been so I quit using a single account to ever post anything. If you are actually a contrarian good luck ever even getting to the point where you can downvote other posts.
- dredmorbius 11y ago
  I do all right. State my piece, supply evidence, and avoid idiotic fights. There's always someone wrong on the Internet. #386.

tomjakubowski 11y ago

"foo knows about X, Y, and Z" doesn't mean the same thing as "foo is required for X, Y, and Z". > > replacement for these features Did GP edit their comment? The quotes and arguments you're arguing with aren't present in it. > We stopped using xinetd a loooooong time ago. If you want to use a central point of failure, that's your business. An init system that groks socket activation yields more benefits than just lazy service startup. Services which communicate over a socket can be more loosely coupled, and a service need not be a traditional "forking daemon" for dependent services to start up at the correct time (since , say, the dependency's UNIX domain socket is already created, they can all start in parallel). edit: I edited the last paragraph in 20 minutes after posting.

vidarh 11y ago

> Works fine on my Gentoo (OpenRC) desktop. This meme that systemd is necessary for cgroups is simply incorrect. That's not what it's about. The point of cgroups integration in systemd is that it allows systemd to precisely track the processes started under it, which means that e.g. applications where things like double-forking or similar happens can still be completely stopped by systemd even if the parent process des. > You're trying to frame the conversation in a way that presumes features like cgroups or "socket activation" are desired features. They are to me. They massively improves things vs. sysvinit. > The entire point of this "debate" is that you shouldn't be tying extra features to the init process. The entire starting point for systemd is that traditional sysvinit is woefully lacking in the functionality required to build reliable systems. And when you start trying to cobble together something on top of it, it quickly becomes clear that it is not easy. E.g. try to build a reliable process manager outside of pid 1. You still need process restarting functionality in pid 1 for when your process manager dies. What if it fails to restart? How are you going to log those failures reliably? You end up duplicating a lot of functionality of a process manager in pid 1 if you want a reliable system even if you run a separate process manager outside of pid 1. There are parts of the systemd design I don't agree with, and I think they'd benefit from splitting out various components from the project, not least for "political" reasons. But the design for the core parts of systemd-the-init-system largely follow on from a very limited set of core requirements of being able to reliably start, stop and keep services running and reliably log data from them. These are requirements that sysvinit basically throws it hands up at and says "not my table", while by owning pid 1 they make it basically impossible to meet them.

pdkl95 11y ago
> The point of cgroups integration in systemd I know why systemd uses cgroups. I was addressing the myth that systemd is required to use cgroups. > They are to me. That's nice. You should use systemd if its features satisfy your requirements better than the other options. Other people have different requirements. Is this concept difficult to understand? We don't want the same features, for a variety of reasons. Disagreement is fine, but systemd advocates often seem to want a monoculture. > the functionality required to build reliable systems That's your opinion, which you're entitled to. I disagree, as I've never had problems like you're describing. I value stability a very strongly, so I consider the methods that worked fine over the past 20+ years. > requirements That's the framing I was talking about. There is more than one way to design a stable system, and your requirement list is only one of those methods. Some of those requirements I consider misfeatures that cause problems, but it's fine if you disagree. > impossible to meet them Then use systemd or some other solution that solves your needs. Is it so hard to understand that we can choose different software?