Slashdot Mirror
Torvalds: "People Who Start Writing Kernel Code Get Hired Really Quickly"
alphadogg writes Now more than ever, the development of the Linux kernel is a matter for the professionals, as unpaid volunteer contributions to the project reached their lowest recorded levels in the latest "Who Writes Linux" report, which was released today. According to the report, which is compiled by the Linux Foundation, just 11.8% of kernel development last year was done by unpaid volunteers – a 19% downturn from the 2012 figure of 14.6%. The foundation says that the downward trend in volunteer contributions has been present for years. According to Linus Torvalds, the shift towards paid developers hasn’t changed much about kernel development on its own. “I think one reason it hasn't changed things all that much is that it's not so much unpaid volunteers are going away as people who start writing kernel code get hired really quickly,” he said.
You can handle a little verbal abuse?! Welcome aboard!
Most linux users don't know this, but the man pages were named after Chuck Norris. Chuck Norris fsck'ing hates noobs!
I would like to contribute to the kernel, but seriously I don't have the time and I don't think I'm alone. And the kernel is also a big project. Almost every time I run into a bug or something that I could fix, some engineer at Intel or something has already fixed it and it's not merged yet. It's not that people that write kernel code gets hired, it's that now you more or less have to be hired in order to write kernel code. Yeah I know you don't have to, but it's not 1998 anymore and anyone can write kernel code just for the fun of it.
Although, in fairness, adding loads of printk(KERN_WARNING "Hire Dave! He's really qualified!\n"); was a pretty great feature.
Many years ago I worked on several parts of the kernel. But I got hired by a start-up and simply had no time, so I had to step away.
But I still fondly remember meeting all of the people involved. When I was doing things, I don't recall Linus being verbally abusive. Maybe it happened and I don't remember.
People who are qualified to modify or create code for the Linux kernel are going to be pretty damn good coders. If they weren't, well they wouldn't be contributing for long. So basically this is saying unpaid, good coders find jobs quickly because companies are completely fucking stupid.
If you have the skills to work on the linux kernel legitimately, you don't really need to pad your CV. You'll very rapidly have more work than you want.
As Linus makes clear, there is no decrease in non-paid contributions. They are a smaller percentage becasue more professionals are now being paid to develop Linux. That is a good sign becasue it means more businesses see Linux development as something worth investing in. And it's probably the same people doing the programming. Previously they would have to do it for free but now they get paid. Nothing wrong with that.
"He took a duck in the face at 250 knots." -- William Gibson, Pattern Recognition
I frequently work with people who are terrified to touch anything related to kernel. Many are "professional" Linux-developers, but to them, all they know is user-space code.
I am the go-to guy with anything kernel related at my work, as I'm not only not afraid of the kernel, but I embrace the opportunity to dig deeper. I've learned that this is a rare and valuable skill in some technology circles. People seem to regard me as some kind of wizard (because I maintain tool chains and do all the integration stuff and similar). I did not exactly actively seek this position. The only real difference is that I've never been afraid to learn. Now I'm quickly becoming the in-house expert and I don't care. I can leverage that to death when looking for other jobs.
Community developers write useful things then get hired by the WMF to work on stuff nobody wants.
So wait, I guess not like MediaWiki.
Your hair look like poop, Bob! - Wanker.
Device driver writing is some "trivial resume-padding you can pick up in a weekend", tbh.
Rewriting a kernel subsystem, on the other hand...
Despite 2015 not being the year of Linux on the Desktop, it IS the year of Linux in just about every embedded device, board and SOC on the market. This means that there are more developers being paid to work on Linux, presumably including the Linux kernel.
The summary is full of percentages. 11.8% seems to be about 19% less than 14.6% but that just serves to obfuscate. I'm not willing to dig into the "fill-in-the-form-to-read" article, but would assume that the total number of paid developers has increased accounting for the change in percentages.
Well, I guess that opens a philosophical discussion of whether writing device drivers counts as "kernel coding" at all.
writing device drivers is debatable; the kernel side of it is frequently just cut and paste from elsewhere and most of the "real work" is on the device side. A strong argument can be made that maintaining them in the longer term is true kernel coding as there's a bigger need to track changes to the kernel side of things.
Then again, it might've gotten easier. I haven't maintained drivers since the 1.3/2.0 days.
Log in or piss off.
As a person with software development skills, I could:
1) spend time writing kernel code, and get a sense of fulfillment from it.
2) spend time writing some other code, and get a sense of fulfillment from it, and get paid too!
3) Play WoW.
The incentives speak for themselves.
Linus comment is out of context, I hope.
Getting hired really quickly changes nothing. You are still an unpaid volunteer unless the new job pays you to contribute to the kernel. Lots of people contribute to open source projects on their own time while drawing income from other work. That does not make them paid developers in the context of the open source project.
So what if it gets pulled into the kernel, than its kernel coding; at least in Linux land because driver code can touch memory belonging to other parts of the the kernel. If we are talking about Minix or something it might not be.
And So what if he did it to pad his resume. Drivers are useful to anyone who has the kit they are written for. Even if he abandons it quickly a working or mostly working driver is still useful because someone else can maintain it. Its way easier for me take your driver for 3.0.19 and tweak it build on 3.0.22 or whatever than it is to work out the hardware details.
He wins and the community wins.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
Well, I guess that opens a philosophical discussion of whether writing device drivers counts as "kernel coding" at all.
Well, kernel-space drivers have the ability to poop all over the system so I'd say being able to write those without people yelling at you indicates some skill. Doing a little tweak so your obscure USB webcam that is 99% similar to all the other webcams work probably not so much. Though if all you're looking for is a one-liner to get your name on the list that might not matter much, I did run into a crash bug on a -rc1 kernel that was simply a missing description causing a null pointer kernel panic but unfortunately I was a few hours short of being the first one with that exact device ID and a patch. Just for the "kernel hacker" title.
Live today, because you never know what tomorrow brings
esd wasn't nothing, it just didn't obey the generic network-able "everything is a file" type of *nix attitude. There were lots of sound servers, but they all took a windows-type attitude of wanting to take over the sound card for exclusive use, and also had low quality and incomplete APIs. PulseAudio was included by distros about 3 years too early, for reasons having to do with implementation bugs, and the wide variety of hardware bugs in sound cards. (because sound cards are cheap hardware, they get less engineering and need more software workarounds)
Before it was really ready, turning off PulseAudio was the second thing I did to a new install. (right after turning off NetworkManager) But once the bugs shook out, the reality is that it is much better than what came before, and properly interfaces with the rest of the ecosystem.
The real point of his point was, people with weak programming skills can improve anything, especially any software they interact with that is in a difficult problem space and therefore has low-appearing fruit. That turns out to be "too hard." And instead of learning to be less credulous of wild complaints, he learned that his mistake was not to charge ahead into the problems that were too hard for him, merely because he saw others who had the background to take on the problems have some amount of difficulty, or at least he heard people say bad things about them.
It is all very typical. He abandoned kernel dev while at the height of the Dunning-Kruger curve, before having even started to take something on, and realized it was just too hard for him. Had he actually tried to push forwards and write code,(just a detail, or the real part?) he'd have quickly found the bottom of that curve.
Ideas are worthless, even good ideas. I've got notebooks full of ideas, and nobody cares. If I had notebooks full of implementations, I'd be famous.
I look back on many years of writing assembly code for 680x0 and PPC, Strong knowledge in Hardware and System development of certain architectures as well as C programming. I even have written an hobbyist Kernel and an Action Replay like software (WinIce for Windows guys). Sadly I am not able to find a job offer here in germany. Most of the time I deal with mid management people who know shite about programming at all. They see you as a toy who can be hired cheaply.
Over the years I found a company named CSC (Computer Sciences Corporation) who hired me as an application developer for surface and subsurface realtime systems (Military services). At least that's what's written on the paper. The reality ended up that I did normal consultancy shite like building up PC's, lot of travelling, systems integrations and other things NOT RELATED to my job description. After 6 years I quit the job because it wasn't satisfying. I wanted to leave earlier but unfortunately the current economic situation didn't allow me to quit the job and become unemployed.
After a while they started treating me with all kind of dirty company stuff like warnings and other things only to enforce me to continue the way "they" saw me. This ended up in me resigning from the job.
After that I wasn't able to find another job anymore because over the 6 years I did so many different tasks, that I ended up doing everything half or on a broad ranger rather than staying the expert that I was before I joined the company.
Now 5 years have passed where I resigned from my job and from then on depend on germans wellfare system.
I wasn't hired anymore. No one want's my knowledge and no one wants to hire a "foreigner" (my parents are migrants).
So far mr. Linus Torvalds. I respect you but you are wrong. The indepth skills one have are worth nothing. The only thing matters is a) you are young, b) you are cheap and c) you are no fucking migrant.
Device driver writing is some "trivial resume-padding you can pick up in a weekend", tbh.
Rewriting a kernel subsystem, on the other hand...
Sortof, except that even if the majority fit that description, the majority are also written before you even know they exist. A person in the position of needing to pad their resume doesn't own pre-release promotional copies of all the latest hardware. By the time the device is in the store and they know to check for a driver, the patch is already a month old on a mailing list. Even if you're reading the mailing lists, the process is not normally, "gosh people there is no driver for this device, will somebody please write one, here I'll mail you the hardware." The first you'll hear about the new hardware needing a driver is when the patch gets paraded on the list.
All the missing device drivers are for very expensive hardware that very few gainfully employed developers have access to, and the things that are hard because of missing or intentionally incorrect proprietary information.
It would be a lot more effective a resume pad to just re-implement a few kernel wheels, not even submit them, and present them as an appendix of working code samples. It saves all the wasted years hunting, hunting, hunting for that elusive easy-but-unimplemented driver. Heck, even just reading the friendly manual during those years would be more productive.
See my anon comment above about people fearing kernel code.
You sir, are one of them. It's a psychological barrier, not a technical one. It really, really isn't hard to get a start on kernel development, especially if you're only talking about things like simple mods and drivers. If you're the type who needs an IDE to get anything done, then yes, it probably is hard, but you're also not a skilled programmer.
As far as documentation goes, to me it's duplicate effort and introduces risk of out-of-date docs. The code and headers should be all you need. Docs are for non-technical managers who like feature lists.
The only important docs are how to configure and compile a kernel, and that's documented to death and rarely changes.
People just think it's hard and won't even try.
Maybe it's the "CS" title. I am more familiar with the engineering world.
Some professional experience might change your tune about the approachability of open source.
You'll likely be tasked at some point on a team building a large system that has components that are closed, components that your team is writing, and open source components. Inevitably some interaction between those spheres will lead to a failing test case (or bug report). You'll be able to see inside the open source (and ask informed meaningful questions about it on the Internet), see inside your team's work and discuss it with your team, and have to trust the documentation of the closed stuff.
Your definition of which sphere has a lack of approachability will change rapidly :)
And where is the Dice link ?
Why do they do this? On the one hand, they may have some profitable use for the Linux kernel, but on the other hand, Linux is GPL'ed, so they are effectively giving away the work to the world at large. That may be fine for Joe Average volunteer kernel developer, but why would a company want to contribute to a public project like so?
Wh47 d1d j00 541, 31337 15n't t3h r0xor5 ne m0r3???
While I look at other code for the details, such as looking at a function I plan to call, some "big picture" documentation is extremely valuable in order to know where to start. It's best to understand how it's supposed to all fit together and you can't see that by looking at individual lines of code in a codebase of millions of lines.
Also a sample HelloWorld module is very useful. What functions are REQUIRED for a kernel module? Reading over an existing module won't answer that; a sample helloword.so will answer that and many more in a compact form.
I found the Apache Modules book very useful for these reasons. The functions in the Apache API can be understood, but the big picture of the architecture is much clearer after reading the book.
...It's a psychological barrier, not a technical one....
Spoken with supreme confidence by someone who has evidently never touched a line of kernel code. I can assure you that it is in fact a technical barrier.
When all you have is a hammer, every problem starts to look like a thumb.
Why does the Linux Foundation force its website visitors to submit a form before they can read this report?
The LInux Foundation is pretty much out of touch with the community, it is basically just a self appointed manager circle jerk. Not understanding basic open source etiquette is a clear demonstration of that.
When all you have is a hammer, every problem starts to look like a thumb.