Ian Jackson <ijack...@chiark.greenend.org.uk> writes: > Russ Allbery writes ("Bug#727708: init system other points, and conclusion"):
>> First, other choices besides systemd and upstart. > I agree with your comments here; it appears you've investigated OpenRC > in more detail than I have but I'm happy to take your word for it. I should be clear that I've not actually run the system. I've tried to track down documentation and tried to understand what the project goals were. It's quite possible that I've gotten some details wrong, and I would welcome any corrections from the OpenRC folks. >> Rather, we're talking about whether or not to swap out a core component >> of an existing integrated ecosystem with a component that we like >> better. > Unless you are proposing to make systemd mandatory for all Debian > installations, this is work that needs to be done anyway. What I'm hearing from both GNOME and KDE maintainers is that assuming systemd would save them a great deal of work. I think having systemd be the only supported and tested option for at least some large package sets that heavily use the systemd infrastructure upstream is a not-unlikely long-term outcome. In other words, I think the long-term portability future of GNOME (and to a much lesser extent KDE, where the issue will be bitrot of unused configurations more than an intentional maintenance choice, and where I expect the system to at worst degrade functionality rather than stop working) to non-systemd platforms is already in some jeopardy, because it's not clear that resources will be available upstream to maintain those projects outside of the APIs that systemd supports. That was, after all, the forcing moment that brought this whole debate to a head. One can, of course, have a wide variety of reactions to that. As someone who considers portability to be an inherent good, I find it sad, although I don't have a full appreciation for what problems GNOME is trying to solve by increasing its reliance on systemd. But I'm highly dubious that Debian will just single-handedly fix that, or that we would drop GNOME because we don't like upstream's integration decisions. > Also, I get the impression me that the "integration" of much of this > functionality into the systemd source package has been done for > political rather than technical reasons. I hear that you have this impression, but I completely disagree. I find the amount of bad will and assumption of malice aimed at the systemd maintainers to be intensely depressing and unwarranted by any of the interactions that I've seen, and I've been doing a fair bit of reading. Lennart passionately argues his side. So do you. So do a lot of us. We all tend to have strong technical opinions and a great deal of confidence in our own judgement. Personally, I'm putting contentions that systemd is doing a power grab or is merging things for political reasons into the same bucket as contentions that Technical Committee opinions are driven by current or past employer relationships. I would prefer to assume good faith among the people involved and understand their projects on their own terms. > At the very least, I worry that the systemd project as a whole is far > too willing to impose decisions of all kinds on its downstreams. All upstreams do this. I have yet to meet an upstream for any piece of software that doesn't care about that software working uniformly on its supported platforms. systemd is entirely in line with normal upstream practice of trying to pick the best solution to a given problem and supporting it thoroughly, rather than incurring the maintenance burden of supporting multiple ways to do the same thing. This always involves imposing some decisions on downstreams unless downstreams are willing to fork around that decision. It's already meant that some of Debian's decisions are being imposed on Red Hat because they were judged to be better solutions. In places where Debian needs to take a different approach for reasons of backward compatibility or existing integrations, obviously we should, and we should be sure that we have the flexibility to do so. For example, I think we should disable the current systemd binfmt support in favor of our existing working solution. I have not seen any indication that would be a problem. You made multiple proposals that do not reflect what Debian is doing *today*, and which are not *necessary* for Debian. I don't think those are good test cases for upstream's willingness to accomodate Debian's needs. > My understanding was that Dimitri had got upstart running on BSD. The latest that I have seen on this porting effort is here: http://blog.surgut.co.uk/2013/11/libnih-upstart-dependency-ported-to.html I asked previously on this bug if someone had later news. Do you have more information than that? The above is definitely not "upstart running on BSD." That's upstart's underlying support library mostly working on BSD after disabling two features (that are required for upstart). I haven't not heard whether the porting of upstart proper has started. That will certainly be much easier once libnih is ported, but there are, for example, direct uses of epoll in upstart proper. (I don't know if kFreeBSD already has a portability layer for epoll in terms of kqueue.) > Furthermore, I am much less worried about Debian going it alone > (although, of course, it's not alone) than you seem to be. We have > historically been entirely unafraid to do our own better things, even if > it is more work and takes us longer. I think "worried" is an incorrect characterization of what I said. What I said, rather, was: I think we should make wise decisions about which areas we want to invest project effort. I dislike investing significant project effort in catch-up efforts that, when complete, merely get us back to where we would have been if we'd chosen a different solution. I don't think that's wise stewardship of project resources. I want to see Debian focus its efforts on places where we can make a real difference, where we can be leaders. That means adopting the best-of-breed existing solutions and building on top of them, not reinventing wheels and thereby starting from a trailing position. upstart is a great project, of which its maintainers are deservedly proud. However, I don't agree that it's better than systemd. My own research convinced me of the opposite. But putting that aside, my point in that section is that, given feature parity (and I mean "feature" expansively, including adaptibility to Debian's needs), we should choose systemd because it has more project momentum and better existing integration, which means that we will have to spend less energy on it and will have more energy to spend on other things. It's absolutely worth doing our own, better things. What I don't want to do is our own *worse* things. Or, for that matter, our own equivalent things, when we could instead use work that already exists. It's a waste of energy. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- 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/87ob3yt8ni....@windlord.stanford.edu