Hi, On 02.12.19 00:07, Uoti Urpala wrote: > In short: there is little to no worthwhile work being done on any > alternatives to systemd. What is happening is some people trying to > keep sysvinit working to about the level it did in 2014, while doing > very little fundamental development to the system that would fix its > widely recognized flaws. Such work will not help innovation, will not > produce a plausible alternative to systemd, and is not worth > supporting. The main work in keeping sysvinit working on the same level as 1994 or 2014 is to stop people from removing working init scripts. There is no need to innovate with sysvinit. Anything that is more complex than "run program" is out of scope, and that is by design. Systemd has reached a level of complexity where debugging failures is a specialized skill set rather than just application of generic shell script knowledge and a few simple design concepts. The promised "flatter learning curve" got appended at the bottom of the mountain and only increased the total height. There is a nice plateau there though. Effectively we now have a new class of user that knows a set of magic incantations to make a piece of black box software behave, but cannot repair problems outside of that. Twenty years ago, we used to make fun of people who crammed system administration recipes for their MCSE exams instead of learning how the system worked so they could derive them on the spot like we did on Unix. Thing is, that was impossible on Windows then, and it is impossible with systemd now, because the actual implementation is complex and very much in flux. If I have a use case where systemd is the best choice, such as when I need to install a system for someone who is less interested in technology than I am, I will happily do so. For my use cases, it provides few tangible benefits, requires me to pick up otherwise useless knowledge and disables most of the debugging tools I'm used to (and requires me to pick up even more otherwise useless knowledge to replace them). [...] > As there currently aren't credible alternatives to systemd, not even at > the level of Upstart, I think it's wrong to phrase the question in > terms of whether Debian "supports innovation" and so on. The phrase "supporting innovation" in this context means adopting new interfaces introduced through systemd, so that is basically what you are asking for. Despite being the default init system, systemd is where the "innovation" happens. The other init systems do not feel the need to innovate, and to some of us, that is a good thing. > The practical > question now is whether Debian insists on supporting the obsolete > sysvinit, not because of any positive qualities it has or potential for > future development (and very little forward development has happened in > the last five years), but only because it allows systemd haters to > avoid using systemd. I wouldn't classify myself as a hater, it just provides no additional benefit to me at the rather high cost of learning a lot of things that I need to know in order to use the system as I did before. Debian's approach with init scripts is already more complex than what I started out with, which was rc.local on NetBSD: a single file that would just start one daemon after the other, with "sleep" commands in between to avoid daemons starting in parallel and competing for disk I/O. The step from rc.local to init scripts is still relatively flat though compared to the jump from init scripts to service units. > IMO encouragement for supporting alternative systems could be > reasonable, but only for actual new innovation; maintainers should be > explicitly permitted to remove any existing sysvinit scripts and refuse > addition of similar scripts. Systemd units should be no worse a basis > to bootstrap a new system. That's the thing: I'm equally uninterested in any other new init systems, because the purpose of my computers is not to run an init system, but to run specific productivity applications on them. My job as a system administrator is not to run an init system or update it with the latest features, but to keep an application running. Change is bad. Change requires attention. Change is work. Change is costly. This is the axis on which I measure whether an init system is "better" than another. Systemd, by design, cannot compete with sysvinit on that axis, and that is neither a flaw in systemd nor in the way I measure that axis. If you remove all other options, then obviously systemd will remain as the "best" option on that axis, but I don't consider "best of one" a very flattering statement. It remains the case that users have different use cases, and different programs are differently well suited for these. I've written[1] about that in 2016, and not much has changed there. Simon [1] http://www.simonrichter.eu/blog/2016-03-03-why-sysvinit.html
Attachment:
signature.asc
Description: OpenPGP digital signature