On Sun, 2013-12-29 at 14:02 +0000, 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-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1388356109.3938.324.camel@glyph.nonexistent.invalid
