Re: Transition of initscripts to new order / sequence number
Harald Braumann dijo [Tue, Mar 24, 2009 at 10:57:45AM +0100]:
> > Only, in this case, we need it abstracted (which it already is), and
> > we need it to _remain_ abstracted.
> > Otherwise, we will have massive pains to switch initsystems (as in:
> > it will be either completely impossible, or it will take two or three
> > stable releases to do it). It was trouble enough to implement
> > invoke-rc.d.
> Who would want to do that, anyway? Why replace a simple working solution
> with something complex and overengineered?
> It's getting harder and harder to really understand the system because
> so many things get replaced by more complex solutions and basic
> interfaces are abstracted and thus become inscrutable.
Because time changes the way things are. SysV-style startup is very
well for a server or workstation - a machine that is basically
always-on and in a stable configuration. If you want your machine to
have a fast startup, you want to parallelize startup as much as
possible - Having a rigidly sorted scheme does not help. Startup
script dependencies help us advance a bit. Having enviromental changes
impact your computer (i.e. new network interfaces coming up, for which
you will have to run several things and might want to start up your
networking, or network interfaces shutting down, which makes running
daemons not useful to have instantiated, or your DHCP lease
expiring/changing which leads to daemons that are bound to a specific
IP to be unreachable) should be handled the best way possible - Right
now we are kludging around it, but an event-based init system _is_ the
way to go for the forseeable future. But we don't want to make things
insta-incompatible, we must go step by step.
Gunnar Wolf - email@example.com - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF