Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Combatting revisionist history

Here you can discuss every aspect of Debian. Note: not for support requests!
Message
Author
User avatar
slackguy
Posts: 91
Joined: 2014-11-29 03:22

Re: Combatting revisionist history

#41 Post by slackguy »

dont feed the trolls !

yes they are using government money to attack unix, X11 (ie, xcb, then waylayd) - anything that is not owened and controlled by ? (that is a good question)

but historically it is a laugh - because to get away with crime it cannot be done publicly

---------------------------
YES. systemd is hooked in with a remote debugger and such

YES. it is possible it could be used to root your system everytime you boot

YES it presents new incompatibilities

all the "binary fluff" needed for a (public domain software terrorist) is certainly present

if you compiled it yourself from source (you should) then you know your features and have choices

you have a choice of not using it , unless ubantu decides to cause it to be a dependancy of all debian utils. haven't heard they have done so. if they do: complain like hell

User avatar
dasein
Posts: 7680
Joined: 2011-03-04 01:06
Location: Terra Incantationum

WARNING!!! Actual math!

#42 Post by dasein »

By popular demand, an extended discussion of the gory analytical details...
confuseling wrote:You asked if anyone wanted to see your working. Yes please.
BACKGROUND
The GR vote was structured as a rank-ordering of five choices. These are ordinal data and need to be treated as such. To be clear: I'm saying that any attempt to demote these data to nominal, or to promote them to interval, is an act of intellectual dishonesty, deliberate or otherwise.

The five choices can be broken down into two discrete and non-overlapping subsets: three choices that take a technical position on systemd/gratuitous init coupling (S/GIC), represented as:

(1) MUST not
(2) SHOULD not
(3) MAY

And two choices that do not take a technical position, summarized as:
(4) "I don't want to talk about this."
(5) "Let's talk about this some more."

Again, each vote was a ranking of all five options, which means that each DD's vote can be represented as a vector in 5-dimensional space.

In case it isn't obvious, both #4 and #5 are identical in that they are talking about the individual's perceived need for dialog, be it further or any. But they do not affect that person's relative preferences for #1-#3. At all.

Thus #4 and #5 are said to be orthogonal to #1-#3. To build an analytical dataset, we separate out the individual's opinions about the need for dialog from his/her opinions about S/GIC (and thanks to their orthogonality, without altering the relative rankings of either subset in any way).

CLEANUP
Now, the resulting data is going to be harder to read if we don't take a moment to re-rank the votes. Re-ranking also does not affect the data in anyway. Watch.

Take two example vectors:

12345
14532

When we separate out the editorial opinions about dialog, we are left with:

123
145

In case it isn't obvious at first glance, these two votes express identical rankings of the three technical choices (that is: MUST not/SHOULD/not/MAY). Because these data are ordinal, not interval, re-ranking the data doesn't alter the results of any appropriate analytical procedure. So our vectors now read:

123
123

tl;dr This is an entirely cosmetic change that does not affect the analysis in any way.

Update July 2016
The original post provided a full summary of the analytical results, but lacked sufficient procedural detail to allow replication. In an effort to permit any motivated investigator to run/replicate this analysis, the following portion of this post has been updated and expanded.

NOTE: Small differences in inclusion/exclusion criteria have altered the total count of votes slightly. But the results remain unaffected.

Begin updated content
A total of 483 GR votes were cast, but not all of those votes are analytically usable.

Examples of unusable votes include:

- Votes that "ranked" multiple technical choices identically. (A "vote" for everything is the same as a "vote" for nothing.)

- Votes that failed to assign an explicit rank to each of the three technical choices (rendering ordinal analysis impossible).
  • NOTE: Although some might argue that "no vote" is basically the same as "low vote," replicable analysis is not and cannot be based on individual claims of clairvoyance. If the person actually casting the vote can't be bothered to express a simple, clear preference among three distinct choices, then there's really no point in trying to guess what s/he "really" meant, much less in trying to compare, for instance, a 42413 vote to a -2213 vote.
In all, some 125 of the GR votes (26% of the total) were unusable under these criteria.

ON WITH THE SHOW
The easiest way (at least for me) to think about the re-ranked data is as a series of three-digit codes that tells us the individual voter's preference among the three technical options.

Each digit of the 3-digit code represents the individual's preference among the three alternatives. The first digit position is the relative ranking of "MUST not," the second digit is the relative ranking of "SHOULD not," and the third digit is the ranking for "MAY." So a code of 123 would correspond to an extreme contra-S/GIC position (MUST not/SHOULD not/MAY), and a code of 321 would represent the opposite pole (MAY/SHOULD not/MUST not).

Aside: In case it's not obvious, we've just seamlessly deobfuscated the data by reducing what was once a huge 5-D matrix down to a handful of discrete points. Dimensionality reduction is a fascinating topic for anyone who's actually enjoying reading this.

Okay, so there are six possible "states" for each vote, but some of those "states" seem nonsensical or contradictory on their face. For example, a vote of either 132 (MUST not/MAY/SHOULD not) or 231 (MAY/MUST not/SHOULD not) would seem to be best explained by a typo. Happily, these contradictions occur in only 8 votes (6 for 132 and 2 for 231); because they are so few in number, the 8 affected data points may be included in or excluded from the analysis without affecting the ultimate results. (For simplicity's sake, this analysis excludes these 8 points.)

Ultimately, the 350 votes in the analytical dataset can be represented using the remaining four points. Let's have a look:

Image

As I've grown tired of repeating, the two "extremes" (the ??3s and the ??1s) are easily visible in the data, and they are nearly identical in size. They serve mostly just to cancel each other out. As is often the case in political elections, it's the folks in the middle who end up making the decision.

In this instance, those "moderates" are the 312s: folks who think that S/GIC is a Genuinely Bad Idea, but who simultaneously think that a(ny) blanket prohibition is also a Genuinely Bad Idea. (In my current mood, I do not concede their point, not even grudgingly.)

But here's the thing and there's just no getting around it: the 312s chose SHOULD NOT as their first choice. They pointedly and explicitly say that S/GIC is a bad idea, their only quibble is over Just How Bad.

To recap the quote from above:
The 312's basically wrote:...a requirement for a non-default init system will mean the software will be unusable for most Debian users and should normally be avoided.
(Emphasis added)
"This a bad idea and should be avoided in all but the most exceptional circumstances" is in no way a pro-S/GIC stance, nor is it even slightly equivocal on the question. And any attempt to suggest otherwise is nothing less than an egregious attempt to distort/misrepresent the historical facts. And that's exactly what this thread exists to combat.

On technical merits, S/GIC lost, 206-to-144. Really. Which is precisely why "we don't even need to talk about this" was pure cowardice. QE-friggin-D

Thus endeth the lesson.

End updated content

Now, @confuseling, for the third time... about that billion-dollar value proposition? I think I've been pretty patient about it. But it has been over a month since I first asked, and it's getting to the point where continued lack of response seems like you tacitly admitting that, y'know, there isn't one. Maybe publish your current draft just to shut me up. Or hey, point me to a quantitative cost justification published/produced by someone else. I just want to see the data, I'm not picky about authorship.

(Sincere and legitimate analytical questions responded to. Trolling of any stripe pointedly ignored.)

Edit: For the benefit of folks who popped into this post from the link I added to the initial post, here's a handy "return" link back: http://forums.debian.net/viewtopic.php? ... 52#p570367
Last edited by dasein on 2016-07-10 16:08, edited 6 times in total.

goulo
Posts: 47
Joined: 2012-01-19 09:52

Re: WARNING!!! Actual math!

#43 Post by goulo »

Thanks very much for that analysis, dasein. It is very illuminating (and depressing).

So to confirm my understanding: the vote (rather bogusly/foolishly) mashed together people's technical assessment of whether systemd was good or bad with people's political/social desire to keep talking about it? And when you separate out the political/social question and look only at the technical assessment, you're left with this pretty stark telling conclusion that a majority thought systemd was technically a bad idea:
dasein wrote:As I've grown tired of repeating, the two "extremes" (the ??3s and the ??1s) are easily visible in the data, and they are nearly identical in size. They serve mostly just to cancel each other out. As is often the case in political elections, it's the folks in the middle who end up making the decision.

In this instance, those "moderates" are the 312s: folks who think that S/GIC is a Genuinely Bad Idea, but who simultaneously think that a(ny) blanket prohibition is also a Genuinely Bad Idea. (In my current mood, I do not concede their point, not even grudgingly.)

But here's the thing and there's just no getting around it: the 312s chose SHOULD NOT as their first choice. They think S/GIC is a bad idea, their only quibble is over Just How Bad.
Given that, how did systemd end up getting accepted? My understanding now is that it's because of the 4th & 5th non-technical questions being included? Apparently many voters (on both sides of the technical divide) gave higher priority to "I don't want to talk about this" than to any of the 3 technical assessments, and therefore further discussion was simply killed for non-technical reasons and instead because of weariness over discussion, because most people did not see the bogosity of mixing together the technical and the social/non-technical issues into a single ranked vote?

User avatar
dasein
Posts: 7680
Joined: 2011-03-04 01:06
Location: Terra Incantationum

Re: WARNING!!! Actual math!

#44 Post by dasein »

goulo wrote:So to confirm my understanding: the vote (rather bogusly/foolishly) mashed together people's technical assessment of whether systemd was good or bad with people's political/social desire to keep talking about it?
Correct. (More pedantically: #5 focused on whether to keep talking; #4 opined that any discussion whatsoever was unnecessary.)
goulo wrote:And when you separate out the political/social question and look only at the technical assessment, you're left with this pretty stark telling conclusion that a majority thought systemd was technically a bad idea:
Sure looks that way, huh?
goulo wrote:Given that, how did systemd end up getting accepted?
It's important to separate out the acceptance of systemd from the GR vote. The original acceptance of systemd was done a long time ago by a very small (and similarly divided) committee (the TC). The TC vote ended up being a tie, with the normally nonvoting chair casting the deciding vote.

In offering the GR, Ian Jackson noted that many of the concerns raised during the TC's original discussion were dismissed at the time as purely speculative/"slippery slope"/just a bunch of FUD. But Jackson's call for the GR noted that time had shown those early concerns to be exactly correct and entirely valid. (And so they are. As things stand right now, a friggin' spreadsheet can (and does!) require a specific init system. Talk about bogosity!)
goulo wrote:My understanding now is that it's because of the 4th & 5th non-technical questions being included?
Well, one could argue that "SHOULD not" is merely "advisory" in nature, and thus not binding on the devs who are foolishly proceeding with GIC. But it's hard for me to see how conflating the two discussions served the cause of clarity. I can't speak to peoples' motives, but the unquestionable effect of #4 was to obscure the technical results pretty thoroughly, while simultaneously laying a convenient foundation for the kind of revisionist history we see trying to take shape. Maybe it's just a Cosmic Coincidence.
Apparently many voters (on both sides of the technical divide) gave higher priority to "I don't want to talk about this" than to any of the 3 technical assessments...
Right again. I'm working from memory but my best recollection is that "We don't need no steenkin' GR" got well over 200 "first votes," including plenty from folks whose technical vote was contra-S/GIC.

Aside: One doesn't have to dig deep to find such votes. In fact, the very first row on the raw tally sheet is a clear contra-S/GIC vote obscured by a "No GR required" cover. The raw vector is 32415, which translates into: No GR/SHOULD not/MUST not/MAY/Further discussion (corresponding to a 213 vote in the de-obfuscated data). This is exactly why I have explicitly characterized as "drivel" confuseling's repeated misrepresentation of #4 as "implicitly" pro-S/GIC. Trying to claim that #4 is a pro-S/GIC position is both factually inaccurate and utterly unsupported by the empirical data. (I did offer a warning about the dangers of pontificating from ignorance at the start of this thread, but some people just can't resist.)

Aside #2: To be fair, ignorance-laden invective is in no way exclusive to either side of the systemd "debate." The early discussion of systemd here at FDN was thoughtful, nuanced, and technically well-grounded. It grieved me to watch that discussion get totally hijacked (and ultimately derailed) by the content-free tirades of a technically clueless contra-systemd "talking head." All of which serves to underscore the point I raised in my OP that very few folks have the chops to think in detail about a(ny) complex, multideterminate technical question (including this one). (It's also why I resigned from the staff. I hated the fact that as a spamhunter, I could ban a user outright, but was not trusted with the power to simply lock a thread that had clearly gone "off-the-rails.")
...and therefore further discussion was simply killed for non-technical reasons...
More accurately, the results of the GR vote were rendered moot for entirely nontechnical reasons. But yeah, to-MAY-to/to-MAH-to.

confuseling
Posts: 2121
Joined: 2009-10-21 01:03

Re: Combatting revisionist history

#45 Post by confuseling »

So your analysis basically revolves entirely around characterising this:
Debian has decided (via the technical committee) to change its default
init system for the next release. The technical committee decided not to
decide about the question of "coupling" i.e. whether other packages in
Debian may depend on a particular init system. However, the technical
committee stated in #746715 that "[it] expects maintainers to continue to
support the multiple available init systems in Debian. That includes
merging reasonable contributions, and not reverting existing support
without a compelling reason."

The Debian Project states that:

Software should support as many architectures as reasonably possible,
and it should normally support the default init system on all
architectures for which it is built. There are some exceptional cases
where lack of support for the default init system may be appropriate,
such as alternative init system implementations, special-use packages
such as managers for non-default init systems, and cooperating
groups of packages intended for use with non-default init systems.
However, package maintainers should be aware that a requirement for a
non-default init system will mean the software will be unusable for
most Debian users and should normally be avoided.

Package maintainers are strongly encouraged to merge any contributions
for support of any init system, and to add that support themselves if
they're willing and capable of doing so. In particular, package
maintainers should put a high priority on merging changes to support
any init system which is the default on one of Debian's non-Linux
ports.


For the jessie release, all software available in Debian 'wheezy'
that supports being run under sysvinit should continue to support
sysvinit unless there is no technically feasible way to do so.
Reasonable changes to preserve or improve sysvinit support should be
accepted through the jessie release. There may be some loss of
functionality under sysvinit if that loss is considered acceptable by
the package maintainer and the package is still basically functional,
but Debian's standard requirement to support smooth upgrades from
wheezy to jessie still applies, even when the system is booted with
sysvinit.

The Debian Project makes no statement at this time on sysvinit support
beyond the jessie release.
As an anti-systemd position. Reads a lot more like 'patches welcome' to me.

You've then used that interpretation to bucket people who voted for the 'coupling is fine' position above 'coupling is unacceptable' as being anti-systemd (your first post in the thread, where "systemd came last"). That doesn't seem very honest, particularly in a thread about revisionism. It seems likely to me that a significant chunk of them pragmatically accept that upstream software is going to depend on it, and there isn't always going to be a lot Debian can do about it, even if they want to: it says nothing about their feelings about systemd.

If we ignore the people who preferred the relatively neutral option 2, we see from your own tally that 148 people preferred 'coupling is fine', and 95 'coupling is unacceptable' - that seems to be about the most direct way of measuring the size of the two poles to me, though obviously it doesn't tell you whether they're voting on the principle of maintainer autonomy, or on systemd specifically.

More broadly, people preferring option 2 or option 3 (either of the 'coupling is acceptable' positions, differing on how desirable), number 262 vs. 95. My position coming into this thread was that most devs seemingly voted that "systemd is where development is heading". You've said nothing that challenges that.
The Forum's search box is terrible. Use site specific search, e.g.
https://www.google.com/search?q=site%3A ... terms+here

User avatar
dasein
Posts: 7680
Joined: 2011-03-04 01:06
Location: Terra Incantationum

Re: Combatting revisionist history

#46 Post by dasein »

Yes, I "pretend" that a document that explicitly says "This renders Debian unusable for a majority of its users and should generally be avoided" expresses a negative sentiment. (Does that, y'know, surprise you?)

I can't help but notice that you've applied some very creative alterations to the data:
  • - Pretending that these data are nominal (a position I've already characterized as fundamentally dishonest, not to mention analytically nonsensical).

    - Additionally, re-casting the word "avoid" as somehow "neutral," which requires a very... um... unconventional definition of the word "neutral." (And it requires an excruciatingly twisted Reality Distortion Field to claim that the word "avoid" somehow implies endorsement, as you have.) As I noted earlier in the thread, this kind of tortured word-butchery is extremely popular among systemd fanbois, from Poeterring on down. But that doesn't make it true.

    - Not content merely to mangle language, whatever passes for arithmetic on your planet allows you to count "SHOULD not/MUST not/MAY" (213) as a pro-S/GIC vote. Wow.
But I'm the one misrepresenting these results?

Image

(Though I do thank you for this exquisitely fine example of "backfire effect." You are quite literally trying to rewrite reality in a desperate attempt to "support" your position.)

And still nothing on that value prop. Color me stunned.

Ok then. No más discussing "methodology" with the intellectually dishonest and arithmetically challenged. No amount of data can penetrate a Reality Distortion Field so strong that a 213 vote looks even vaguely pro-S/GIC.

User avatar
golinux
Posts: 1579
Joined: 2010-12-09 00:56
Location: not a 'buntard!
Been thanked: 1 time

Re: Combatting revisionist history

#47 Post by golinux »

dasein . . . I just had occasion to repost this link on the devuan ML in the hopes of quelling yet another long discussion about systemd. One of the participants wrote this in response.

And since I'm here . . . an FYI on Devuan adoption.
May the FORK be with you!

User avatar
/tmp
Posts: 426
Joined: 2011-12-31 08:39
Location: GNU Userlands
Has thanked: 1 time
Been thanked: 3 times

Re: Combatting revisionist history

#48 Post by /tmp »

As of right now I tolerate the existence of systemd because it does not violate the Four Freedoms. However, when it comes to the replacement of init with systemd, removing the foundation of a house in order to repaint that house is baffling. Is it worth it to set up or continue maintaining init based computers?
Bookworm | Intel I7-3667U | Apple Macbook Air 5,2 (Mid 2012) (Laptop) | 8 GB RAM | 3rd Gen Intel Core Graphics

Post Reply