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-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
