On Sun, Apr 29, 2012 at 2:45 PM, Roger Leigh <rle...@codelibre.net> wrote: > One of the definining characteristics of the Linux ecosystem, including > Debian, has been that the system has been made up of a set of loosely- > coupled compoments with well-defined interfaces. This is in stark > contrast to, e.g. Windows, MacOS and other proprietary systems, which > have extremely tight coupling between their components, and where being > able to swap out one component for another is almost unheard of. Given > that this loose coupling has enabled experimentation with a wide > variety of different solutions to problems, and allowed the evolution > of a diverse range of different packages to solve a very wide variety > of needs, it could be considered one of the defining factors in the > success of Linux. Quite why we would want to replace this with a > one-size-fits-all solution beggars belief.
Just to be clear, what you're describing is specific to systemd, not to event-based init systems in general. It's true that diversity fosters innovation. I think the question here is, should Debian make technical choices based on whether or not the resulting distribution is an ambient that fosters innovation on init system design? And when I think of it that way, the answer seems to be a resounding no. > Given the ongoing debate regarding the different init systems we might > want to adopt long-term, I think this is perhaps one of the less > discussed factors, but perhaps one of the more important ones. Both > systemd and upstart are technically superior to all the alternatives, > systemd perhaps more so. But while the technical advantages are nice, > these come at the cost of reducing the amount of diversity in the > system, and our ability to replace pieces which don't fit our needs > due to the tight coupling. Just to be clear again, this is also specific to the current event-based init implementations. It's not in any way a characteristic of event-based init systems in general. Integration versus flexibility is a tradeoff. At one end of the spectrum, we have a very tightly integrated distribution, where nothing is interchangeable. At the other end, we have the concept of distribution as a simple collection of binaries with pretty much no integration. Having a better integrated init system would push Debian a little bit towards the former, no doubt. > While sysvinit is clearly inferior, it gives us (Debian) something the > others do not: control over our own destiny, and the ability to > modify every aspect of it and the init scripts to fit our needs. Both > systemd and upstart are largely influenced by third parties. As a > trivial example: systemd creates user session information in > /run/user/$user . I brought up with lennart the fact that this would > only permit one session per user. He rejected out of hand the fact > that more than one session would ever be needed, because Gnome only > allowed one session per user. So the limitations of Gnome in this > respect have led to a fundamental limitation in systemd's session > management. > > We could patch and work around this type of brokenness easily enough. > But given the rapid speed at which systemd is growing and swallowing > up more and more functionality previously served by different tools, > would we have the ability and will to continue to patch every bit that > didn't fit our needs, and keep that working over time? If we can't, > we'll potentialy end up with a technically superior system... which > meets the needs of Gnome/Fedora and other distributions, rather than > our own. And when the primary maintainers have shown themselves to > be less than willing to accommodate even this simplest of requests > (as above; a single tempnam call would have been sufficient), would > we be committing ourselves to a less than desirable fate? That's certainly something we need to take into account. There's an option you didn't mention: forking. I think it's better to fork than to try to come up with something from scratch. When people write stuff from scratch, 9 out of 10 times they just don't understand the problem they're trying to solve. And if it's a big project (such as an init system), it's very unlikely to ever get off the ground. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canvyna838ycfnqc7g0todrcjkdbsmpdjh-9zrsz4x4aymrh...@mail.gmail.com
