Re: RFC: OpenRC as Init System for Debian
On Sun, Apr 29, 2012 at 2:45 PM, Roger Leigh <rleigh@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,
Reply to: