Hi, On Mon, 02 Dec 2019, Guillem Jover wrote: > Reframing > --------- > > Why have init systems become such a contentions and toxic issue? I mean > yeah, it potentially integrates with many parts of the system, but we do > have other components in the distribution with multiple or non-portable > implementations, where we have managed to handle them all just fine (at > least w/o major conflict)? Say http servers, databases, etc., or Linux > specific security frameworks such as SE Linux or AppArmor. We even have > multiple implementations of things like shell interpreters, or awk. The > exact same thing applies to hardware architectures, some of which have > less popcon than say GNU/Hurd or GNU/kFreeBSD! It's easier to handle multiple alternatives for optional components. You can have a Linux system without any security module or without an HTTP server or database server. You can't have an OS without a kernel or without an init system. For the kernel, we already made it clear that we are primarily about Linux, both due to the name of our distribution and with the fact that the release architectures. I certainly appreciate the non-Linux ports and I'm generally in favor of welcoming those efforts under the Debian umbrella as long as they don't impede the rest of the project in any substantive way. For the init system, we have changed the default but it seems that in the minds of many contributors, it should be considered an equal to openrc or sysvinit and we should not fully embrace it so that it remains equal to the other init systems. I believe that's the part that needs to be clarified with this GR: - (a) either we endorse the fact that we can fully embrace it, accepting that we create more work for contributors of alternate init systems - (b) or we don't want to fully embrace it and we stick to a minimum usage of systemd features I'm firmly in favor of (a) but that doesn't mean that I don't welcome the contributions of people using alternative init systems and I still believe that we can host their work within Debian. > * Portability and alternatives camp: This proposal. I see it, as allowing > and welcoming people from both the above camps, as long as they are > open to constructively cooperate, and accept that these both camps > exist, their respective technologies have value, and that there are > people that are fine with using any of these alternatives or at least > supporting them. And that this makes for a richer and more interesting > project with different perspectives. I do believe their respective technologies have value and that Debian can/should offer those technologies if we have volunteers, but I also believe that we should not consider all those technologies as equal, and that when we have to make a choice for the default implementation of a non-optional component, we should fully embrace it. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hertzog@debian.org> ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
Attachment:
signature.asc
Description: PGP signature