On Wed, Nov 14, 2012 at 03:04:35PM +0100, John Paul Adrian Glaubitz wrote: > On Wed, Nov 14, 2012 at 09:49:07PM +0800, Patrick Lauer wrote: > > But anyway, we're getting tired of their ADHD-driven changes just to > > change things > > TBH, I'm getting tired of people who are constantly shooting against > them because these people are unwilling to accept changes. We're not > bringing Linux forward if we stick to 30-year-old concepts. systemd is a good > design and most people actually agree otherwise it wouldn't become > standard on so many distributions (except Ubuntu, but that's rather a > political decision IMHO).
systemd does have some good design features. It also has some bad ones. It's not as black and white as some people have claimed. If you want a reliable system, you need a reliable PID 1. Putting additional complexity into PID1 increases the likelihood that a bug will bring down your *entire system*. PID 1 is a single point of failure. It *must* be absolutely dependable and reliable. Upstart is also AFAIK at fault here. sysvinit is fairly minimal, but even it could be simplified further. Other init systems (e.g. s6)[1] take that even further so that at any point in time, PID1 is running an image dedicated to the current system state, e.g. booting, running, shutting down, and it will exec() a new image to initiate a state change. When running normally, PID 1 should do nothing except to reap zombies, and switch to shutdown. Everything else can be done in a separate process started by PID 1. In the case of sysvinit, runlevel changes are delegated to /etc/init.d/rc. This could be sysv-rc, openrc, or some other program. If that program fails, init will carry on running. That's not to say that systemd doesn't do a better job of resolving dependencies and service management. It does. But. It's introduced a single point of failure by putting all that into a single process, running as PID 1. That complexity should not be in PID1, it should be a separate process. There's no intrinsic need for it to be there. We've contained the damage should there be a failure by keeping things separate. >From a technical POV of how it resolves dependencies and manages services, systemd should be better. But from the POV of the system stability and reliability as a whole... that's much harder to quantify and much less clear cut. After all, if sysvinit is working for you, and starts up all the services correctly, once the system is up, it's up. It will continue to run reliably. Regards, Roger [1] http://www.skarnet.org/software/s6/ -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121114160512.gk...@codelibre.net
