On Mon, 2016-01-25 at 08:05 -0600, Chris Adams wrote: > Once upon a time, Peter Duffy <peter at pwduffy.org.uk> said: > > The thing which always gets me about systemd is not the thing itself, > > but the way it was rolled out. When I first installed Red Hat 7, if a > > window had appeared telling me about systemd and asking me if I wanted > > to use it, or stick with the old init framework, I'd have opted for the > > latter (as I was interested primarily in continuity from the previous > > version.) > > That's not really practical for something as core as the init system. > Trying to support two init systems in parallel, especially for as long > as Red Hat supports a RHEL release, would require a massive amount of > work. A distribution is about making choices and implementing them in > the best way possible; for "leaf" packages like an editor or a web > browser, it is easy to have multiple options (where they don't > conflict), but core stuff like the kernel and init system don't leave > lots of room for choice. > Ultimately it's all software, and software can be written/changed/updated to do anything required - all that's needed is the skill and the motivation. If systemd is so "core" that it can't be unplugged and plugged easily, and glues together a lot of otherwise unrelated components, then it's just bad software - end of story (the problems with tightly-coupled components were first identified over 40 years ago, and modularization has been the watchword ever since.) In my view, it's high time someone independently analysed systemd down to basic code level, and understood why it's so invasive (if it actually is.) Then the way forward would be clear - fork it, and produce a new version which wasn't so invasive, and which could be swapped in/out. I'm not saying it would be easy! ("We do not do these things because they are easy - we do them because they are hard!") > I remember people complaining about SysV-style init too, "what's with > all these scripts" and "why can't I just add a line to /etc/rc". > systemd is a different way of thinking, but it isn't exactly original > (Sun and Mac have similar launchers); practical experience has shown > that this can be a better way of managing services. No one is saying that sysvinit is perfect. What I can't grasp is why replace it with something which is no less imperfect, and is almost certainly worse in at least some respects - and to make that replacement unavoidable and mandatory. I'm also still trying to figure out in what way systemd is supposed to be "better". I've seen the following things claimed for it: - faster boot time (this was apparently the main motivation behind it.) My experience with systemd-managed systems has been limited - but so far, I've not noticed faster boot times with systemd (maybe because the boxes booted fast enough previously.) - parallel startup of services. Not sure that I'd want that anyway - too much risk of two services trying to grab the same resource at the same time - I'm absolutely happy with the sysvinit approach of one service startup completing/failing before the next one happens. That way, things are nice and orderly. - better handling of hot-plug devices. I've not yet seen that in action, but that is the one thing which makes me inclined to investigate systemd in more detail. > Nobody is forcing you to run systemd; you can continue to run CentOS 6 > and earlier for years. But if you are a system administrator, your job > is about learning and adapting, not trying to keep a static setup for > life. systemd is different (just like SELinux was years ago), but I > suggest you learn it. It can make your admin life easier. Is it > perfect? No, nothing ever is; I do think it is a big improvement > though. > My job as a system administrator is to serve the users who use the servers I manage and administer, and to keep those servers and services in suitable condition for the users to do their work and earn their daily bread. As we all know (don't we just?) sysadmin work and responsibilities are heavy, and frequently eat into evenings, nights, weekends and (so-called) holidays. Anything which increases the sysadmin workload - e.g. suddenly faced with a vertical learning curve just to do the tasks they did yesterday, or a GUI which leaves them unable to find anything on their screens - is a major issue, and prejudicial not only to the sysadmin's own work, but also to that of the users to whom he/she is responsible. And when you're talking about systems used by hundreds and thousands of users, that's a big problem.