Comment by arkh
4 years ago
> I will not be sending any more patches due to the attitude that is not only unwelcome but also intimidating to newbies and non experts.
Maybe not being nice is part of the immune system of open source.
4 years ago
> I will not be sending any more patches due to the attitude that is not only unwelcome but also intimidating to newbies and non experts.
Maybe not being nice is part of the immune system of open source.
On the other thread, I suggested this was an attack on critical infrastructure using a university as cover and that this was a criminal/counter-intellgence matter, and then asked whether any of these bug submitters also suggested the project culture was too aggressive and created an unsafe environment, to reduce scrutiny on their backdoors.
Talk about predictive power in a hypothesis.
Given its ubiquity in so many industries, tampering with Linux kernel security sounds an awful lot like criminal sabotage under US law.
Getting banned from contributing is a light penalty.
> criminal sabotage under US law
It is pretty comfortably not sabotage under 18 USC 105, which requires proving intent to harm the national defense of the United States. Absent finding an email from one of the researchers saying "this use-after-free is gonna fuck up the tankz," intent would otherwise be nearly impossible to prove.
3 replies →
Either that or the CFAA
"I suggested this was an attack on critical infrastructure using a university as cover and that this was a criminal/counter-intellgence matter"
There is absolutely zero evidence of this. None. In my opinion it's baseless speculation.
It's far more likely that they are upset over being called out, and are out of touch with regards as to what is ethical testing.
Sure, don't attribute to malice what can be attributed to ignorance. But you have to admit that backdooring Linux would be huge and worth billions.
1 reply →
GP had a hypothesis and made a prediction based on it. The prediction turned out to be right. What more do you want?
3 replies →
"We're banning you for deliberately submitting buggy patches as an experiment."
"Well if you're gonna be a jerk about it, I won't be sending any more patches."
"I can excuse r̶a̶c̶i̶s̶m̶ wasting OSS maintainers time, but I draw the line at rudeness!" - (community)
There is nothing about enforcing high standards that requires hostility or meanness. In this case the complaint that greg is being intimidating is being made entirely in bad faith. I don't think anyone else has a problem with greg's reply. So this doesn't really come across as an example that demonstrates your "not being nice is necessary" view.
I think so. With a large project I think a realist attitude that raises to the level of mean when there’s bullshit around is somewhat necessary to prevent decay.
If not you get cluttered up with bad code and people there for the experience. Like how stackoverflow is lost to rule zealots there for the game not for the purpose.
Something big and important should be intimidating and isn’t a public service babysitter...
It feels like a corollary of memetic assholery in online communities. Essentially the R0 [0] of being a dick.
If I have a community, bombarded by a random number of transient bad actors at random times, then if R0 > some threshold, my community inevitably trends to a cesspool, as each bad actor creates more negative members.
If I take steps to decrease R0, one of which may indeed be "blunt- and harshness to new contributors", then my community may survive in the face of equivalent pressures.
It's a valid point, and seems to have historical support via evidence of many egalitarian / welcoming communities collapsing due to the accumulation of bad faith participants.
The key distinction is probably "Are you being blunt / harsh in the service of the primary goal, or ancillary to the mission?"
[0] https://en.m.wikipedia.org/wiki/Basic_reproduction_number
> It's a valid point, and seems to have historical support via evidence of many egalitarian / welcoming communities collapsing due to the accumulation of bad faith participants.
Could you provide references to some of this historical support?
3 replies →
I'm not sure why you think you have to be mean to avoid bad code. Being nice doesn't mean accepting any and all contributions. It just means not being a jerk or _overly_ harsh when rejecting.
You can create a strict, high functioning organization without being an asshole. Maintaining high standards and expecting excellence isn't an exercise in babysitting; it's an exercise in aligning contributors to those same standards and expectations.
You don't need to do that by telling them they're garbage. You can do it by getting them invested in growth and improvement.
that is depend on who you are asking. if i am taking "no nonsense" aproach then some people are having no problem. but other people, include especialy woman, are say that it is not "nice" and that there is some problem even if it is neither "mean".
also here we are seeing persons are having no interest in "growth and improvement", they are not even creating the good faith contributions to project.
> Like how stackoverflow is lost to rule zealots there for the game not for the purpose.
Like?
Honest questions getting downvoted, closed for being too broad, duplicates or just "Wrong" in the eyes of overzealous long time members
7 replies →
I was enjoying Linus being less aggressive, but maybe we do need angry Linus.
Angry Greg is doing a great job. Effective, and completely without expletives or personal insults.
He is doing a great job. But I think a few insults earlier on might have prevented a whole lot of trouble.
Angry Linus would risk a stroke responding in that email thread.
Because he's old. I think young Linus wouldn't have held back in making judgement about the quality and usefulness of the research being done here.
1 reply →
I enjoy Linus's wit in insulting people. He's good.
I enjoyed (and now miss) angry Linus.
> Maybe not being nice is part of the immune system of open source.
Someone for whom being a bad actor is a day job will not get deterred by being told to fuck off.
Being nasty might deter some low key negative contributors - maybe someone who overestimates their ability or someone "too smart to follow the rules". But it might also deter someone who could become a good contributor.
Being rude isn't going to discourage malicious actors, who are motivated by fame or wealth.
If you ran a bank and had a bunch of rude bank tellers, you are only going to dissuade customers, not bank robbers.
Being nice is expensive, and sending bad code imposes costs on maintainers, so the sharp brevity of maintainers is efficient, and in cases where the submitter has wasted the maintainers time, the maintainer should impose a consequence by barking at them.
Sustaining the belief that every submitter is an earnest, good, and altruistic person is painfully expensive and a waste of very valuable minds. Unhinged is unhinged and that needs to be managed, but keeping up the farce that there is some imaginary universe where the submitter is not wasting your time and working the process is wrong.
I see this in architecture all the time, where people feign ignorance and appeal to this idea you are obligated to keep up the pretense that they aren't being sneaky. Competent people hold each other accountable. If you can afford civility, absolutely use it, but when people attempt to tax your civility, impose a cost. It's the difference between being civil and harmless.
A better analogy: Attempting to pee in the community pool to research if the maintainers are doing a good job of managing the hygiene standards.
Enforcing formal behavior makes the deviant behavior more noticeable.
Proper analogy would be 'rude SWAT team', not 'rude bank tellers'.
Honestly WTF would a "newbie and non-expert" have to do with sending KERNEL PATCHES.
Personally I don't think you can become an expert in Linux kernel programming without sending patches. So over the long term, if you don't let non-experts submit patches then no new experts will ever be created, the existing ones will die or move on, and there won't be any experts at all. At that point the project will die.
but Greg had the correct that patches sent were in many part easily seeable as bad for any persons who are knowing C. each person must have some time new to C, and some time new to kernel, but those times should not be same.
Nobody is an expert on every subject. You could have PhD level knowledge of the theory behind a specific filesystem or allocator but know next to nothing about the underlying hardware.
My point is that "we're newbies on the topic of the Linux Kernel, so be friendly to us when sending Linux Kernel patches" is the worst argument I've heard about anything in years.
2 replies →
How is it possible that you have a PhD in filesystems but you don't know how to write an acceptable patch for the Linux kernel? That's what I call a scam PhD.
So they can tell companies "I am a contributor to the Linux kernel"..there are charlatans are in every field. Assuming this wasn't malicious and "I'm a newbie" isn't just a cover.
I had a professor in college who gave out references to students and made his assignments so easy a middle school kid could do the homework. He never said why but I'm 100% positive he was gaming the reviews sent back so that he'd stay hired on as an instructor while he built up his lesson plans. I think he figured out how to game it pretty quick seeing as the position had like 3 instructors before him whom students universally hated for either being ridiculously strict or lying through their teeth about even knowing what the difference between public and private meant.
Attacking those critical of your questionable behavior and then refusing to participate further is a common response people have when caught red handed.
This is just a form of "well I'll just take my business elsewhere!". Chances are he'll try again under a pseudonym.
Every time I have seen Theo from the OpenBSD project come down hard on someone, it was deserved.
But G. K-H's correspondence here is completely cordial and professional, and still gets all the results that were needed?
I disagree, I think it's important to be nice and welcoming to contributors but the immune system should be a robust code of conduct which explicitly lists things like this that will result in a temporary or permanent ban
I'm curious what sort of lawsuits might be possible here. I for one would donate $1000 to a non-profit trust formed to find plaintiffs for whatever possible cause and then sue the everloving shit out of the author + advisor + university as many times as possible.
EDIT: University is fair game too.
Absolutely. The derision that people like Linus get for being “mean” to big corpos trying to submit shitty patches is totally misplaced.
Not being nice is always to protect self. Not always effective though, and not always necessary.
Instead of not being nice, maybe Linux should adopt some sort of CI and testing infrastructure.
https://kernelci.org is a Linux Foundation project; there are others, but that's just the main one I know of offhand.
The idea that "not being nice" is necessary is plainly ridiculous, but this post is pretty wild--effectively you're implying that they're just amateurs or something and that this is a novel idea nobody's considered, while billions and billions of dollars of business run atop Linux-powered systems.
What they don't do is hand over CI resources to randos submitting patches. That's why kernel developers receive and process those patches.
Linux are have plenty testing machines, but it are not so simple that you seem to think for to test whole kernel. there is not any catching for all these possible cases, so not nice remain importance. and greater part is driver, driver need device for to work, so CI on this is hard.