Being a little more friendly could help their cause.
It's hard, but I think what needs to happen here is a culture of mentoring like in most successful software companies. If there is such a thing for aspiring Linux devs, I've never heard of it.
If you're a kernel n00b, chances are you will not be submitting your patches to Linus himself but someone two or three levels down from him, the maintainer of some driver or FS or virtual memory subsystem, who will tell you in nicer terms what you did wrong and how to fix it.
By the time you get to the submitting to Linus stage, it is assumed that you will have your shit in one sock, code-wise; violating that assumption is what earns you the Finnish-obscenity-laden opprobrium.
Why does it persist? Because normal conversations from kernel dev mailing lists are boring while the occasional directed vitriol is very amusing and spawns lots of heated discussions on Slashdot and HN. That, and because calling people out for "things", whether those "things" are cursing, or any other number of things on other days, makes people feel good and superior. See? I'm doing it right now. ;)
Hypothetically though - would it be that much better if Linus et al. were turning away people politely with words like "this code doesn't meet our standards of quality because X Y Z" instead of "your code is shit, see X Y Z"? Also, for people at the lead, you need those who can say "no", know when to say "no", aren't going to compromise just because the patch was sent by so-and-so and won't hold back from saying where they see a problem. You also want them to be good at communicating with people in a civil manner. The two are unfortunately orthogonal qualities. It seems to me that we should first take the people who are definitely good enough in the engineering aspect to understand and lead the project, then select the best communicator, rather than seeking someone with a best average score at engineering and communicating. You might get impolite people at the top, but you will guarantee the project won't get worse.
It seems quite reasonable to imagine that more of those people would come back and try again if they were treated politely. Working with new contributors takes time at first, but it's an investment that you hope will pay back when they're productive core developers.
Great examples of Unix command line idioms that are needlessly baroque: find, ifconfig, route, netstat, lsof.
To use the unix command line you have to get your head around a bunch of key concepts, say, globbing, i/o redirection, pipes, etc. After that, whether it's 'grep' or 'brian' isn't going to get in your way much.
This sort of jargon is pretty typical, though, and I think it's a fairly small barrier. Want to learn some LISPy language? Here come the entirely meaningless car, cdr, cons, s-expression. Functional processing of sequences? Well you can map, you can reduce, you can zip, you can fold. Building your first RoR app? Don't forget to railtie your merb to the phusion gem of the sinatra rack, but not before you've raked your capistrano with a cucumber. You can probably safely rename every JS framework to an MMM (Marklar, Marklar, Marklar) framework given the liberties they take with the meaning of the things M, V and C stand for.
You can give, say, 'cat' or 'tee' magically and perfectly clear names but than in itself won't make anyone understand things like 'unix utilities have one input and two output streams' any better.
I agree with man. It makes sense technically because of "manual"...except that "man" is its own word. Every time I type man, I feel like I'm typing the gender, and it's weird.
cp bothers me because they shortened a four-letter word, the same with ls and list. Despite the original terminal constraints, they couldn't spare two characters?
Really, I think that with an OS designed in the late 1960s, brutally reducing commonly-used commands to the shortest recognizable form was a very good idea.
Storage capacity (both RAM and persistent), processor speeds, and bandwidth for internal and network transfers were all many orders of magnitude less than today's systems. Extra bytes had a real cost.
http://alt.folklore.computers.narkive.com/7q9reknM/1950s-at-...
Author of that post is Tom Van Vleck, who ought to know.
These names are short, but not memorable or easily discoverable.
Not to mention that a language that relies on its own automatic memory management (garbage collection) might not work so well for kernel programming.
Linus representing "FOSS" just doesn't sound right. Look at RMS for a real leader.
[0] - www.youtube.com/watch?v=bw58LZTuZjA [1] - news.ycombinator.com/item?id=5107386