Alan Cox Leaves Red Hat 163
ruphus13 writes "Alan Cox — one of the lead Linux kernel developers at Red Hat — is leaving the company after 10 years and is heading to Intel, where he can focus on more low-level development tasks. Some are speculating whether this is indicative of a shift to a more 'application-centric' vision at Red Hat. From the article: 'Red Hat is integrating more application related, user- and enterprise-centric tools into its well-established "low-level," "core" development and support tools. It'd be more worrisome if Red Hat neglected to strike out in this direction. Cox was with Red Hat for ten years, and regardless of any suspected change of course within the company, that's a fair amount of time.'"
Re:As an Intel Employee..... (Score:3, Informative)
Doesn't Cox "work from home?"
Home being in the UK somewhere.
Re:Hmm. (Score:1, Informative)
That's odd. I also claim to have talked to him and he said vi was better than emacs.
It wouldn't surprise me if he decided to work for Intel's obvious troll division.
Did I just blow your mind?
Bu cryn newid mewn deng mlynedd (Score:3, Informative)
I first stumbled on Slashdot ten years ago when Alan Cox mentioned in his online diary (a novelty in those days) that it was nice that even Slashdot were carrying it as a story.
I knew Alan from my uni days when I heard the outrageous rumour that SUCS (the comp.soc.) were trying to put real Unix onto a PC.
Re:As a Red Hat Employee..... (Score:1, Informative)
Outrageous eh? : ) (Score:2, Informative)
Hey some of us young 'uns in SUCS [sucs.org] would like to hear more about the old days of the 90s. If you've got a moment hop on by to the SUCS@20 [sucs.org] site or drop by Milliways...
Source vs. Binary (Score:4, Informative)
One of the nice benefits of having driver source available is that the kernel developers can fix them if they understand the device itself. The original designer of the device is always in the best position to write at least the initial driver code.
One of the big rules in kernel development is that "if you break it, you have to fix it."
Having a good-quality original driver from the manufacturer means that the driver will be ported to new kernel versions, and any incompatibilities introduced are fixed by the person on the kernel team who made them break.
Re:Alan Cox is a Good Influence (Score:5, Informative)
Re:Alan Cox is a Good Influence (Score:1, Informative)
I met Alan about 10 years ago in Raleigh at what I believe was the final Linux Expo there. We were at a SuSE after party, and I was (and am) absolutely nobody in the Linux community. I was just there to meet up with an old friend who at the time was Somebody in the Linux community and it was through him that I met Alan.
There are a lot of chest thumping silverback alpha geeks, a lot of frothing at the mouth megalomaniacs out there. Alan Cox is furthest from any of these things. Just a really intelligent but down to earth guy that you want to go have pints with down at the pub.
I wish him much success with his new job.
Re:Alan Cox is a Good Influence (Score:2, Informative)
I submitted a bug a few years ago and was surprised to get an email from Alan Cox requesting more information. He did end up fixing the problem (some sound issue, iirc) and acted as if I was some high-level customer and he was just a random coder. Super down-to-earth guy.
Re:There is speculation... (Score:4, Informative)
It seems that this article [lxer.com] referred to by the main article [ostatic.com] speculates incorrectly, saying that:
whereas Alan actually wrote:
a few lines below.
Re:Anyone care to speculate about his compensation (Score:2, Informative)
Re:Anyone care to speculate about his compensation (Score:3, Informative)
In engineering, it's pretty easy to get $80-90k with relatively little experience, or with a not-so-great track record of performance, just by moving around a little. If you're a star performer, in fact, you'd be lucky to get raises sufficient to make much more than new hires who left their previous job because they didn't get any raises (i.e. not great performers), and the new company wants to pay them "market rate". Typically, you'll only match the new hires with your raises. So what, exactly, is the incentive to be a star performer? There is none. You can be a total slacker instead, just change jobs every few years, and do just as well as the guys putting in 90 hours/week and doing the work of several lesser engineers.
This is absolutely true... where I work, the pay ranges that I know of for all north american sites, as of last year, were:
MTS: 103k-168k
SMTS: 115k-187k
I'd say roughly MTS means 7+ years of experience, and SMTS means 9+ years, give or take.
Of the people that were brought in at their current level, most (say around 80%) are around the median of those ranges, tending to be a bit higher. Of the people that were promoted to those levels, most are in the bottom 25% of the salary range.
Now, there is certainly significant correlation between compensation and performance, but only when looking within each of the {hired, promoted} groups. But when looking at the whole group (everyone reporting under our director at least), there are several cases of people ranked in the bottom 25% of performers having salaries 30-40% higher than the top ranked engineers. Just from the salary data, it's very easy to tell who's been around for a while.
And you're right, there's no incentive to be a top performer really, other than having a better shot at escaping the layoff axe when it comes around...