I'm not actually sure on balance how much transcode gets done in hardware vs software, since it's also very amenable to using batch compute that's otherwise idle. I'll guess that most or all live transcoding - streams, on-the-fly transcode into formats not pregenerated - are done in hardware, and transcoding new formats for the back catalog are probably done on a mixture of mechanisms where and when capacity is available. (Source: Googler, not on YouTube though.)

From my perspective, Bard went from "literally didn't exist" to "released" over the course of about a month. GP seems correct in that it very much felt like something picked up off the shelf, slightly dusted off, and released. Is it as good as chatGPT? From my testing, no. Is it the pinnacle of what Google can create, given motivation? I'm pretty sure also no. In comparison to the state of all the research papers Google and Deepmind release, it definitely feels rushed. So I'd suggest not judging Google on its initial fast -follow project: either Google will come out with something compelling in the next 6mo or so, or we can conclude it really was leapfrogged and has fallen behind. But judging it now seems a bit too conveniently pessimistic, IMO.

(There's a legit chance Google will flub this, don't get me wrong. It's just too early to properly conclude one way or the other.)

> Callum's mum may try to avoid shuttering her doors by raising her prices by more than 5x but that will result in $13 chocolate crossiants and $20 iced lattes.

What kind of flawed reasoning is this? The net prices will only have to go up 5x if the price is the product originally was 100% covering the cost of electricity. In practice, it'll probably need to go up something <2x to maintain the same profit margins, with other costs (e.g. wages, property) trickling up at a slower pace (years) as the overall economy adjusts. Which is material, no doubt, but let's not lose ourselves to hysteria here.

If we assume this AI or a successor can win that evaluation, in what way would you say you know what a giraffe is better than the AI?

You're right about the bit flips though. I don't know if a gravitational wave computer is actually ever going to be feasible, just an interesting dream for the far future. Hopefully there are more options to consider in the meantime :).

"Wires" are a useful convenience in the electron world, to build pathways that don't degrade with the passing of the elections themselves. But if we relax that constraint a bit, are there other ways we can build up arrangements of "organized flow" sufficient to have logic units arise? E.g. imagine pressure waves in a fluid -filled container, with mini barriers throughout defining the possible flow arrangement that allows for interesting self-reflections. Or way further out, could we use gravitational waves through some dense substance with carefully arranged holes, self-interfering via their effect on space-time, to do computations for us? And maybe before we get there, is there a way we could capitalize on the strong or weak nuclear force to "arrange" higher frequency logical computations to happen?

Physics permits all sorts of interactions, and we only really use the simple/easy-to-conceptualize ones as yet, which I hope and believe leaves lots more for us to grow into yet :).

(Python isn't my usual language these days, but this is a great example where the seamless bigint support shines. The number of possible sets grows fast!)

Tapes are suitable for tape-oriented async-retrieval products (not sure if any Clouds have one?), or for putting _some_ replicas of data on as an implementation detail if the TCO is lower than achieving replication/durability guaranteed from HDD alone. But that still puts a floor on the non-tape cold bytes, where this sort of drive might help.

How is this not what you searched for? Is there an implicit constraint you think Google should be applying?

Note that search results have long favoured giving you an intentionally diverse selection of results in ambiguous cases, so you can narrow down for what you want more easily. Otherwise you'd probably get 12 different images of whoever the most popular celebrity is, which is probably not the most useful result in practice.

I think this is the most interesting truism of leadership. Which leads risk averse companies to minimize the harm a bad leader can have, and utilitarian companies to maximize the expected value - even when that results in tolerating terrible managers. I don't honestly know which strategy I prefer.

> ...is that it keeps a company from hemorhaging technical experts who have little interest in people managing.

In our defense, it's not quite that simple. I personally can and will write code in any product in my scope, often at the behest of an ongoing incident where the team in question lacks the necessary experience to get themselves out of the situation they find themselves in. E.g. breakdown of some communication protocol, backend knocked offline by a firehose of retries, corrupt database. But even more, my job is to _prevent_ incidents, whatever that takes. Over the last ~year I've concluded that a lack of sufficient staffing prevents any good long term future, and so my main (self imposed) project is evangelizing leadership for headcount. Primarily through the lens of technical arguments - I can tell you which systems will hit fundamental scalability limits first (that aren't being invested in!), and also the individuals across the org that are at highest burnout risk from toil.

Am I an architect? Sometimes. More often I'm a janitor. But most of all, I spend an inordinate amount of time understanding the technical product of hundreds of engineers, to be able to speak to any part of it.

And what does that qualify me for in terms of organizational responsibility? I have no clue :).

I'd love to see the end of this road, if other companies have taken it further. I personally offer guidance to the TLs in my scope (and that of my director, to a lesser extent), but have no technical leadership above me. And I think that's where it gets really hard - finding folk capable of being TLs for say 500 to 1000 people is hard.

Of course, in some places this approximates the split between PM and eng. I don't have great breadth of experience, but I haven't seen that work amazingly... though admittedly, more from PM churn issues than necessarily fundamental infeasibility. But still, it might not be as simple as that.

Yes and no. It's hard for any given manager to support a large team - managing too many often results in either burning out, or being very hands-off with the team... limited career coaching, limited knowledge of the individual context, etc. And it's somewhat worse at higher levels of middle management, where the individual is responsible for aggregating the needs of between say 2 and 25x that of the managers below them.

Of course, it's not that simple. avg 5 reports vs 10 is only 1 or 2 on org chart depth, but almost 2x on the number of middle managers. (And so 3 sounds particularly bad, if you're 'average').

If middle management is growing because the company is growing, that's probably fine, including resetting after large growth in the lower levels. If it's growing because fan-in is reducing, that's more of a concern... possibly managers are becoming lower quality, or there's a lot more top-down burden, or individuals are becoming harder to manage (for many reasons). None of those are great signs.

There is no offside in golf...yet. But the rules are surprisingly long, and will only get longer as loopholes are found and exploited. Humans trying to codify a game, or any system, cannot do so precisely; others can and will find the gaps between the written rules and the intended meaning, and play a different game but pretend it's the same. Or I guess, every game is a language game?

Which I think is a point of meta rationality: we can't avoid including questions of the rules of the problem. It's clouds all the way down.

If the author is interested in standardizing the same, I'd suggest implementing the REAPI protocol (https://github.com/bazelbuild/remote-apis). It should be amenable to implementing on a Lambda-esque back-end, and is already standard amongst most tools doing Remote Execution (including Bazel! Bazel+llama could be fun). And equally, it's totally usable by a distcc-esque distribution tool (recc[1] is one example) - that's also what Android is doing before they finish migrating to Bazel ([2], sadly not yet oss'd).

The main interesting challenge I expect this project to hit is going to be worker-local caching: for compilation actions it's not too bad to skip assuming the compiler is built into the container environment, but if branching out into either hermetic toolchains or data-heavy action types (like linking), fetching all bytes to the ephemeral worker anew each time may prove to be prohibitive. On the other hand, that might be a nice transition point to switch to persistent workers: use a lambda backed solution for the scale-to-0 case, and switch execution stacks under the hood to something based on reused VMs when hitting sufficient scale that persistent executors start to win out.

(Disclaimer: I TL'd the creation of this API, and Google implementation of the same).

[1] https://gitlab.com/BuildGrid/recc

[2] https://opensource.googleblog.com/2020/11/welcome-android-op...