My analysis of the proposals

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

My analysis of the proposals

Antonio Terceiro-3
First of all, I would like to thank those who took the time to make proposals.
This is a very draining issue, and I thought more than twice about saying
something about it publicly at all. I hope that this is useful.


My position
-----------

I think systemd is better than anything that came before. I think it's good
that it has been made the default, and I don't want to do any substantial
amount of work to support anything else. I think the majority of our users are
better off with a well-integrated system based on systemd. The non-init
facilities for declarative configuration, such as support for system users and
temporary files, are a big improvement with regards to our traditional
maintainer script approach, and we should standardize on strategies like those.

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.

On the one hand, maintainers should not be forced to do work to support
non-default configurations. On the other hand, they should not stand in the way
of those who want to put the effort in to make non-default setup work.

Personally, I commit to take patches for non-systemd support, even if I cannot
test them, as long as there is not something clearly wrong or I trust the patch
submitter enough to just take their word for it.

I also think that the challenge of supporting multiple configurations
like this is an interesting engineering challenge, and would like to
contribute to make it easier for those want to spend their effort in
supporting alternative init systems. For example I considered a few
times adding support for testing packages against non-systemd test
systems to ci.debian.net, and didn't do it so far just due to lack of
time. Anyone who wants to work on that with my guidance can talk to me
by mail ([hidden email]) or on IRC (#debci).

Analysis of the current proposals
---------------------------------

In light of the above, I created the following checklist to evaluate the
current proposed options:

* non-systemd support is not mandatory
* maintainers should be free to use non-init facilities provided by systemd
* maintainers should be encouraged to take patches for non-systemd support

What follows is my evaluation of the current options, based on the above
checklist. Matching an item in the checklist provides 1 point, or 0.5 if if the
match is not very clear or partial.

* Proposal A (Sam): 2

  It doesn't say anything about the non-init facilities

* Proposal B (Sam): 3

* Proposal D (Ian): 2.5

  Even though it allows for the use of the non-init facilities, it imposes a
  somewhat artificial delay for having them accepted in policy, which in the
  worst case means at least a 6 month delay even if there is no effort from the
  communities of alternative init systems to provide an implementation.

* Proposal E (Dmitry): 1.5

  Makes supporting non-default setups mandatory, and will in practice prevent
  usage of non-init declarative facilities until there is actually
  implementations outside of systemd (which can be forever in the worst case).

* Proposal F (Martin): 2.5

  Errs on the opposite side as proposal D (Ian), relegating non-default init
  support to wishlist.

* Proposal G (Guillem): ?

  As others have pointed out, this contains no concrete proposal so far.  It
  reads to me like a great preamble to an actual proposal, but without the
  proposal part.


I am still wondering where I want to put my threshold, but so far I am
leaning towards ranking any proposal with score 2 or lower below
NOTA/FD.

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: My analysis of the proposals

Uoti Urpala
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.

Reply | Threaded
Open this post in threaded view
|

Re: My analysis of the proposals

Sam Hartman-3
>>>>> "Uoti" == Uoti Urpala <[hidden email]> 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.

That said, parts of your message would have been more constructive if
they were phrased more politely.
It's possible to disagree with people (even very strongly) while still
respecting that there are different opinions.
As a recipient of such disagreement I've found Debian to be a much more
enjoyable place to be when people take the time to do that.

--Sam

Reply | Threaded
Open this post in threaded view
|

Re: My analysis of the proposals

Uoti Urpala
On Sun, 2019-12-01 at 18:43 -0500, Sam Hartman wrote:

> > > > > > "Uoti" == Uoti Urpala <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|

Re: My analysis of the proposals

Simon Richter
In reply to this post by Uoti Urpala
Hi,

On 02.12.19 00:07, Uoti Urpala wrote:

> 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.

The main work in keeping sysvinit working on the same level as 1994 or
2014 is to stop people from removing working init scripts.

There is no need to innovate with sysvinit. Anything that is more
complex than "run program" is out of scope, and that is by design.

Systemd has reached a level of complexity where debugging failures is a
specialized skill set rather than just application of generic shell
script knowledge and a few simple design concepts. The promised "flatter
learning curve" got appended at the bottom of the mountain and only
increased the total height. There is a nice plateau there though.

Effectively we now have a new class of user that knows a set of magic
incantations to make a piece of black box software behave, but cannot
repair problems outside of that.

Twenty years ago, we used to make fun of people who crammed system
administration recipes for their MCSE exams instead of learning how the
system worked so they could derive them on the spot like we did on Unix.
Thing is, that was impossible on Windows then, and it is impossible with
systemd now, because the actual implementation is complex and very much
in flux.

If I have a use case where systemd is the best choice, such as when I
need to install a system for someone who is less interested in
technology than I am, I will happily do so. For my use cases, it
provides few tangible benefits, requires me to pick up otherwise useless
knowledge and disables most of the debugging tools I'm used to (and
requires me to pick up even more otherwise useless knowledge to replace
them).

[...]

> 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 phrase "supporting innovation" in this context means adopting new
interfaces introduced through systemd, so that is basically what you are
asking for.

Despite being the default init system, systemd is where the "innovation"
happens. The other init systems do not feel the need to innovate, and to
some of us, that is a good thing.

> 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.

I wouldn't classify myself as a hater, it just provides no additional
benefit to me at the rather high cost of learning a lot of things that I
need to know in order to use the system as I did before.

Debian's approach with init scripts is already more complex than what I
started out with, which was rc.local on NetBSD: a single file that would
just start one daemon after the other, with "sleep" commands in between
to avoid daemons starting in parallel and competing for disk I/O.

The step from rc.local to init scripts is still relatively flat though
compared to the jump from init scripts to service units.

> 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.

That's the thing: I'm equally uninterested in any other new init
systems, because the purpose of my computers is not to run an init
system, but to run specific productivity applications on them.

My job as a system administrator is not to run an init system or update
it with the latest features, but to keep an application running. Change
is bad. Change requires attention. Change is work. Change is costly.

This is the axis on which I measure whether an init system is "better"
than another. Systemd, by design, cannot compete with sysvinit on that
axis, and that is neither a flaw in systemd nor in the way I measure
that axis.

If you remove all other options, then obviously systemd will remain as
the "best" option on that axis, but I don't consider "best of one" a
very flattering statement.

It remains the case that users have different use cases, and different
programs are differently well suited for these. I've written[1] about
that in 2016, and not much has changed there.

   Simon

[1] http://www.simonrichter.eu/blog/2016-03-03-why-sysvinit.html


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: My analysis of the proposals

Wouter Verhelst
In reply to this post by Uoti Urpala
On Mon, Dec 02, 2019 at 03:59:58AM +0200, Uoti Urpala wrote:

> On Sun, 2019-12-01 at 18:43 -0500, Sam Hartman wrote:
> > > > > > > "Uoti" == Uoti Urpala <[hidden email]> 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.

While I prefer systemd on my personal systems, I don't think this
framing is in any way correct or fair.

Sysvinit has worked for over 20 years. Yes, it has warts, but the warts
are well-known and can fairly easily be dealt with. More importantly,
the concept of how sysvinit works ("here's a bunch of scripts that are
executed" is at a certain level easier to grasp than systemd's concepts.

You may be of the opinion that systemd is strictly and obviously better,
but that is a judgment call, one which reasonable people may disagree
with. There is nothing wrong with being of the opinion that booting with
sysvinit is easier to grasp and preferable over using systemd. It is
therefore still a valid alternative for as long as Debian does not make
the use of systemd mandatory.

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.

--
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Reply | Threaded
Open this post in threaded view
|

Re: My analysis of the proposals

Russ Allbery-2
In reply to this post by Simon Richter
I should say up front that I'm not also replying to Uoti along the same
lines only because Sam and Wouter already have.

Simon Richter <[hidden email]> writes:

> Systemd has reached a level of complexity where debugging failures is a
> specialized skill set rather than just application of generic shell
> script knowledge and a few simple design concepts. The promised "flatter
> learning curve" got appended at the bottom of the mountain and only
> increased the total height. There is a nice plateau there though.

> Effectively we now have a new class of user that knows a set of magic
> incantations to make a piece of black box software behave, but cannot
> repair problems outside of that.

> Twenty years ago, we used to make fun of people who crammed system
> administration recipes for their MCSE exams instead of learning how the
> system worked so they could derive them on the spot like we did on Unix.
> Thing is, that was impossible on Windows then, and it is impossible with
> systemd now, because the actual implementation is complex and very much
> in flux.

This sort of presentation is a good example of the kinds of social
problems that always surface in this debate.  I realize that you were
provoked, which also wasn't okay, but I hope that in re-reading these
three paragraphs you can see how insulting it is to those who prefer to
use systemd, and how it serves as bait for systemd users to defend their
choice against what they see as unfair and inaccurate criticism.

You may not *like* how debugging systemd works, and you may believe that
it is much more complex or uses systemd-specific instead of general
skills.  Many other people *do not agree with you*.  Stating these
opinions as if they're uncontrovertible facts contributes to emotional
burnout and makes Debian a less enjoyable project to interact with.
Please acknowledge that you could be wrong, and that other equally
intelligent and thoughtful members of the project have arrived at
different conclusions.

We were doing so well in this thread in staying away from reiterating
these aggressive and insulting arguments about each other's preferences,
and then Uoti dug up a common line of attack and baited you into making
the rote response.  Please don't.

--
Russ Allbery ([hidden email])              <https://www.eyrie.org/~eagle/>

Reply | Threaded
Open this post in threaded view
|

Re: My analysis of the proposals

Uoti Urpala
In reply to this post by Wouter Verhelst
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.


Reply | Threaded
Open this post in threaded view
|

Re: My analysis of the proposals

Wouter Verhelst
On Mon, Dec 02, 2019 at 08:36:11PM +0200, Uoti Urpala wrote:

> 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.

I grant you that I could have quoted better. Allow me to try to do that
now.

You wrote, in a message upthread, the following:

> [...] 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".

This to me framed the rest of what you wrote, also in later messages. I
should have replied to the above message rather than the later one, but
I guess I was not careful enough. Sorry about that.

Anyway, my point is that even if you think that sysvinit is now no
longer a valid option, that is an opinion that reasonable people could
disagree with.

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
for Debian to decide whether to continue to support alternative
solutions to systemd, I don't think it's reasonable for someone who is
not involved with any of the alternatives to decide whether one of the
available options is valuable to begin with.

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".

Thanks,

--
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Reply | Threaded
Open this post in threaded view
|

Re: My analysis of the proposals

Uoti Urpala
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.


Reply | Threaded
Open this post in threaded view
|

Re: My analysis of the proposals

Paul Tagliamonte-3
On Tue, Dec 03, 2019 at 01:31:53AM +0200, Uoti Urpala wrote:
> 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.

I know I'm going to regret wading in here -- but maybe I can help?

Uoti -- Remember when reading this rest of this message that from what I
can understand from what you've written, we will likely vote nearly the
same way on this GR. I've not hid the fact that I vastly prefer systemd
to sysvinit, and don't really care about sysv anymore (sorry not sorry?).

However:

This is not the right place to have this discussion. I don't think
trying to hash this out here is productive, and largely isn't adding to
the substance here.

We need to have this GR **not** to rehash the last god knows how many
years since "the bug" was filed, but to provide direction to the project
on what we should be doing (on a technical level) when it comes to
supporting multiple init systems.

The options provided are to show us a way out of this mess. I don't
think trying to comapre and contrast is helpful or even relevant to this
vote at all. The technical merits are largely not in play and shouldn't
factor in to the vote too much.

Please can we stop this discussion and getting baited into talking about
the technical merits of pid 1?

   paultag

--
 .''`.  Paul Tagliamonte <[hidden email]>
: :'  : Proud Debian Developer
`. `'`  4096R / FEF2 EB20 16E6 A856 B98C E820 2DCD 6B5D E858 ADF3
 `-     http://people.debian.org/~paultag

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: My analysis of the proposals

Russ Allbery-2
In reply to this post by Uoti Urpala
Uoti Urpala <[hidden email]> writes:

> 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".

I encourage you to take a step back and think through what you're trying
to accomplish by using phrases like that.  Do you expect someone who wants
to continue to run sysvinit for the time being to see a statement from you
that sysvinit is obsolete or a technological dead end and think "oh, I
never considered that, I guess I should stop using it"?

In other words, I don't think it matters whether or not those statements
are correct because, regardless of whether they are correct, they are not
persuasive.

Saying that something is obsolete in the free software world is
essentially a forecast.  Because free software can always form the basis
for additional development, it's making a *prediction* that no one is
going to use that specific piece of software as a basis for future
development or keep it working for new use cases.  It's difficult to make
predictions, especially about the future [1].

Making non-persuasive statements of position like this doesn't come across
as participating in a discussion or attempting to find common ground or
shared goals.  Instead, it provides tribal signaling: you are aligned with
the "stop supporting sysvinit" camp and you want everyone else to know
that.

My position is that those statements are not useful, and indeed are
actively harmful, for the following reasons:

1. We're about to hold a vote, which is the formal way in which Debian
   developers can decide what position they want to take.  While
   persuasive arguments may be useful before a vote, declarations of
   voting intention are less useful (unless they are an argument for
   making a change to a proposal).  There's no point in voting before we
   vote.  (I don't remember if you are a Debian developer; if not, perhaps
   your goal is to persuade other people who can vote.  However, as
   mentioned, these sorts of statements are not persuasive to people who
   disagree with you.)

2. Voting via mailing list post just encourages other people to also vote
   via mailing list post because they're worried that silence seems like
   disagreement, and then the thread degrades into a bunch of people
   stating their (unsurprising and already known) positions, which is both
   noisy and demoralizing.

3. It's extremely hard to make statements like this without having them
   come across as implicit, or even explicit, attacks on people who
   disagree with you.  (And you're not currently succeeding at that, IMO.)

In my opinion, it is very, very unlikely that anyone is going to come up
with a new, insightful, and perceptive argument about init systems that is
going to change a bunch of people's minds in the course of a debian-vote
thread, given the past six (!!) years of project discussions.  We've
already heard all the arguments.  Many times.  This is why the discussion
has focused on process and on ensuring the voting options reflect the
possible ways forward, rather than on the merits of the positions.

[1] https://quoteinvestigator.com/2013/10/20/no-predict/

--
Russ Allbery ([hidden email])              <https://www.eyrie.org/~eagle/>

Reply | Threaded
Open this post in threaded view
|

Re: My analysis of the proposals

Sam Hartman-3
In reply to this post by Uoti Urpala
>>>>> "Uoti" == Uoti Urpala <[hidden email]> writes:
    Uoti> I still don't really see why you disagree with my view (not
    Uoti> exactly a "proposal").

    Uoti> Which of these do you disagree with?

As someone charged with facilitating discussions within Debian, I'm
asking you to stop this thread now.
It's obvious there is some lingering misunderstanding, but I do not
believe this discussion on -vote will be served by exploring it further.

It seems clear that:

* There are people here who value being able to use sysvinit.

* There are people here who would value Debian deciding not to support
  sysvinit.

* We respect both these views, and deciding among them is one potential
  outcome of the current GR process.

I don't think it was your intention to escalate the situation, but that
seems to be happening, and I'd ask you to step back rather than
continuing.

Sam Hartman
Debian Project Leader.

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: My analysis of the proposals

Thomas Goirand-3
In reply to this post by Uoti Urpala
Hi,

I've CC-ed Benda, so he may answer too.

On 12/2/19 12:07 AM, Uoti Urpala wrote:
> 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.

I don't agree. OpenRC is, these days, better than what Upstart was in
many ways. For example, it supports cgroups, it is state-full, and it
has process supervision [1] (all of which Upstart didn't have as a
feature). I cannot agree that OpenRC doesn't bring any innovation. Just
try it, it's easy:

apt-get install openrc sysvinit-core

reboot, and you're done. If you want more, you can replace sysv-init by
openrc-init (beware that the "reboot" command isn't implemented by
default, see the Gentoo doc for that...).

Writing a runscript is as easy as a systemd unit, and the page I link to
shows it's a little bit different, but largely as easy.

What needs to actually happen, IMO, is that sysv-rc dies in the favor of
OpenRC as a replacement, so that we have a way of getting completely rid
of the obsolete part of sysv-rc (ie: slowly replacing sysv-rc init
scripts by declarative runscripts) without loosing anything. Benda, why
don't you do that?

Cheers,

Thomas Goirand (zigo)

[1] https://wiki.gentoo.org/wiki/OpenRC/supervise-daemon