Re: Reframing (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)
Hi, On Thu, Dec 05, 2019 at 08:32:28AM -0500, The Wanderer wrote: > 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". Debian also has a bit of a special role in that it is upstream to other distributions, including the systemd-only Ubuntu and the everything-except-systemd Devuan, in addition to being useful as a standalone distribution, so the definition of "default" concerns not only our direct, but also indirect users. Simon
Re: Reframing (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)
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 signature.asc Description: OpenPGP digital signature
Re: Reframing (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)
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 ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS signature.asc Description: PGP signature
Re: Reframing (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)
Hi Ian, On Di 03 Dez 2019 13:54:40 CET, Ian Jackson wrote: * Should I adopt Guillem's framing as a preamble to my own proposal ? (Should this be a new alternative or a replacement?) * Would Guillem's framing make a good preamble to Dmitry's option ? * Or do the supporters of Guillem's option favour some other combination of possible answers to the specific questions ? Personally, I think that the full scope of the tendency spectrum regarding init systems is +/- covered by the available proposals. However, not all proposals provide proper guidance how to act and react in certain corner and/or non-corner cases. I think, this lack of specifics can be amended with a follow-GR that goes into details and fine-tunes the voted for proposal. Personally, I am much more on the multiple init systems side than on the systemd side, however, if the majority in Debian wants to see systemd-only, you can safe the drafting time today for other valuable tasks. My 2¢, light+love Mike -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpyIX_aSZYC3.pgp Description: Digitale PGP-Signatur
Reframing (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)
In some sense I am asking the same questions as Russ.
Guillem Jover writes ("Reframing (was Re: Proposal: Reaffirm our commitment to
support portability and multiple implementations)"):
> I've to say, that while I think I understand where your and other similar
> reactions to this proposal are coming from, I also found them a bit
> perplexing. :)
Let me skip to the end:
> The key here, I guess, is that each situation needs to be evaluated
> independently, and no magic decision tree will ever fix trying to work
> things out with other people, in good faith, and trying to find
> solutions or compromises that satisfy others and us too. But maybe this
> is asking too much, dunno. :/
>
> I understand that not giving apparently detailed guidance might make
> things more difficult for the policy editors, and I'm sorry about that,
> but I think no one ever expected that collaborating in a project such as
> Debian with people pulling in random directions would always be easy?
As you know I very much agree with you about the framing.
But it appears that you don't that we should then, in something like
your proposal, take the principles in that framing and apply them in
to some of the most contentious specific problems facing us today.
In its current state I think your proposal is unlikely to do well.
I am very keen that something with your framing text should do well.
Since you don't seem to agree that your option should be supplemented
by specifics, I would like to ask the rest of the community:
* Should I adopt Guillem's framing as a preamble to my own proposal ?
(Should this be a new alternative or a replacement?)
* Would Guillem's framing make a good preamble to Dmitry's option ?
* Or do the supporters of Guillem's option favour some other
combination of possible answers to the specific questions ?
I think they key specific questions are:
Q1 Init scripts. Possible answers, roughly:
E Lack of an init script is an RC bug; maintainers must write
init scripts.
D Lack of an init script is not an RC bug but contributions of init
scripts should be filed as RC bugs. Ie the non-systemd community
must write them but maintainers must accept them.
All other options [1]
Lack of an init script is a normal or wishlist bug and
maintainers can block them because they want systemd
hegemony.
Q2 sysusers.d, systemd timer units, etc.
E May not be used (RC bug) unless a non-systemd-pid-1
implementation is available. Ie proponents of these
interfaces must write the non-systemd variant.
D Can be standardised in policy and used but only if they (i) are
any good (ii) can sensibly exist for non-systemd. Ie, the
non-systemd community must write the non-systemd variant, but they
will get the time to do so.
All other options [1]
Everyone is allowed to use them willy-nilly and non-systemd
support will rot.
Q3 dependencies which cause init system switching etc.
E,D
Forbiddden
All other options [1]
Allowed. Theoretical degradations of dependencies on systemd
systems will continue to make it really hard to install and
maintain non-systemd ones.
I have written this mail To people who seconded Guillem's proposal and
to some people from the thread. I would particularly like to hear
your views.
I am considering making a formal variant of Guillem's proposal, which,
if Guillem doesn't agree that specific guidance is needed, would stand
on the ballot alongside Guillem's and my proposal D. I would like
that proposal to reflect the views of people who seconded Guillem's
proposal.
Thanks
Ian.
[1] Sam's B "Support for multiple init systems is Important" appears
to allow NMUs to provide init scripts and to use alternatives to
systemd facilities but it says "According to the NMU guidelines". The
NMU guidelines forbid NMUs when the maintainer has explicitly said
they do not want a particular change. So in practice a maintainer who
does not want an init script in their package can block this and the
only possible recourse is to the TC, which is not suitable and not
effective.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Reframing (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)
I'm going to make a similar point to Sam's but in a slightly different way that hopefully will help. (Also, I apologize for sounding rather too absolute in my initial response to your proposal. There were better ways of phrasing my concerns.) Guillem Jover writes: > I'm actually not sure how the other options can be seen as resolving the > root issue at hand. I see what they are trying to do, but I don't think > they are framing it correctly. They are all approaching the problem from > the symptoms, by either trying to go into details on how to integrate > specific stuff, or on how to behave. This all feels like they assume > that people would not respect the spirit of a decision, and to combat > bad faith they need to be very specific on details? But if we'd assume > people are going to be acting in bad faith, then no amount of details > and specifics would fix this, and IMO it can make it worse, as it gives > a list of things to be looking loop holes into and questioning > legalities all over. I think this is a recipe for disaster, and I also > find that type of framing a bit depressing. This isn't how I think about the options. I don't think people are going to behave in bad faith. Rather, I think the problem is what Sam alluded to: General statements of principle are more open to interpretation than their authors think that they are. With full respect and credit to those who have different goals for this GR, I personally am largely uninterested in the project making a general statement of principles about integrating technology. To be frank, I'm dubious of such statements. I don't think they're always helpful. I also think the principles of Debian developers are highly diverse (which is great), and perhaps our goal should not be to try to get everyone in Debian to align on the same principles, but instead to make practical decisions that can be supported from a variety of principles. The problem I want to solve is that we need to make three work-blocking decisions: 1. Is every package that wants to start a service always, sometimes, or never required to include an init script? If they are, at what bug severity and with what consequences if this is not done? 2. Are package maintainers allowed to use systemd-exclusive facilities that would improve system integration for systemd users or improve other goals (such as security) at the cost of compatibility with other init systems? If so, what process should we use for adopting those facilities? 3. How much effort is the project committing to undertaking to incorporate alternatives to major systemd ecosystem components (such as elogind) that are not drop-in replacements, either due to their own implementation limitations or because our dependency system or other tools makes drop-in replacement difficult? As one of the Policy editors, I am primarily concerned with 1 and 2. I'm only an interested bystander for 3 (ideally Policy should have something to say here, but we haven't gotten there). I see huge value in the project making those decisions without regard to whether the project can agree on principles underlying those decisions. I don't want to argue about interpretation of some general, non-specific statement. I want the project to make some decisions. I believe that we have already exhausted or ruled out other project mechanisms to make these three critical technical decisions (Policy process, debian-devel discussion, and the Technical Committee). I think delegatd teams and the Technical Committee are (correctly!) unwilling to speak for the project on these closely-divided and highly divisive issues. Debian is constituted as a democracy of developers. The project makes technical decisions of last resort via vote. We've put off this decision as long as we reasonably can, we've tried for five years to let the discussion calm down and to find some alternative method of reaching consensus, we've waited to see if some nonconfrontational approach will evolve, and people are still sniping at each other. Meanwhile, work that people want to do in Debian, whether that be better support for non-systemd systems or taking advantage of valuable systemd features such as ProtectSystem or DynamicUser, is often blocked on these decisions with no clear prospect for resolution or unblocking. You may have noticed in these discussions that I'm not talking about my own opinion about what the decision could be. I have an opinion, but I've spent enough energy attempting to convince other people of my opinions on init systems for one lifetime. On this vote, I'm on team "make a decision already, whatever that decision is," and the position I'm advocating here is please do not kick the can even farther down the road. Towards that end, here are the specific implications of the various options that I anticipate for Policy. Please note that this is just my personal opinion as one of the Policy editors. Sean doubtless
Re: Reframing (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)
> "Guillem" == Guillem Jover writes: Guillem> The key here, I guess, is that each situation needs to be Guillem> evaluated independently, and no magic decision tree will Guillem> ever fix trying to work things out with other people, in Guillem> good faith, and trying to find solutions or compromises Guillem> that satisfy others and us too. But maybe this is asking Guillem> too much, dunno. :/ Hi. I strongly agree with the above--that things need to be evaluated on a situation-by-situation basis. I'm responding not in the hopes of convincing you or persuading you (or really anyone else). It's obvious that we see the world differently. However, I feel that if I simply said nothing, I would not be respecting the thought you've put into your proposal and to your position. So, I'm responding to say that I've tried to listen and understand where you're coming from, and to show where I think our differences are. Thanks for the work that you put into this. While I disagree, I value what you've done here. My experience in leading groups to consensus is that it is often much easier to focus on specific details and specific situations than on general principles. It is very easy to get people to appear to agree when you are talking about generalities that can be widely interpreted. However, in practice when you go try and apply those generalities to specific cases, you find that the same divisions exist and that the generalities don't help much. There are exceptions: I think the Social Contract has done significant good for the project. In my experience those exceptions tend to be agreements to general principles not born out of conflict, but rather out of a community's desire to define itself. In contrast, when there is conflict, I've found that you get better results focused on specifics. But Guillem is right that as we move forward we'll find things where the specific details we focus on in this GR do not apply. We'll also find cases where circumstances have changed, we have new information, or new ways of thinking about something emerge. At that point, we can (and I think should) start to derive general principles from the specifics we adopt in the GR. I hope we take this GR as the feeling of the project at a single point in time and accept that things will change. I hope that we do not force ourselves to have future GRs to revisit aspects of what we decide in the coming weeks when we can come to agreement that things have changed. I respect that this is an area where people can look at the world differently. Thanks for placing option G on the ballot: if the project believes that focusing on principles is the right way forward here, we now have a way to concretely express that. signature.asc Description: PGP signature
Re: Reframing (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)
guil...@debian.org wrote: > * The traditional-only way camp: This group outright rejects things > like systemd, and other similar technologies. Some of this group was > part of Debian in the past, but found a new home in Devuan. People I read all my emails with mutt (which I used to maintain) and the news with tin (which I still maintain). I send all my emails over UUCP. My desktop is fvwm (with parts of GNOME!) My terminals are 80x25. I maintain Fidonet-related software. My favourite programming language is Perl. I use IRC all the time and I despise Slack. I judge people who send HTML emails or top quote or have signatures longer than 4 lines. I am quite fond of my traditions but I still recognize the systemic benefits provided by only supporting systemd: I do not accept for this issue to be framed as "tradition vs. progress". -- ciao, Marco
Reframing (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)
Hi! [ I'm sorry this has gotten a bit long, but I assume I'm going to run out of time for any discussion, due to the imposed timeline, so I'm trying to put it all upfront. ] On Sat, 2019-11-30 at 11:54:09 -0700, Bdale Garbee wrote: > Guillem Jover writes: > > I think the current GR is incorrectly framing the problem at hand, > > as if it was just an init system selection. > > This resonates with me, but... > > > I'm thus proposing the following: > > I find this really appealing as a higher-level statement of values and > intent, but unfortunately, I don't think the text does anything to help > resolve the problems that Sam set out to try and tackle with this GR. > > I therefore find myself unwilling to second it, even though on some > level I would really like to. I've to say, that while I think I understand where your and other similar reactions to this proposal are coming from, I also found them a bit perplexing. :) Other options - I'm actually not sure how the other options can be seen as resolving the root issue at hand. I see what they are trying to do, but I don't think they are framing it correctly. They are all approaching the problem from the symptoms, by either trying to go into details on how to integrate specific stuff, or on how to behave. This all feels like they assume that people would not respect the spirit of a decision, and to combat bad faith they need to be very specific on details? But if we'd assume people are going to be acting in bad faith, then no amount of details and specifics would fix this, and IMO it can make it worse, as it gives a list of things to be looking loop holes into and questioning legalities all over. I think this is a recipe for disaster, and I also find that type of framing a bit depressing. The options that favor focusing on systemd still seem to leave the door open in appearance to alternatives, but in some kind of false sense of hope way, due to either the proposed vague hopes or all the conditionals which depend on maintainer discretion to apply based on the (naturally insufficient) details provided on those options. It seems like a death by a thousand cuts, which sets the stage for more frustration and conflict. The options that favor init alternatives go into specific details (are these truly exhaustive enough though?). But they still seem to not be asking the right question. Let's skim over the other options: * Option F - The "cross-distro and standardization efforts" mention feels a bit misleading to me, as this is really restricted to an ecosystem based on Linux + glibc + systemd. (To clarify, I think this is obviously a valid stance to take, I mostly take issue in the way it is presented.) - Provides a false sense of hope (see above): + "patches _can_ be submitted". How is this going to prevent the same situations that triggered this GR? * Option B - Provides a false sense of hope (see above): + _Should_ include unit and init scripts. + Developers and user _can_ explore and develop alternatives. + Developers need to provide the work, but that does not imply others will integrate it. + Reviewing and discussing patches but obviously not necessarily agreeing to them. How are any of these going to prevent the same situations that triggered this GR? * Option A - Provides a false sense of hope (see above): + Focuses on sysvinit specifics like init script, but does not mention other potentially ancillary features upstream might use that are not core functionality to the project at hand. + The NMU reference looks like a distraction, as it does not fix any possible deadlock or blocking, as one can always reject an NMU, or revert it. + In Debian, policy (in most cases) follows practice, so whether policy accepts something does not say much about what maintainers will be accepting. How are any of these going to prevent the same situations that triggered this GR? * Option D - Goes into much detail about possible conflicting scenarios, but does it cover them all? This seems inherently non-exhaustive. - This encodes very concrete package names and implementation details, which seem off for a GR. + What if the sysvinit maintainers and users agree they want to switch to something else on top of sysvinit that does not use traditional init scripts? - Isn't option D.7 potentially very counterproductive? Mixing regressions in support with new support seems murky. Also what kind of patch are we talking about? A 10 liner, or 1 MiB of delta which upstream is not willing to take, so the burden falls on the Debian maintainers? * Option E - What does the "MUST" and "work" in here really imply? Does this mean every package must fully support natively all currently available init systems in Debian (runit, s6, etc)? Or say, the day after this option wins,
