Hi Russ, On Fri, Nov 01, 2013 at 08:11:38PM -0700, Russ Allbery wrote: > Steve Langasek <vorlon@debian.org> writes: > > For the TC decision, what kind of information are you looking for about > > the plans, beyond "the Ubuntu developers expect to need to address this > > before upgrading from systemd logind 204 and will hold at 204 until a > > correct solution is known"? > I think the right way to put this is that systemd has significant > development resources behind it and is working in fairly close cooperation > with both kernel developers and GNOME developers to make available new > kernel functionality and to provide implementations of various other > interfaces. Multiple implementations are good, but there's potentially an > ongoing stream of development to keep up with, and (putting aside > arguments about coupling and appropriate ways to integrate that > functionality) I believe there is a general agreement that functionality > is desirable and will be used by other software that Debian wants to > provide. > So, one question is whether anyone outside of Canonical is in a position > to help with the heavy development (as opposed to the occasional patch). > Red Hat is clearly committed to systemd, and there's some convergence > towards it among other RPM-based distributions, so long-term resources for > systemd don't seem to be in doubt. Canonical is a smaller company, and > does not always have the resources to keep projects for which it is the > sole upstream vibrant and growing, even when it seems strongly committed > to them (c.f. bzr). While it's fair to note that Canonical is a smaller company with fewer resources than Red Hat, Canonical is certainly not the only company working on technologies that don't fit into systemd upstream's model. On the question of cgroup management for instance, while there's broad consensus that we want to move to a single-writer model, there is not consensus about what that single writer should be; at the last on-line Ubuntu Developer Summit, developers from Canonical and Google discussed how to collaborate around their respective cgroup technologies (lxc, lcmtfy) to address the single-writer requirement for non-systemd systems. http://summit.ubuntu.com/uds-1311/meeting/21982/core-1311-cgroup-manager/ We're not talking here about whether Google will contribute to upstart upstream, because this is code which is separate from upstart by design. But in the wider ecosystem of projects that exist in parallel to (and are incompatible with) systemd, there are other players besides Canonical. For logind, which is the main point of contention with respect to systemd 205 being usable on systems that don't use systemd as init, the main blocker is, again, around logind's use of init as the cgroup manager. In that same UDS session, a decision was taken to provide cgroup manager API compatibility with systemd via the systemd-shim package, which is a small Canonical-maintained compatibility layer (not yet in Debian, but that's easily addressed). This will enable use of logind 205 on systems running upstart (or, for that matter, sysvinit). I don't believe we need to worry about sufficient manpower to keep up with systemd development. There are a fair number of people who have resigned themselves to systemd because they've been led to believe it's the only option. If Debian standardizes on upstart, some of these developers will be interested in collaborating with Debian to provide equivalent functionality / compatible interfaces. It may not be many developers in absolute terms, but the rate of development for an init system should not be high in absolute terms either. The greater Free Software community does not have inexhaustible patience for projects that are constantly breaking backwards-compatibility; whether Debian adopts systemd or not, we are going to care about things like being able to run current systems in chroots/containers on older (stable) kernels, and we're going to care about being able to cleanly upgrade from one stable release to the next, and a revolving door of rapidly changing kernel interface requirements is bad for the ecosystem as a whole - and will therefore be self-limiting. > If Canonical *is* the sole upstream, the upstream future here is troubling > to me, particularly given Canonical's current strategic direction towards > Unity. To give a specific example of the sort of thing that I'm worried > about, suppose that GNOME Shell wants a new piece of functionality that > is, on Red Hat, provided via kernel functionality managed by systemd, but > Unity has no need for that functionality. Is Canonical going to develop > an upstart equivalent in support of GNOME Shell, when it is pushing Unity > over GNOME Shell? > Maybe this example is very artificial; I know it's not clear what piece of > functionality would be required from the init system and surrounding > infrastructure that would be required by GNOME Shell and not Unity. But I > think it's at least conceivable given different priorities around such > things as multiseat, and in any case it provides a concrete example of the > sort of scenario I'm worried about. Well, I guess you wouldn't expect me to say "yes" here, or if I did, you wouldn't believe me; it's unrealistic for Canonical to commit to implementing some arbitrary - and hypothetical - future functionality. Canonical is committed to being a good steward for upstart for as long as Ubuntu itself uses it, and welcomes its use by other distributions. But this isn't an act of altruism, it's enlightened self-interest. Canonical isn't going to make an indefinite committment to maintain features it doesn't have need for itself. But I think the same can be said of systemd. If Debian concluded that systemd's cgroup manager design was wrong because it embeds it in PID 1, and wanted systemd to be compatible with other container solutions like lxc and lmctfy, I don't think we would expect Red Hat to make this happen for us. All that said, I think your example /is/ very artificial. logind is unquestionably the best solution for seat management today, and there's no reason to implement a competing solution. Systemd upstream doesn't want to support logind on non-systemd systems, but we can reasonably provide the necessary compatibility layer so that it just works everywhere, for everyone's benefit. So in practice, I don't foresee a case where divergent requirements of Unity vs. GNOME Shell would leave Debian holding the bag. > In other words, it's not so much a specific roadmap as it is a roadmap > approach and resource committment. Debian, by choosing a default init > system, is potentially investing a lot of developer effort on supporting > that platform for packaged daemons, somewhat akin to an organization > choosing a product on which to base a required piece of internal > functionality. I'm therefore asking the same sort of question that I > would ask of a vendor whose products we were evaluating for my day job: > what guarantees do we have that this product will continue to be developed > and supported going forward? > The situation with free software is a bit different from a vendor, of > course, since Debian could always patch or even pick up development of the > software ourselves, but I think we'd all agree that Debian ending up > committed to a system service family (since that's really what we're > talking about here -- not just the init system itself, but also how the > equivalents, forks, or refactorings of logind, D-Bus, cgroups, udev, and > so forth will be handled) whose pace of development has slowed to the > extent that bzr's has would be a very bad outcome. bzr lost the DVCS war not because Canonical was unwilling to invest in bzr, but because git had an early lead in performance and flexibility that made it the runaway choice for developers, and by the time bzr was catching up in functionality, network effects meant it was too late. Once it became clear that bzr would not deliver on its promise of being a universal DVCS because the world had already adopted git as a de facto standard, it was reasonable for Canonical to stop investing in bzr development. So I don't think there's much similarity between what happened with bzr, and what would happen with upstart if Debian adopted it. If Debian adopted systemd instead of upstart, /then/ there would be hard questions about the future of upstart, in light of a clear consensus that systemd is the technically superior option. But if Debian /does/ adopt upstart, Debian + Ubuntu represents a critical mass to keep the project going for the foreseeable future. > At least superficially, that outcome looks more likely to me with upstart > than it does with systemd, so I'm looking for some reassurance for why the > risk of ending up in that situation is low. Hopefully I've addressed this concern. If not, please let me know. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature