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 +, 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. Cheers, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: systemd vs. binfmt-support
]] Colin Watson On Thu, Dec 26, 2013 at 08:49:11AM +0100, Tollef Fog Heen wrote: As I explain in the bug [1], I think that the facilities provided by binfmt-support are objectively superior; and even if they were broadly equivalent, I'd still question the utility of converting packages from an interface that's been well-established in Debian for over ten years. What is the systemd maintainers' position on this bug? I bring it up here mainly because it's an interesting example of integration. Tollef said during the committee's last meeting on IRC that he hadn't thought much about binfmt before, so perhaps this is just a loose end. binfmt-support is, AFAIK, only used in Debian and derivatives and in general, I think having tools that are used across the ecosystem is more valuable than having tools that are only used for parts of the ecosystem. Arch uses binfmt-support as well, I believe (and now I search for it I see that it also ships systemd configuration for it, which will be useful). I admit that I haven't put much effort into evangelising it, but there's nothing especially Debian-specific about binfmt-support and it ought to be trivial to make it work elsewhere. Correction wrt Arch accepted, and I wasn't trying to imply it was Debian-specific, merely that it is used in Debian and derivatives. [...] Given that binfmt-support is doing a better job, my preference would be to put a small amount of work into making it more clearly an independent upstream project, and simply get more distributions using it. Doing Fedora, Gentoo, and openSUSE would cover most of the bases. Now that I'm aware of the effort being wasted on reinvention, I can move that sort of thing further up my list. Great, if it becomes the standard in all those distros, I'm fairly sure systemd will deprecate or drop the binfmt support there. I'll hold off on asking upstream for any support for the more advanced features that binfmt-support offers, then. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: systemd vs. binfmt-support
On Sun, 2013-12-29 at 14:02 +, Colin Watson wrote: 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 Tollef's post was a reasonable first reaction at least - minimizing Debian-specific code (even if it's used somewhere else, Tollef was apparently not aware of that). 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, 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. I'm not saying that it would be too small to do anything useful with. But is it really different enough from other cases of setting kernel parameters to justify a completely unique approach? My gut feeling is that either binfmt-support should be closer to other tools, or the other tools should be changed to take into account lessons from binfmt-support. 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 It's not an argument from authority - I'm not saying that implementation is best, because systemd upstream chose it; in fact I was not trying to argue the benefits of any implementation. What I meant was that I think it's beneficial to have default choices, and that choices made by systemd upstream are more likely to be correct than the collective average of people who would make such choices individually (plus everyone making individual choices would use more effort). Accepting this as true does not require accepting systemd upstream as an authority whose opinion would automatically decide an issue. It's also beneficial to use shared standard methods as much as possible, and systemd upstream is probably about as close as you'll get to a shared standard in an actively developing area in practice (I certainly don't believe that any committee could do better). I think avoiding unnecessary deviations from the shared code has benefits similar to doing things according to POSIX when possible; that does not mean that I would consider POSIX authors to be authorities who could dictate how things should be done. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: systemd vs. binfmt-support
On Thu, 2013-12-26 at 21:42 +, 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
Bug#727708: systemd vs. binfmt-support
On Thu, Dec 26, 2013 at 08:49:11AM +0100, Tollef Fog Heen wrote: As I explain in the bug [1], I think that the facilities provided by binfmt-support are objectively superior; and even if they were broadly equivalent, I'd still question the utility of converting packages from an interface that's been well-established in Debian for over ten years. What is the systemd maintainers' position on this bug? I bring it up here mainly because it's an interesting example of integration. Tollef said during the committee's last meeting on IRC that he hadn't thought much about binfmt before, so perhaps this is just a loose end. binfmt-support is, AFAIK, only used in Debian and derivatives and in general, I think having tools that are used across the ecosystem is more valuable than having tools that are only used for parts of the ecosystem. Arch uses binfmt-support as well, I believe (and now I search for it I see that it also ships systemd configuration for it, which will be useful). I admit that I haven't put much effort into evangelising it, but there's nothing especially Debian-specific about binfmt-support and it ought to be trivial to make it work elsewhere. 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 file format of binfmt-support is stable and unlikely to change substantially in the future. I think the last non-trivial file format change was in 2010, but there are other interfaces (e.g. update-binfmts --find, plus of course the various ones used by humans) which are in use. This is the longer-term view. Short term, if there's any harm in having both enabled, having binfmt-support disable systemd-binfmtd (by masking it) would be fine. I don't think there's much harm in having both enabled as long as their files are disjoint, but it would probably be unwise to have them both try to process imports from /usr/share/binfmts/ into /var/lib/binfmts/. Some thought would be involved in terms of how the two approaches to site-specific configuration (creating files in /etc/ vs. running update-binfmts --install etc.) would interact. Does this sound like a reasonable plan, or do you have a preference to move in another direction? Thanks for your reply. I can certainly see why you would have this preference, and I suppose we both have fairly predictable biases. I'm 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 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. 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. Given that binfmt-support is doing a better job, my preference would be to put a small amount of work into making it more clearly an independent upstream project, and simply get more distributions using it. Doing Fedora, Gentoo, and openSUSE would cover most of the bases. Now that I'm aware of the effort being wasted on reinvention, I can move that sort of thing further up my list. Cheers, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: systemd vs. binfmt-support
#716812 asks for binfmt-support to be disabled when systemd is present, because systemd-binfmt exists. The two have a sort of soft conflict; I'm sure it's possible to run both, but having two programs configure the same kernel facility is bound to be confusing sooner or later, so it would certainly be good to come up with a coherent resolution. As I explain in the bug [1], I think that the facilities provided by binfmt-support are objectively superior; and even if they were broadly equivalent, I'd still question the utility of converting packages from an interface that's been well-established in Debian for over ten years. What is the systemd maintainers' position on this bug? I bring it up here mainly because it's an interesting example of integration. Tollef said during the committee's last meeting on IRC that he hadn't thought much about binfmt before, so perhaps this is just a loose end. For what it's worth, it doesn't look terribly difficult to make binfmt-support also support the path names used by systemd-binfmt, since the configuration is essentially a subset of what binfmt-support can handle; it would require a bit of thought to do well, of course. If people think it's important (e.g. because upstream packages are starting to ship files in the systemd-binfmt paths) then I can certainly look into that. And as I said in the bug I'd be happy to include systemd configuration in the same way that I've already included Upstart configuration; if I get time over Christmas I may manage to do this myself in the VM that Steve provided, as part of gaining practical experience with systemd. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=716812#15 -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
