jsolson

I'd add Microsoft and drop Facebook, personally, but... yeah, the first part is kinda fair. That said, the second part is wrong. It was no trouble at all to jump from Amazon to Google Seattle when I felt the time was right. My desk at the office (if you remember offices from the pre-pandemic days) is less than two blocks from my original desk at Amazon.

Despite my reservations about Amazon after having worked there, I think you're wrong here, _particularly_ with respect to Bezos. With some random director or VP? Sure. With Jeff you don't get the impression that he's a snob about the sources of good ideas.

Note that I don't think you'd get so much as a bonus or pay bump for your trouble, but don't worry, you can feed your family with the pride you have in your idea making the flywheel turn that much faster.

I debated calling this out and decided against because I knew you all would do it for me.

This, right here, is precisely why this issue is important. We have gendered pronouns that are so ingrained we try to pretend they're not gendered.

"All" is a _shorter_ and more inclusive substitute for "guys".

If you think this isn't important, just replace every occurance of "guys" that you see with "gals". If you're cool with that, good on you, but if you think for one second "oh don't say gals that might piss someone off" then, well, there's the kicker.

Unlike buddy, it's an inaccurate generic reference. It's a little more typing, but replacing "guy" with "person" or in this case "engineer" would be more precise (and inclusive).

Blaze itself runs locally, reading BUILD files from citc. The build actions mostly execute remotely.

Google automates it away, to the extent that if you run our "rebuild if anything changes" tool it will automatically run the BUILD cleaning tool if any layering violations happen or if any dependencies are absent.

I'm curious what you consider "insane" to be -- and I mean this genuinely. Google has what I think most would consider to be a large monorepo, but also provides developer desktops with ample RAM. I've noticed blaze's startup time, but never really thought about its memory consumption. Where are you running into limits?

I assume that's supposed to be state/local income tax -- Nevada is one of the few states other than Washington without one.

For much of Amazon's early history, the sales tax in Washington was only relevant if you happened to live in Washington. The set of areas where Amazon must collect taxes has grown, and at this point for all I know might be everywhere in the US.

Realistically, you'd use the FPGA as your NIC.

> FWIW it's also done for ICs at Google where you have to get promoted to senior by some time or you're let go. I don't know what the story is for managers.

Google explicitly changed the policy from expecting that all eng ICs reach L5 (Senior SWE) to expecting that all reach L4 (informally a "solid individual contributor").

Compute Engine isn't really a separate thing so much as it's another thing built on the same infra. All the way down to the individual VMs, it runs on Google's production infrastructure and is scheduled by Borg (onto dedicated machine pools, although that sort of dedicated resource pooling is not unique to GCE). Once you get into VM networking things get a bit more exotic, although all of that still runs atop the same software defined network infrastructure as everything else (but, much like with Borg, it uses more features than many workloads at Google).

(I work on Compute Engine's virtualization infrastructure)

Perhaps it is only upon leaving Google that one achieves transcendence?

(Source: I work at Google, yet still see life as often confusing and sometimes terrifying)

I have access to my (Google) building to allow me to get to the hardware lab there, but it's somewhat discouraged to do so.

Equipment is not to leave the lab, but we are encouraged to set things up to allow as much to happen remotely as possible. So I've got remote power, remote debug probes, a brace of EM100 QSPI emulators, etc. The net result is that unless I need to physically change the cabling on something I can work from home. I work on data center hardware which makes this pretty practical. I don't know how folks on the consumer side of things are faring.

Beth Gibbons is not a name I usually see called out as a solo artist -- to be honest, until today I didn't know she had done any solo work, despite Portishead's Dummy being in my most played albums every year since software started keeping track of that kind of thing for me.

Thanks for causing me to Google that. Now I've got something "new" to listen to while I make breakfast.

Xcode on OS X has been doing this for at least one decade.

Mind pinging me internally? Username in profile.

I have... an idea.

Right. It does a similar (albeit smaller scale) thing for Anathem.

Abeula.

(and it was glorious)

That episode is a mighty study in contrasts!

Cryptonomicon and Anathem get endings of a sort... later :)

Who doesn't love 40 pages (more?) of winding a clock as a hook? :)

Agreed, though, that it picks up a tad more after the clock winding and other front matter.

Interesting. I've loved most of Stephenson's books and Cryptonomicon easily holds the title of most re-read book in my collection.

Seveneves, on the other hand, I absolutely loathed in basically every regard. My loathing for it makes it memorable enough to be my most hated book (there are plenty of books out there that are 'worse', but are also unmemorable -- Seveneves is viscerally memorable)

Ah, that's where it all went wrong, moving beyond Netscape 4!

I need to send this to the people who designed the website for one of my favorite local pizza places, Dino's (https://www.dinostomatopie.com/) -- they did _really_ well, generally, but no matter how hard you try, some things come through: the fonts rendered as text are perfectly crisp at whatever absurd DPI this Chromebook has.

Alright, that's looking like the start of a syllabus, although I may need a guest writer for binary translation (less of that these days, but a friend and colleague was the first employee at VMware, so I'll bug him and see if he wants to write :)

The virtual CPU is (typically) represented as a single OS thread. Depending on how you've configured the virtualization hardware, it may look like a thread that's always runnable, or it may block whenever the guest kernel halts that CPU (while waiting for an interrupt). While the VCPU is running the guest OS is free to context switch what's running there. If it halts, and the CPU has been set up to generate a VM exit on halt, it may take longer to wake it up: and IPI from another VCPU has to hit the host OS, which then has to put the target VCPU thread back into a runnable state, and that thread has to begin running and issue a VMRESUME before the IPI completes. If it sounds like this could have disproportionate performance impact, it can. It works at all because operating systems tend to have fairly relaxed timing expectations (in addition to being largely event driven). Also, virtualization isn't the only source of potential stalls in a modern processor. Consider that a transition from the lowest power state up to a running state can take tens to (iirc) hundreds of microseconds. Generally a pass through the scheduler would be much faster, unless things are contended, _or_ unless the host scheduler needs to wake up a physical CPU -- now the costs compound!

A related problem to consider in the non-virtualized space: the Go runtime scheduling Goroutines onto OS threads. It has to contend with many of them same "is the target thread running" problems, and exhibits some of the same pathologies. Also, once the number of runnable host threads approaches the number of physical threads, the potential for contention, stalls, etc. increases dramatically. Once it exceeds that threshold, it becomes unavoidable. Collectively, all of these issues are commonly filed under the heading of "jitter" -- things that break the illusion of a continuously executing stream of instructions on a computer dedicated just to one thread.

I'd be curious what topics people would find most interesting. The whole COVID lockdown has left me with an abundance of "free" time, and I work professionally in this space (on virtualization for Google Compute Engine). I've been feeling the need to write lately[0]. I know better than to try to tackle a whole textbook, but I'm hoping I could manage a series of blog posts.

[0]: My work has put me in a lot of meetings for quite some time. I've felt a decline in my written communication skills: it takes me a lot longer to write things than it used to, and I'm less happy with the results. Nothing to be done for it but to write!

For any analog engineers in the audience: how would this chip differ if designed and fabricated today (if at all)?

Miles, I can't tell if you're messing with me or just stating what actually happened :)

Right, but Snowmobile is packaged as a shipping container because it has a small datacenter inside, so unless you can fit the assembled 45ft container in the plane, I don't think this works?

Those are big fucking planes, so maybe you can?

Pretty good idea on #3 (and for much much much larger links), and a decent idea for #1.

If I had 1-10 PB to move I could totally see most people using FedEx to ship JBODs around. For small transfers it makes sense, and we also have a product for this. Internally I'd use our WAN for those, which is where this now starts to make sense: Amazon does not have anywhere near the global WAN capacity that we do, nor so far have they had a good reason to have that capacity.

If you've got the global capacity to allow a customer to peer to your nearest location (and your nearest location likely isn't too far away for most of the world), fiber makes sense for large (~EB-scale, which I assume anyone with 100PB+ is well on their way to 1EB+) amounts of data. We have a product for these peerings (primarily for customers in colos): https://cloud.google.com/interconnect/docs/concepts/dedicate...