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 gun. 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. http://www.schneier.com/blog/archives/2009/01/biometrics.html
Attachment:
signature.asc
Description: Digital signature