Yes it does. Search for [digital camera] on Bing and DDG. Notice that the first ad is not just similar, it is exactly the same:

Sony® Digital Cameras
Digital Cameras for Beautiful Pictures. Free Shipping Order Now!
store.sony.com

Ok, so they are using AdCenter for ads, but that might not be true for actual search results. Now search for something esoteric and not likely to be in a tiny corpus, such as [state space motion planning]. The results have been re-ordered so clearly DDG has some re-ranking heuristics, but the results that are common (nearly all of them) are uncannily similar, including in most cases the exact same summary snippet. For example, the following exact result (all text) comes back in both:

Informed and Probabilistically Complete Search for Motion Planning ...
Sampling-based search has been shown effective in motion planning, a hard continuous state-space problem. Motion planning is especially challenging when the robotic system

Having a common phrase used throughout a paper yield exactly the same extracted snippet is unlikely, unless the implementations are identical. Since Bing isn't open source, Occam's Razor says they are using the API.

The simple fact is that one guy cannot implement a modern search engine, despite our hopes for the continued relevance of the garage revolutionary. While DDG likes to downplay the Bing API dependence, the majority of results come from there, and the rest is a few bits of sugar peppered on top for common queries. Claiming that having a special mode for wikipedia or "zero click" boxes makes it no longer Bing-using is kind of like saying Google's calculator means it doesn't need a search index.

I stopped watching after about 10 minutes. Gundersen does have a master's degree in Nuclear Engineering, but it seems he's always been a consultant rather than directly involved in the industry. Arguments presented in the first 10 minutes below in italics

We've never tested a large water tank on top of a reactor in a full scale test.

I don't really understand this; the actual source of heat is irrelevant when you are engineering a gravity-fed water tank, and that's pretty damned well understood.

It hasn't been approved yet. What's the rush? We should incorporate design changes from Fukushima and restart certification.

IOW, we're almost done with a design, so lets make a bunch of changes now and restart certification. I'll tell you what the rush is: we need to build new reactors and decommission the old known-to-be-unsafe ones. You know, the ones the people funding you are trying to get shut down. Just because a 1957 Chevy is dangerous to drive doesn't mean we should delay rolling out a Volvo S60 because it isn't "perfect" yet. Yes we should keep changing new designs but at some point you have to say "this is way better than what we currently have, let's build them".

Pressure at Fukushima raised up to 0.7 lbs within AP1000's design limit. The control rods might not go down when you try to stop it (after a partial meltdown, which falls into the "no shit" category).

This would be relevant if the reactors were at all similar internally. Hint: Fukushima was an ancient boiling water design, obsolete even when it was built. The AP1000 is much newer non-boiling design, and is much more amenable to passive cooling approaches. Yes, it is true that modern gasoline engines are not built to specifications for safe steam engines, which had quite a problem with boiler explosions.

Tank on the roof could fail. Seismic analysis indicates weight on roof is always bad (they appear unaware of counterweights used in tall buildings).

The alternative of course is tanks on the ground and active pumps, which is where we came from previously and are trying to avoid now. In other words, no solution is acceptable, let's not build anything. A corollary of that is that crappy old designs will continue to run. If this ends up a bad design for earthquake zones, it would still make sense to build them in seismically stable locations and replace known-bad power sources.

Terrorists could try to blow up the water tank!

This is apparently coordinated with an earlier attack on the primary method, since the water tank is the backup. People need to seriously give up on the airliner hijack thing -- yes our old rules on dealing with hijacking were flawed. They've now been patched, and passengers and the air force know what [not] to do. In fact those rules were already patched *on 9/11* as Flight 93 demonstrated. Terrorists are also opportunistic anyway, and will always seek an easy new attack route, rather than one that has been tried before (leaving responders prepared).

Shrapnel from an exploding neighboring reactor could peirce the tank!

Cool let's build the AP1000 and shut down the ones that can explode, ok? The alternative is to find new sites for a nuclear plant, which will take from decades to never given the same groups opposing them.

And interestingly that hypothetical answer gets at least 5 of the top 6 results as perfectly valid interpretations. People frequently complain about how "search sucks now" yet they never seem to be able to come up with *real* examples where they searched using unambiguous terms. People will say things like "I was looking for mag wheels for my car, and searched for [mags]. The results were crap, google is so broken!". They never seem to ask themselves "what terms do I need to put so that this would mean the same thing to everyone on the internet?".

I've come to appreciate that many people are extremely bad at searching, and that this should ideally be taught in school as an absolutely necessary skill. Usually I can find things pretty well, but I used to have to use Altavista so I got pretty good at figuring out key terms for a search, and I'm familiar enough with things like TF/IDF to avoid picking exceedingly bad terms that will tend to confuse an engine.

Steve Yegge still works at Google, after penning a rant which was well-known enough to be covered on slashdot and wikipedia:
    http://en.wikipedia.org/wiki/Steve_Yegge#Accidental_posting
    https://plus.google.com/112678702228711889851/posts/eVeouesvaVX
Here's the "aftermath" where not only did nothing bad happen, but some folks listened to him:
    https://plus.google.com/110981030061712822816/posts/AaygmbzVeRq
Now, a lot of folks didn't agree with the content of his post or characterization of why things were the way they were. However, there were definitely parts that rang true, and people wanted to share how they were trying to tackle those problems and invite others to join such efforts.

Steve's post also provides a window into how open and vocal the debate is internally at Google.

So, do you think that'd fly at the company you work for? How about at Apple, Microsoft, Amazon, or Facebook?

I have spent time at both Microsoft and Google. For a software engineer both are good places to work IMHO, but there is/was a huge difference in how much the rank and file could speak up regarding company policy. You can't always change things you don't agree with (there are often multiple sides to an issue) but you can usually get them modified for the better.

The word regime has multiple meanings.
    http://www.merriam-webster.com/dictionary/regime
    http://en.wikipedia.org/wiki/Regime
The article title clearly means "set of conditions" or "regimen" in this context.

CSM is one of very few English newspapers left with a high-school level of language. I'd prefer to keep it that way, though seeing your post get modded to +5 makes it clear why other newspapers are now written at middle school or even grade school reading levels.

Funny, I work at Google, have done many interviews, and my experience is the same as the AC. The only people who ask puzzle questions of engineering candidates are either unaware of or willfully ignoring current guidelines.

Of course, open ended design questions are fair game, as are algorithm problems asked as word questions. Blog authors often mix these up with puzzle questions. These design and verbal questions are asked because (a) applicants are expected to be able to implement things without a 100% watertight specification, and (b) design requires starting from a verbal description of the goal and figuring out what algorithms are needed to achieve the desired output.

Outside of software engineering, I have heard that puzzle questions are still asked, but that's not within the scope of this article, which is specifically about programmers.

Well, they do often lie about being straight.

Ad prices are mainly set by what the advertiser will pay. A site can set a minimum (although if nobody is willing to pay that no ad shows and the site gets nothing), and a maximum (which obviously you want as high as possible). Everything else is up to whatever auctions or contracts you can get with advertisers.

Ad prices are low now because there is excess inventory (place to show ads) and click rates aren't high enough to justify higher payments by advertisers. In that environment, you succeed by getting better click rates or figuring out how to run your service more cheaply, both of which Google is good at.

There has been a shift toward Debian-based derivatives such as Ubuntu. Historically at least, Debian repos were bigger and didn't require going outside the manager to download an RPM/tgz as much. RPM distros also seemed to be more fragmented into incompatible subgroups, while Ubuntu and several others stay close enough to their parent that simple packages (the bulk of long-tail software) can be exchanged. Things are much closer than they used to be, but if you gather a lot of data you might still see a statistical difference.

The data doesn't support your statement:
    http://www2.ed.gov/about/overview/fed/10facts/edlite-chart.html
(1) We spend more than most other developed nations, and way more than some countries getting better results.
(2) Since the 1960s the amount spent per student has tripled.

There are indeed many problems to solve in the US Education system. Insufficient total money spent on education is not one of them.

Alas, poor Syousef! I knew him, AC.

IANANE but I've been studying this area for a while. I think you are right, it wouldn't be practical to cycle a production plant. However I'm not at all worried about it, here's why:

To kick fossil fuels in any meaningful way, we need to generate power for transportation too, which means either charging electric vehicle batteries or making hydrogen (probably both). Those things can easily be shifted to be mostly-at-night operations, and would level the load significantly. Large scale hydrogen production can be co-located with the plant, so we wouldn't even need to improve the electrical grid.

Also, a cheap source of constant power like an MSR makes energy-intensive production cheaper, which happens to include solar panel production. Cheaper solar panels would allow for the continued expansion of rooftop solar power, which helps takes the edge off of the daily peak. Again this helps level the load without requiring changes to our grid.

Now if only we could have the will/courage to put significant resources into solving the engineering challenges of MSRs (which by the way are easier versions of all the problems we'd need to solve for fusion to be practical).

So solving a QA problem is not a technical reason? Surely there is more to this story.

This is an extrapolation based on your sample of one project before you left, which was unrelated to either of the three biggest codebases at the company. I think you've established your opinion that the larger group you were in was mismanaged; I think others agreed and there's been a bit a reboot there from what I have heard.

On the projects I've worked on, some quite high profile, I haven't seen this at all. Yes it is a big company and there are company-wide changes and migrations that can be a PITA, but it is rare that there isn't a good reason for such actions. When there isn't a good reason, aggregate developer push-back usually forces a more reasonable plan.

Of course, getting stuff done in such an environment requires tactful communication skills, but that ability varies among developers (as is visible on Slashdot, at Google, on LKML, or just about anywhere developers frequent).

What I saw was a platforms-guy railing about a product that was rushed for product reasons. I think he's entitled to his opinion, and as a backend-developer I certainly see where he is coming from. However I don't think he can put himself in product-development shoes very well, as there are times when you simply must launch (any good startup will know this). A successful product with bad code is an engineering problem, which engineers can fix. A beautiful design and codebase with no users is still dead. In the kernel world, you might compare Linux versus Hurd in this regard.

Anyway, on the original topic, the build systems at Google are kinda different now, such that compilation time is never a problem. In particular for an early release, I can see why this has not been optimized (note that 16G is simply achieve 25 min parallel compile, and is not necessary if you wait longer on a less beefy machine). If build requirements are a big problem for the AOSP community that would a be a good place for a community member to help the rest of the community. With the run up to the release, along with things such as kernel.org going down, developers such as JBQ are pretty damned busy.

Hmf, if that were true Madagascar's port would be closed by now.

Interesting, I had always heard there was a 20% difference. Wikipedia has calculations showing 8% (sea level at 0C) which is much closer to your number:
    http://en.wikipedia.org/wiki/Lifting_gas#Hydrogen_versus_helium
That calculation there looks altitude invariant; perhaps the difference that leads to your 5% is due to non-ideal gas behavior of air at altitude or something like that? I'm curious.

Also I wonder if the 20% was for a given size of balloon where they factored in the extra envelope size, additional support, and everything else that snowballs from starting at an 8% penalty.