4 ms·

> That's good that you didn't experience any bumps in the road, but did you notice the supposed benefits of systemd yet? Namely faster startup times? I have,

> That's good that you didn't experience any bumps in the road, but did you notice the supposed benefits of systemd yet? Namely faster startup times? I have, for what it's worth, but it's worth noting that the biggest benefits of systemd are invisible to end-users. Startup time is the one mentioned most frequently because it's one of the few that's directly observable by end-users, not because it's the most important. For example, systemd makes it much easier to write services (both system and user services), and it definitely has delivered on this promise, since I take advantage of it frequently. Most users still don't have a need for this, though for the ones that do, it's now several orders of magnitude easier to write basic services. But more importantly, systemd is far easier to maintain. That's the real reason distros like Arch switched so rapidly[0]; it wasn't part of some vast systemd conspiracy. They were willing to support sysvinit as long as there were people to maintain them, but it turns out that almost nobody wanted to maintain it. And since it's a volunteer/community-run distro, you can't exactly force people to maintain code they don't want to. There was one guy who posted to the mailing list and was very adamant about providing an AUR package for it, but last I checked, it didn't have much traction. [0] Arch switched back in 2012, long before most other distros. And they deprecated sysvinit within less than a year - far faster than they originally planned - for the above reasons.

vezzy-fnord 11y ago
Please stop perpetuating the false dichotomy of systemd versus sysvinit, it gets tiring. [1] One does not "write services" in systemd. One configures manifests for services in the unit file format, which is internally translated into a Unit object, used for representing various system resources, including services (service actions being queued as another internal unit type, that of jobs). "systemd is far easier to maintain" is not measurable in any way. In fact, given it expects a particular FHS [2], has a lot in the way of needing optimization [3], has a rapid pace of development, adds a complicated transactional dependency system based on seven different job queuing modes and undocumented heuristics, the evidence would point that it is not. Indeed, I do recall Dave Reisner of Arch Linux complaining about systemd's pace and its poor test suite, requiring lots of patching. [1] http://blog.darknedgy.net/technology/2015/09/05/0/ http://blog.darknedgy.net/technology/2015/09/05/0/ [2] http://www.freedesktop.org/software/systemd/man/file-hierarchy.html http://www.freedesktop.org/software/systemd/man/file-hierarc... [3] https://wiki.freedesktop.org/www/Software/systemd/Optimizations/ https://wiki.freedesktop.org/www/Software/systemd/Optimizati...
- chimeracoder 11y ago
  > Please stop perpetuating the false dichotomy of systemd versus sysvinit, it gets tiring. It's hardly a false dichotomy to compare what a distro was using previously to what they are using today, which is what I did (and what OP asked for). > Indeed, I do recall Dave Reisner of Arch Linux complaining about systemd's pace and its poor test suite, requiring lots of patching. I didn't say it was perfect, and in fact, I have a long list of complaints about the initial switch in Arch (though not Debian). That doesn't negate the point that the reason Arch (and other distros) dropped support for sysvinit was that there ended up being insufficient interest from maintainers in maintaining it.

vezzy-fnord 11y ago

Please stop perpetuating the false dichotomy of systemd versus sysvinit, it gets tiring. [1] One does not "write services" in systemd. One configures manifests for services in the unit file format, which is internally translated into a Unit object, used for representing various system resources, including services (service actions being queued as another internal unit type, that of jobs). "systemd is far easier to maintain" is not measurable in any way. In fact, given it expects a particular FHS [2], has a lot in the way of needing optimization [3], has a rapid pace of development, adds a complicated transactional dependency system based on seven different job queuing modes and undocumented heuristics, the evidence would point that it is not. Indeed, I do recall Dave Reisner of Arch Linux complaining about systemd's pace and its poor test suite, requiring lots of patching. [1] http://blog.darknedgy.net/technology/2015/09/05/0/ http://blog.darknedgy.net/technology/2015/09/05/0/ [2] http://www.freedesktop.org/software/systemd/man/file-hierarchy.html http://www.freedesktop.org/software/systemd/man/file-hierarc... [3] https://wiki.freedesktop.org/www/Software/systemd/Optimizations/ https://wiki.freedesktop.org/www/Software/systemd/Optimizati...

chimeracoder 11y ago
> Please stop perpetuating the false dichotomy of systemd versus sysvinit, it gets tiring. It's hardly a false dichotomy to compare what a distro was using previously to what they are using today, which is what I did (and what OP asked for). > Indeed, I do recall Dave Reisner of Arch Linux complaining about systemd's pace and its poor test suite, requiring lots of patching. I didn't say it was perfect, and in fact, I have a long list of complaints about the initial switch in Arch (though not Debian). That doesn't negate the point that the reason Arch (and other distros) dropped support for sysvinit was that there ended up being insufficient interest from maintainers in maintaining it.