# Author: Squire, M. # License: Open Database License 1.0 # This data 2015LTinsultsLKML.tsv.txt is made available under the # Open Database License: http://opendatacommons.org/licenses/odbl/1.0/. # Any rights in individual contents of the database are licensed under the # Database Contents License: http://opendatacommons.org/licenses/dbcl/1.0/ # # filename: 2015LTinsultsLKML.tsv.txt # explanation: # This data set is part of a larger group of data sets # described in the paper below, and hosted on the FLOSSmole.org site. # Contains insults gleaned from messages sent to the LKML mailing list by # Linus Torvalds during the year 2015 # # fields: # date: this is the date the original email was sent # IU permalink: this is a permalink to the email on Indiana University's LKML archive # type: this is our code for what type of insult we think this is # mail excerpt: this is the fragment of the email containing the insult(s). # Ellipses (...) have been added where necessary. # # Please cite the paper and FLOSSmole as follows: # # Citations: # Squire, M. & Gazda, R. (2015). FLOSS as a source for profanity # and insults: Collecting the data. In Proceedings of 48th # Hawai'i International Conference on System # Sciences (HICSS-48). IEEE. Hawaii, USA. 5290-5298. # # Howison, J., Conklin, M., & Crowston, K. (2006). FLOSSmole: A # collaborative repository for FLOSS research data and analyses. # International Journal of Information Technology and Web # Engineering, 1(3), 17–26. # date IU permalink type(code, personal, both, unsure) mail excerpt Thu Jan 01 2015 - 15:14:21 EST http://lkml.iu.edu/hypermail/linux/kernel/1501.0/00127.html B So I'm not saying "ifconfig is wonderful". It's not. But I *am* saying that "changing user interfaces and then expecting people to change is f*cking stupid".... Because people who think that "we'll just redesign everything" are actually f*cking morons. Really. There's a real reason the kernel has the "no regression" policy. And that reason is that I'm not a moron. Sun Jan 04 2015 - 15:22:52 EST http://lkml.iu.edu/hypermail/linux/kernel/1501.0/00786.html B To quote the standard response for people who ignore regressions: "SHUT THE FUCK UP"...I don't understand how people can't get this simple thing. You have two choices: - acknowledge and fix regressions - get the hell out of kernel development....Christ people. Why does this even have to be discussed any more?...But you guys need to shape up. We don't break things.... Sun Jan 04 2015 - 15:58:52 EST http://lkml.iu.edu/hypermail/linux/kernel/1501.0/00799.html P ...End of discussion. Seriously. Your whinging about "support costs" is just crying over the fact that you have users. Deal with it. ...And dammit, I really never *ever* want to hear arguments against fixing regressions ever again. It really is the #1 rule for the kernel. There is *no* excuse for that NAK. There is only "sorry". Sun Jan 04 2015 - 16:02:22 EST http://lkml.iu.edu/hypermail/linux/kernel/1501.0/00803.html B Really. Shut up.... And if you aren't ok with "wasting time" on trying to give that kind of reassurances to users, then you shouldn't be working on the kernel. I'm serious about this. You really *need* to understand that. Your job as a kernel developer is very much to support the users. Not try to make it easy for *you* at the cost of being nasty for *them*. Wed Jan 07 2015 - 19:57:38 EST http://lkml.iu.edu/hypermail/linux/kernel/1501.0/03751.html P Yes, I actually would mind, unless you have a damn good reason for it....I really don't see why you should lie in your /proc/cpuinfo. ...Just give the real information. Don't lie. Quite frankly, the *only* actual real reason I've heard from you for not having the real bogomips there is "waste of time". And this whole thread has been *nothing* but waste of time. But it has been *you* wasting time, and that original commit. ... So quite frankly, my patience for you arguing "wasting time" is pretty damn low. I think your arguments are crap, I still think your NAK was *way* out of line, and I think it's completely *insane* to lie about bogomips. It's disasteful, it's dishonest, and there's no reason for it. ... Seriously, what kind of *insane* argument can you really marshal for lying to users?... Christ, this whole thing is annoying. I really find it *offensive* how you want to basically lie to users. Stop this idiocy. Really. There is no excuse. Thu Jan 08 2015 - 00:04:40 EST http://lkml.iu.edu/hypermail/linux/kernel/1501.1/00000.html P Fuck no. ... You are just making shit up. Bad shit. Get off the drugs, because it's not the good kind.... Cry me a river. ... Bullshit. This whole thread is now marked as "muted" for me, because I can't take the BS any more. You make no sense. ...You're crazy. Go away. Or don't. I won't be seeing your emails anyway, so why would I care? Sat Jan 10 2015 - 17:07:29 EST http://lkml.iu.edu/hypermail/linux/kernel/1501.1/01747.html C Ugh. This is too ugly, it needs to die. ... Because this is unreadable. Thu Jan 29 2015 - 20:25:15 EST http://lkml.iu.edu/hypermail/linux/kernel/1501.3/05334.html C Why do I say "total crap"? ...it's really wrong. ... The comment is also crap. ... So doing this in "__may_sleep()" is just bogus and horrible horrible crap. It turns the "harmless ugliness" into a real *harmful* bug. ... PeterZ, please don't make "debugging" patches like this. Ever again. Because this was just stupid, and it took me too long to realize that despite the warning being shut up, the debug patch was still actively doing bad bad things. Sun Feb 01 2015 - 16:01:12 EST http://lkml.iu.edu/hypermail/linux/kernel/1502.0/00120.html C Ugh. This patch is too ugly to live. ... I really detest debug code (or compiler warnings) that encourage people to write code that is *worse* than the code that causes the debug code or warning to trigger. It's fundamentally wrong when those "fixes" actually make the code less readable and maintainable in the long run. Sun Feb 01 2015 - 18:09:44 EST http://lkml.iu.edu/hypermail/linux/kernel/1502.0/00135.html C Because code like this is just crap: ... really. It's just crazy. It makes no sense. It's all just avoiding the warning, it's not making the code any better. Fri Feb 06 2015 - 17:11:07 EST http://lkml.iu.edu/hypermail/linux/kernel/1502.0/04512.html C This makes no sense. You're trying to fix what you perceive as a problem in the page fault handling in some totally different place. ... Don't try to make horrible code in insane places that have nothing to do with the fundamental problem. Why did you pick this particular get/put user anyway? There are tons others that we don't test, why did you happen pick these and then make it have that horrible and senseless error handling? Because at *NO* point was it obvious that that patch had anything at all to do with "out of memory". Not in the code, not in your commit messages, *nowhere*. ... Mon Feb 16 2015 - 19:07:31 EST http://lkml.iu.edu/hypermail/linux/kernel/1502.2/00574.html C Ugh. Your diffstat is crap, because you don't show the inexact renames that are very abundant in the nouveau driver. Tue Feb 17 2015 - 14:41:45 EST http://lkml.iu.edu/hypermail/linux/kernel/1502.2/01301.html B No. Really. ... No. The whole concept of "drop the lock in the middle" is *BROKEN*. It's seriously crap. It's not just a bug, it's a really fundamentally wrong thing to do. ... No. That's still wrong. You can have two people holding a write-lock. Seriously. That's *shit* Sat Feb 21 2015 - 15:12:47 EST http://lkml.iu.edu/hypermail/linux/kernel/1502.2/03755.html C No. I pulled, and immediately unpulled again. This is complete shit, and the compiler even tells you so: ... I'm not taking "cleanups" like this. And I certainly don't appreciate being sent completely bogus shit pull requests at the end of the merge cycle. Sat Feb 21 2015 - 17:45:50 EST http://lkml.iu.edu/hypermail/linux/kernel/1502.2/03774.html C ... There is absolutely no sane reason to use this crap, as far as I can tell. The new "fs_inode_once()" thing is just stupid. ... Dammit, if we add wrapper and "helper" functions, they should *help*, not confuse. This thing is just badly named, and there is no actual real explanation for why it exists in the first place, nor for when to use one or the other. There is just an endless series of patches with pointless churn.... Explain it, or that crap gets undone. I'm annoyed, because shit like this that comes in at the end of the merge window when everybody and their dog sends me random crap on the Friday afternoon before the merge window closes is just annoying as hell. ... Today has been a huge waste of time for me, and reading through this was just the last drop. Sat Feb 21 2015 - 20:34:32 EST http://lkml.iu.edu/hypermail/linux/kernel/1502.2/03800.html B And what *possible* situation could make that "_once()" version ever be valid? None. It's bogus. It's crap. It's insane. There is no way that it is *ever* a valid question to even ask. Sat Mar 07 2015 - 13:42:35 EST http://lkml.iu.edu/hypermail/linux/kernel/1503.0/06080.html B (self) So my patch was obviously wrong, and I should feel bad for suggesting it. I'm a moron, and my expectations that "pte_modify()" would just take the accessed bit from the vm_page_prot field was stupid and wrong. Mon Mar 09 2015 - 21:14:34 EST http://lkml.iu.edu/hypermail/linux/kernel/1503.1/01347.html P You make no sense. The commits you list were all on top of plain 4.0-rc2. Thu Mar 26 2015 - 12:15:27 EST http://lkml.iu.edu/hypermail/linux/kernel/1503.3/02670.html C NOOO!... Get rid of the f*cking size checks etc on READ_ONCE() and friends. ... Hell f*cking no. The "something like so" is huge and utter crap, because the barrier is on the wrong side. Wed Apr 01 2015 - 14:15:25 EST http://lkml.iu.edu/hypermail/linux/kernel/1504.0/00504.html C Completely immaterial. Seriously. ... Answer: you don't. ... It's wrong. It's fundamentally invalid crap. ... NO WAY IN HELL do we add generic support for doing shit. Really. If p9 does crazy crap, that is not an excuse to extend the crazy crap to more code. Tue Apr 14 2015 - 20:25:22 EST http://lkml.iu.edu/hypermail/linux/kernel/1504.1/04846.html C Side note, you'll obviously also need to fix the actual bogus 'gp_init_delay' use in kernel/rcu/tree.c. That code is horrible. Fri Apr 17 2015 - 16:18:28 EST http://lkml.iu.edu/hypermail/linux/kernel/1504.2/01393.html C Why not just revert that commit. It looks like garbage. ... The reason I think it's garbage is... code like the above is just crap to begin with.. So I don't think this code is "fixable". It really smells like a fundamental mistake to begin with. Just revert it, chalk it up as "ok, that was a stupid idea", and move on... Tue Apr 28 2015 - 14:38:42 EST http://lkml.iu.edu/hypermail/linux/kernel/1504.3/02818.html B Basically, I absolutely hate the notion of us doing something unsynchronized, when I can see us undoing a mmap that another thread is doing. It's wrong. You also didn't react to all the *other* things that were wrong in that patch-set. The games you play with !fatal_signal_pending() etc are just crazy. End result: I absolutely detest the whole thing. I told you what I consider an acceptable solution instead, that is much simpler and doesn't have any of the problems of your patchset. Fri May 22 2015 - 17:34:42 EST http://lkml.iu.edu/hypermail/linux/kernel/1505.2/06069.html P Ok, I'm used to fixing up your whitespace and lack of capitalization, but you're getting so incoherent that I can no longer even parse it well enough to fix it up. English *is* your first language, right? Sun Jun 07 2015 - 20:17:34 EST http://lkml.iu.edu/hypermail/linux/kernel/1506.0/04868.html B Hell no. Stop with the random BUG_ON() additions. ... Dammit, there's no reason to add a BUG_ON() here in the first place, and the reason of "but but it's an unused error return": is f*cking retarded. Stop this idiocy. We don't write crap code just to satisfy some random coding standard or shut up a compiler error.... NO NO NO. ... Really. I'm getting very tired indeed of people adding BUG_ON's like that. Stop it. Thu Jun 11 2015 - 16:38:00 EST http://lkml.iu.edu/hypermail/linux/kernel/1506.1/03497.html C This is not at all equivalent, and it looks stupid. Tue Jun 16 2015 - 02:41:35 EST http://lkml.iu.edu/hypermail/linux/kernel/1506.2/00044.html B Bullshit, Andrea. That's *exactly* what you said in the commit message for the broken patch that I complained about. ... and I pointed out that your commit message was garbage, and that it's not at all as easy as you claim, and that your patch was broken, and your description was even more broken.... Your commit message was garbage, and actively misleading. Don't make excuses. Wed Jun 24 2015 - 08:14:46 EST http://lkml.iu.edu/hypermail/linux/kernel/1506.3/00255.html B No. I refuse to touch this crap.... You really expect me to take crap like that? Hell no. If your stuff isn't self-sufficient, then it's not something I want to ever pull. If the top of the tree you ask me to pull doesn't work (and quite frankly, every commit leading to it) then it's bad and unusable. ...But it's one thing to have an unintentional bug, and another thing to do it on _purpose_. Wed Jun 24 2015 - 08:41:02 EST http://lkml.iu.edu/hypermail/linux/kernel/1506.3/00300.html B No, it really isn't. You still seem to be in denial: ... NO YOU DID NOT! Stop claiming that. You didn't actually test what you sent me. YOU TESTED SOMETHING ENTIRELY DIFFERENT. Do you really not see the difference? Because that's a honking big difference. ... Wed Jul 08 2015 - 11:53:51 EST http://lkml.iu.edu/hypermail/linux/kernel/1507.1/00798.html C Ugh. I hate that. It looks bad, but it's also pointless. ...Compilers that warn for the good kind of safe range tests should be taken out and shot. ... so I just detest that buggy piece of crap for *so* many reasons. It's also sad that a one-liner commit that claims to "fix" something was this broken to begin with. Grr. Honza, not good. Tue Aug 18 2015 - 19:54:41 EST http://lkml.iu.edu/hypermail/linux/kernel/1508.2/01419.html B What the hell have you done with the commit messages? The first line is completely corrupted for those reverts, and as a result your own shortlog looks like crap and is completely misleading. ... presumably due to some horribly broken automation crap of yours that adds the "[media]" prefix or something. How did you not notice this when you sent the shortlog? Or even earlier? This is some serious sh*t, since it basically means that your log messages are very misleading, since the one-liner actually implies exactly the reverse of what the commit does. I unpulled this, because I think misleading commit messages is a serious problem, and basically *half* (and patch-wise, the bulk) of the commits in this queue are completely broken. Thu Sep 03 2015 - 12:45:52 EST http://lkml.iu.edu/hypermail/linux/kernel/1509.0/01911.html C ... Christ, people. Learn C, instead of just stringing random characters together until it compiles (with warnings). ... There are arguments for them, but they are from weak minds. ... A later patch then added onto the pile of manure by adding *another* broken array argument, ...It's basically just lying about what is going on, and the only thing it documents is "I don't know how to C". ... Please people. ... Thu Sep 10 2015 - 14:01:42 EST http://lkml.iu.edu/hypermail/linux/kernel/1509.1/01958.html C No. You think *WRONG*. ... YOUR CODE IS WRONG, AND REALITY SHOWS THAT YOUR DEFAULT IS CRAP. Really. ... BS. The only reason for your interface was that it was simpler to use. You broke that. And you broke that for no good reason. .... So your "default" is not actually safe. It breaks real cases, and doesn't add any security. It's broken. Fri Sep 11 2015 - 17:19:24 EST http://lkml.iu.edu/hypermail/linux/kernel/1509.1/02764.html B Your arguments all are entirely irrelevant to the fundamental issue. And then when I suggest a *sane* interface that doesn't have this problem, your arguments are crap - again. ... Bullshit. You clearly didn't even read my proposal. ... Anyway, I'm not discussing this. You are clearly unwilling to just admit that your patch-series was broken, ... As such, why bother arguing? Fri Oct 02 2015 - 15:01:13 EST http://lkml.iu.edu/hypermail/linux/kernel/1510.0/01693.html B No. Stop this theoretical idiocy. We've tried it. I objected before people tried it, and it turns out that it was a horrible idea.... So this "people should check for allocation failures" is bullshit. It's a computer science myth. ... So no. ...Get over it. I refuse to go through that circus again. It's stupid. Tue Oct 06 2015 - 04:49:26 EST http://lkml.iu.edu/hypermail/linux/kernel/1510.0/03479.html B Really. Stop this idiocy. We have gone through this before. It's a disaster. Wed Oct 28 2015 - 05:40:26 EST http://lkml.iu.edu/hypermail/linux/kernel/1510.3/02866.html B Christ people. This is just sh*t.... But what makes me upset is that the crap is for completely bogus reasons. ... and anybody who thinks that the above is (a) legible (b) efficient (even with the magical compiler support) (c) particularly safe is just incompetent and out to lunch. The above code is sh*t, and it generates shit code. It looks bad, and there's no reason for it.... Really. Give me *one* reason why it was written in that idiotic way with two different conditionals, and a shiny new nonstandard function that wants particular compiler support to generate even half-way sane code, and even then generates worse code? A shiny function that we have never ever needed anywhere else, and that is just compiler-masturbation. ... So I really see no reason for this kind of complete idiotic crap. ... Because I'm not pulling this kind of completely insane stuff that generates conflicts at rc7 time, and that seems to have absolutely no reason for being anm idiotic unreadable mess. ... And it's a f*cking bad excuse for that braindamage. I'm sorry, but we don't add idiotic new interfaces like this for idiotic new code like that. ...In fact, I want to make it clear to *everybody* that code like this is completely unacceptable. Anybody who thinks that code like this is "safe" and "secure" because it uses fancy overflow detection functions is so far out to lunch that it's not even funny. All this kind of crap does is to make the code a unreadable mess with code that no sane person will ever really understand what it actually does. Get rid of it. And I don't *ever* want to see that shit again. Mon Nov 02 2015 - 13:08:30 EST http://lkml.iu.edu/hypermail/linux/kernel/1511.0/00823.html C This code makes absolutely no sense.... So the code may end up *working*, but the comments in it are misleading, insane, and nonsensical. ...The comment is actively and entirely wrong. ... So the code looks insane to me. ...So in no case can that code make sense, as far as I can tell. Mon Nov 02 2015 - 16:16:25 EST http://lkml.iu.edu/hypermail/linux/kernel/1511.0/00957.html B Stop this idiocy. ... And that disgusting "overflow_usub()" in no way makes the code more readable. EVER. So stop just making things up.... It wasn't more efficient, it wasn't more legible, and it simply had no excuse for it. Stop making excuses for shit. Mon Nov 02 2015 - 16:19:32 EST http://lkml.iu.edu/hypermail/linux/kernel/1511.0/00959.html B Really. That's it. Claiming that that is "complicated" and needs a helper function is not something sane people do. A fifth-grader that isn't good at math can understand that. In contrast, nobody sane understands "usub_overflow(a, b, &res)". So really. Stop making inane arguments. Mon Nov 02 2015 - 18:22:26 EST http://lkml.iu.edu/hypermail/linux/kernel/1511.0/01029.html B Hell no.... In exactly *WHAT* crazy universe does that make sense as an argument? It's like saying "I put literal shit on your plate, because there are potentially nutritious sausages that look superficially a bit like the dogshit I served you". Seriously. ... It's *exactly* the same argument as "dog poop superficially looks like good sausages". Is that really your argument? There is never an excuse for "usub_overflow()". It's that simple. No amount of _other_ overflow functions make that shit palatable. Mon Nov 02 2015 - 19:16:18 EST http://lkml.iu.edu/hypermail/linux/kernel/1511.0/01060.html C No. Your repository is bogus. I don't know what the hell you have done or why you have done it, but you have actually rebased *my* 4-3-rc7 commit that updates the Makefile from rc6 to rc7... and there is no way I will take things like this. Tue Nov 03 2015 - 14:40:33 EST http://lkml.iu.edu/hypermail/linux/kernel/1511.0/01843.html B Your arguments make no sense. ... NO IT DOES NOT. Christ, Paul. ... You have turned it into something else in your mind. But your mind is WRONG. ... I really don't understand your logic. ... That is NOT WHAT I WANT AT ALL. Wed Nov 11 2015 - 16:23:35 EST http://lkml.iu.edu/hypermail/linux/kernel/1511.1/02587.html B That's insane. ... It is simply not sensible to have a "wait_for_unlock()" that then synchronizes loads or stores that happened *before* the wait. That's some crazy voodoo programming. ... Or just take the damn lock, and don't play any games at all. Fri Dec 04 2015 - 17:05:58 EST http://lkml.iu.edu/hypermail/linux/kernel/1512.0/03875.html C Are we trying to win some obfuscated C contest here? Fri Dec 11 2015 - 15:50:41 EST http://lkml.iu.edu/hypermail/linux/kernel/1512.1/03816.html C So this is definitely crap. You can't return an error. ... Same deal. Returning an error is wrong. Mon Dec 21 2015 - 19:03:19 EST http://lkml.iu.edu/hypermail/linux/kernel/1512.2/03700.html C Absolutely not. I will not take this, and it's stupid in the extreme. ...That's just crazy talk. ... So I don't know how many ways I can say "NO", but I'll not take anythign like this. It's *completely* wrong.