smueller1234

For moderate to large projects, link time can be a huge factor even for incremental builds. It might be that faster IO is the better investment, though.

Unless you deliberately ship them off-site to a vault. Or the tape libraries are too small such that you'd rather eject pure DR use cases tapes.

Minutes. And depending on where I'm the world your tape is relative to the drive, days! :)

Absolutely! In that long comment, mitchellh briefly talks about the impact of employing folks in different states on potential corporate tax.

Now imagine you ran one of the big billion+ USD revenue tech companies, and you're not talking about different states in the same country but a distributed workforce in many countries and the political pressures on taxation of e-commerce or similar business models involving intangible goods. One of the key arguments in many a tech company's tax/legal toolbox (usually for arguing they should pay taxes on one jurisdiction instead of another) is in which countries their engineering efforts reside and to what extent.

It's really no wonder that employment legal & finance wins out on totally flexible work arrangements in that situation, for better or worse. Politicians aren't taking any hostages in this context, see eg. France.

To provide an example from sufficient years back: I had to represent the stance of a past employer on compliance with Russian privacy laws to Roskomnadzor[1] in their HQ in Moscow. Through a carefully planted trick they tried to get us to commit to establish just the right kind of representation to be able to tax our revenue from Russian customers. In many countries, the narrative would've been "you have engineers here, you therefore build your products here, you should pay income tax here". Curiously, there isn't really obvious right or wrong in all this since the goods are intangible.

[1] https://www.google.com/search?q=roskomnadzor

(Disclaimer: experience entirely from prior to my current employment at Google, I don't speak for Google in any way and have no insight into these matters at Google.)

For big companies, this is an international problem!

And then tax issues aren't just the employees' income taxes but the company's tax regime.

This needed to be said, thank you.

> Don't take it personally

No offense taken! https://xkcd.com/386/ :)

My apologies, but your analogy is flawed. An adverse effect of ionizing radiation is that it could cause a mutation that replicates (before it's caught by the immune system) - cancer. It's therefore intrinsically probabilistic: if you're exceedingly unlucky, a small amount of ionizing radiation could get you there. That does not apply to your caffeine analogy, which actually does have a threshold.

Now, there's indications that at least the linearity of the LNT model is off in that there IS any effect of the immune system on the outcome, but that at high doses, it may be suppressed thus making the response non linear. I'm sure there's other effects of that nature and I don't think this is particularly well understood. But I dare say the linear no threshold model is actually somewhat more supported by common sense than you imply. Your distinction between the words "model" and "assumption" is moot by the way. A model is an attempt to (typically mathematically) describe a complex process. That's always an assumption in that sense. :)

(Former high energy physicist. Not an MD. Not a medical physicist.)

The only internal reference I had was a distant acquaintance who - as they said themselves - just submitted one that basically read "don't know them much but they don't seem to be a jerk".

So you can absolutely get hired in engineering without internal references. (I'm also on a hiring committee myself.)

I think that's about half right: for large storage infrastructure, you would indeed eschew local RAID, but instead of storing multiple copies, you'd use Reed Solomon encoding to stripe a single copy across many disks/servers/failure domains with a configurable number of added parity stripes. Full copies are really expensive!

It's actually "at most 50% on toil". But of course it's also hard to measure exactly. It's more of a barrier that if we exceed it, the team probably needs serious help!

Ultimately, Google engineers can move between teams pretty freely, so if we allow a team to descend into an operational or a deadline-induced death march, and we don't address that quickly, chances are the engineers will move to another team. It's sometimes frustrating not to have more control as a manager, but it's a very nicely self correcting mechanism and fixes various incentives for us managers.

(I'm a manager in Google SRE. Not speaking for Google.)

Nitpick: he's not talking about the Drittes Reich, he clearly must be talking about the experience people had in eastern German DDR / "German people's republic".

GCP Transfer Appliance: https://cloud.google.com/transfer-appliance

(I work at Google, don't work on that product.)

Disaggregated home SSD? Err, wow!

For a topically related effort see the oft featured and outstanding book at http://craftinginterpreters.com. (I'm not affiliated.)

See also boulos' comment:

"As for 224, we've always reserved threads on each host for I/O and so on. Figure 2 from the Snap paper [1] is probably the best public reference. We also don't make it clear (on purpose) what size the underlying host processors are, though you can clearly guesstimate pretty easily."

Ie. if there's even one thread reserved on the host, your speculation comes to naught. Sorry.

Google's big enough that no one person could possibly speak confidently for all of engineering in this regard.

For what it's worth, this doesn't match my experience at all. In the area I work in (SRE in technical infrastructure, but the same seems to be true for our dev partners), I see a lot of expectation for bottom up ownership. I could totally understand if somebody with a different mindset and perspective (I'm a manager, so I can see pretty clearly what's valued at evaluation time) arrived at a different conclusion.

That's actually mandated by law in Germany (Reißverschlussverfahren). Took me a few years of driving in other countries to realize that wasn't universal.

Are you looking for https://www.google.com/patents/opnpledge/ ?

I suspect you can only filter there, but haven't tried just now.

No it is not. How on Earth did you get the impression that you can't sort by price?

Mobile website and app, from just now: https://imgur.com/a/9422eyt

Sorry for the self reply, some context. The reason I looked at a number of these urgency messaging implementations is that we'd gotten a bunch of allegations from legislators that they were wrong. I was in a senior enough position that I would've been able to push back on anything dodgy/outright lying I would've found. I didn't find any that were incorrect.

As you might intuitively conclude, Booking and its competitors invest quite heavily into detecting real vs. bot traffic. Often, sites will block bot traffic or degrade the content. Booking is very torn on that because they don't want an arms race. When I worked on the experiment tooling, we very much preferred to have more, but tagged bot traffic than less and undiscovered. That's because for the experiment analysis, the undiscovered bot traffic was poison.

Pavlos worked for Booking.com in the past.

It's owned by booking holdings (formerly called Priceline group). Booking.com is owned by the same group. They're being operated as fairly independent companies just as Agoda, opentable and Priceline.com are.

Would love to see an example of a booking employee (current or former) claiming they're false. I looked into a number of them first hand and they weren't (last I did that would've been 2016/2017 and certainly didn't audit the entire code base).

Oh yeah. Booking doesn't do it because it's big enough that it would get called out - externally and internally. Also, is actually much less snake oily a company than its reputation here or else I wouldn't have worked there for as many years.

That's exactly right! Source: I designed and built a version of their experiment tooling (the last iteration before they had proper mathematicians to get it more right).

I used to work there until end of 2017 in a senior role, running the infrastructure development department.

During my time there, the company would never actually do something that was technically wrong (or lying), with a couple of exceptions where some individual went too far and wasn't caught in any review. There were certainly UI elements that were misleading or suggesting (never claiming) of something being a freebie when it was included in the chosen rate. These sort of changes consistently received internal criticism, but ultimately due to the outstanding A/B testing tooling, were shown to be worth too much money for the detractors to succeed. There were maybe a handful that were rolled back due to internal criticism.

In any case, it seems unlikely that booking would implement the change you describe.

NB: the actual availability was always controlled by the hotels, as were the prices - booking does not own inventory, unlike some of its competitors!

Edit: removed surplus punctuation.

Sure, but "schedule action at scope exit" is an easy (assuming your runtime already knows how to unwind the stacks) problem to solve. "Perform escape analysis and guarantee immediate destruction; efficiently without full gc nor refcounting" is not and they're not the same problem at all.