Re: My analysis of the proposals
On Mon, 2019-12-02 at 21:37 +0200, Wouter Verhelst wrote: > For those who think that sysvinit is good enough, and that the problems > for which systemd provides a solution are not problems to begin with, > there is nothing wrong with the premise of "try to keep sysvinit at 2014 > levels indefinitely", on the contrary. So, while it's a valid question I don't doubt that there exist people for whose needs an existing sysvinit system can be perfectly adequate. Just like there are people for whose needs an old 80286 computer is adequate. But I don't think that contradicts with "is obsolete" or "is a technological dead end". There are reasons why support for some software should be low priority even if it's not yet literally absolutely useless for everyone. > As such, I don't think, and vehemently disagree with your stated > proposal, that we should decide anything on sysvinit in particular, > other than through the more general question of "should Debian support > anything that is not systemd". I still don't really see why you disagree with my view (not exactly a "proposal"). Which of these do you disagree with? fact: The conflicts that occur in practice are about sysvinit support. fact: There is in practice no development of new alternative init systems happening, and no clear reason to believe that if it hypothetically did occur, there would be particular problems. Certainly there are no concrete problems in need of resolution. consequence: How clearly a decision resolves conflicts is determined by how clearly it decides the question of sysvinit support. consequence: Talking about "other init systems" in general is either misleading, insofar as it's about policies that only have practical effect through application to sysvinit, or about uncertain hypotheticals that are in no particular need of resolving at this time. The relevant question now is not "should Debian support anything that is not systemd", but "should Debian support sysvinit". In case any promising systems appear in the future, decisions about them are best left for when it's not arguing about hypotheticals.
Re: My analysis of the proposals
On Mon, 2019-12-02 at 19:29 +0200, Wouter Verhelst wrote: > Sysvinit has worked for over 20 years. Yes, it has warts, but the warts > I therefore disagree in the strongest terms to make this be about the > position of sysvinit, except in so far as it is part of an abstract > group of "not systemd" options that we are trying to decide upon. I don't understand what point you're trying to make. My point was that what actual conflict there is, is in practice conflict between those who want to stay with sysvinit, and those who want to use systemd; and therefore the most practically important part of a resolution is how it would apply to sysvinit support. Your message first contains a defense of sysvinit, then a claim that "therefore" it should not be considered to be about sysvinit. I don't see how that "therefore" would logically follow.
Re: My analysis of the proposals
On Sun, 2019-12-01 at 18:43 -0500, Sam Hartman wrote: > > > > > > "Uoti" == Uoti Urpala writes: > > Uoti> IMO encouragement for supporting alternative systems could be > Uoti> reasonable, but only for actual new innovation; maintainers > Uoti> should be explicitly permitted to remove any existing sysvinit > Uoti> scripts and refuse addition of similar scripts. Systemd units > Uoti> should be no worse a basis to bootstrap a new system. > > > This is what I tried to capture with Proposal B. > I wrote a blog post yesterday which still should be on planet discussing > my thoughts about this and discussing some of the risks of that > proposal. Based on your blog post, your technological views seem similar to mine. Where my view differs, and why I think Proposal B is not particularly satisfactory, is more about the social view of opposition to systemd. Like you, I think that from a technological point of view you shouldn't assume that those who want alternatives to systemd would support sysvinit. However, as a matter of social reality, people who oppose systemd almost exclusively do want to keep using sysvinit. People who find systemd objectionable mostly just don't want to switch to it, without really caring about whether their current setup is a technological dead end or not. Thus, in practice, I don't think there is any real conflict between people who are trying to create innovative new systems and people who want to use systemd (I count elogind as "now needed to keep sysvinit working like in 2014" rather than any kind of innovation). There is a conflict between people who want to stay with sysvinit and people who want to use systemd. To resolve this conflict, the important part of a resolution would be how to treat sysvinit in particular. I don't think Proposal B clearly answers this question. It does not clearly say that Debian has no need to explore sysvinit technology any more than it already has, and it's now OK to throw away all sysvinit support. If it DID clearly say that, I think most of the practical conflict would already be resolved, and text beyond that would be mostly superfluous.
Re: My analysis of the proposals
Antonio Terceiro wrote: > However, as with any piece of software, systemd doesn't and won't ever cover > all use cases. It should be possible for people to use other init it they > choose so, for whatever reason. How well those would work should depend only > on > the effort of those interested in doing the necessary work. I think the discussion has concentrated too much on this principle in the abstract. The situation is clearer when you look at the more concrete details of what kind of changes there is controversy over. In short: there is little to no worthwhile work being done on any alternatives to systemd. What is happening is some people trying to keep sysvinit working to about the level it did in 2014, while doing very little fundamental development to the system that would fix its widely recognized flaws. Such work will not help innovation, will not produce a plausible alternative to systemd, and is not worth supporting. It was already near consensus five years ago that sysvinit was seriously lacking and improvements were needed. The choice of systemd over Upstart was more controversial, but systemd opponents have not managed to create an alternative that would reach even the level that Upstart had back then. Even Ian, as one of the main authors of the "diversity" proposals, agrees that sysvinit is flawed and significant future development would be needed. Yet he argues that sysvinit work should be respected, that it should not be considered obsolete, and so on. I disagree: it's perfectly reasonable to consider sysv init scripts obsolete, and consider "try to keep sysvinit at 2014 levels indefinitely" activity a dead end. Note that I'm not saying that people shouldn't develop alternatives to systemd. But to be taken seriously, they'd need to display some real progress beyond sysvinit (and Upstart). Just "this allows to boot without systemd" is not a worthwhile "alternative". "I disagree with systemd decisions, here's my fork / alternative system" - this may be OK depending on system quality. "I disagree with systemd decisions, but, uh, I don't really have resources to create a credible alternative, so... uh... let's just keep using sysvinit indefinitely?" - this is not OK, not EVEN IF your criticism of systemd choices were valid, and activity which amounts to essentially this does not deserve support. As there currently aren't credible alternatives to systemd, not even at the level of Upstart, I think it's wrong to phrase the question in terms of whether Debian "supports innovation" and so on. The practical question now is whether Debian insists on supporting the obsolete sysvinit, not because of any positive qualities it has or potential for future development (and very little forward development has happened in the last five years), but only because it allows systemd haters to avoid using systemd. IMO encouragement for supporting alternative systems could be reasonable, but only for actual new innovation; maintainers should be explicitly permitted to remove any existing sysvinit scripts and refuse addition of similar scripts. Systemd units should be no worse a basis to bootstrap a new system. TL;DR You'd need real work to develop a credible alternative to systemd. Nobody has done or is doing that work. As long as the practical alternatives are crap, abstract arguments like "diversity" or "supporting innovation" are no reason to support anything else.
Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]
Steve Langasek wrote: > On Fri, Oct 24, 2014 at 01:32:36PM +, Anthony Towns wrote: > > If you were literally beating people with a stick for not testing their > > packages with other init systems, that would certainly be compulsion, no? > > Using policy and RC bugs as a metaphorical stick to beat people with > > would similarly be compulsion, in my view. > > Debian never compels anyone to do any work. They always have the option of > not doing the work, and as a result, not having the software that they care > about being included in the release. > > You can read this as compulsion if you want, but that's clearly not what the > constitution means when it speaks of compulsion, because immediately after > stating that no one is compelled to do any work for the project it goes on > to say that they are not allowed to work against its rules. And one of > those rules is that we can set technical policies for the project by a But this GR has effects beyond anything that could be reasonably described as a general technical policy. It prohibits even leaf packages that offer functionality to the majority of people, unless the maintainers do possibly significant work for the benefit of a certain minority. Would you consider it as purely technical policy if Debian tried to help the adoption of better programming languages by forbidding any program implemented in PHP unless there's an equivalent program implemented in another language, or forbidding packaging of Perl modules unless an equivalent module was available for Python? > At the same time that systemd skeptics are feeling marginalized by the > systemd decision, systemd supporters are concerned about being prevented > from adopting systemd-specific interfaces that they want to use. Well, only > one of these groups can be a majority. Either the majority of DDs want us > to let software leverage systemd interfaces all the way up the stack, > possibly breaking support for non-systemd init; or the majority of DDs want > us to hold the line on diversity with respect to init systems, ensuring that > new interfaces need to be negotiated with the project in some fashion before > being adopted in the distribution; or both of these are minority views. > It's a legitimate use of the GR process to find out which of these groups is > actually the majority, and to require the project to respect the will of > that majority with regards to an issue that threatens to drive deep fissures > through our archive and through our community. IMO the above could be a valid justification for *a* GR, but it does not really apply to *this* particular GR proposed by Ian. There is no clear "leverage systemd interfaces all the way up the stack, possibly breaking support for non-systemd init" option for systemd supporters to select. The anti-systemd option is not "ensuring that new interfaces need to be negotiated with the project in some fashion", but strictly sticking with the obsolete sysvinit, no room for negotiating any upgrades. > thing to do. But I'm not even sure how I come down on this particular GR > question yet *personally*, because even if I think we should adopt systemd, > I have grave misgivings about Debian being tied to an upgrade treadmill by > an upstream that may pay little heed to things that matter to Debian's > community in the absence of a forcing function. If you have concerns about the *future* development of systemd, is sticking with sysvinit-level functionality like this GR really a sane answer? Even if systemd development goes in a direction Debian does not like, why wouldn't a fork of systemd be a better answer to that? It shouldn't be too much work to maintain a fork if it's only required to work better than sysvinit. > There are very powerful network effects with PID 1. I do not believe that a > "do-ocracy" approach is sensible in the face of such monopoly potential. > The playing field will always be biased towards the option that bundles more > features, whether or not Debian as a whole *wants* those features. Leaving > it for sysvinit supporters to play catch-up on features is not a way to > decide this matter if Debian's majority doesn't believe it's appropriate to > bundle those features in the first place. (N.B.: this doesn't require Systemd developers are making fast progress implementing several positive features that are desirable for Debian too. It does not really matter whether the majority believes it's appropriate to bundle those features with each other (or with other features that people don't care about) if there is no realistic plan to implement an at all comparable level of functionality without such bundling. "Biased" playing field or not, if one side gets a huge amount of useful functionality working and the other has nothing, trying to declare the latter side a winner only makes you ridiculous and/or irrelevant. And I don't believe that you could get a large amount of sysvinit work done by "you must work on this o
Re: Tentative summary of the amendments
On Wed, 2014-10-22 at 22:25 +0300, Aigars Mahinovs wrote:
> On 22 October 2014 20:14, Uoti Urpala wrote:
> > Ian Jackson wrote:
> >> Jonas Smedegaard writes ("Re: Tentative summary of the amendments"):
> >> > Quoting Nikolaus Rath (2014-10-22 05:09:18)
> >> > > I believe Ian's intended reading is that a package that depends on
> >> > > uselessd | systemd (but does not work with sysvinit) would be allowed
> >> > > by his proposal.
> >>
> >> Yes.
> >>
> >> In practice such packages are not going to be a big problem because
> >> writing init scripts for them would be straightforward, and then the
> >> dependency could be relaxed.
> >
> > So you agree that there is no fundamental problem with packaging
> > software that requires either systemd or uselessd?
>
> That would not be a problem, because uselessd is only an init system
> and does not include all the extra services that systemd does, for
You're not replying to what was the point of that paragraph. I was not
arguing that the GR might fail to outlaw things its proposers dislike.
The essential part was what you cut away:
> > So you agree that there is no fundamental problem with packaging
> > software that requires either systemd or uselessd? Does the GR still
> > require "someone"(tm) to package uselessd for Debian before
> > packaging
> > that other (fundamentally OK even by your standards) software is
> > allowed? To polish uselessd integration until it's actually a usable
> > init system in Debian? I assume you are not volunteering for this
> > work?
In another mail, Ian said that his interpretation is that the init
system would not only have to be packaged in Debian, but in testing and
not RC buggy.
So even GR proponents agree that software which works with either
systemd or uselessd would be fine. Yet they want to FORBID packaging
such software, unless someone packages and integrates uselessd for
Debian. That's a large amount of work which would be mostly unrelated to
the software running under those systems. And the proponents are not
volunteering to do such work.
> example - logind is not a part of uselessd. Therefore, even if
> uselessd is packaged tomorrow, there would still be just one init
> system in Debian implementing this feature. So the Ians proposal makes
> it a bug to depend on features that are only implemented in one init
This is technically inaccurate. Logind is used under other init systems
with cgmanager+systemd-shim (otherwise the claim that this GR would make
no difference for Jessie could not be true). Also, logind is not part of
the systemd init process either; it only requires the system to support
APIs that other init systems lack. So whether logind is shipped as a
"part of" uselessd doesn't necessarily matter much. I don't know whether
uselessd retains the APIs required by logind.
> I think that practical effect would be the same if we mandated
> "support running with at least one non-default init system at PID 1"
> or "support running with sysvinit at PID 1" or "support running with
> any init systems in the archive at PID 1" from the point of view of
> software being able to start with an alternative init system managing
> the installation (not from the point of view of having init scripts
> for all init systems).
That's kind of backwards - the practical effect of the GR is pretty much
to require that everything must implement sysv scripts, while there are
init features that should not be considered to be/remain specific to
systemd but sysvinit does not support. For example, any init system that
Debian might want to switch to in the future will support systemd-style
socket activation. Uselessd probably supports it. Of course, support for
socket activation could be implemented on top of sysvinit - but AFAIK
the GR proponents are not volunteering to implement that either.
Before Debian selected its next init system, there were three that could
reasonably work for a distro like it: sysvinit, Upstart and systemd.
Most of developers and all of tech-ctte agreed that sysvinit is outdated
and it was a choice between Upstart and systemd. Now Upstart is not a
real alternative any more, and no new system has risen to the status of
a credible contender yet. The GR talks about alternative init systems in
general, and tells people that they must support at least two, any two
they like. In practice it allows selecting any two from the set
{systemd, sysvinit}.
By making the hurdle as high as requiring that the alternative init
systems have actually been packaged and integrated in Debian, the
practical effect of the GR is pretty much "must support sysvinit", tying
Debian down to s
Re: Tentative summary of the amendments
Ian Jackson wrote:
> Jonas Smedegaard writes ("Re: Tentative summary of the amendments"):
> > Quoting Nikolaus Rath (2014-10-22 05:09:18)
> > > I believe Ian's intended reading is that a package that depends on
> > > uselessd | systemd (but does not work with sysvinit) would be allowed
> > > by his proposal.
>
> Yes.
>
> In practice such packages are not going to be a big problem because
> writing init scripts for them would be straightforward, and then the
> dependency could be relaxed.
So you agree that there is no fundamental problem with packaging
software that requires either systemd or uselessd? Does the GR still
require "someone"(tm) to package uselessd for Debian before packaging
that other (fundamentally OK even by your standards) software is
allowed? To polish uselessd integration until it's actually a usable
init system in Debian? I assume you are not volunteering for this work?
Consider what happens if the uselessd project is abandoned, and systemd
opponents do not come up with any other viable alternative either.
Upstart dies after Canonical abandons it. At some point in the future
developers decide that sysvinit is hopelessly obsolete, and maintaining
support for such an obsolete system will not be help migration to any
new init system appearing in the future (which would likely support at
least basic systemd features anyway). Does this GR imply that such a
decision may not be made without a new GR to override this one? Sysvinit
support must be kept indefinitely just to fulfill the "at least 2 init
systems" requirement?
I think the part about degraded operation with some init systems is
unclear. "Degraded operation with some init systems is tolerable, so
long as the degradation is no worse than what the Debian project would
consider a tolerable (non-RC) bug even if it were affecting all users."
Is this supposed to apply only to init systems that the package
"officially" supports in some sense? If a package works great with
systemd, with tolerable problems with Upstart, and is almost completely
unusable with Sysvinit, then a straightforward reading would suggest
that the GR would make it RC-buggy. Is the idea that the package would
declare that it requires either systemd or Upstart, and as long as there
are at least two such systems, the Sysvinit problems don't count?
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1413998067.32583.13.ca...@pp1.inet.fi
Re: Proposal - preserve freedom of choice of init systems
On Wed, 2014-03-05 at 00:42 +, Sam Kuper wrote: > On Mar 4, 2014 11:57 PM, "Uoti Urpala" > wrote: > > If systemd "hegemony" becomes a problem, there is a much better > > open-source answer: fork systemd. > > By saying this, you have outlined the following competing scenarios > for users for whom systemd is unsuitable... > > (1) Spend time trying to live with systemd. Conclude you can't. Fork > it. Hack the fork, perhaps extensively, until it becomes suitable for > your system - by which time it might no longer be very compatible with > anyone else's. > > (2) Continue using (e.g.) SysV, which you know works. Sysvinit never worked well. It's become worse since things have become more dynamic (both underlying kernel and use cases that need to be supported). That it ever worked even to the extent that it did was because people spent significant effort to work around its limitations. You can't expect them to keep doing that. For many years GCC was the only credible open-source compiler. Even if you think that the eventual appearance of LLVM as an alternative was a positive thing, do you really think it would have been a good idea for Debian to require before that that all packages must work OK if compiled with some other non-GCC compiler? Or that such a policy would actually have worked to create multiple credible compiler alternatives sooner? -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1393985146.31149.54.camel@glyph.nonexistent.invalid
Re: Proposal - preserve freedom of choice of init systems
Ian Jackson wrote:
> Ansgar Burchardt writes ("Re: Proposal - preserve freedom of choice of init
> systems"):
> > So if someone packages a new init system that is not compatible with
> > existing init scripts (e.g. if it does not support /etc/init.d/* as a
> > fallback), then it won't be able to start any service.
>
> This point was dealt with in the TC discussion on this same text.
>
> Packages are not required to support all init systems; they must not
> require "a specific" init system.
>
> Since in practice there is only one hegemonic init system, this is
> sufficient to ensure our commitment to diversity.
What does that really "ensure" in practice? The reason why pretty much
everyone is by now either already using systemd or moving to it is not
that upstream software would not work with anything else, but that
systemd offers better functionality than any current alternatives. This
resolution would not help make the alternatives any more plausible.
Upstart was the closest contender, but it was already clearly worse than
systemd, and after the announced Ubuntu move to systemd it probably
won't have much of a future. Whether OpenRC will be worth anything is
still an open question. The most likely practical result of this
resolution would be that people are forced to write some unreliable and
buggy init scripts for degraded functionality under the obsolete
sysvinit in order to fulfill the letter of the "multiple-init" support
requirement at a minimal level. That would only be a waste of resources
and would not help with any positive diversity.
If systemd "hegemony" becomes a problem, there is a much better
open-source answer: fork systemd. Systemd has obviously done a lot of
things better than its competitors, and even if you disagree with some
parts, it's the best available starting point. Insisting that you must
throw *all* currently systemd-specific features out in the name of
diversity would be idiotic - it'd be like insisting that Debian must
have various distro-specific non-FHS paths just for the sake of
"diversity".
If someone forks systemd, then most applications that require systemd
functionality will presumably continue working with the fork, and the
fork will fulfill the "multiple init" requirement. If nobody forks
systemd, then apparently people don't consider systemd hegemony to cause
that many problems - or at least not enough that they'd be willing to do
actual work to address them.
Of course, forking also gives a way to fulfill the requirements of this
proposal: create and package a fork of systemd with some minimal
changes, and now everything works with at least two init systems - the
original systemd and the mostly identical fork. If you want to argue
that the result would not be a credible independent project and could be
ignored, then IMO the long-term credibility of the current alternative
inits could be questioned too.
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/1393976072.31149.43.camel@glyph.nonexistent.invalid
