Combatting revisionist history

Here you can discuss every aspect of Debian. Note: not for support requests!

Re: Combatting revisionist history

Postby goulo » 2015-02-27 21:57

1of12 wrote:For years the average user didn't know or care what init system was used and didn't care about hal, dbus, policykit, consolekit, PAM and similar stuff creeping onto their systems. Most desktop users have used or tolerated parts of gnome and KDE, which made big use of these interfaces, for years, and there was barely a complaint.

And now there's a lot more awareness about the security risks of large complex software than there was a few years ago, as more and more security-compromising bugs are actively exploited. Not to mention a lot more awareness of spyware and intentionally planted bugs and weaknesses in crypto-related software.

So there is more incentive to keep things simpler instead of needlessly accepting massive amounts of newly written system-level code spearheaded by a guy whose software quality and motives are suspicious to many people. Even before all this, I switched from Gnome (which had been installed by default on my old Ubuntu system) to LXDE and was quite pleased to not have all the additional bloat.

In any case, whether or not the majority of people know or care about something is not a very useful criterion in deciding whether I care about something. Plenty of people see no harm in smoking, for example, but that doesn't mean I am going to start smoking.
goulo
 
Posts: 47
Joined: 2012-01-19 09:52

Re: Combatting revisionist history

Postby dasein » 2015-02-28 05:10

For those who'd care to learn about the Unix philosophy before dissing it: https://en.wikipedia.org/wiki/Unix_philosophy

Particularly worthy of attention is the section on the 17 rules. They aren't just principles of good software design; they are principles for effective problem solving in general.

Then too, a systematic preference for simpler solutions isn't just the "unix way." It's Occam's Razor, which is not only basic epistemological hygiene, it's a crucial element of the scientific method, and a "best practice" in every engineering discipline I'm aware of.

Which is not to say that there aren't other approaches to systems development, and certainly not everyone likes Unix. One self-proclaimed Unix hater described it as "a computer virus with a UI." But it's a little tough to argue that the Unix philosophy hasn't proven successful. (Harder still for the scientific method.)

(Man, for a guy who wasn't going to post much anymore, I sure do have a big mouth. Just sayin'.)
User avatar
dasein
 
Posts: 7775
Joined: 2011-03-04 01:06
Location: Terra Incantationum

Re: Combatting revisionist history

Postby JLloyd13 » 2015-02-28 11:29

Make each program do one thing well [...]
Choose portability over efficiency.


And yet they insist they are Unix inspired- its quite insulting really how they (Red Hat & Co) treats us.
Laptop: Debian GNU/Linux 9 'Stretch' 64bit
Read: https://wiki.debian.org/DontBreakDebian/
We are the Universal OS. Be patient, give help, teach the Debian way.
User avatar
JLloyd13
 
Posts: 394
Joined: 2012-06-29 04:08
Location: Halifax NS Canada

Re: Combatting revisionist history

Postby dasein » 2015-02-28 17:45

emariz wrote:...giant sets of tools, like Gnome, depend on systemd,

Which is great if one envisions Linux (Debian in particular) as existing primarily to provide a backend for GNOME. Otherwise, artificial and unnecessary interdependence among components is a symptom of the core problem, not a justification for it.

emariz wrote:...packagers must decide whether to ... create alternatives...

No, systemd is the re-invention; working userspace is the wheel. It already exists. And while I'm not suggesting for a moment that it's problem-free, I know of no data that even hint at any flaw(s) in existing userspace so severe as to justify a multi-billion-dollar rewrite-from-scratch.

JLloyd13 wrote:...its quite insulting really how they (Red Hat & Co) treats us.

In fairness, I don't think anyone can blame RedHat for what Debian has decided to do. That's exactly why the GR was absolutely necessary. Bless Ian Jackson for insisting that folks stop (or at least pause for a moment) to consider the larger implications of the systemd decision, regardless of outcome.
User avatar
dasein
 
Posts: 7775
Joined: 2011-03-04 01:06
Location: Terra Incantationum

Re: Combatting revisionist history

Postby dasein » 2015-03-11 02:54

Hallvor wrote:Maybe you could give this post a little more work and publish it somewhere on the web with the title: "The history of systemd." Why shouldn't the losing side write history for once? :)

As it turns out, this history is being written by the winners, at least as regards the technical merits of systemd and gratuitous init coupling.

In case it isn't obvious, a deep dive into data is my idea of a fun Friday night.

The raw tally sheet is available online, so I decided to forcibly deobfuscate the systemd vote, for the benefit of posterity. So I simply removed all of the "votes" that did not affect the technical decision, and then rank-ordered the remaining data.

At multiple levels of granularity, roughly 80% of Debian devs are split very nearly down the middle into clearly defined and recognizably entrenched positions, pro- and contra- systemd (thus reinforcing the notion that "there was never any real 'debate'").

(I'd still love to know the median ages of those two groups, and I'll bet a beer that the difference is statistically significant.)

It's also why, in retrospect, a fork was probably not only predictable, but inevitable.

Anyway, the remaining 20% think systemd is a bad idea, but think that any blanket rule might also prove to be a bad idea. (And I'll admit it again: they might have a point. Maybe. Depending on my mood.) Since the other two groups basically cancel each other out, this is the group whose vote would have carried the day if the self-destruct amendment hadn't been allowed.

So, here's what they actually said:
There are some exceptional cases...[h]owever...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)

(Full text available here: https://www.debian.org/vote/2014/vote_0 ... dmenttexta)

And that, ladies and gents, is what Debian developers actually think of systemd in general, and gratuitous init coupling in particular, minus all the B.S.

(Anybody give a flyin' flip about the gory analytical details?)
User avatar
dasein
 
Posts: 7775
Joined: 2011-03-04 01:06
Location: Terra Incantationum

Re: Combatting revisionist history

Postby confuseling » 2015-03-21 19:29

Righty, so you got rid of all the votes that said "the status quo is fine, nothing to see here", when the status quo is that systemd is the new default and where the majority of development is focusing. And you concluded that in fact everyone hates systemd.

Do you see a methodological flaw with that?
The Forum's search box is terrible. Use site specific search, e.g.
https://www.google.com/search?q=site%3A ... terms+here
confuseling
 
Posts: 2143
Joined: 2009-10-21 01:03

Re: Combatting revisionist history

Postby dasein » 2015-03-21 19:54

No. Removing noise is a well-established and well-understood part of signal processing.

Now, about that billion-dollar value proposition?
User avatar
dasein
 
Posts: 7775
Joined: 2011-03-04 01:06
Location: Terra Incantationum

Re: Combatting revisionist history

Postby confuseling » 2015-03-21 20:01

I've just got rid of all the mainstream parties in the last US election results, because, well, you know, they don't really stand for anything. Turns out the Maoists won again! Funny old world, isn't it?

Have fun on your crusade... (but really, this is beneath you).
The Forum's search box is terrible. Use site specific search, e.g.
https://www.google.com/search?q=site%3A ... terms+here
confuseling
 
Posts: 2143
Joined: 2009-10-21 01:03

Re: Combatting revisionist history

Postby dasein » 2015-03-21 20:16

confuseling wrote:I've just got rid of all the mainstream parties in the last US election results, because, well, you know, they don't really stand for anything. Turns out the Maoists won again! Funny old world, isn't it?

Have fun on your crusade... (but really, this is beneath you).

And straw man arguments are beneath you, confuseling. If you don't understand how to divide a dataset into two orthogonal subsets, then maybe you shouldn't be talking about methodology.

And thanks for illustrating so vividly my point about what happens when systemd fanbois are challenged to articulate a value prop. Couldn't have asked for a better exemplar.

Afterthought: Some folks asked early in this thread why I felt move to post it. This is exactly the reason why. "Status quo = fine and status quo = systemd" is not what the "no GR required" amendment said, nor is it even remotely close. In point of fact, the amendment makes no mention whatsoever of either systemd or init coupling. Anyone who wants to "cite" that amendment might want to consider reading it before mischaracterizing it as an implicit (or explicit) endorsement of systemd. (Again, don't take my word for it. Go look it up.)

Afterthought the Second: For the benefit of someone stumbling upon this thread in the future, confuseling's argument is a straw man because "vote for one and only one, winner take all" of US political elections is nothing like the structure of the GR vote. Rather, the GR vote was a ranking of alternatives for each preference.

tl;dr: In the GR vote, everyone voted for everything. There is zero valid analogy to US politics.

(And this is exactly what I had in mind when I encouraged folks in my OP to do their homework before posting what I characterized as "GR-related drivel.")
Last edited by dasein on 2015-03-22 07:51, edited 5 times in total.
User avatar
dasein
 
Posts: 7775
Joined: 2011-03-04 01:06
Location: Terra Incantationum

Re: Combatting revisionist history

Postby Linadian » 2015-03-21 20:50

I can't resist not chiming in...Debian should be following its own path, not Redhat's. If I wanted an overbearing monolithic svchost.exe, I would have stayed with Windows. Debian used to be a leader, now they're just a sad little follower. Enjoy the systemd bugs and headaches. I would even hazard a guess there's some pimply faced kid in his parent's basement finding vulnerabilities in systemd as I'm typing this, the multiple houses of cards (all those that embraced systemd) tumbling down simutaneously will be a joy to watch. My systemd free computer will still be able to boot and get on the internet to read about it, lol.
Linux Registered User 533946
User avatar
Linadian
 
Posts: 490
Joined: 2013-12-20 15:25
Location: In a systemd free distro

Re: Combatting revisionist history

Postby slackguy » 2015-03-22 18:30

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
slackguy
 
Posts: 91
Joined: 2014-11-29 03:22

WARNING!!! Actual math!

Postby dasein » 2015-05-04 03:49

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: viewtopic.php?f=20&t=120652#p570367
Last edited by dasein on 2016-07-10 16:08, edited 6 times in total.
User avatar
dasein
 
Posts: 7775
Joined: 2011-03-04 01:06
Location: Terra Incantationum

Re: WARNING!!! Actual math!

Postby goulo » 2015-05-04 07:34

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?
goulo
 
Posts: 47
Joined: 2012-01-19 09:52

Re: WARNING!!! Actual math!

Postby dasein » 2015-05-04 15:36

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.
User avatar
dasein
 
Posts: 7775
Joined: 2011-03-04 01:06
Location: Terra Incantationum

Re: Combatting revisionist history

Postby confuseling » 2015-05-04 20:45

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
confuseling
 
Posts: 2143
Joined: 2009-10-21 01:03

PreviousNext

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 9 guests

fashionable