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

Re: Switching the default startup method

On Mon, Aug 24, 2009 at 03:34:51PM +0200, Raphael Hertzog wrote:
> On Mon, 24 Aug 2009, Bernd Zeimetz wrote:
> > No, decimal numbers are the superior design here as they just work without any
> > magic. One of the reasons I migrated away from SuSE long time ago was the mess
> > called insserv...
> There are reports of init script not working because they rely on some
> other (unexpected) initialization done by other scripts, i.e. numbers
> were wrong and could not be easily fixed. And there's nothing magic in the
> dependency based system.
> On Mon, 24 Aug 2009, Wouter Verhelst wrote:
> > On Mon, Aug 24, 2009 at 08:54:06AM +0200, Raphael Hertzog wrote:
> > > On Mon, 24 Aug 2009, Andreas Barth wrote:
> > > > We should definitly continue to support oldstyle booting, at least for
> > > > the time being.
> > > 
> > > Until what? Missing boot-time dependencies were the only problem that had
> > > to be adressed to fix boot sequence ordering.
> > 
> > Until we're 100% confident that the new method is working correctly, and
> > is not causing problems for our users.
> How do you get that confidence without testing it on a large scale such as
> unstable?

As I said, making it the default for new installations makes sense to
me. However, I think this change is too intrusive to allow it being the
*only* option at this time.

> It's not like he did not work on this before-hand. It has been
> tested but there's no way he could have tested all combinations.

This is exactly why it should not be the only option yet!

> > I have no problem with making it the default for new installs -- that
> > makes sense. However, it should still be possible for people to remove
> > it if they have problems with it.
> I don't see the value in being able to disable insserv for those using
> sysv-rc. I understand that Petter might want to maintain only a single boot
> system.

If that is the case, then he should ask for help from more people.

> I agree however that both should be removable together for those who want
> to use something else.
> > > They are relying on an inferior system and the fact that they are used to
> > > it doesn't change anything on its inferior design.
> > 
> > What makes it an 'inferior design'? I utterly disagree with that statement.
> Getting the numbers right is a difficult task and as soon as you want to
> order something between 2 services registered with the same priority you
> might have to renumber lots of services since you don't know whether one
> service was started after another on purpose or not.
> With dependency based ordering, you just state the dependencies and you
> let it figure out the order.
> > There are advantages to dependency-based boot systems, sure; but there
> > are advantages to *not* having that, too (e.g., it is more
> > deterministic, and therefore easier to debug).
> Well, both are deterministic but they do not decide of the ordering in the
> same way and it's just easier for our brains to represent a number-based
> sequence.

Sorry, but dependency-based boot systems are *not* deterministic.

Let's assume the following:

- initscript a depends on b
- initscript c declares that it wants a to be started first if it is
  installed, but that it is not a problem if it isn't installed.

Now we may have either of the following situations, depending on whether
the user does or does not install recommendations:

- b is started first, then a, then c
- b is started, and c too. The order depends on coincidence, since there
  is no relationship between the two

If initscript c should actually declare a dependency on initscript b,
then you have a bug that the maintainer may find himself hard-pressed to
reproduce, simply because he does have the package containing initscript
a installed.

This kind of behaviour is called 'non-deterministic'.

Again, I'm not saying it's not worth the effort making it the default
and (long-term) the only option, and I'm also not saying that the
above-described behaviour will definitely happen; however, I seriously
feel that making it the only option *now*, before it has been the
default option over one or two release cycles (and thereby seen exposure
to a large amount of users and use cases in that way), is jumping the

It's perfectly possible to make it the default *without* making it the
only supported option.


The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.

Attachment: signature.asc
Description: Digital signature

Reply to: