smueller1234

Nitpick: From the PoV of the (public tech) employers, they typically look at compensation not including appreciation of the restricted stock. It's typically "base + bonus + new stock grant value" or sometimes "base + bonus + value of the restricted stock that vests this year, but using the value at GRANT time, not at VEST time".

More specifically as an employee, I think any incremental value from holding the stock is not compensation FROM the company, since the employee equally has to carry the risk of stock prices going down.

Of course, practically, one's cash flow in any given year is "base + bonus + actual value of the stock that vests in the given year" and can be vastly different from how the company does compensation planning. And this is also what determines income taxes (unless I'm bizarrely mistaken about how income taxes work in some jurisdictions).

Having been a manager at multiple public tech companies, I'll say that this has led to very many 'interesting' comp conversations and not everyone comprehends the distinctions here -- regardless of what's arguably more 'correct'.

And survival.

I'm not the original author but I used to work with him and now do in storage infrastructure at Google. As others pointed out, what the author, Kris, writes kind of implies/requires a certain scale of infrastructure to make sense. Let me try to provide at least a little bit of context:

The larger your infrastructure, the smaller the relative efficiency win that's worth pursuing (duh, I know, engineering time costs the same, but the absolute savings numbers from relative wins go up). That's why an approach along the lines of "redundancy at all levels" (raid + x-machine replication + x-geo replication etc) starts becoming increasingly worth streamlining.

Another, separate consideration is types of failures you have to consider: an availability incident (temporary unavailability) vs. durability (permanent data loss). And then it's worth considering that in the limit to long durations, an availability incident will become the same as a durability incident. This is contextual: To pick an obvious/illustrative example, if your Snapchat messages are offline for 24h, you might as well have lost the data instead.

Now, machines fail, of course. Doing physical maintenance (swapping disks) is going to take significant, human time scales. It's not generally tolerable for your data to be offline for that long. So local RAID barely helps at all. Instead, you're going to want to make sure your data stays available despite a certain rate of machine failure.

You can now make similar considerations for different, larger domains. Network, power, building, city/location, etc. They have vastly different failure probabilities and also different failure modes (network devices failing is likely an availability concern, a mudslide into your DC is a bit less likely to recover). Depending on your needs, you might accept some of these but not others.

The most trivial way to deal with this is to simply make sure you have a replica of each chunk of data in multiple of each of these kinds of failure zones. A replica each on multiple machines (pick the amount of redundancy you need based on a statistical model from component failure rates), a replica each on machines under different network devices, on different power, in different geographies, etc.

That's expensive. The next most efficient thing would be to use the same concept as RAID (erasure codes) and apply that across a wider scope. So you basically get RAID, but you use your clever model of failure zones for placement.

This gets a bit complicated in practice. Most folks stick to replicas. (Eg. last I looked, for example HDFS/Hadoop only supported replication, but it did use knowledge of network topology for placing data.)

The reason why you don't want to do this in your application is because it's really kinda complicated. You're far more likely to have many applications than many storage technologies (or databases).

Now, at some point of infrastructure size or complexity or team size it may make sense to separate your storage (the stuff I'm talking about) from your databases as well. But as Kris argues, many common databases can be made to handle some of these failure zones.

In any case, that's the extremely long version of an answer to your question why you'd handle redundancy in this particular layer. The short answer is: Below this layer is too small a scope or with too little meta information. But doing it higher in the stack fails to exploit a prime opportunity to abstract away some really significant complexity. I think we all know how useful good encapsulation can be! You avoid doing this in multiple places simply because it's expensive.

(Everything above is common knowledge among storage folks, nothing is Google specific or otherwise it has been covered in published articles. Alas, the way we would defend against bugs in storage is not public. Sorry.)

The current forecasts don't predict cost parity for the next few years. I wouldn't speculate as far out as ten.

What you'll see is that spinning rust will increasingly become used for cold(er) storage due to still offering cheaper bytes, and (relatively) ever increasing cost of IO (you get one spindle per il unit, but at increasing capacity, with barely a change in sequential throughout and no improvement in random access). This is happening in data centers now, either through explicit product tiring or clever offloading.

Correction: I understand it to be a quarter of staff (the total staff being 26000). So the article is pretty grossly wrong in an important and obvious detail. Not sure how much I'd trust it on the more nuanced but.

(Former booking employee here, but not for several years)

It really depends on your job and location.

I think the "your boss expects/forces you to" interpretation from the grand parent isn't generally what happens (at Google). I haven't seen that at all. It's rather more common that you realize on your own that a certain amount of travel is highly effective for building and maintaining the relationships you need to do your job.

This is extremely strongly correlated with your distance from HQ and with the seniority of your position in the company.

For what it's worth, I hold a reasonably senior role (at Google) in EMEA and I'm living off of the relationships I built in the two years prior to the pandemic. I traveled nearly 25% of the time then. Ask your nearest director+ in EMEA engineering and they'll recognize this at least in principle. This is likely to be very similar in other companies that are globally distributed but with a strong epicenter somewhere. I don't think it's particularly Google specific except in that Google engineering isn't very top down/command-and-control, so relationships in a complex org are an even more important tool for getting things done than they would be in a more hierarchical environment.

Perl is a tree based interpreter. It's not exactly an AST anymore but the time it's being executed, but close enough.

Don't wait, read it. It's fun and informative, worth every minute! I haven't had as much fun reading a technical book in years!

You're right. Oof, I need to stop reading HN late at night when I can't even read units wrong or have any intuition. Apologies.

Another impressive one: Ultra high energy cosmic rays have been detected to 3e20 eV (300 EeV; detected by the Fly's Eye Collaboration). They're nuclei, however, so the rest mess is at least about 10000x higher.

https://en.m.wikipedia.org/wiki/Ultra-high-energy_cosmic_ray

If you're interested in popular science but haven't read about this before, consider following the link to the GZK cutoff from that page. It's super cool.

I used to work for the Pierre Auger Observatory. Happy to try to answer any questions if folks are curious. :)

Google is hiring just fine. (Source: I'm hiring. I work for Google. Also careers.google.com.)

Actually reading tapes from two generations back can decrease the lifetime of your drive considerably. So in a larger setup you're probably not going to want to skip as many generations (in part because you can and practically must incrementally upgrade).

Actually, I seem to recall that he was working on it before getting hired by Facebook (unless there was a massive delay in the hiring to become known). I was following his excellent blog posts on the matter at the time.

Suggestion: I hope I didn't completely miss something, but the site seems to put average prices for procedures all over the place when the median price would actually be much more informative to somebody searching for a provider. Looking at a few procedures, the prices seem to have significant outliers, which exacerbates this.

You seem to have looked at Google specifically (mention of Docs). Google has substantial engineering presence in several european countries. Just a few cities/countries off the top of my head in no specific order: Munich, Zürich, London, Dublin, Warsaw. There's others, IIRC a bit on Stockholm for example, but I think those I named after among the larger presences. Anyway. Not just Germany.

There's also SRE, which has a slightly different twang on how we spend our time and then interview makeup.

For what it's worth, I'm not a computer science grad at all and I'm doing just fine at Google. Got hired as a senior manager, though, so YMMV.

Not trying to convince you of anything, just trying to be helpful. :)

Probably relevant: if I go to the terms/privacy policy via settings, I am greeted by the following preamble.

"If you don't live in the European Region, WhatsApp LLC provides WhatsApp to you under this Terms of Service and Privacy Policy."

I won't comment on the incident, but I can tell you that we have two, not three, SRE sibling teams each. That still gives awake-time coverage, but not working-hours coverage. We simply pay folks for the time spent oncall outside of working hours. (Google SRE)

This reminds me of a relevant anecdote: back in the naughts, I was doing research in cosmic rays at a large nuclear research facility. I did simulation and data analysis - office/computer work mostly. One day, a person with a clipboard comes into my office and asks about the whereabouts of some radiation source. I look at them confused - I had not touched sources since teaching nuclear physics labs. They show me their clipboard and lo and behold, it has my name next to a really high intensity source and they're looking to locate it.

After a few minutes of awkward shock and denying all involvement, we realized it was a colleague at the same research institute (and of the same name). He was, one building down, doing his PhD research on radiation hardened detectors for the CMS experiment at CERN(1). He was using the source for the testing. But I had a minute of real stress before that came together in my mind...

(1) I think this was his work: https://onlinelibrary.wiley.com/doi/abs/10.1002/pssa.2007763...

You should. Some of his books may take a bit of patience to appreciate, but there's plenty that give you a great ride with a good conscience of having done something to improve your vocabulary. :)

Throughout 2020, this hasn't actually been true.

Ah, I'd be out of date then. Go back a few years and my info would've been authoritative. I was running product development for booking's marketing department then, including the meta search integration.

Time flies!

That's correct, Booking was the largest Adwords spender. I worked on their adwords integration then. Good fun.

I wouldn't immediately consider the hotel metasearch products a problem for booking. It shifts traffic to different paid channels with different tradeoffs (eg. less fine grained control of spend if it's a revshare model). I ran the product development in marketing for a little while. Some years ago (ie. late in the game, largely due to politics), we started investing in cross channel attribution models to better direct spending.

Disclosure: I no longer work for Booking, though. I do work for Google, but am in NO way involved in Ads or travel and an not trying to comment on the company's business.

For what it's worth, this (sort of thing) was one of the reasons why I joined Google. And lo and behold I do in storage infrastructure now. :) (Alas, I am not at liberty to speak for the company or share any numbers.)

I appreciate that working for Google isn't everyone's cup of tea for a myriad of reasons, and would never pretend otherwise. And yes, the interview process can be onerous. But we are hiring! Certainly the 'technical scale' bit didn't disappoint me.

As with any other big company, if you're wondering how it is to work there, I would strongly recommend looking up acquaintances in the company and getting an inside view of the workplace dynamics to get a sense of what would await you and whether you'd enjoy it, even if experiences across this large an organization will vary greatly. If they're not close personal friends chances are if you just know them casually, they would still be happy enough to give you an unfiltered and honest summary of their experience.

Unfortunately I have to disappoint you. DDR5 is expected to be significantly more expensive than DDR4 at a system level, byte for byte.

Actually Freiburg has quarters with plenty of old town charm. And if that's not old town enough, you can always go to one of the smaller towns around, which should have plenty. It's an article that picks out and exaggerates one aspect of the city.

Makes for a great play table for kids as well. We bought one and put a custom sticker of roads/trees/houses on it that the kids can play with toy cars on, or amend with additional lego houses/trees etc.

Which happens to be what the actual article does as well!

That's a surprisingly accessible read and I would recommend it to folks curious about "what does intense irradiation do to the human body". But it's also quite haunting.

I think what you're looking for is this: https://metacpan.org/pod/Google::ProtocolBuffers::Dynamic

It probably does. But it requires someone to pick the battle (a customer or an enforcement agency on their own) to get it enforced.