Bug#727708: init system thoughts
On Tue, 2013-12-31 at 02:55 +0000, Colin Watson wrote:
> My main concerns with systemd relate to its broad scope regarding units
> it provides for system initialisation tasks currently performed by other
> packages, and the potential for that to interfere with past and future
> work elsewhere in Debian. I can understand why the systemd authors felt
> The two examples which I've run across so far, both ones I was inclined
> to look at since I'm familiar with the territories, are:
>
> #716812 (binfmt-support)
> #608457 (console-setup)
> Basically, systemd would be more compelling to me if it tried to do
> less. I don't expect to persuade systemd advocates of this, as I think
> it amounts to different basic views of the world, but the basic approach
> here is probably the single biggest factor influencing my position.
I think this is absolutely ridiculous as a "rationale" for choosing
upstart. If you have done any investigation, you should know that it's
trivial to disable any of those components if Debian decides it's better
off without them. Yet you really seriously present their existence as
the "biggest factor influencing your position"? In what kind of scenario
could their existence possibly cause noticeable problems for Debian
systemd use?
I can imagine some kind of extrapolated arguments about "project scope
issues" that would not be completely laughable, but you haven't really
presented any of those. As is, what you're saying just does not form an
argument that could be taken seriously at all.
> The criticisms of Upstart's event model in the systemd position
> statement simply do not make sense to me. Events model how things
> actually happen in reality; dependencies are artificial constructions on
> top of them, and making them work requires the plethora of different
> directives in systemd (e.g. Wants, which is sort of a non-depending
> dependency) to avoid blocking the boot process on a single failing
> service.
Dependencies are the natural way to express what people know about the
system and what they need. Events are the internal implementation
details of what the machine does to make it happen.
"I want task X started, and it needs task Y" is what people express.
"Start Y, and when Y is ready, start X" are the "compiled"
implementation instructions to achieve the higher-level goal.
Reply to: