[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Lennart Poettering] Re: A few observations about systemd

Steve Langasek <vorlon <at> debian.org> writes:
> > Tradeoff? What tradeoff?
> The tradeoff of hard-coding policy into C code in exchange for faster boot.

What's actually hard-coded so hard that it would have negative effects? What do
you actually *lose* here? The systemd model prefers to avoid shell scripts when
possible. I think that's a very good principle. But it's not like you couldn't
run shell code if you can't achieve the effect you want any other way (after all
even compatibility for sysv scripts is still provided!).

By the way, I think "in exchange for faster boot" is focusing too narrowly on
boot speed. It's not like boot speed would be the only reason to avoid shell.

> > Sysv-style init scripts are messy, definitely not maintainable, and
> > theoretically configurable in the "turing-complete" sense but hard to
> > modify in practice.
> Yes, all of this is true.  You seem to have mistaken my criticism of the
> systemd model for a defense of sysvinit, which it was not.  A system where
> *everything* is a shell script is not very maintainable; but neither is a
> system whose design is predicated on the idea that everything is built-in.
> The middle ground between the two seems to be upstart.

Again, what's the actual maintainability problem in the systemd model? I think
you haven't identified any, and I can't really guess what you mean either.

> > systemd service configuration wins in boot speed,
> You did actually read my message, right, where I observed that there are no
> published numbers to support this claim in a relevant head-to-head
> comparison?  And your only response is to repeat the unsubstantiated claim?

I don't know how much it wins, and I don't really care that much about boot
speed myself. Also, overall speed win could come from socket activation too, not
just avoidance of shell scripts. My main point was that your claim of "tradeoff"
was unsubstantiated as you didn't actually identify any negative effects to
counter the speed gains (and in fact I think quite the opposite is true). That
holds whether the speed gains are large or small.

> > It's not that misleading after all when you consider how quickly systemd has
> > reached that position.
> Um, of course it is.  Claiming that "it's included in the distro" as if
> that's some sort of major milestone is *incredibly* misleading.  Lots of
> things are included in lots of distros that are never going to be used by
> default.  Debian has certainly not made a decision to use systemd yet, but
> that doesn't stop Lennart from using the package's presence in the Debian
> archive in his propaganda.

Yes literally just "is included" doesn't mean much, but it has more support in
Debian than just a lone maintainer uploading it. Anyway I don't want to argue
about the exact semantics of his statement. systemd does have a lot momentum
even if its adoption is not a "done deal" in every distribution yet, and it's
hard to imagine Upstart turning the tide now or a new candidate appearing and
taking over.

Reply to: