7 ms·

Being a little more friendly could help their cause.

by uuilly 13y ago

jamesaguilar 13y ago
Careful, keep talking like this and you're liable to be informed that cursing someone out is efficient communication by the HN crowd. 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.
- anonymous 13y ago
  Well, it is efficient if you want to minimise the number of people who aren't star programmers with hard heads and don't care how many star programmers with manners you turn away. If your supply pool is big enough, you will have great success. 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.
  - takluyver 13y ago
    > 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" 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.
    - SEMW 13y ago
      See https://lwn.net/Articles/559061/ https://lwn.net/Articles/559061/ for a recent discussion about the tone of LKML.
- zanny 13y ago
  Come on, Linus curses out one guy a year and it always hits HN front page. It isn't like your kernel commits are going to get you an angry veto with 90% explitive vocabulary density on a daily basis, it is the exception that people like to point out.
- bitwize 13y ago
  When Linux curses someone out, it is usually someone who's been in the community for a while and should have known better than to push the crappy code they pushed. 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.
  - jlgreco 13y ago
    Exactly right; this notion that people here have of kernel devs spewing vitriol with reckless abandon at anybody not in their club is pure fantasy. 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. ;)
munin 13y ago
seriously, why subject yourself to that kind of acidic ridicule when you can make more public contributions working on things closer to the frontend. doing the systems engineering work to make the kernel go is very important, but unless you're at the very very top (linus) nobody is going to care about you.
- uuilly 13y ago
  That depends a lot on your industry. At most places I've worked, nobody knew what node.js or bootstrap was. At all those places being a journeyman kernel dev would look REALLY good.
- jlgreco 13y ago
  "Padding your resume" is not a priority shared by everybody. Many people contribute to projects that are not visible because they see an inadequacy and they believe they have a solution. Or you know, for fun. Fun is pretty independent of visibility, if it wasn't then single-player video-games wouldn't exist.
rubiquity 13y ago
Since when is Linus the only middle aged person working on Linux? Your comment reeks of ignorance and cargo culting.
- pyre 13y ago
  Are you suggesting that Linus is the only person in FOSS that cusses people out?
  - chatman 13y ago
    Linus is against free software [0]. Linus publicly abuses fellow developers for making mistakes [1] 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
    - pyre 13y ago
      I'm aware of Linus' thoughts on Free Software. Regardless of those thoughts the Linux kernel is a Free Software project, and by extension Linus is a "person in FOSS."
  - rubiquity 13y ago
    No I'm saying the exact opposite.
Demiurge 13y ago
Rewriting linux from scratch in a cool language like Go would also help a lot.
- deleted 13y ago
  [deleted]
  - deleted 13y ago
    [deleted]
- pyre 13y ago
  Yes. The Linux kernel should be entirely rewritten every 5-10 years so that it can be in the latest "trendy" programming languages.
- vikas0380 13y ago
  Or in java or any other language
  - Demiurge 13y ago
    As long as it's cool and has goroutines and interfaces and no semicolons.
- greenyoda 13y ago
  Go doesn't even support all of the architectures on which Linux runs, for example, IBM mainframes. Not to mention that a language that relies on its own automatic memory management (garbage collection) might not work so well for kernel programming.
  - Demiurge 13y ago
    I thought it was obvious that it was a joke motivated by the recent headlines on HN...
- bifrost 13y ago
  I think it should be rewritten in assembler, because its so old its retro and now will become the new hotness.
anigbrowl 13y ago
Or user-friendly for that matter. I think it's pointless to keep using utilities with titles like man, cp, ls, fsck, grep etc., which are are extremely unintuitive to most people. We're not using 300 bps dumb terminals any more, but the Unix command line remains about as friendly as a leopard. I hated this ~20 years ago when I first learned Linux, but it was the price I had to pay to set up my own domain and hey, a free Unix clone. But two decades later, it's still pretty unfriendly, and a there's still a lot of command-line snobbery that seems dedicated to preserving this unintentional but obsolete obscurantism, like thoroughbred horse breeders who refuse to acknowledge the market's preference for cars and bicycles.
- zanny 13y ago
  I agree with this. A lot of the limitations of 1980s unix no longer exist, yet we still constrain our terminals to obtuse nomenclature and bad syntax like we only have 80 characters before the terminal auto-returns.
- kragniz 13y ago
  I believe we're talking about kernel development here, not GNU utilities. However, what naming scheme would you prefer? The command line is fairly unintuitive as it is. I would argue it is preferable to have short, memorable and fast to type names.
  - nsmartt 13y ago
    To be fair, it's entirely possible to create aliases with more intuitive names and dump a "you can type ____ for short" message on each run.
    - jlgreco 13y ago
      Which leads me to suspect that if there were a demand for "a big file to source in your bashrc to alias 'cp' to 'copy'", it would exist. It is not exactly a difficult thing to do, but nobody actually cares enough to do it (probably because it is not actually a problem).

Being a little more friendly could help their cause.

by uuilly 13y ago

Being a little more friendly could help their cause.

Careful, keep talking like this and you're liable to be informed that cursing someone out is efficient communication by the HN crowd. 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.

anonymous 13y ago
Well, it is efficient if you want to minimise the number of people who aren't star programmers with hard heads and don't care how many star programmers with manners you turn away. If your supply pool is big enough, you will have great success. 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.
- takluyver 13y ago
  > 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" 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.
  - SEMW 13y ago
    See https://lwn.net/Articles/559061/ https://lwn.net/Articles/559061/ for a recent discussion about the tone of LKML.
zanny 13y ago
Come on, Linus curses out one guy a year and it always hits HN front page. It isn't like your kernel commits are going to get you an angry veto with 90% explitive vocabulary density on a daily basis, it is the exception that people like to point out.
bitwize 13y ago
When Linux curses someone out, it is usually someone who's been in the community for a while and should have known better than to push the crappy code they pushed. 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.
- jlgreco 13y ago
  Exactly right; this notion that people here have of kernel devs spewing vitriol with reckless abandon at anybody not in their club is pure fantasy. 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. ;)

munin 13y ago

seriously, why subject yourself to that kind of acidic ridicule when you can make more public contributions working on things closer to the frontend. doing the systems engineering work to make the kernel go is very important, but unless you're at the very very top (linus) nobody is going to care about you.

uuilly 13y ago
That depends a lot on your industry. At most places I've worked, nobody knew what node.js or bootstrap was. At all those places being a journeyman kernel dev would look REALLY good.
jlgreco 13y ago
"Padding your resume" is not a priority shared by everybody. Many people contribute to projects that are not visible because they see an inadequacy and they believe they have a solution. Or you know, for fun. Fun is pretty independent of visibility, if it wasn't then single-player video-games wouldn't exist.

rubiquity 13y ago

Since when is Linus the only middle aged person working on Linux? Your comment reeks of ignorance and cargo culting.

pyre 13y ago
Are you suggesting that Linus is the only person in FOSS that cusses people out?
- chatman 13y ago
  Linus is against free software [0]. Linus publicly abuses fellow developers for making mistakes [1] 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
  - pyre 13y ago
    I'm aware of Linus' thoughts on Free Software. Regardless of those thoughts the Linux kernel is a Free Software project, and by extension Linus is a "person in FOSS."
- rubiquity 13y ago
  No I'm saying the exact opposite.

Demiurge 13y ago

Rewriting linux from scratch in a cool language like Go would also help a lot.

deleted 13y ago
[deleted]
- deleted 13y ago
  [deleted]
pyre 13y ago
Yes. The Linux kernel should be entirely rewritten every 5-10 years so that it can be in the latest "trendy" programming languages.
vikas0380 13y ago
Or in java or any other language
- Demiurge 13y ago
  As long as it's cool and has goroutines and interfaces and no semicolons.
greenyoda 13y ago
Go doesn't even support all of the architectures on which Linux runs, for example, IBM mainframes. Not to mention that a language that relies on its own automatic memory management (garbage collection) might not work so well for kernel programming.
- Demiurge 13y ago
  I thought it was obvious that it was a joke motivated by the recent headlines on HN...
bifrost 13y ago
I think it should be rewritten in assembler, because its so old its retro and now will become the new hotness.

anigbrowl 13y ago

Or user-friendly for that matter. I think it's pointless to keep using utilities with titles like man, cp, ls, fsck, grep etc., which are are extremely unintuitive to most people. We're not using 300 bps dumb terminals any more, but the Unix command line remains about as friendly as a leopard. I hated this ~20 years ago when I first learned Linux, but it was the price I had to pay to set up my own domain and hey, a free Unix clone. But two decades later, it's still pretty unfriendly, and a there's still a lot of command-line snobbery that seems dedicated to preserving this unintentional but obsolete obscurantism, like thoroughbred horse breeders who refuse to acknowledge the market's preference for cars and bicycles.

zanny 13y ago
I agree with this. A lot of the limitations of 1980s unix no longer exist, yet we still constrain our terminals to obtuse nomenclature and bad syntax like we only have 80 characters before the terminal auto-returns.
kragniz 13y ago
I believe we're talking about kernel development here, not GNU utilities. However, what naming scheme would you prefer? The command line is fairly unintuitive as it is. I would argue it is preferable to have short, memorable and fast to type names.
- nsmartt 13y ago
  To be fair, it's entirely possible to create aliases with more intuitive names and dump a "you can type ____ for short" message on each run.
  - jlgreco 13y ago
    Which leads me to suspect that if there were a demand for "a big file to source in your bashrc to alias 'cp' to 'copy'", it would exist. It is not exactly a difficult thing to do, but nobody actually cares enough to do it (probably because it is not actually a problem).