Bug#727708: systemd and support for other distros
]] Ian Jackson It's not clear to me from the discussion there exactly what systemd upstream's position on this kind of thing is. Can someone point us, for example, to a statement by the systemd upstreams about their support for separate /usr (or their non-support for it) ? http://lists.freedesktop.org/archives/systemd-devel/2013-November/014797.html So they see it as pointless, but will be supported for a long time. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87vbz7ejx4@qurzaw.varnish-software.com
Bug#727708: systemd (security) bugs
Russ Allbery writes (Re: Bug#727708: systemd (security) bugs): Another point here is that it's sounding like we'll be using a lot of those services regardless, at least on systems that need them, which means that their security track record and bug rate is somewhat irrelevant for this discussion provided that running systemd doesn't force them to be running on systems that don't need them. [...] I don't think that's entirely true. I think it is fair to look at the security history of other parts of the same project as indicative regarding code quality. Ian. -- 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/21148.28008.298258.859...@chiark.greenend.org.uk
Bug#727708: systemd (security) bugs
Le lundi 02 décembre 2013 à 11:22 +, Ian Jackson a écrit : I don't think that's entirely true. I think it is fair to look at the security history of other parts of the same project as indicative regarding code quality. There are two implied assumptions here: * that the same people are developing all components; * that develolpers have the same attention to code quality and security in all components they work on. I don’t think either of them applies to systemd. -- .''`.Josselin Mouette : :' : `. `' `- -- 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/1386002708.24216.1389.camel@dsp0698014
Bug#727708: systemd and support for other distros
On Mon, Dec 02, 2013 at 09:28:23AM +0100, Tollef Fog Heen wrote: ]] Ian Jackson It's not clear to me from the discussion there exactly what systemd upstream's position on this kind of thing is. Can someone point us, for example, to a statement by the systemd upstreams about their support for separate /usr (or their non-support for it) ? http://lists.freedesktop.org/archives/systemd-devel/2013-November/014797.html So they see it as pointless, but will be supported for a long time. Note that the original complaint in the samba upstream discussion was about hard-coding of paths to system utilities, which a) is not portable between distributions and b) contradicts Debian policy. So systemd upstream may support separate /usr, but that doesn't change the fact that there are still portability issues when one starts writing systemd units. -- 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Hi Russ, On Fri, Nov 01, 2013 at 08:11:38PM -0700, Russ Allbery wrote: Steve Langasek vor...@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
Bug#727708: systemd and support for other distros
On Mon, Dec 02, 2013 at 11:24:41AM -0800, Russ Allbery wrote: Steve Langasek vor...@debian.org writes: Note that the original complaint in the samba upstream discussion was about hard-coding of paths to system utilities, which a) is not portable between distributions and b) contradicts Debian policy. So systemd upstream may support separate /usr, but that doesn't change the fact that there are still portability issues when one starts writing systemd units. They're fairly trivial ones, though, no? Maintaining a local patch to change the paths in a systemd unit is certainly way less effort than maintaining the whole unit. It's akin to changing the #! paths in installed scripts, which we do all the time. In this case, the porting requirements are trivial, yes. My point is that porting is still required, and systemd units aren't write once, run everywhere the way systemd advocates have claimed. In my experience, the cost of a packaging delta is in *maintaining* the delta over time, not in creating it initially, and a one-line delta to something like a systemd unit is not measurably less of a maintenance burden than, say, a 20-line delta to an init script. (I should say, for full disclosure, that I have never been a fan of the implications of our always use PATH policy for init scripts anyway. I feel like init scripts or the equivalent should always start the same binary, regardless of what other things the system administrator has installed elsewhere on the system, unless explicitly changed by the administrator. Having them honor PATH is too likely to lead to really strange and difficult-to-diagnose problems, since you get different behavior when manually running the init script versus when it's started at boot.) Sure. Both systemd and upstart manage to avoid the problem of inconsistent behavior due to tainted admin environments, because daemons are always started as children of init and not of the admin's login shell. That being the case, hard-coding the path to an executable in your initscript equivalent doesn't buy you much added protection, compared with just using the system $PATH, and does cause gratuitous incompatibilities in exactly those cases that Debian Policy's prohibition on hard-coded paths is meant to address. -- 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#727708: systemd and support for other distros
Steve Langasek vor...@debian.org writes: On Mon, Dec 02, 2013 at 11:24:41AM -0800, Russ Allbery wrote: They're fairly trivial ones, though, no? Maintaining a local patch to change the paths in a systemd unit is certainly way less effort than maintaining the whole unit. It's akin to changing the #! paths in installed scripts, which we do all the time. In this case, the porting requirements are trivial, yes. My point is that porting is still required, and systemd units aren't write once, run everywhere the way systemd advocates have claimed. In my experience, the cost of a packaging delta is in *maintaining* the delta over time, not in creating it initially, and a one-line delta to something like a systemd unit is not measurably less of a maintenance burden than, say, a 20-line delta to an init script. Hm. I guess what I can say there is that this doesn't match my experience, mostly because the deltas that I've had to maintain to init scripts are much more serious than path changes. Path changes are pretty easy to maintain over time. Init scripts have historically required more serious changes for different helper function libraries, using Debian-specific tools like start-stop-daemon, and so forth. In fact, most of my upstreams have long since given up on trying to write a portable init script and just have separate ones for each major UNIX variant. By comparison, path differences are trivial. As far as I'm concerned, that still counts as write once, run everywhere. Sure. Both systemd and upstart manage to avoid the problem of inconsistent behavior due to tainted admin environments, because daemons are always started as children of init and not of the admin's login shell. That being the case, hard-coding the path to an executable in your initscript equivalent doesn't buy you much added protection, compared with just using the system $PATH, and does cause gratuitous incompatibilities in exactly those cases that Debian Policy's prohibition on hard-coded paths is meant to address. I have never seen a gratuitous incompatibility caused by this. Do you have any examples? -- 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/87wqjmc1ij@windlord.stanford.edu
Bug#728486: Current patch for resolving lvm/systemd compatibility
Hi Don, Don Armstrong d...@debian.org writes: I'd like to get this particular bug discussion restarted. Thanks for your mail. From my understanding, a static, non generator version of lvm2_activation_generator_systemd_red_hat.c will allow for the activation of lvm2 after the addition of an lvm device by udev/systemd. Michael: Is this correct? To the best of my knowledge, a static non-generator patch will make lvm2 work with systemd, yes. I offer to work on producing an easily mergable patch, should Bastian agree to that. -- Best regards, Michael -- 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/x67gbmamy1@midna.lan
Bug#728486: Current patch for resolving lvm/systemd compatibility
On Sun, Dec 01, 2013 at 05:49:13PM -0800, Don Armstrong wrote: Bastian: Would such a patch be acceptable in principle? After systemd was fixed, yes. Bastian -- Conquest is easy. Control is not. -- Kirk, Mirror, Mirror, stardate unknown -- 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/20131202225150.ga9...@mail.waldi.eu.org
Bug#727708: systemd (security) bugs (was: init system question)
On Sun, Dec 01, 2013 at 11:11:43PM +0100, Sune Vuorela wrote: On Sunday 01 December 2013 21:50:49 Ian Jackson wrote: This leads me to a question which I find myself asking, after reading the systemd debate page: If we were to adopt systemd as pid 1, which sections of the systemd source code would we probably want to adopt as well ? Or to put it another way, which other existing programs would be obsoleted ? logind is obsoleting consolekit and libpam-xdg. (Consolekit tracks wether or not a user is sitting on the physical console or logged in. libpam-xdg ensures that XDG_RUNTIME_DIR is handled according to the spec). Logind also ensures that a user session actually can be terminated when she logs out. Logind is the most important one, and within a year or two all desktop environments that wants to be slightly more advanced than TWM is going to need it. Even Ubuntu is using logind and is iirc maintained there by Steve Langasek. It's collectively maintained in Ubuntu; I do help with it, but Martin Pitt does most of the routine maintenance for the systemd source package (udev, logind). Beside that, there are among others: the timezoned is ensuring a common way that applications can get notified when the hosts timezone changes. KDE does have something for that that would be obsoleted. I think most other systems requires restart of applications or manual magic in each app. 'timedated' hostnamed is for notifying when hostname changes. KDE does have something for that. I don't know who else. There are more parts, but that's where my research has ended so far. The other one that GNOME uses, and that should be adopted, is localed. But these dbus services (logind, timedated, hostnamed, localed) are things that we should adopt, /independently/ of whether systemd is used as pid 1. I don't know that there are any systemd services that we would want to adopt IFF we switched to systemd for pid 1. -- 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#728486: Current patch for resolving lvm/systemd compatibility
Hi Michael, On Mon, Dec 02, 2013 at 11:48:54PM +0100, Michael Stapelberg wrote: Hi Don, Don Armstrong d...@debian.org writes: I'd like to get this particular bug discussion restarted. Thanks for your mail. From my understanding, a static, non generator version of lvm2_activation_generator_systemd_red_hat.c will allow for the activation of lvm2 after the addition of an lvm device by udev/systemd. Michael: Is this correct? To the best of my knowledge, a static non-generator patch will make lvm2 work with systemd, yes. I offer to work on producing an easily mergable patch, should Bastian agree to that. This was my concern with the technical implementation as well. I would be happy with lvm2/systemd integration that used a static configuration instead of requiring a generator. -- 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#727708: systemd (security) bugs
Le lundi 02 décembre 2013 à 13:41 -0700, Bdale Garbee a écrit : Josselin Mouette j...@debian.org writes: There are two implied assumptions here: * that the same people are developing all components; * that develolpers have the same attention to code quality and security in all components they work on. I don’t think either of them applies to systemd. Right, this succinctly captures one of my biggest concerns about systemd. Could you please elaborate on this concern? Is it about the large number of developers, or about the fact they treat important pieces of code more carefully? -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1386025428.9475.0.camel@tomoyo
Bug#728486: Current patch for resolving lvm/systemd compatibility
On Mon, 02 Dec 2013, Bastian Blank wrote: On Sun, Dec 01, 2013 at 05:49:13PM -0800, Don Armstrong wrote: Bastian: Would such a patch be acceptable in principle? After systemd was fixed, yes. Can you let me know which part of systemd needed to be fixed? [What bug# is this?] Can you also clarify for me why the patch needs to wait for systemd to be fixed? -- Don Armstrong http://www.donarmstrong.com Leukocyte... I am your father. -- R. Stevens http://www.dieselsweeties.com/archive.php?s=1546 -- 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/20131202231103.gm4...@rzlab.ucr.edu
Bug#727708: systemd (security) bugs
On Tue, 03 Dec 2013, Josselin Mouette wrote: Le lundi 02 décembre 2013 à 13:41 -0700, Bdale Garbee a écrit : Josselin Mouette j...@debian.org writes: There are two implied assumptions here: * that the same people are developing all components; * that develolpers have the same attention to code quality and security in all components they work on. I don’t think either of them applies to systemd. Right, this succinctly captures one of my biggest concerns about systemd. Could you please elaborate on this concern? Is it about the large number of developers, or about the fact they treat important pieces of code more carefully? Projects which have multiple components, each of which has different security/interface surfaces without stable defined interfaces, can lead to problems when one set of developers doesn't understand the security implications of the parts that they do not work on. The combination of components into a single monolith is sometimes necessary, but it's not clear that it is so in the case of systemd. -- Don Armstrong http://www.donarmstrong.com THERE IS NO GRAVITY THE WORLD SUCKS -- Vietnam War Penquin Lighter http://gallery.donarmstrong.com/clippings/vietnam_there_is_no_gravity.jpg -- 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/20131202233232.gn4...@rzlab.ucr.edu
Bug#727708: systemd (security) bugs
On Mon, 2013-12-02 at 15:32 -0800, Don Armstrong wrote: On Tue, 03 Dec 2013, Josselin Mouette wrote: Le lundi 02 décembre 2013 à 13:41 -0700, Bdale Garbee a écrit : Josselin Mouette j...@debian.org writes: There are two implied assumptions here: * that the same people are developing all components; * that develolpers have the same attention to code quality and security in all components they work on. I don’t think either of them applies to systemd. Right, this succinctly captures one of my biggest concerns about systemd. Could you please elaborate on this concern? Is it about the large number of developers, or about the fact they treat important pieces of code more carefully? Projects which have multiple components, each of which has different security/interface surfaces without stable defined interfaces, can lead to problems when one set of developers doesn't understand the security implications of the parts that they do not work on. The combination of components into a single monolith is sometimes necessary, but it's not clear that it is so in the case of systemd. IMO single monolith is bad terminology - to me that sounds something like everything in a single process, while the systemd components are quite modular. Not clear it's necessary seems like an overly negative attitude. There doesn't seem to be much disagreement about the fact that many of the systemd components are very useful and would be used even with a different init. The above security considerations seem purely theoretical, with no sign that they'd be an issue with systemd in practice. And IIRC no other actual technical problems resulting from developing the components together have been brought up in this thread either. So why should it be done any differently, when this way appears highly successful? -- 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/1386051464.1822.19.camel@glyph.nonexistent.invalid
Bug#727708: systemd (security) bugs
Don Armstrong d...@debian.org writes: Projects which have multiple components, each of which has different security/interface surfaces without stable defined interfaces, can lead to problems when one set of developers doesn't understand the security implications of the parts that they do not work on. It's unclear to me that this is a correct characterization of systemd. Do the separate components of systemd not have stable, defined interfaces? I know they largely don't have other implementations, but that's not the same thing. The combination of components into a single monolith is sometimes necessary, but it's not clear that it is so in the case of systemd. systemd is a large package from a source code perspective, but it's not my impression that the result of building that source is a monolith. Rather, it's a variety of separate, interoperating services, which strikes me as a good general model. In fact, that design is what makes it possible to consider using upstart and still support GNOME, since it means that logind is separable from systemd with some effort. That strongly implies that systemd is not a monolith. I think the concern on the systemd side is not stemming from unstable interfaces but from *evolving* interfaces, which is not the same thing. In other words, the current systemd services do not implement all the functionality that will be eventually needed, particularly by desktops, so those interfaces will grow with time, and may require further D-Bus, udev, cgroups, and similar integrations. Let me put it this way. I think there are a couple of givens here, some of which have been expressed by both the GNOME maintainers and the KDE maintainers and which are also reflected by the current state of Ubuntu: * We use udev as the default device management platform and will continue to do so regardless of the init system we choose. * Many of the other systemd services, particularly logind but also several of the others, are quite desirable or even necessary for desktop environments, so we will need to adopt those services in Debian regardless of what init system we choose. Obviously, if we adopt systemd, integrating those services into the distribution is quite straightforward. If we don't adopt systemd, there are some critical missing integrations (relative to the normal systemd infrastructure) that will have to be replaced. The cgroups manager appears to be the most significant one at the moment. If the interfaces for those supplemental components are actually unstable, that's going to pose problems all around, but I'm not sure how directly relevant to this discussion that is since we're going to have to deal with those components *anyway*. Choosing a different init system than systemd is not going to let us ignore logind, since it's going to be a required component for a modern desktop. (Although it would still be good to know if this is the case.) -- 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/87eh5u4ewi@windlord.stanford.edu
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Steve Langasek vor...@debian.org writes: 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). This is useful, thank you. So you believe that the necessary cgroup functionality will be easy to maintain going forward in collaboration with a different cgroup manager? How far away is this functionality from being production-ready? My understanding is that this will need to be tested and working for jessie. 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. Well, I partly agree with this, but I'll point out that upstart is currently significantly behind in functionality. Contrary to some other expressed opinions here, I personally do not consider systemd's support for such things as private /tmp or other security and isolation features to be minor side features or only marginally interesting. I think these sorts of features are where the Linux ecosystem is moving, quite quickly, and Debian badly needs those features as soon as we can get them. It's going to take some time to adapt all of our software to use those features, so the sooner our init system can provide them and we can get started, the better. I have a similar question about OpenRC: the lack of this sort of functionality is, for me, a very serious issue, although one that would be mitigated by a clear plan to add it that seems likely to happen. 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. The problem for upstart is that these are not comparable, precisely because Canonical plays such a smaller role in the broader ecosystem. For better or worse, integration with Red Hat and Fedora is extremely important to most of our upstream projects, and Red Hat provides significant development resources itself to many upstream projects. This means that systemd integration is far more likely to happen without Debian's assistance than upstart integration. I think the argument for upstart relies on the assumption that such integration is not horribly important or normally won't be a serious issue. In essence, my understanding of how you view a world with upstart (and the world that Ubuntu is implementing) is that we will use most of the systemd services but not its init engine,
Bug#727708: systemd code documentation
I should say up-front that I don't consider this to be a decisive issue, but since it was raised and I did a bit of investigation, I wanted to report my initial conclusions and see if I missed anything or got anything wrong. I did a quick code inspection of the code base for both upstart and systemd. This was quite far from any sort of audit, and was necessarily quite limited. The goal was to get a quick feel for the code smell and style, and to see how comfortable I would be working on the source base. First, I'll say that both projects seem like generally well-written C. They both use well-defined small functions, there isn't a lot of deeply-nested structure, they both have published coding styles and clearly adhere to them, and in general both packages strike me as written by people who knew what they were doing and have been kept up to date. (By comparison, sysvinit looks like old and somewhat crufty UNIX code and makes me nervous and uncomfortable, even though it's much simpler.) That said, on first impression the upstart code struck me as significantly superior to the systemd code in terms of orientation for a new developer or someone attempting to isolate bugs, primarily due to substantial differences in internal documentation. In systemd, each function seems well-designed and isolated and does document some of its assumptions with asserts, which is good style, but there are almost no comments. Functions usually don't have leading comments describing when to call them, header files don't comment functions, files don't have leading comments to orient the reader towards the purpose of the file, and most of the internal comments were cryptic to a first-time reader and struck me more as marginalia than commentary. By comparison, upstart was lovely code to read. It uses Doxygen, which I can take or leave, but more importantly it documents the internal interfaces and functions and provides much more internal orientation (although it could still use leading commentary for each file). My question here is: am I missing something in systemd? Did I just look at the wrong files, or not look deeply enough, or is there orientation documentation somewhere else where I didn't see it? Is there something about this comparison that's unfair? I'll admit that this is a debated point of style, and some programmers think that regular commentary make the code less readable and tend to become out-of-date. I'm in the other camp; I prefer orientation commentary on each logical block of code, and probably write code that some people would consider excessively commented. I think code should tell a story to someone who is reading it and invite understanding. (I've probably read too much Knuth, although I don't think Knuth's method of doing this worked.) -- 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/87zjoi2yjf@windlord.stanford.edu
