Bug#727708: systemd vs. binfmt-support
On Sun, Dec 29, 2013 at 05:56:30AM +0200, Uoti Urpala wrote:
> On Thu, 2013-12-26 at 21:42 +0000, Colin Watson wrote:
> > The first reason is, I suppose, rather selfish: I've been working on
> > this on and off for fourteen years and it seems a bit rude for systemd
> > to turn up and declare that it's now the standard on the strength of an
> > underpowered implementation, without even mentioning it to me (I'll
> > accept that this is irrational since the systemd authors probably
> > weren't aware of the prior art, but it's certainly my gut reaction). I
> I don't think systemd authors have made any declarations about binfmt in
> particular. The only thing they've actually done is add a very simple
> implementation (src/binfmt/binfmt.c, less than 200 lines of code, much
> of it argument parsing). I consider having a basic implementation to be
> a useful "batteries included" feature: systemd supports lots of
> different setups from embedded to desktop, and it's useful to have at
> least a basic implementation ready when building a system. It's easy
> enough to override if you want something different.
I agree with this part. My comments above were imprecisely phrased,
sorry (though I did flag them as a gut reaction); I'm mainly referring
to the end result for Debian.
> Thus I consider any opinions saying systemd should not include a tool
> for setting binfmt, or that adding it was somehow objectionable
> behavior, to be wrong.
I was referring more to Tollef's position, really. Debian systemd
maintenance ought to take into account matters of Debian integration,
which includes whether it fits well into best-of-breed Debian practice.
If it's easy enough to override, then given that we have a better
implementation in Debian then we should simply continue to use it.
> I think this has been proven false by experience - systemd has innovated
> a lot in things where smaller projects were stagnant. And there's a
> fairly clear reason why this would be so: something like binfmt-support
> is too small a unit for independent development, both to design
> independently and to "sell" to every user individually.
It's simply not true that it's too small a unit for independent
development (what on earth gives you the authority to pronounce on this,
please, given that I've been independently developing it and working
with the people who consume it directly for much longer than systemd's
been around?). Besides, this is a red herring; there's no need to sell
it to every user individually, only to distributions complex enough for
it to be worth it, maybe half a dozen conversations. Typical users get
it by way of dependencies or similar.
> Binfmt support is not that complex a task in itself. In practice, a lot
> of the usability will depend on consistency with other system parts.
> Designing APIs for it only is too narrow a view; you need to consider
> other tools, and if you can do better, then it's quite likely you should
> change the other tools too (things like adding udev rules etc).
However, I've been thinking about this for rather a long time, and I'm
actually quite familiar with the design issues. binfmt-support is
specifically designed to be suitable for distributions (not just Debian)
shipping binfmt integration; in particular I have put much more effort
than systemd has into how it fits into packaging.
> Convincing every distro builder out there individually that your binfmt
> support code is best wastes effort, both yours and theirs. It's more
> efficient to have systemd upstream decide what is a reasonable default
> implementation, and then have only people with specific needs or
> opinions change it.
This sounds very much like an argument from authority, and I'm afraid I
don't subscribe to it. I don't consider my effort wasted, and I don't
consider it wasted effort for other distributions to take improved code
either; nor do I think that something really not particularly tied to
the init system needs to be developed under the systemd umbrella.
Colin Watson [email@example.com]