EricBurnett

Ooh, I'd love that. Or native steam functionality for the same. I never install games onto my SSD for that reason, so I'm at the mercy of whatever windows naturally does in that space. (Possibly nothing, as I don't remember manually configuring a SSD cache file on this computer, and last I checked that was required).

Indeed. https://blog.youtube/inside-youtube/new-era-video-infrastruc... , https://research.google/pubs/pub50300/ . (Search the paper title and you should be able to find the pdf itself elsewhere).

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.)

Googler here, opinions my own, etc.

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.)

My mum owns a small café in Leicester. Her electricity bill has just jumped from £10k ($12k) a year to £55k ($64k) a year.

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.

Thought experiment: between you and the AI, which would do a better job depicting a giraffe skeleton? A giraffe in it's natural habitat? Their favorite tree to eat? Species on the genetic tree closest to giraffes?

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 that the speed of light remains a constant limitation on propagation delay, but the defining limitation on the speed of computation is rather the clock speed - how long it takes for each round of computation. Electrons are comparatively slow due to the time it takes to fill and stabilize a transistor. Our hypothetical new type of computer will have to be faster to converge, rather than faster to propagate.

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 :).

I've long been enamored with the idea of learning from analog computers to build the next generation of digital ones. In some perspective all our computers are analog, of a sort - today's computer chips are effectively leveraging electron flow through a carefully arranged metal/silicon substrate, with self-interference via electromagnetic fields used to construct transistors and build up higher order logic units. We're now working on photonic computers, presumably with some new property leading to self interference, and allowing transistors/logic above that.

"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 :).

If efficiently calculating this mapping is of interest, see also http://www.thelowlyprogrammer.com/2010/04/indexing-and-enume... .

(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!)

'Conflict', not 'combat'. Doesn't have to be physical, e.g. ideological conflict.

Tapes are awkward though, since they can't directly satisfy the same random-access use-cases. E.g. even GCS's 'Archive' storage class, for the coldest of the cold, offers sub-second retrieval, so there's at least one copy on HDD or similar at any time.

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.

Hyperscalars use a blend of storage flavours covering the whole spectrum, and for most data-heavy purposes can mix hot and cold bytes on the same device to get the right IO/byte mix. At which point you can simplify down to _"are they currently buying disks to get more bytes or more IO"_ - if the HDD mix skews far enough that they're overall byte constrained, yeah they'll be looking to add byte-heavy disks to the pool. If they've got surplus bytes already, they'll keep introducing colder storage products and mix those bytes onto disks bought for IO instead.

The recent change, implemented without a formal announcement, is meant to present a variety of skin tones in image queries related to beauty, such as “beautiful skin” and “professional hairstyles,” as well as simpler people-related searches like “woman” or “happy family,” the Alphabet Inc.-owned company said Tuesday.

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.

A good starting point for reading is https://cloud.google.com/security/binary-authorization-for-b... . It also links out to other whitepapers covering different dimensions of the problem.

When it's done right, it seems to work well.

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 :).

That's actually a strategy recommended to ADHD folk: do 20m of engaging "fun" to prepare yourself for 5m of forced boring activity. Think of it as recharging a reservoir of $tolerance before draining it to power some boring activity.

I'm (at Google) one of those "technical leaders" - peer to a manager of ~50 with an informal title of "Uber TL", and no reports of my own. Though for us at least, responsibility still accrues to the manager - I'm a consultant in some sense, with impact through my ability to influence rather than any direct authority.

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.

Relatedly, I'd love to see an experiment in segregating "people managers" from "organizational managers". Imagine having one manager who is responsible for coaching your career growth, helping ensure you have the right opportunities, etc; and another manager who is responsible for the product you work on. You could have lots of people managers for support, and few organizational managers for minimizing org chart depth between products and the CEO.

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.

1) Is it bad?

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.

It depends how you define "simple" : '(ap|ib|ind)ex' is fewer symbols and a smaller character graph.

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.

Very nice! I really like the ease-of-use of this, as well as the scale-to-zero costs. That's a tricky thing to achieve. Seems like it could become a standard path to ease the migration from local to remote builds.

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...

In addition to the aging paradigms of local storage and the perfect/gone dichotomy of in-memory storage of active items, which I definitely agree should go away, we should also prepare for the breakdown of the "local compute" paradigm that underpins it. Discussed in part 2 of http://www.thelowlyprogrammer.com/2021/04/the-rise-of-datace... (note: self link), I'll summarize as _"expect most compute power you use for anything non-trivial to end up being remote"_. The 'fragment' based model discussed in the parent article fits well with this, with the idea that a fragment is not bound to the local computer in either production or consumption, but just a handle to something sufficiently durable for the purpose.

One somewhat perverse detail: MacOS is much more limited in terms of userspace sandboxing options than other OS, because Apple hasn't implemented them. Which makes me wonder what the main entry vectors of all this malware are, and how much it could have been reduced with better constructs available to devs?

Googler here. These people are smart and usually experienced, but don't put them on a pedestal. A lot goes into it - whole teams building the infrastructure with reliability as a core feature, and many hours spent running down all possible single sources of failure (so it usually takes a couple issues together to combine into a big incident). Good monitoring platforms, release systems, etc. Training and practice at incident handling, with many more folk only a page away.

https://sre.google/sre-book/table-of-contents/ is a good source to start with.

And ultimately, the perhaps most critical distinction - opportunity. You only work on a huge distributed system when there's enough customer demand for it to need to exist, and every large system started as a smaller system. That scaling of demand scales importance, which scales the effort invested in its reliability/scalability/efficiency/etc. You can read great stories about the many failures at Google, or Twitter (remember the Fail Whale?), or any other large company. The maturity you see now was developed over time, and any newly hired engineers will be trained into the culture of maintaining and improving it further. With few exceptions, the folk that incepted the big systems back when they were small aren't the ones scaling them out today anyways - it's a very teachable skill, given the need and opportunity.

It very much depends on your clients and the nature of the traffic they send. For a high-volume client, assuming a default of 100 concurrent streams per connection max, this actually works out to <connection establishment>, <50 parallel requests>, <connection close>. Have to ~quadruple your connection count vs what you could have done on one unfettered connection, and every connection will spend 50% of it's time being established.

Some hybrid of count and time might do, e.g. `50 requests AND 1+ minute since establishment`. But it's nuanced - surprisingly hard to find logic that works well in all cases.

An old squirrel nest fell into my lawn a couple days ago, and I got a look at it while removing it. It had five entire plastic bags incorporated into it's structure.

Reuse has to be the key. My tote bags are likely coming up on 500 uses by now, from reusing the same ones every trip for years, and are nowhere near done yet.

Is 1k runnable goroutines materially worse than 1k runnable threads? (Honest question, I don't know myself).

I'd start by making it uniformly enforced, and with no "cliff" where you can go from being unticketed to owing thousands through a calibration change.

In this case, change the ticketing model to have a graduated scale so e.g. going 1mph through a stop sign is $1, going 2 is $3, going 10mph is $100. Ideally, enforce it through technology at all stops. And then anyone who accrues more than say $10 in fines in a month has to pay it, and everyone can see where they are towards that.

And then to make it properly "fair" make it equitable, e.g. ticket costs indexed against your personal income rather than a flat rate.

I'll note that zlib and gzip are approximately the same, with the same algorithm under the hood (`deflate`) but different framing. But if it's working well for your use-case, that's all that really matters - especially over having to deal with C interop.

Depends on selected compressor, but yes, you can. I've definitely observed zstd-1 to be a net savings, where compression/decompression costs were offset by pushing fewer bytes through the RPC and network layers - and this was only from observing the endpoints, not even counting CPU on intermediate proxies/firewalls/etc.

I wouldn't normally expect gzip to be a net savings (it's comparatively more expensive), but depending on compression ratio achieved and what layers you're passing the bytes through, I'd definitely believe it can be in some contexts.

Related tip: anywhere you're looking to deploy compression in a backend, consider zstd (https://facebook.github.io/zstd/). I've found it suitable for streaming compression (Gbps+ flows without exorbitant CPU usage), storage compression (high compression ratios at higher levels; fast decompression), and found implementations available to every language I've needed. It comes out strictly better than gzip ~across the board in my experience, and should be the default compressor to choose or start evaluations from if you have no other constraints.

I don't think it's yet deployed in browsers, so I'm restricting my recommendation to tools and backends. IIRC brotli is worth considering for browsers, but I haven't deployed it myself.