On 2019-12-05 at 04:34, Raphael Hertzog wrote: > 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. To me, it looks as if this entire thing is an outgrowth and/or another expression of something which I've seen - and, I think, sometimes pointed out - as far back as the original "should we change the default init system?" discussions: people don't have a shared understanding of what it means for an init system to be the default. At minimum, "X is the default" means "you will get X if you don't take any action to avoid doing so". All definitions I can think of seem to share that baseline. At something like maximum, "X is the default" could be read to mean "getting anything other than X is not expected to be possible". There is a lot of room in between those two, and I believe I've seen people who seem to be expecting it to mean many different things in that range. (Just offhand, I can't even tell what meaning you had in mind when you used the term in the last quoted paragraph above.) At least from a certain perspective, the various options presented in this GR - and some of the positions taken in discussion, which may not have become formal options - can be seen as advocating for various definitions of "default" within that range. It has been, and remains, my opinion that until we (preferably) reach agreement on what is meant by this term in the context of init systems, or (at least) bring the various definitions being used - if only implicitly - by different parties/factions/whatever into explicit view, we will not even be able to have fully meaningful discussions of the subject, let alone actually reach an agreement which might settle the larger init-system arguments. I've been hoping, every time this discussion comes up, that we would wind up having that explicit conversation about what "default" does or should mean in this context (although I haven't tried to speak up with that goal nearly as often as I've had the thought, because I'm not great at that type of advocacy and it usually seemed like doing so would be less likely to help than to make the situation worse). Unfortunately, as far as I can tell, that doesn't seem to have ever happened. This GR seems to be nearly as close as we've come, and it's still a layer or two of implicitness away from actually making it explicit. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature