sysvinit VS initng VS upstart VS launchd (Was: Future New Init for FC7?)

[Rahul Sundaram]

Patrice Dumas wrote:

> 
> You cannot say that for packagers. Packagers may be interested in that
> work. If we forbid new init systems we prevent interested people to do 
> the job.

Are you suggesting that all packagers would be interested in providing 
alternative versions of the required init scripts for all different init 
scripts systems?

> Why? If people are interested, they will make it scale.

The problem happens when people are not interested. We would end up 
having init script systems which don't work properly because the 
packages dont provide init scripts except for the default init script 
system. When end users find more such packages in the repository (which 
do not know is experimental), the level of trust on the quality of the 
repository goes down. More choices without proper integration and 
testing is bad.

The question here is: What do you propose to guarantee better 
integration for all the different init scripts?

The critical difference between a package like the window manager and 
alternative init systems is that with window managers integration is 
centralized and can be done via proper generation of menus within the 
package itself.

With init systems, thousands of packages have to provide alternative 
versions of all their init scripts.

  We have to
> accept new stuff, otherwise it won't get off. For example, for init
> systems, if we say 'this system is too new, it needs new init
> files/scripts' it will never get in because packagers and upstreams
> potentially interested will say 'this system is not packaged it is 
> a waste of time to get interested in it'.

If the goal here is just to experiment and ultimately find the "optimal" 
  init system (within the constraints that nothing is optimal for 
everyone), the solution there is provide the alternative init system 
only for the development branch which helps packagers integrate with it 
and testers test it and provide feedback while not disrupting the end 
users and then only provide a single init system for the stable branches.

  > Let the new init systems packagers decide (as a community) when they
> can put new init systems in stable release, just like for normal
> components. If contributors cannot be trusted, things are wrong anyway.

Trust is not a black and white thing. Neither it is always a question of 
trust. If we can trust everyone we don't require ACL's in any packages. 
We have several cross checks in place, processes and guidelines 
precisely because we *cannot* trust all contributors all the time. As we 
scale to more contributors expect such processes to *increase*.

Rahul