Re: Gentoo guys starting a fork of udev
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
Reply to: