Re: Transition of initscripts to new order / sequence number
On Tue, 24 Mar 2009, Harald Braumann wrote:
> > 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?
Because what we have right now doesn't work well.
And it doesn't work well mostly because of halfbaked APIs, not because
of complexity or overengineering. Complete APIs means less complexity
and code duplication, and easy to use ones avoid errors.
As a simple example: if we had "restart-if-running" and/or "status"
initscript actions since day one, invoke-rc.d wouldn't have come into
existence (although the chroot issue would need something for the
maintainer scripts anyway, but it could be much simpler).
If update-rc.d had gotten fixed to act like dpkg-divert does early on,
we wouldn't be losing local admin configuration to fix packaging
bugs...
Now that an abstraction layer is finally in place, it is a bad idea to
remove it right away. Instead, make the stuff below it so simple that
the layer can become simple, too.
Only then, after you're sure you have something that really is worty
of being the only choice, should you think about removing the
abstraction layer.
> 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.
You mean stuff like udev?
Wait until you get to deal with fully async userspace... Everything
is becoming hotpluggable, and that is something we haven't even begun
to address correctly yet.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: