general_ai

No, you're not going to be a "dinosaur". 99% of extremely well compensated software engineering jobs do not involve ML. Using top large companies as a proxy of what things are going to be like in the world at large 3 years from now, maybe one in 200-300 engineers does anything in any way related to ML there. And that's a generous estimate. You do need to know what it is, roughly, but there's no need to drop everything you're doing and switch careers.

TF is in a fortunate position of having several UIs at this point. It's a lower level framework with a lot of power. If you don't need all that power, Keras or TFLearn or Slim are pretty great. If you do, it's there for you. I see no evidence that Google's goal with TF is to lock you into anything, and especially GCE. I'm a former Google employee, and I can tell you unequivocally — that's not how Google actually works.

It's just that we haven't seen people protesting in the streets for some reason. Hmmm, I wonder why that is. Dropping 100k bombs, killing 2200 people with drones, and toppling several governments sure seems like a bigger deal to me than a 3 month visa ban.

The way I see it, TF is about to pull _way_ ahead thanks to XLA JIT/AOT. All of a sudden you get the ability to fuse things at a much more granular level, which could reduce memory bandwidth requirements by a lot. Frameworks like Torch can't do any fusing at all, since their computation is fully imperative. Tactical win for imperative frameworks, I suppose, but strategically functional graph is the way to go. DB people realized this in the 70s, ML people are realizing this now.

It just blows my mind that Soviet Venera landers were sending digital (!) images back from the surface of Venus in early 80s. This would be a heck of an achievement even today some 35 years later.

Have your lawyer review it. $200 at most.

You only need basic knowledge of physics to see why a high performance car without large radiators would overheat when expending a ton of energy per unit of time. Sadly a lot of people here lack it.

Because if you drive a Tesla hard, battery overheats and it shuts down. Plus once you run out of battery (even if it doesn't overheat) you need several hours to recharge it. Plus Tesla is only "high performance" in a straight line. I believe they had an episode with a Tesla. It ended up on a tow truck.

If I'm working with a paper (i.e. running experiments, writing code) then my workstation. If I'm just reading a paper, then iPad Pro.

They don't use Docker outside Cloud, true, but their container technology is the same as what Docker uses: cgroups. Brought to you by a couple of Google dudes a decade ago.

You're thinking about it incorrectly. Docker is not a VM. Docker is more like a chroot and a set of additional capability restrictions on top. Basically there are several things that are namespaced in Linux. Processes, network, users, IPC, mount, etc. Docker simply manages these namespaces. At a high level, when you fire up a container, a namespace gets created for it. So unless you explicitly tell Docker to expose things from the host, there's only a very limited set of things your container will see. Crucially, everything uses the same kernel, same drivers, etc, and there's zero overhead.

Think of your Linux host as simply a default namespace.

The real news here is that HuffPo agrees with Trump. I thought their editorial policy was to interpret everything Trump says in the most low-IQ and paranoid way possible. Someone needs to call them and ask if everything is OK.

There's security and there's safety. Linux desktop may well be less secure, meaning that it could be successfully attacked by an experienced attacker. At the same time it's far less likely to be attacked, so it's safer, for the same reason as macOS: less marketshare, few people are motivated to learn/research attack vectors.

As a person who's looking to hire people, I'm signaling them the opposite. We use C++ with only a few maximally boring dependencies. And even in C++ we stick to C plus smart pointers, and a very occasional class where it makes sense.

But that's just Windows. What you can get a Google is a full test run over _everything_ that your change affects. This lets you ensure that an obscure change in behavior will not break others, including products built using your library as a remote, transitive dependency. You also get to fix bugs globally. Say you had a really shitty internal API that was causing problems or slowing things down. You get to actually go in there and change that API, and update callsites in one atomic commit. You can also make sure that you're not breaking anyone's build or tests by introducing your change. There are teams at Google whose purpose in life is repo-wide "code cultivation". Finding issues and fixing them globally basically. This just doesn't happen at MS.

Says there it uses sqlite.

Be that as it may, it's a relatively obscure and quickly changing language, that _ends up calling into C_ anyway.

designed for embedding

Yet implemented in Rust. Why? If you want adoption, the best way to design something "for embedding" is to write it in C.

And I guess we should just forget about Forest Brothers and stuff, amirite?

Whatever is already public. You can watch a video about Piper and some other systems on YouTube, and read about other things from Google's own blogs, papers, etc.

Dunno how it is now, but years ago it'd take them a _few weeks_ to just propagate commits into the stable branch through a series of elaborate branch integrations, so yeah, you couldn't change something and test it on a whim. Plus build of just windows alone would take overnight, and rebuilding everything to test a Windows change was not logistically, politically, or technically possible.

+1. I know some insiders at MS and their build/test/deployment story is universally very crappy. Things barely work, held together by curse words and duct tape.

Googlers like to joke internally that Google looks like a race car from the outside and like Moving Castle from Hayao Miyazaki'a cartoon from the inside, but that's not the case at all. Comparatively speaking it's a race car inside and out, it's just that the insiders don't know how shitty things are elsewhere.

P.S. I heard Bing is different, but I have no visibility into it, so can't comment.

I know. :-)

perforce model is far inferior to git's

That's just, like, your opinion, man. There are other bits of infra that integrate with it quite nicely, and would integrate with something like Git quite poorly. One of those things is their code review system. The closest thing I could find to it outside Google is Gerrit, but it's a tremendous pain to set up and use, and it's but a pale shadow of Google's internal tool (Critique).

And also, one does not preclude another: Google has a git wrapper on top of Piper, so you can spend your entire Google career not even touching Piper directly if that's what you prefer. And Piper went beyond the "Perforce model" in ways I can't disclose here.

Because very few people have a need to support a billion-LOC monorepo on which 30K engineers make tens of thousands of commits daily. That's where this system shines.

For smaller projects, Git+Bazel (open source, non-distributed version of Blaze) works fine if you're working with C++, and other build systems work OK as well, if you're working with other languages.

Google is far more advanced than this. They have one giant monorepo (Piper) that's backed by Bigtable (or at least it was, when I was there). Piper was mostly created in response to Perforce's inability to scale and be fault tolerant. Until Piper came along, they would have to periodically restart The Giant Perforce Server in Mountain View. Piper is 24x7x365 and doesn't need any restarts at all. But the key bit here is not Piper per se. Unlike Microsoft, Google also has a distributed, caching, incremental build system (Blaze), and a distributed test system (Forge), and they are integrated with Piper. The vast majority of the code you depend on never actually ends up on your machine. Thanks to this, what takes hours at Microsoft takes seconds at Google. This enables pretty staggering productivity gains. You don't think twice about kicking off a build, and in most cases no more than a minute or two later you have your binaries, irrespective of the size of your transitive closure. Some projects take longer than that to build, most take less time. Tests are heavily parallelized. Dependencies are tracked (so tests can be re-run when dependencies change), there are large scale refactoring tools that let you make changes that affect the entire monorepo with confidence and without breaking anyone.

Google's dev infra is pretty amazing and it's at least a decade ahead of anything else I've seen. Every single ex-Googler misses it quite a bit.

I wonder if they're still using Google AppEngine, or have moved to something lower level. GAE resolved a lot of its scalability and isolation issues thanks to Snapchat.

In a way, Snapchat was to GAE what Hotmail was to Windows NT back in the day — trial by fire.

As far as I can tell from available news, no one "struggled" worth a damn to create a safe environment. In fact the opposite seems to be true: police was ordered to stand down, inviting the situation to get out of control.

Fake news. Antifa thug was shot by a man whose identity or political affiliation hasn't been disclosed, in self defense. How do we know it was in self defense? UW police said so, after releasing him.

That wasn't a protest. That was a riot. Let's call a spade a spade for once. I dont't expect much from Jeff Bezos's personal blog, but here on HN standards should be higher.