Marco d'Itri wrote on 02/05/2007 18:56: > On May 02, Sven Mueller <[EMAIL PROTECTED]> wrote: > >>Though I agree that we should clean up the init system while we enable >>usage of newer, better, faster init systems, I don't think that we can >>remove much yet. For a while to come, many system administrators (think >>servers) will like to stay with the old faithful, long tested sysvinit. > > Do we need to care? Ubuntu switched to upstart and I have not noticed > anybody complaining.
Hmm, two things vome to mind: 1) Ubuntu is still relatively new (2-3 years), and I know of nobody who is using it in a production environment designed for maximum reliability. 2) Many people say that Ubuntu isn't the right fit for servers. Mainly because a lot of software is without official security support. I don't know how good upstart actually is, and frankly, I'm still not completely understanding how the event based init works, but I admit I didn't try hard to understand it (I fully understand sysvinit and dependency based inits though). >>That being said, a lot of cleanup could be done while we move to >>script-generated (from meta-information, script snippets and templates) >>init scripts. > > This would introduce a lot of complexity. Complexity is bad, and needs > to be weigthed about the benefits. What are the benefits of supporting > many init system schemes? Many people (including me) think of the ability to choose as one of the main features of free software (and Debian). So the main benefit for me is that I could safely switch between init systems to try which fits my needs best. Really easy to understand how it works: sysvinit. Relatively easy to understand, faster: dependency based. More complex to understand completely, but perhaps even more efficient: event based. However, even within a class of init systems, there are choices and I welcome them, even if it means that packaging daemon packages becomes a bit more complex. But as I wrote in my original mail: I don't actually think that packaging needs to become more complex. The point in my ideas on init system support is that we gather 99% of the complexity in a single initsystems-base package which generates the needed init config/scripts from meta information included with the daemon packages. And at the same time make this meta information as easy (or even easier) to handle for package maintainers as the current sysvinit scripts. > Is there a middle ground which allows a compromise? Depends on what you see as the positions: In my opinion, we should support at least three init systems: - sysvinit (slow, but known to work well for servers) - some dependency based init with daemon babysitting (ie. ensuring the daemons keeps running). runit? (faster, not as thoroughly tested) - upstart or a similar event based init (even faster? different approach but probably better tested because of the usage in Ubuntu) If another init system wants to get added to the supported list, it should be able to provide some generator script which creates its configuration and support scripts based on the meta information we already have for the above three init systems. This generator script should then be included in the initscripts-base package or that init system's package. I would prefer the latter. regards, Sven
signature.asc
Description: OpenPGP digital signature
_______________________________________________ initscripts-ng-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/initscripts-ng-devel
