Bug#727708: systemd vs. binfmt-support
On Thu, 2013-12-26 at 21:42 +0000, Colin Watson wrote:
> On Thu, Dec 26, 2013 at 08:49:11AM +0100, Tollef Fog Heen wrote:
> > In this particular case, as you write, I hadn't really given it any
> > consideration before, but what I think would make sense is to extend
> > systemd to support the same interface as binfmt-support and then people
> > who don't use systemd can use binfmt-support and those who use systemd
> > (on Debian or elsewhere) can use systemd-binfmt. I'm guessing the
> afraid it leaves me rather cold, though.
>
> 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. 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. Whether
it would be preferable for the tool to support more complex
functionality is another question.
> suppose I'm concerned what the incentive is for people to innovate on
> this sort of thing in the future (and binfmt-support absolutely was
> innovative in terms of making the packaging of the underlying kernel
> technology trivially accessible) if they can be steamrollered at any
> time; in the long term I have more faith in the flexibility of many
> small projects than one big one.
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.
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).
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.
> The second is that it seems like makework for the sake of aggrandising
> systemd. systemd isn't bringing anything new to the table here; right
> now it's just exposing the raw underlying kernel interface in the form
> that's existed since 1997, and in a way that (AIUI) only works properly
> at boot time rather than doing sensible things when packages are
> installed or removed. Of course you can put all the pieces together,
> but that was the point of binfmt-support. This is straight
> wheel-reinvention and it seems like a total waste of everyone's time.
As above, I certainly disagree about including binfmt code being a waste
of time; having to look at a separate project to get any support at all
for something so simple would be a waste of time. Most likely supporting
more features from binfmt-support would be an improvement, but that
doesn't make having the current code a negative thing.
I'm not sure whether including exact binfmt-support functionality would
have been a reasonable option for systemd (GPL vs LGPL probably
precludes code copy). At least the API would not be very consistent with
other tools.
Reply to: