4 ms·

This is partially true but a little disingenuous, I think. Though it hasn't been true for a very long time that all components of a system "do one thing, and do

by burke 10y ago

This is partially true but a little disingenuous, I think. Though it hasn't been true for a very long time that all components of a system "do one thing, and do it well", systemd introduces a large component that is very difficult to replace in a piecemeal fashion. For me, the UNIX philosophy has not been about the tools, but about replaceability. Systemd has made itself nigh on impossible to replace.

CaptSpify 10y ago
systemd may be convenient for now, but what about long-term? If it stops being convenient, tearing it out is going to be a long and horrible process. But nobody is thinking about that because "init-scripts sucked". Yes, they did, but that ignores the long-term issues that systemd brings to the table.
- kbenson 10y ago
  > If it stops being convenient, tearing it out is going to be a long and horrible process. The SysV init system stopped being convenient for some number of people, so they replaced it, and it has been a long and horrible process. It will happen again if it needs to. > But nobody is thinking about that because "init-scripts sucked". Well, now they're thinking about it, and talking about it every time they bring up problems with systemd. Those problems and discussions are something that will be brought up when any potential future init system is being designed or advocated for.
  - CaptSpify 10y ago
    > The SysV init system stopped being convenient for some number of people, so they replaced it, and it has been a long and horrible process. It will happen again if it needs to. Instead of learning from that mistake, systemd just doubles-down on it. systemd will be much harder than SysV to replace because it includes more than SysV stuff. It will happen if it needs to, but why not just make it easy to replace if it needs to? (answer, IMO: insecurities about your product make you want to entrench yourself instead of constantly improve it) > Well, now they're thinking about it, and talking about it every time they bring up problems with systemd. Those problems and discussions are something that will be brought up when any potential future init system is being designed or advocated for. Sure, but why not do that now? instead of pushing it off for people in the future to figure out?
    - kbenson 10y ago
      > Instead of learning from that mistake, systemd just doubles-down on it. Well, I was actually talking about future successors. What systemd did right and wrong at a technical level, as well as at a marketing, design and adoption level, will obviously have been internalized to a greater or lesser degree depending on the aspect being considered and the person doing the consideration. > systemd will be much harder than SysV to replace because it includes more than SysV stuff. I don't think so. There are a plethora of other init systems that have either been started in response, and people work out how to get those into these different distributions. The market for init systems is more vibrant than it ever has been, so any eventual successor gets to reap the benefits of everyone's collective experience in this area. Systemd may be overtaking most the large distributions, but let's not pretend the init system in linux, what it interacts with, and what's required to replace some or all of one init system with another aren't far better understood than they were a decade ago. > why not just make it easy to replace if it needs to? It may not be easy to replace, but it's far from impossible, and it's getting easier and better understood all the time because of people that don't want to run systemd. That's a good thing. > Sure, but why not do that now? instead of pushing it off for people in the future to figure out? Because regardless of how much it seems like people dislike systemd, I'm confident the majority of people either didn't notice, don't care, or like the new features enough to outweigh their dislike of other aspects. I would be happy to consider data that points to an alternate conclusion, but there's a reason why it's taking over, even if there are problematic aspects.

by burke 10y ago

CaptSpify 10y ago

systemd may be convenient for now, but what about long-term? If it stops being convenient, tearing it out is going to be a long and horrible process. But nobody is thinking about that because "init-scripts sucked". Yes, they did, but that ignores the long-term issues that systemd brings to the table.

kbenson 10y ago
> If it stops being convenient, tearing it out is going to be a long and horrible process. The SysV init system stopped being convenient for some number of people, so they replaced it, and it has been a long and horrible process. It will happen again if it needs to. > But nobody is thinking about that because "init-scripts sucked". Well, now they're thinking about it, and talking about it every time they bring up problems with systemd. Those problems and discussions are something that will be brought up when any potential future init system is being designed or advocated for.
- CaptSpify 10y ago
  > The SysV init system stopped being convenient for some number of people, so they replaced it, and it has been a long and horrible process. It will happen again if it needs to. Instead of learning from that mistake, systemd just doubles-down on it. systemd will be much harder than SysV to replace because it includes more than SysV stuff. It will happen if it needs to, but why not just make it easy to replace if it needs to? (answer, IMO: insecurities about your product make you want to entrench yourself instead of constantly improve it) > Well, now they're thinking about it, and talking about it every time they bring up problems with systemd. Those problems and discussions are something that will be brought up when any potential future init system is being designed or advocated for. Sure, but why not do that now? instead of pushing it off for people in the future to figure out?
  - kbenson 10y ago
    > Instead of learning from that mistake, systemd just doubles-down on it. Well, I was actually talking about future successors. What systemd did right and wrong at a technical level, as well as at a marketing, design and adoption level, will obviously have been internalized to a greater or lesser degree depending on the aspect being considered and the person doing the consideration. > systemd will be much harder than SysV to replace because it includes more than SysV stuff. I don't think so. There are a plethora of other init systems that have either been started in response, and people work out how to get those into these different distributions. The market for init systems is more vibrant than it ever has been, so any eventual successor gets to reap the benefits of everyone's collective experience in this area. Systemd may be overtaking most the large distributions, but let's not pretend the init system in linux, what it interacts with, and what's required to replace some or all of one init system with another aren't far better understood than they were a decade ago. > why not just make it easy to replace if it needs to? It may not be easy to replace, but it's far from impossible, and it's getting easier and better understood all the time because of people that don't want to run systemd. That's a good thing. > Sure, but why not do that now? instead of pushing it off for people in the future to figure out? Because regardless of how much it seems like people dislike systemd, I'm confident the majority of people either didn't notice, don't care, or like the new features enough to outweigh their dislike of other aspects. I would be happy to consider data that points to an alternate conclusion, but there's a reason why it's taking over, even if there are problematic aspects.