[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Gentoo guys starting a fork of udev

On Wed, Nov 14, 2012 at 04:05:12PM +0000, Roger Leigh wrote:
> 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.

[Citation needed]

Upstart provides a PID 1 that is absolutely rock solid.  It's true that it's
more complex than sysvinit, because it's more featureful; but great care has
been taken to only pull the features into PID 1 that absolutely have to be
there, and the implementation of those features is very elegant and

Aside from libc, upstart has only two external library dependencies (three
in trunk), dbus and nih:

$ objdump -p /sbin/init | grep NEEDED
  NEEDED               libnih.so.1
  NEEDED               libnih-dbus.so.1
  NEEDED               libdbus-1.so.3
  NEEDED               librt.so.1
  NEEDED               libc.so.6

And upstart is rigorously unit-tested at build time.

That's a far cry from systemd's 8 external dependencies:

$ objdump -p /lib/systemd/systemd | grep NEEDED
  NEEDED               libselinux.so.1
  NEEDED               libdbus-1.so.3
  NEEDED               libudev.so.0
  NEEDED               libwrap.so.0
  NEEDED               libpam.so.0
  NEEDED               libaudit.so.0
  NEEDED               libcap.so.2
  NEEDED               libkmod.so.2
  NEEDED               librt.so.1
  NEEDED               libc.so.6
  NEEDED               ld-linux.so.2

And of all the concerns raised when Ubuntu (and Fedora and OpenSuSE)
switched to upstart, "PID 1 is buggy and crashes" was not one of them.

> 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.

This is an arbitrary design constraint that's not grounded in anyone's
actual experience of deploying upstart.

This is not theoretical.  upstart has been PID 1 in Ubuntu since 2006.  It
*is* absolutely dependable and reliable.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[1] http://ifdeflinux.blogspot.co.uk/2012/11/upstart-cookbook-updated-for-developers.html

Attachment: signature.asc
Description: Digital signature

Reply to: