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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
