# Author: Squire, M. & Gazda, R. # License: Open Database License 1.0 # This data 20132LTinsultsLKML.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: 2013LTinsultsLKML.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 2013 # # fields: # date: this is the date the original email was sent # markmail permalink: this is a permalink to the email on markmail (for easy reading) # type: this is our code for what type of insult 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 markmail permalink type(code, personal, both, unsure) mail excerpt 1/2/2013 10:14:00 http://markmail.org/message/sqsdlnspk4o6wcku B No. I'm not pulling 3000 lines of broken defconfig crap. That defconfig update is pure and utter shit, and changes from the minimal kind of defconfig to the old-style "everything and the kitchen sink" crap. We started doing that defconfig minimization for a reason. See commit 8b1bb90701f9 for example. We're not going back to the bad old days, and I'm not pulling thousands of lines or pure garbage noise just because you were too lazy to do it right. 1/12/2013 12:51:26 http://markmail.org/message/dxuql7eif6jzrfgm B Christ people. I already reported that it DOES NOT EVEN COMPILE. ... Alan apparently doesn't care about the patch he wrote to even bother fixing that, and the only person who does seem to care enough to carry two fixes around (Andrew) apparently doesn't feel that he's comfortable forwarding it to me ... I'm not picking up random patches from people who don't care enough about those patches to even bother fixing compile errors when reportyed and didn't even send them to me to begin with. 1/14/2013 9:29:55 http://markmail.org/message/azgsopo63xulybfj B Bullshit. That expectation is just a fact. ... We do not say "user mode shouldn't". Seriously. EVER. User mode *does*, and we deal with it. Learn it now, and stop ever saying that again. This is really starting to annoy me. Kernel developers who say "user mode should be fixes to not do that" should go somewhere else. 1/15/2013 9:36:34 http://markmail.org/message/a33yo653hshtlorn C No way. ... In fact, just to prove how bad it is, YOU SCREWED IT UP YOURSELF. ... But the "hacky workaround" absolutely needs to be *automatic*. Because the "driver writers need to get this subtle untestable thing right" is *not* acceptable. That's the patch that Ming Lei did, and I refuse to have that kind of fragile crap in the kernel. 2/7/2013 17:09:11 http://markmail.org/message/lgbu2h56mmrlyhov C No. You guys need to realize that I'm not talking crap like this this late. This is not major bugfixes. I already looked away once just because it's a new filesystem, but enough is enough. This is way way WAY too late to start sendign "enhancements". Seriously. 2/8/2013 13:14:20 http://markmail.org/message/dlcehtdw2iylosx4 B No. Your pull requests are just illogical. I have yet to see a single reason why it should be merged. ... That's total bullshit. ... Again, total *bullshit*. ... ... Ingo, it's not us being silly, it is *you*. ... So here, let me state it very very clearly: I will not be merging kvmtool. ... In other words, I don't see *any* advantage to merging kvmtool. I think merging it would be an active mistake, and would just tie two projects together that just shouldn't be tied together. So nobody is "hurting useful code", except perhaps you. Explain to me why I'm wrong. I don't think you can. You certainly haven't so far. 2/8/2013 16:45:27 http://markmail.org/message/zsagmx3labefqnj7 B NONE of your statements made any sense at all, since everything you talk about could have been done with a separate project. The only thing the lock-step does is to generate the kind of dependency that I ABSOLUTELY DETEST, 2/9/2013 10:07:22 http://markmail.org/message/wes3zmjkc7cvhvtp P You do realize that none of your arguments touched the "why should Linus merge the tree" question at all? Everything you said was about how it's more convenient for you and Ingo, not at all about why it should be better for anybody else. ... You're the only one working on it, so being convenient for you is the primary issue. Arguments like that actively make me not want to merge it, ... 2/9/2013 11:57:18 http://markmail.org/message/fajyuralww7ecu46 B Why? You've made this statement over and over and over again, and I've dismissed it over and over and over again because I simply don't think it's true. It's simply a statement with nothing to back it up. Why repeat it? THAT is my main contention. I told you why I think it's actually actively untrue. ... So you make these unsubstantiated claims about how much easier it is, and they make no sense. You never explain *why* it's so magically easier. ... Anyway, I'm done arguing. You can do what you want, but just stop misrepresenting it as being "linux-next" material unless you are willing to actually explain why it should be so. 2/11/2013 15:32:03 http://markmail.org/message/v7zrdos3ivvwyy3j B Ingo, stop this idiotic nonsense. You seem to think that "kvmtool is useful for kernel" is somehow relevant. IT IS TOTALLY IRRELEVANT. 2/11/2013 19:32:39 http://markmail.org/message/v4qqvcyonunfr4f7 C Christ. This is so ugly that it's almost a work of art. 2/13/2013 8:20:19 http://markmail.org/message/4n3bz5v7zcilvwec C Did anybody actually look at the code generation of this? Adding an external function call is *horrible*, ... Guys, the biggest cost of a function call is not the "call" instruction, it's all the crap around it ... And the excuse is "so that we can add stuff to the wait loop". What the f*ck? ... and which is something we have actively *avoided* in the past, because back-off is a f*cking idiotic thing, and the only real fix for contended spinlocks is to try to avoid the contention and fix the caller to do something smarter to begin with. In other words, the whole f*cking thing looks incredibly broken. At least give some good explanations for why crap like this is needed ... 2/13/2013 14:39:50 http://markmail.org/message/u7s4aiysqw22yoks B So you're potentially making things worse for just about everybody, in order to fix a problem that almost nobody can actually see. And apparently you don't even know the problem.. and as I already explained, THAT IS PURE AND UTTER BULLSHIT. It may make things WORSE. On all the things you haven't run to check that it does better. You just stated something that is not at all necessarily true. .... That's pure bullshit. ... And yet you go on to say that it will fix performance problems THAT WE DON'T EVEN KNOW ABOUT! After seeing *proof* to the exact contrary behavior! What f*cking planet are you from, again? Christ, that's hubris. ... 2/15/2013 17:44:10 http://markmail.org/message/yfj2wsfb53wooham C Christ, we should just try to get rid of the personality bits entirely, they are completely insane 2/21/2013 8:39:15 http://markmail.org/message/ri3kexilpdikwffk C Quite frankly, this is f*cking moronic. 2/21/2013 8:58:08 http://markmail.org/message/5vnikbcmtiy37trs B Guys, this is not a dick-sucking contest. ... If Red Hat wants to deep-throat Microsoft, that's *your* issue. 2/21/2013 10:02:57 http://markmail.org/message/ayphowwkqhokglgq C Quite frankly, I doubt that anybody will ever care, ... Plus quite frankly, signing random kernel vendor modules (indirectly) with a MS key is f*cking stupid to begin with. In other words, I really don't see why we should bend over backwards, when there really is no reason to. It's adding stupid code to the kernel only to encourage stupidities in other people. ... And the whole "no, we only think it makes sense to trust MS keys" argument is so f*cking stupid that if somebody really brings that up, I can only throw my hands up and say "whatever". In other words, none of this makes me think that we should do stupid things just to perpetuate the stupidity. 2/21/2013 10:21:06 http://markmail.org/message/noa6avyls3prnljg C Ugh. The placement of that #ifndef is just horrible, please don't do that. 2/21/2013 10:25:06 http://markmail.org/message/fg2kiaccjm3umykj B Your arguments only make sense if you accept those insane assumptions to begin with. And I don't. 2/22/2013 13:07:37 http://markmail.org/message/ymksyompaadrlpeo C The softirq semantics are perfectly fine. Don't blame softirq for the fact that irq_exit() has had shit-for-brains for a long time. ... Don't blame the wrong code here. 2/22/2013 16:29:46 http://markmail.org/message/crdmpdgia7w2kc3v B Rafael, please don't *ever* write that crap again. ... Seriously. Why do I even have to mention this? Why do I have to explain this to somebody pretty much *every* f*cking merge window? This is not a new rule. ... So you should be well acquainted with the rule, and I'm surprised to hear that kind of utter garbage from you in particular. ... 2/25/2013 19:31:26 http://markmail.org/message/nkatkgctxzv6efs2 B And you're happy shilling for a broken model? ... Your arguments constantly seem to miss that rather big point. You think this is about bending over when MS whispers sweet nothings in your ear.. ... You, on the other hand, seem to have drunk the cool-aid on the whole "let's control the user" crap. Did you forget what security was all about? 2/25/2013 19:44:46 http://markmail.org/message/jv7pjzgaugm4bbud B How f*cking hard is it for you to understand? Stop arguing about what MS wants. We do not care. We care bout the *user*. You are continually missing the whole point of security, and then you make some idiotic arguments about what MS wants you to do. It's irrelevant. The only thing that matters is what our *users* want us to do, and protecting *their* rights. As long as you seem to treat this as some kind of "let's please MS, not our users" issue, all your arguments are going to be crap. 2/25/2013 20:30:31 http://markmail.org/message/agrpwdrqk3htku5x B ... Stop the fear mongering already. So here's what I would suggest, and it is based on REAL SECURITY and on PUTTING THE USER FIRST instead of your continual "let's please microsoft by doing idiotic crap" approach. ... Quite frankly, *you* are what he key-hating crazies were afraid of. You peddle the "control, not security" crap-ware. The whole "MS owns your machine" is *exactly* the wrong way to use keys. 2/25/2013 20:43:19 http://markmail.org/message/pebyvitew3mmel2h P This is the kind of totally bogus crap that no sane person should ever spout. Stop it. 2/27/2013 8:56:45 http://markmail.org/message/5kd5gx6lowz34hwg C I would love to blame gcc, but no, I think the code is crap. ... And gcc would be completely correct. That test is moronic. 2/28/2013 20:18:04 http://markmail.org/message/qmxezyrnc4rgeiwt B Has Chris Ball been told what an incredible pain this kind of crap is, and that there's a damn good reason why WE DO NOT REBASE PUBLIC TREES THAT OTHERS MAY BE BASING THEIR DEVELOPMENT ON! Chris, can you hear me shouting? Don't do that. 3/1/2013 10:03:09 http://markmail.org/message/7vojjlvgvx3pg6ih C Yeah, that would be a no. I finally got to look at the new architectures and be ready to pull them, and you just made sure I won't pull this. This is exactly the kind of crap I don't want to see in *any* pull requests, ... Why the f*ck are you doing back-merges? There is no excuse for even a single one. And here you have just about one back-merge per commit. No, no no. 3/7/2013 7:55:02 http://markmail.org/message/z3sqbcs5zvttxvs5 C No, guys. That cannot work. It's a completely moronic idea. 3/7/2013 13:50:59 http://markmail.org/message/luivhcj5s3tmnhg3 P Yeah, I'm a f*cking moron. 3/26/2013 9:07:45 http://markmail.org/message/wnh5hpofc6u5ux3k B Bullshit. This is a regression, and it needs to be fixed. The "device needs power" crap is just that - crap. Nobody cares. ... Claiming that we need to know the power regulator for an accelerometer is total utter idiocy and crap. ... The notion that you have to have regulator information in order to use some random device is insanity. I don't understand how you can even start to make excuses like that. It's so obviously bogus that it's not even funny. Why do I have to explain the "no regressions" to long-time kernel maintainers EVERY SINGLE RELEASE? What the f*ck is *wrong* with you people? Seriously? 3/29/2013 11:08:00 http://markmail.org/message/dnkiqq7dw4wc5ylj C No it's not. ... which is entirely and utterly pointless. Christ, the amount of confusion in that tree. ... Don't do this kind of thing. That branch is pointless, and just confused you. 3/29/2013 12:56:47 http://markmail.org/message/fqeuavztempqtt4e C Because you screwed up that pull request, and I argue that you screwed up exactly *because* it's ambiguous and confusing. 4/6/2013 9:13:15 http://markmail.org/message/zydmz4wtbkm5raty C This is all *COMPLETELY* wrong. ... Fix ARC, don't try to blame generic code. You should have asked yourself why only ARC saw this bug, when the code apparently works fine for everybody else! 4/7/2013 21:47:42 http://markmail.org/message/tymjfm4sler2maof C That's absolutely insane. It's insane for two reasons: - it's not SUFFICIENT. ... - it's POINTLESS and WRONG. ... 4/9/2013 7:32:02 http://markmail.org/message/tquutcp3how7so4i P I'm a moron. 4/24/2013 14:30:14 http://markmail.org/message/ww3kki6aafcc3int B Bullshit. That's exactly the wrong kind of thinking. ... This whole discussion has been f*cking moronic. The "security" arguments have been utter shite with clearly no thinking behind it, the feature is total crap ... and I'm seriously considering just getting rid of this idiotic dmesg_restrict thing entirely. Your comment is the very epitome of bad security thinking. 4/30/2013 7:49:13 http://markmail.org/message/z4tgggqhp4bzaobu C Why does this have the crappy cputime scaling overflow code, ... WTF happened here? I and others spent efforts so that we wouldn't need this kind of crap. 5/1/2013 10:10:51 http://markmail.org/message/x7dppnevszkf32t7 C Ugh. Sorry, but this patch just looks stupid. 5/3/2013 9:55:45 http://markmail.org/message/czm34752nkrdcsyl P F*ck yes it does. It means that NOBODY EVEN TEST-COMPILED THE TREE THAT GOT SENT TO ME. WTF? If that's not "irresponsible and lame", I don't know what the hell is. 5/3/2013 14:48:23 http://markmail.org/message/bfb52yzgga25ekbl B And you are making that excuse exactly *why*? ... Stop making excuses for bad behavior. Just admit that you guys screwed up rather than trying to soldier on. ... That's a f*cking disgrace. ... Stop making excuses for it. Really. It just makes you look even worse. ... 5/11/2013 15:22:14 http://markmail.org/message/k3wjhpzykhjs6d46 C This has so much wrong that I don't know where to start. 6/9/2013 14:33:13 http://markmail.org/message/gubc7op3sndc26kx C Not pulled, because your hamster smells of eldeberries. This is not just bugfixes. In fact, as far as I can tell, this *introduces* bugs, ... I'm f*cking tired of people having problems understanding "we're past rc5". If it's not something you would call stable material, you shouldn't send it to me. 6/10/2013 13:03:47 http://markmail.org/message/ahfmn75iictvv7hs C That patch is really ugly. And it doesn't make much sense. ... So the patch seems to make things just worse. 7/7/2013 14:31:51 http://markmail.org/message/n2llxam2eakjj5dx P What the F*CK is wrong with people? 7/9/2013 19:50:18 http://markmail.org/message/2sa6oh7tlbn6wpst C David, what the heck are you doing? ... Seriously. Those commits now have TOTALLY MISLEADING summary messages. ... 7/10/2013 19:11:30 http://markmail.org/message/34bxbzbympklsjik C THIS IS SOME HORRIBLY BROKEN CRAP. ... Dammit, this has happened before, and it was broken then, and it is broken now. If they do, they are *F*CKING*BROKEN*. ... You need to start being more careful. ... There is no excuse for this. That commit is shit. ... And that totally crap commit is even marked for stable. I hate hate hate when this kind of crap happens. 7/11/2013 12:33:10 http://markmail.org/message/pnxj6xr332gu4oog C Grr. I hate it when people do this. Your merge message sucks. 7/12/2013 8:22:04 http://markmail.org/message/mmvlphelw5gea4lw B That's f*cking sad. You know *why* it's sad? ... Now, that should make you think about THE ABSOLUTE CRAP YOU MARK FOR -stable! ... Listen to yourself. In fact, there is a damn good solution": don't mark crap for stable, and don't send crap to me after -rc4. ... Greg, the reason you get a lot of stable patches seems to be that you make it easy to act as a door-mat. ... You may need to learn to shout at people. 7/13/2013 15:40:01 http://markmail.org/message/6h3gtqeizljyjqio C What the F*CK, guys? This piece-of-shit commit is marked for stable, but you clearly never even test-compiled it, did you? ...The declaration for gate_desc is very very different for 32-bit and 64-bit x86 for whatever braindamaged reasons. Seriously, WTF? I made the mistake of doing multiple merges back-to-back with the intention of not doing a full allmodconfig build in between them, and now I have to undo them all because this pull request was full of unbelievable shit. And why the hell was this marked for stable even *IF* it hadn't been complete and utter tripe? It even has a comment in the commit message about how this probably doesn't matter. So it's doubly crap: it's *wrong*, and it didn't actually fix anything to begin with. There aren't enough swear-words in the English language, so now I'll have to call you perkeleen vittupää just to express my disgust and frustration with this crap. 7/14/2013 11:33:52 http://markmail.org/message/h36hza3w6tc6wc3p C Ok. So your commit message and explanation was pure and utter tripe, 7/26/2013 17:29:19 http://markmail.org/message/sid3n3nvz5cewzdq C Ugh. I dislike this RCU'ism. It's bad code. It doesn't just look ugly and complex, it's also not even clever. It is possible that the compiler can fix up this horrible stuff and turn it into the nice clever stuff, but I dunno. 8/22/2013 9:53:14 http://markmail.org/message/w5jkhwsqqr765nut C Please don't do these ugly and pointless preprocessor macro expanders that hide what the actual operation is. And this is really ugly. Again it's also then hidden behind the ugly macro. ... 9/5/2013 13:41:49 http://markmail.org/message/jthwd7tcgkdjujxz B Yes it damn well is. Stop the f*cking stupid arguments, and instead listen to what I say. Here. Let me bold-face the most important part for you, so that you don't miss it in all the other crap: ... Nothing else. Seriously. Your "you can't do it because we copy backwards" arguments are pure and utter garbage, ... You're complicating the whole thing for no good reason. ... 9/23/2013 13:08:13 http://markmail.org/message/3e7kuotauypbggjd C We should definitely drop it. The feature is an abomination. I thought gcc only allowed them at the end of structs, in the middle of a struct it's just f*cking insane beyond belief. 10/5/2013 16:17:32 http://markmail.org/message/gfq4zrm3sjv3dfg7 B What drugs are you on? Your example is moronic, and against all _documented_ uses of chroot. 10/10/2013 18:42:27 http://markmail.org/message/eoldtrf5kv43ryk7 C I can't even begin to say whether this is a good solution or not, because that if-conditional makes me want to go out and kill some homeless people to let my aggressions out. Can we please agree to *never* write code like this? Ever? 10/10/2013 11:48:49 http://markmail.org/message/6ed7vcd3drtzru2e C The whole "it's more convenient to use sleeping locks" argument is PURE AND UTTER SHIT when it comes to really core code. ... Seriously. Your argument is bad, but more importantly, it is *dangerously* bad. It's crap that results in bad code: and the bad code is almost impossible to fix up later... 10/15/2013 10:47:44 http://markmail.org/message/zh5hmrt35h7aw7qp C So get your act together, and push back on the people you are supposed to manage. Because this is *not* acceptable for post-rc5, and I'm giving this single warning. Next time, I'll just ignore the sh*t you send me. Comprende? 10/25/2013 7:33:05 http://markmail.org/message/epfiszw6jrzdhycs C Not acceptable. ... Plase stop sending me untested crap that doesn't even compile cleanly! 10/27/2013 12:22:40 http://markmail.org/message/gxmmhefjyijrucsd B Stop this idiotic "blame gcc bug" crap. Which part of my explanation for why it was *NOT* a compiler bug did you not understand? ... Stop the f*cking around already! The whole "we expect ww_ctx to be null" thing shows that YOU DO NOT SEEM TO UNDERSTAND WHAT THE TEST ACTUALLY IS! ... Christ, can you really not understand that? NO NO NO NO. No a f*cking thousand times. It's not "too broken in gcc". It's too broken in the source code, and the fact that you don't even understand that is sad. You wrote the code, and you seem to be unable to admit that *your* code was buggy. It's not a compiler bug. It's your bug. Stand up like a man, instead of trying to flail around and blame anything else but yourself. So guys, get your act together, and stop blaming the compiler already. 11/1/2013 11:04:03 http://markmail.org/message/4ebgm5lnsavu7vya C This looks totally invalid....Your patch is horribly wrong. 11/15/2013 11:55:30 http://markmail.org/message/65bftkuk3cumvw26 P You need to also explain *why* people should apply it, and stop the f*cking idiotic arguing every time somebody comments about your patches.Stop this idiotic "blame gcc bug" crap. Which part of my explanation for why it was *NOT* a compiler bug did you not understand? ... Stop the f*cking around already! The whole "we expect ww_ctx to be null" thing shows that YOU DO NOT SEEM TO UNDERSTAND WHAT THE TEST ACTUALLY IS! ... Christ, can you really not understand that? NO NO NO NO. No a f*cking thousand times. It's not "too broken in gcc". It's too broken in the source code, and the fact that you don't even understand that is sad. You wrote the code, and you seem to be unable to admit that *your* code was buggy. It's not a compiler bug. It's your bug. Stand up like a man, instead of trying to flail around and blame anything else but yourself. So guys, get your act together, and stop blaming the compiler already. 11/15/2013 12:15:17 http://markmail.org/message/sjy3fjyyyyfn3b55 P My point is that I have sixteen pointless messages in my mbox, half of which are due to just your argumentative nature. 11/19/2013 10:47:13 http://markmail.org/message/grt4baiscs4yr6d6 C This seems to be just pure stupid. ...Even the help message is pure and utter garbage ... Asking the user questions that make no f*cking sense to ask is stupid. And I'm not knowingly pulling stupid crap. 11/21/2013 16:16:49 http://markmail.org/message/xcbchfqfnnew7g7r B Why? You're wrong. I mean, anybody who disagrees with me is pretty much wrong just on pure principles, but I actually mean a deeper kind of wrong than that. I mean a very objective "you're clearly wrong". ... .. and then you use a totally bogus example to try to "prove" your point. ... Your example is pure and utter shit, since you still get confused about what is actually const and what isn't. ... But that argument is BULLSHIT, because the fact is, the function *doesn't* do what you try to claim it does. 12/3/2013 10:59:53 http://markmail.org/message/x75diahvbizh73rl C I think that code is bad, and you should feel bad. 12/9/2013 19:58:11 http://markmail.org/message/s27yeuhbzjclo5kk C Grr. I've pulled it, but looking at that history, it's just pure and utter f*cking garbage. 12/10/2013 12:43:04 http://markmail.org/message/zyo2xf6zmgckhmki B No it's not. Thomas, stop this crap already. Look at the f*cking code carefully instead of just dismissing cases. ... So, Christ, Thomas, you have now *twice* dismissed a real concern with totally bogus "that can never happen" by explaining some totally unrelated *simple* case rather than the much more complex case. So please. Really. Truly look at the code and thing about it, or shut the f*ck up. No more of this shit where you glance at the code, find some simple case, and say "that can't happen", and dismiss the bug-report. 12/19/2013 12:01:53 http://markmail.org/message/hsdp434ozq5z26cc C Ok, I'm sorry, but that's just pure bullshit then. ... This code is pure and utter garbage. It's beyond the pale how crazy it is. 12/23/2013 10:42:40 http://markmail.org/message/j2lpjzyu34b7c7bc C No. I think it makes sense to put a big warning on any users you find, and fart in the general direction of any developer who did that broken pattern. Because code like that is obviously crap.