3 ms·

> No, it caused more problems than solved Talk about a statement without substance. But setting that aside, I think init is guilty of "breaking" and "being un

> No, it caused more problems than solved Talk about a statement without substance. But setting that aside, I think init is guilty of "breaking" and "being unstable". Having existed long enough for others to work around your flaws is damning with faint praise. The hours I have spent combing documentation upon an upgrade of one thing or another (I'm looking at you, Apache) because init broke would be difficult to count. If you manage all your components from within the distribution then it's usually fine, but if you are managing something not included in the repositories... buckle up, it's going to be a bumpy ride. But the greatest vote for systemd is that every major linux distribution, even ones that value stability very highly (RHEL and Debian) adopted it, sometimes at great cost to the community. That says a great deal about systemd's advantages in a system often fractured by choice.

raverbashing 10y ago
> Talk about a statement without substance. The substance is in several bug reports and general trouble that are available in google for all to search But I'm curious at what problems you did have with init
- stinkytaco 10y ago
  Like I said, mostly upgrading packages outside of the distribution's package manager or running separate packages. This is especially problematic with internal tools that I (1) needed to write a script for and (2) were not necessarily well documented and (3) relied on other portions of the system. It was also problematic when trying to untangle someone else's solution to the problem (say a colleague or worse, a predecessor). So say I adopt a system that starts up some internal application as a subsystem. Being diligent I start to do my system upgrades and now my totally undocumented script has broken and I've got to piece it back together. Systemd takes much of the guesswork out of that process, because now I simply need to define that service and it's up to the vendor or package maintainer to ensure it starts. It's perhaps worse that this is not my full time job, I work in an organization that has pieced together systems from vendors, volunteers, outside organizations and so on. It doesn't help that we are increasingly dependent on packages that most would argue are as opaque as systemd. For example, if my organization wants to adopt single sign on (and why not), I've got to install shibboleth: a massive, hulking beast of a system that I don't really understand but can tell you for sure does not obey Unix's "one tool, one function" philosophy and with an init script that I pieced together from parts. (Tangent: There are days when I miss Microsoft and it's suite of integrated tools, notable active directory). So I would say that while systemd has plenty of bug reports, init simply substitutes endless form posts on fixing init for bugs. And frankly, after a rocky start on the switch over, I haven't seen many issues with systemd. So perhaps it's just acknowledging that best practices don't always get followed and that others have a different set of problems. I expect systemd resolved a lot of issues for distribution maintainers that had to walk gingerly around init when planning their upgrades. Perhaps that's the wrong reason to switch, but at least it's a reason I understand.

raverbashing 10y ago

> Talk about a statement without substance. The substance is in several bug reports and general trouble that are available in google for all to search But I'm curious at what problems you did have with init

stinkytaco 10y ago
Like I said, mostly upgrading packages outside of the distribution's package manager or running separate packages. This is especially problematic with internal tools that I (1) needed to write a script for and (2) were not necessarily well documented and (3) relied on other portions of the system. It was also problematic when trying to untangle someone else's solution to the problem (say a colleague or worse, a predecessor). So say I adopt a system that starts up some internal application as a subsystem. Being diligent I start to do my system upgrades and now my totally undocumented script has broken and I've got to piece it back together. Systemd takes much of the guesswork out of that process, because now I simply need to define that service and it's up to the vendor or package maintainer to ensure it starts. It's perhaps worse that this is not my full time job, I work in an organization that has pieced together systems from vendors, volunteers, outside organizations and so on. It doesn't help that we are increasingly dependent on packages that most would argue are as opaque as systemd. For example, if my organization wants to adopt single sign on (and why not), I've got to install shibboleth: a massive, hulking beast of a system that I don't really understand but can tell you for sure does not obey Unix's "one tool, one function" philosophy and with an init script that I pieced together from parts. (Tangent: There are days when I miss Microsoft and it's suite of integrated tools, notable active directory). So I would say that while systemd has plenty of bug reports, init simply substitutes endless form posts on fixing init for bugs. And frankly, after a rocky start on the switch over, I haven't seen many issues with systemd. So perhaps it's just acknowledging that best practices don't always get followed and that others have a different set of problems. I expect systemd resolved a lot of issues for distribution maintainers that had to walk gingerly around init when planning their upgrades. Perhaps that's the wrong reason to switch, but at least it's a reason I understand.