jsolson

Xilinx's tool suite works quite nicely on Linux, and there are excellent "starter kit" FPGAs from some of their partners. I have nothing but good things to say about the Arty line of boards from Digilent (I own one or more of each of them). As you start to approach the higher end of things with larger designs, the boards from Xilinx begin to become your best option unless you've got connections. Note that for small-ish designs the Artix 200 has a reasonable amount of space, and you can simulate and implement for anything up to the Kintex UltraScale+ 5 (including things that don't actually fit in the 5, for simulation) using the same free-as-in-beer WebPack license.

Google still has the notion of release branches. They're point-in-time snapshots of the monorepo (copy on write), plus the occasional cherry-pick from HEAD.

Development happens at HEAD is the important part.

That was my observation as well. I find the quality of work goes up dramatically when people are invested personally in the success of their part of it. "Signing up", to me, is about committing to that sort of investment, and it's the signal I look for to know if a team is going to be healthy. Not having that signal is a two-way street, though -- sometimes the answer is to restructure the work overall so that the pieces align better with what team members will sign up for.

I am a software engineer who's been involved in the tapeout of a few ASICs (although none of the TPUs). Particularly when you plan to build a series of chips, the continuous approach taken by software is massively preferable. X v2 does what X v1 did, plus some additional things, and with all of the errata fixed. Also, you find the errata in X v1 after tapeout but before your driver team does, saving them an enormous amount of work trying to track down a driver bug that's actually a HW bug (maybe even one with a simple workaround).

This is amazing.

Make sure to view it on a sufficiently wide browser to see the ASCII art of a torn piece of punched paper tape.

This conversation would be better continued over corp hangouts or e-mail -- as I said, my username is in my profile.

Indeed, and even stranger arrangements. I know one professor who comes to work for us every summer (with hilarious HR boundary condition consequences every year).

Google employs a non-trivial number of former university faculty as engineers...

So don't give that sort of interview; give one you wouldn't walk out of where, if it goes well, you'll be able to write a compelling argument about why the candidate should work at Google, and if it doesn't go well you'll be able to write about where the gaps are.

Feel free to ping me on IM (username is in my profile) if you'd like to talk about how to do this in a way that helps hiring committee make informed decisions.

Yes; it enables tens of thousands of developers to work on a monorepo with billions of lines of code across over a billion files and generally be able to move between parts of that codebase without surprises. It promotes re-use, and simplifies refactoring useful utilities from one-shots into general libraries.

Speaking for myself as an engineer who works in that codebase, I rarely find it gets in my way, and when I've felt exceptions were the clearest/best approach, I've not found it burdensome or difficult to justify them.

It's challenging to think about how things will scale beyond out immediate stellar volume, though. We have so little high quality data.

Or did you think "systems" ended at some smaller scale? ;)

Altera was acquired by Intel.

Xilinx was not.

Honestly for what I'm doing what you have here is a pretty reasonable start. I'm comfortable writing (and calling into) C where the Go bits aren't in place yet, and I'm a lot more familiar with LLVM's internals than with GCC's if I need to debug something. We'll see what I get up to after brunch.

One request: if you're open to PRs (I can't promise I'll send any, but I'm trying to get into a habit of contributing to OSS with my hobby hackery), can you add a LICENSE file (context: the OSS patching policy I'm bound by is very friendly for projects on Github under most licenses -- https://opensource.google.com/docs/patching/ -- it's more problematic when the license for the code is undefined)?

In my case I was less interested in the WASM part of it than I was in something targeting a "no OS" environment. That said, for my target (those little Pine64 RTL8710 Cortex M3 MCU) you're almost certainly right. On the other hand it's a hobby project, and I like writing Go while I find writing Rust to be a bit of a chore. Also, it's a hobby project, so distractions like re-targeting WASM to the ARMv7-M are half of the fun :)

I suppose it's not strange to see WASM come up -- last weekend I was considering doing something even weirder: writing a WASM to Thumb2 AoT compiler so I could leverage Go's built-in WASM support.

This project seems more immediately useful :)

Start simple: find a list (with answers). Don't try to "solve" them, just read the questions and try within a minute or so to name a data structure or algorithm -- something you'd expect most undergraduate intro classes to cover -- that seems likely to be part of the solution. Check your work, keep track of which ones you got right/wrong, and move onto the next question.

Re-visit the ones you got wrong first. Try them again, repeat until you've gotten them all right (this might just be because you remember the solution from looking it up, that's fine, you'll have plenty of time to forget by the time we get back to it :).

Now, revisit the ones where you had the right data structure on the first go. HOW would that data structure help? Go a level deeper on actually trying to solve it.

I can't guarantee this will be fun, but it should be fast. A few minutes here on there on any given problem, going one level deeper each time you visit it.

Eventually you'll have the whole algorithm for one of the problems, likely using some common data structure like a hash map, tree, or heap.

Code it in a language with a good set of algorithmic primitives, use every tool the library gives you (don't worry about remembering how the data structures work on this pass). Hopefully with the whole algorithm in mind and all of the tools at your disposal, this is "just plumbing".

Rinse, repeat.

Somewhere in there, do the same with the complexity analysis (time and space!).

Next time, try it where you have to build the data structure by hand.

Then one day you'll see a problem not on your original list, and you'll immediately think "red-black tree with a hash table lookaside buffer, but I wouldn't want to have to build the RB tree by hand if they asked me to, so AVL tree because the complexity is the same and I can bang out the code like it's what I do every morning before breakfast".

Like I said, it might not be fun (at least at first), but it is a way to break up the practice into digestible chunks. Also it builds on the strategy that I've seen work best in interviews -- if you treat each step of iterative deepening of the solution as a point where you'd talk with the interviewer about what you're thinking and why, you give them a lot to go on about your thought process and a chance to course correct if you misunderstood the question or your heuristic for how to approach it simply came up wrong.

This had never occurred to me as something someone might do.

I cannot do this thing, as I don't open my desk drawer very often, and a banana is exactly the sort of the sort of thing I would forget about. I'm thinking through how this would play out for me, and it's unpleasant for all involved.

"Do you want ants?! Because that's how you get ants!" — Archer

Note: mix of facts and opinions ahead; the facts mostly boil down to "all of these technologies _are_ used within Google"; the opinions are my own thoughts on what our internal future looks like. Other Googlers may see a different future or different reasons for the status quo :)

We do use gRPC internally, but the bulk of services were built prior to its existence/maturity and use its predecessors. My expectation is that services will eventually migrate, but that's a long way out. I'd say it's less to do with performance than a clear reason for teams to migrate, and several compelling reasons not to (yet).

Bazel is mostly a subset of Blaze, and many packages would "just work" if pulled into a Bazel workspace. Those that wouldn't are mostly broken because they rely on proprietary (but in many cases deprecated) Blaze features. I see a handful of changes go by every week migrating packages to newer Bazel-friendly definitions (a big one here is the historical handling of proto_library rules).

Kubernetes is used for some things built on GCP, but that's mostly suitable for green-field work (it's easier to integrate with existing things on Borg if you just run on Borg).

Single-planet redundancy isn't a problem until it's a _really big_ (say, inescapable) problem.

I'd put good odds on us wiping ourselves out or being wiped out before we manage to put a sustainable stake in some other chunk of ground.

Also $400B/yr is great if you can make use of it. Do we have the intellectual and facility resources to make use of that sort of windfall today? Probably not. Could more money go to cancer research for immediate positive effect? Probably, although working out the logistics for how best to direct that funding requires resources of its own (which is of course the sort of work the Gates Foundation does).

I once had an interesting argument about Learning Perl.

The first chapter, when I picked up the book, was a tour of Perl. I loved it. It showed me all of the highlights with no details at all. I never read another chapter, and instead picked up the second book in the series to use as a reference.

My counter in this argument HATED that first chapter. They almost didn't read another one, because it put all of these examples in front of them with no depth. They thought the book would be much improved by removing that chapter.

I would have been bored to tears by the book this person wanted to read.

I'm not going anywhere in particular with this, except to say that the world takes all kinds. Sometimes docs don't exist simply because nobody realized someone else would find that shape of document useful, so they decided not to write it.

The docs I love may well be the docs you hate :)

As mentioned in the post (which is from 2016), Google has also been experimenting with Mercurial as a frontend (in collaboration with "contributors from other companies that value the monolithic source model"). As an avid user of that experiment at Google, it's seems to be going very well.

Lots of bits of KVM turned off, though. Makes it really interesting when I work with people on Open Source stuff. I find out all sorts of things KVM can apparently do that mostly leave me going "you put WHAT in host ring zero?!" :)

(note: as implied, I work on our userland QEMU replacement)

Even extremely basic commands are routinely misunderstood by humans, too.

With the human you can have a conversation that will hopefully avoid similar confusion in the future which eases the frustration for many. How long before machines allow us to do the same? My bet is months, a year or two at the outside. After all, we already have conversational interactions. Building on those and tying an intent interpretation to a clarifying correction provides high information training data. There's already a swath of old, well understood ML techniques -- mean subtraction, singular value decomposition, boosting, etc. -- aimed at differentiating information from data. Instantaneous classification of responses as errors followed by information on a better response? That sounds like training gold.

DPDK's drivers are (as far as I know?) all poll-mode: https://doc.dpdk.org/guides/prog_guide/poll_mode_drv.html

I bought a sailboat. Similar effect, but lower carbon emissions.

Clear Containers has merged into Kata Containers -- gVisor offers a different set of tradeoffs than Kata (or CC). The big one is resource footprint -- gVisor will typically be lower, often much lower than Kata. On the other hand, for very syscall heavy workloads Kata needn't take exits (while gVisor exits for many syscalls that make it beyond the sandbox), so performance on gVisor will have higher variance with respect to syscall rate. Kata also offers the opportunity for sandboxing things like kernel driver blobs (since you get a whole new Linux ring 0) while gVisor relies on the host kernel for many tasks.

There's a lot of overlap between cgroups, gVisor-style sandboxes, and VM-style sandboxes like Kata. The tradeoffs between them are mostly with respect to compatibility, robustness of the security boundaries, and performance. So, you know, the usual suspects.

We've reached a stage where we probably need better vocabulary for describing these tradeoffs :)

(I work on "near" the gVisor folks at Google, and I'm involved in the Kata community)

Ooof. Stephenson is among my favorite authors. Before Seveneves that wouldn't have had a qualifier. I re-read Cryptonomicon every year or two, the baroque cycle about half that frequently, and Anathem a couple times now. I own Snow Crash and The Diamond Age in first editions. I cannot imagine re-reading Seveneves; it was both not a totally flawed plot (a quality I can ordinarily forgive in a Stephenson novel -- I love a good yarn) and it killed everyone I know and love, in an immediate near future sense, on the page in front of me.

It was, for lack of a better description, a callous novel.

I saw the presentation for their paper at NSDI last week. I was (inwardly) giddy the whole time. They had a live demo. It doesn't even resemble something that could be turned into a real product in the near term. It is, despite that, comically amazingly cool tech.

If you (or the parent) are interested in some details about that ridiculous technology, there was a paper in NSDI this year: https://www.usenix.org/system/files/conference/nsdi18/nsdi18...

(disclaimer: I'm one of the many authors on the paper, although for building parts of the underlying tech, not writing the prose)

> (whole-slide scanners are a bit expensive)

Huh... Why? It _seems_ like a problem with an easy (and cheap) solution, given how readily available (and cheap!) suitably precise cartesian bots are these days, combined with high-quality digital microscopes and the state of modern image alignment algorithms.

What am I missing here?