puzzle

Google has tracked office air quality for years, e.g. through the Aclima partnership.

That's basically because Larry Page really, really cares about it. He's kinda like your friend with a Kubrick obsession that can't stop bringing up facts:

https://twitter.com/elonmusk/status/727189428142235648

He was on to something! Jokes aside, I think he just has a heightened sense of smell and that's why he had air filters stronger than law requirements installed everywhere, at least in Mountain View.

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.

Google retrains models all the time. They gave a presentation about ML and production last year:

https://www.usenix.org/conference/srecon18asia/presentation/...

You can see there's a section on privacy and deleted data as well.

Each team has its own policies, because each product is different: at a bare minimum they might be using different storage systems, but it's very likely that their data pipelines are quite different, too. In any case, each team's targets are at least as strict as any published ones, of course.

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.

It might have been a legend or an exaggeration, but Miner sometimes asked Mitchy whether to draw a circuit one way or another. He'd look at the dog's tail for a response. More often than not, she was right.

More seriously, he admitted that the presence of the dog set a much informal tone in the office and made it easier to hire "unconventional" characters.

In Chrome beta 74, the count is in the bottom toolbar, so a variant of this attack that were UA-aware might have an even easier time. (The padlock is no longer green, either, and the leading https:// is omitted.)

On the other hand, scrolling to the very top of the page reveals the original address bar.

A possible mitigation would be to use a custom background or gradient for the bar that a web page can't guess. I'd be tempted to suggest the Google account's picture (if Chrome is logged in), but I don't know how safe that is from cross-site shenanigans.

Google used to have a phonebook search feature, but it was retired years ago. I don't know the reasons, but it might have had something to do with privacy or legal actions.

In a commencement speech, Jeff Hoefer goes a little bit into why he left the team four years ago and how he's changed his job each year since:

https://youtu.be/a7cJHTpW4Tg (jump to 49:00 or so for the more relevant bits)

Note also that he had a quarter century of experience before Apple, having worked on anything from the (RotJ?) Darth Vader helmet to the Oral B CrossAction, which is, a bit surprisingly, the product he thinks defines his career.

Probably the former, given that the team has been around for a long time. There was another defection even before their earliest example of 2016. In that case it was someone with a decade of experience on the team and another 25 years in the field who went to Google (ouch).

Or, in more recent times, it's not as if wiretapping abuse was discovered in places like Greece or Italy.

I remember that being a former Google intern.

I found in my own amateur UX studies that there are drivers who hear "in a quarter mile, turn right" and don't know how far that is, even after having heard that prompt thousands of times. You'd think that after a while they'd build a mental model of the distance. Instead, they seem to just tune out the "in a quarter mile". This is one of the classes of users for which products need to be designed. (I have similar problems with people's heights.)

Also, as a passenger it's fairly easy to say "turn in five blocks" and track how many blocks are left, maybe even while holding a conversation. For drivers, that seems more difficult, probably due to cognitive overload, unless it's just a couple of blocks. And I've noticed that some drivers react to that kind of direction by scanning the view and quickly translating the number of blocks to a landmark.

Do you mean rerouting? Google Maps is tuned differently than Waze, which caters to drivers looking to shave off minutes or even seconds. It tries to keep directions simple and easier to follow (e.g. not making a large number of turns), even if that means a slightly slower route. That was a deliberate product decision, at least until a few years ago.

What kind of incomprehensible directions and business names are you referring to?

It's not an ad¹. A lot of humans navigate that way, for many reasons. Google has done research on that through the years. Landmarks might be easier to spot and are an useful confirmation that you got the turn right. Do you never ask yourself if you just made a mistake? Perhaps you got distracted by a passenger, another vehicle or a pedestrian.

The street name you are turning onto might be not as visible because the sign is small, covered by a large truck or not well lit at night. Key Bank is probably harder to miss.

Or there might be no street name at all, which is often the case in places like India, where Google has been testing this for many years. In that case you have no choice but to use landmarks.

¹Or, at least, one that you can purchase now. It might happen in the future, but of course they'd have to be careful when rolling this out. Imagine if they used a business that is not very distinguishable and thus not a real landmark. That would diminish Maps' utility.

Interesting, I didn't know about the ten years. The relevant rules seem to be here:

https://www.irs.gov/individuals/international-taxpayers/expa...

He mentioned it in 2013. So he's probably not affected anymore, but he still tends not to spend a lot of time in the US.

Another thing that is commonly baked, by professionals: old tapes that have trapped too much moisture and start to deteriorate. They're placed in ovens for much longer, at lower temperatures.

There was another good interview in NYC on US premiere day: https://youtu.be/zH982kFXMuM

I had to make sure to be in NY for it. Last time I saw him live (at IFC for The Zero Theorem), he mentioned that he can only spend 29 days per year in the United States after giving up his American citizenship. His days are counted, in a way...

Which might or might not involve Gilliam himself in some kind of consulting form. He's not sure yet, because they've been talking, but at the moment there's no signature.

Yes, Amazon was going to distribute it, but they got scared after last year's lawsuit.

Juicy details about Levandowski and their Google Maps costs...