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

[Patrice Dumas]

On Fri, Apr 06, 2007 at 07:10:09PM +0530, Rahul Sundaram wrote:
> 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?

Not all, but those that appear to be popular. But without competition
you cannot know which one is the most popular.

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

I may be wrong, but I don't think that any user will chose another init 
system than the default init system unknowingly. Maybe we could require
for alternate packages that the user edits a file by hand and in this
file there should be something like 
# beware, this is not the default init system.

But I don't think the users have expectations about non-default init 
systems. If they have wrong expectations, don't do proper investigation 
before changing such an important piece of fedora from the default, 
change defaults without being knowledgable enough, I don't think these
are users we should care that much about. In any case they will
certainly be free riders, if not worse.
 
> 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.

We could have guidelines explaining that the only required system is 
the default init. Then we could also provide explanation on how to
integrate each of the init system shipped. It could even be a
requirement for the inclusion in fedora that the maintainer adds a
guideline on te wiki with hints on integration.

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

I trust in the free software community to provide them for a new init
system if the new init sysem is better or just different, and there is 
no entry barrier, like an init system not being packaged in big distros.

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

Having them in the development branch would be a must in my opinion. And
for stable branch stable enough and widely enough covered init systems
should be accepted. Maybe this could be a guideline.

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

Ok, we could have guidelines, like what I suggest above, but just saying
we use only one init system is wrong.

--
Pat