aij

Ack, yes, I meant 1935. I'm on mobile and typoed that in a way the spell checker couldn't catch...

Even now in the US I have yet to see Disney selling rice under the Mickey Mouse brand in a way that could be at all confused with the Mickey rice in Paraguay that I grew up with.

Mickey was selling foods under that trademark in Paraguay since 1835. When did Disney start competing in that market segment with their Mickey Mouse brand?

> Step one, double the limit to alleviate immediate customer pain.

I've been oncall for systems where that would not work.

Doubling the memory means you need twice as many machines. Depending on the service, that could require significantly increased network bandwidth. Now the network is saturated and every node needs to queue more data. Now latency and throughput are even worse, and even more requests are being dropped, so you automatically double the limit again...

> I've seen plenty of really scalable systems being built by a small core team of people who know what they are doing.

There is huge difference between building a system that could theoretically be scaled up and actually scaling it up efficiently.

At small scales, it's really easy to build on the work of others and take things for granted without even knowing where the scaling limits are. For example, if I suddenly find I need to double my data storage capacity, I can drive to a store and come back with a trunk full of hard drives the same day. I can only do that because someone already build the hard drives, and someone stocked the nearby stores with them. If a hyperscaler needs to double their capacity, they need to plan it well in advance, allocating a substantial fraction of global hard drive manufacturing capacity. They can't just assume someone would have already built the hardware, much less have it in stock near where it's needed.

It's kind of like how an implicit side effect in "normal" FP languages is that memory is being allocated.

The nix garbage collector will even free up disk space by deleting unreferenced packages just like a garbage collector freeing memory by deleting unreferenced values.

I never thought of it as backwards. Defining functions before calling them makes as much sense as defining terms before using them or assigning variables before reading them.

Is that having GCed all but the current generation of packages? Or filtering for a single nixpkgs version some other way?

Even then, I would expect NixOS to do some unsharing of shared libraries, so it would probably be best to use the full path to determine how much each shared object is actually shared.

For example, I have 87 different `libzstd.so.1` in my `/nix/store` right now.

Static linking does not preclude separate compilation though. Go and Rust both use separate compilation with static linking by default (at least last I used them... it's been a while). I know Rust at least used to support dynamic linking too -- it just wasn't the default. And C also supports static linking of course.

Google does hire SREs actually. It doesn't mean dev teams aren't on call also. But dev teams do get paged much less frequently.

You mean it's Newspeak for "running under a supervisor, but without the supervisor running under a hypervisor".

Of course it's better marketing wise to market your products/offerings/capabilities as better than they actually are. Even if 90% of users don't notice the difference, it really shouldn't be surprising that some small fraction of users will notice and will be unhappy.

NY does the same.

But a $0.05 deposit for a can to be returned and melted down as scrap is quite different from a $1.50 deposit for a glass bottle to be returned where it can be sanitized and reused.

If small dairy farms can do the later, why can't Coca Cola? (And why can Coca Cola do it in South America?)

I had heard about tin whiskers, but always in relation to NASA. I had assumed it was only a problem in space, somehow related to lack of gravity and/or atmosphere.

Apparently it's just that NASA cares about reliability more than most, and hence takes the time to do more detailed failure analyses.

Thanks for linking those slides.