puzzle

It was even crazier: when the original download server was written, local disk was faster, mainly because the network wasn't too fast (rack locality was a concern, way back when), but also because GFS chunk servers weren't, either. At the time of the rewrite, Firehose and co. were being deployed everywhere, D did a better job at serving bytes and, later, local disk use was placed in a lower QOS level. Unless you were one of the few teams that had a good rationale for dedicated machines, if you fought for I/O time on a given disk against D, invariably you lost.

I bet there's a very long tail, i.e. the majority of images are rarely accessed, if ever.

Resizing images in Golang is not as trivial as you might imagine at first. You need to be able to handle all sorts of formats and color spaces. You'd be surprised by the kind of weird garbage your users will upload. Then you need to use SIMD, not pure Golang solutions, or performance will suffer. So you end up adopting a wrapper around libvips or similar, at which point you will start to ponder if you should have stuck with C/C++ in the first place. (It all depends on how much of Go's features you use or if it's just a nicer, safer C for you.)

But Yahoo search itself has been, for the past four years, a mishmash of Bing, Google and Yahoo results. I wonder which mix of the three Yahoo will pass along when using its API, versus using its search page.

I'm an ex employee. There's actually a whole team whose sole job is making sure that all other teams have policies, measurements and alerting for deleting data. They'll chase you if any of the above doesn't hold. It's non-trivial work and slows down your development, if you believe in releasing early and fast. For everybody else, it makes total sense.

I bet it's not free to run, but it's cheaper and easier than elsewhere, because Google's infrastructure is built in-house and mostly integrated. I don't envy other companies that want to do the same.

Maybe they're the same service behind the scenes. Would you store the same music twice, if you had to run both?

Is this on desktop or mobile? It could match the theory in the grandparent post that they preferred sticking to one backend. That also allows handling conflicts in one place, with one protocol. E.g. what would the behaviour be if you edited the home address with a ZIP code on your phone, while offline? What if you try to make the same change from your laptop and e.g. you set a ZIP+4 code? And then what happens when your phone is online again?

Oh, God. I forgot about the empty src bug. YouTube wasn't the only substantial Google service affected by it from time to time. But I remember it differently.

Yes, it triggered a GET for /. But that generated HTML (usually the service's homepage, as was our case), which the browser would attempt to parse as an image, obviously failing. It would not trigger a recursive fetching of all the resources on the page. Even without recursion, it already inflicted major damage, because our service's homepage was dynamic, while the resources linked from it were mostly static (and thus a lot cheaper, as well as cacheable). I think I would have noticed if it multiplied other traffic, not just the homepage.

This was the bane of my existence for many months. Every few weeks I would have to fire up Dremel and try to figure what was causing the spurious page loads. I hated and still hate SQL, so that was no fun. I knew when it was time to investigate thanks to our human monitoring system: our PMs would get excited or puzzled by a sudden jump in the page view dashboards. (They lived by those graphs...)

Thank you Chris and co. for your contributions in killing the browser version from hell.

The new headcount is coming from cloud. Lots of sales people in particular.

I left Google years ago and have a few crazy stories about Eric, but it might be still too early for some of them.

He was very approachable and understood well the technology that we were building. Most of my colleagues seemed to like him, too. He wasn't the money guy at the top of the org chart that doesn't understand his own products. That was even clearer when I talked to him in person once, after a company-wide meeting. He wasn't in a rush to get away from us plebeians, either.

Someone next to me made a comment about surveillance and he replied along the lines of "You know, I grew up in the Hoover days", explaining that he had seen the potential for abuse of power or personal information since a young age and that he held that as something to keep in mind or avoid when making strategic decisions.

Yeah, Sergey was better with numbers. Like that time when a PM was showing a new payment product on stage and he asked "was that your real credit card number?". She confirmed it was, to which he replied "Anyone could have memorized it... [starts reciting the digits, with the demo already at the next screen]".

Well, there's one guy (Ron Nicholson, who later worked on the N64 chipset) whose signature appears in both machines. Perhaps he thought to apply Job's idea to the Amiga 1000.

As for other machines, I don't know of other signatures, but there are often Easter eggs. Commodore machines had funny stuff on their PCBs: codenames Rock Lobster, Junebug, plus the Fred/Wilma LEDs, etc. Lots of integrated circuits from several companies had artwork in unused areas of the silicon die.