How Google Uses Linux
postfail writes 'lwn.net coverage of the 2009 Linux Kernel Summit includes a recap of a presentation by Google engineers on how they use Linux. According to the article, a team of 30 Google engineers is rebasing to the mainline kernel every 17 months, presently carrying 1208 patches to 2.6.26 and inserting almost 300,000 lines of code; roughly 25% of those patches are backports of newer features.'
This company had about a million servers last time I cared to find out. I dont think 'more cheap hardware' means the same thing to you as it does to Google.
"His name was James Damore."
They are already running absolutely absurd amounts of cheap hardware. "Just buying more" is something that I'm sure they are already doing all the time but clearly that only goes so far.
I suspect the answer to that is a very very small number.
"linux is just DOS with a UNIX like syntax" -- Galactic Dominator (944134)
You are clearly not an engineer of scientist. Aside from the fact that some people just like to solve technical problems, I am betting google's logic goes something like this:
We have a problem that is basically only costing us $0.01*10,000computers/day. While that seems low, we plan on staying in business a long time, we could pay someone to solve the problem. Then there is that X factor, that if you don't do it, if you stop innovating, your competitors will, and they will get more and you will get less from the pool of money that is out there. In addition to that, the CS guy you paid to solve that is now worth more to your company (if you employed him) because [s]he now has a better understanding of a complex bit of code (the linux kernel) that you rely on heavily.
Does Google give any code and patches back to the Linux kernel maintainers? Since they probably only use it internally and never distribute anything they are not required to by the GPL, but it would still be the right thing to do.
Well, most programs are not OOM safe. It turns out to be really hard to write programs that behave gracefully in OOM scenarios. Killing a sacrificial process when the system is out of memory works OK if you have a pretty good idea of priority ordering of the processes, which Google systems do.
Hmm, you realize that Android alone is over 10 million lines of code right? That's a pretty big open source contribution right there. But then there's also over a million lines of code across 100+ smaller projects too. So I am not sure what your definition of "table scraps" is but it's significantly more lines of code than most companies do.
Also consider the fact that Google has been basically deploying new servers non-stop for many many years. They are already purchasing cheap hardware at a very high rate. Even a tiny 1% improvement in efficiency for the existing and future servers is a huge huge win for them.
That could amount to hundreds of millions of dollars saved over the next decade, and it doesnt take a genius to realize that a couple dozen programmer salaries will be a hell of a lot less than that.
"His name was James Damore."
Yeah great work Linus.
The distros STILL stick with older versions and backport fixes, because who in their right mind is going to bump a kernel version in the middle of a support cycle? It's even MORE broken because the kernel devs rarely identify security fixes as such, and often don't understand the security implications of a fix, so they don't always get backported as they should.
The Linux dev model is NOT something to be proud of.