This is the way to go.

China cracked the pollution issues of burning trash, and built a lot of high-temperature incinerator to burn trash and generate electricity.

The overcapacity leads to a shortage(!) of new trash to burn, and it has started to dig out landfills accumulated from the past decades.

The video from Asianometry is very interesting: https://www.youtube.com/watch?v=AuIEBSb2xiE

what's the latency when someone pressed the button and you hear the bell?

I was going to ask, because any latency means picking up packages at a random pick-up point.

My office is in the other end of the house, and most package delivery service press the doorbell and starts working away instantly. While that's also a bit extreme, I can't expect them to stand around for more than ~30 seconds.

It's just a few seconds and a lot of that is the HA polling interval.

for me its (length of wire/signal propagation speed through copper wire) + (distance from buzzer/speed of sound)

For the time spent finding the ethernet adapter, plugging the cable, configuring IP addresses, and testing with pings, any decent portable SSD drives should have finished copying tens of GB of data.

As the article says,

> Removable storage is quite slow unless you are willing to spend a lot of money.

An SSD good enough to copy tens of GB quickly is not cheap.

At this particular point in time, yes SSD is expensive. But 5~10Gbps USB 3.0 SSD had been very affordable for a long time before 2025.

Unluckily for us, and the author at the time of writing, we're in 2026.

You can still get a drive that will beat the ethernet connection by a lot for $50.

But also I'd feel weird if I didn't have at least one good flash drive somewhere, so anyone like me would already have it.

I'm going to ignore the part where the USB port described in the article sounds broken. A 100% functioning cable, especially a short one for a drive, is not hard to find.

If you haven't yet got any portable drives in the drawer, chances are high that you rarely need to copy large amount of files around anyway. In which case free tier of cloud sync services would be preferred for the majority of users.

Unified memory is about address space. The bandwidth is still determined by bottlenecks to the processor. CPU/RAM links are still fairly narrow.

> because all those cheap smart home things like roku sticks and pet feeders and so on are built for cost and a decent 5Ghz chip is just too much to ask.

Cost certainly is the primary factor in the decision, but you definitely want those low-bandwidth but long-range devices OFF your precious 5GHz band.

Unless you want the same crappy experience of 2.4GHz band in 5GHz.

When talking about network bandwidth, it is custom to measure in bit-per-second therefore the "bps" notation. If you convert to bytes, it is highly recommended to use "b/s" notation instead, i.e 150MB/s, to avoid confusion.

Thanks, I'll make sure to use B/s in the future.

> with Wi-Fi 7 reaching a maximum theoretical throughput of 23Gbit per band

Note to tech reports: do not EVER quote this metric as it is the most useless piece of information.

"per band" is also hilarious, as if you could get that kind of data rate in 2.4GHz

It's slightly better than the aggregate number :p

> inherited from 10 levels of parent classes

This is not (yet) a thing in Go. Go does not have classes and inheritance. Interface is more like duck-typing.

But you can do equally horrible inheritance-y things with embedded structs.

That’s composition, and it’s not really the same as inheritance

Yes, though it's non-idiomatic and in my experience, rare to encounter in the wild for anything you'd actually want to use.

That's right, embedded structs in Go are far less common than inheritance in Java though.

There's a asymmetry here that "-R" works both for reverse static and dynamic (using SOCKS protocol) forwarding, but "-D" is required for dynamic forwarding which "-L" cannot do.

Why is that?

It's historical. Some older flags could be easily extended for dynamic port support and others could not.

Are you sure? I thought it's just AES without any authentication.

Yes, it's AES with a tweak based on the physical address. It adds some protection from RowHammer and the like because flipping a bit in encrypted memory is catastrophic, while it can be done in a controlled manner if it's not encrypted.

Whether you get controlled bit flip depends on exact encryption mode used. Haven't seen any document with enough technical details on how exactly their encryption scheme works.

Many of traditional block cypher encryption modes do `cypher_text = plain_text ^ block_chypher_output` with the differences being what goes into block cypher input. This means that single bit flip in cypher text maps 1:1 to bit flip in corresponding decrypted block (and sometimes uncontrolled flips in next block). For malleability prevention full protocols would use MAC in addition to encryption. That's not very practical for memory encryption. Ability to use of various chaining modes is limited since you don't want to re encrypt whole ram when single byte changes or otherwise reduce parallelization of ram processing. Only traditional mode which doesn't degrade parallelization is counter mode, but that's fully susceptible to controlled bit flips. Maybe they can use chaining at cache line or cache block level.

This made me think. If the memory controller is already implementing encryption with limited chaining at block level. It wouldn't take much more additional resources to include hardware MAC as well, thus providing much stronger error detection (not correction) capability compared to typical ECC. The fact they aren't advertising it makes me think they aren't doing it, thus using some kind of counter mode variation and thus no extra bitflip protection.

Surely ECC already does that. You don't need encryption.

ECC just makes it take longer to find the right conditions for Rowhammering. You need to flip more bits in one go to override ECC integrity checks.

Not that common on consumer hardware.

well, not NOW

Which encrypts each cache line with a key unknown to the attacker. This means an attacker can't target individual bits. Every change affects at least one AES encrypted block. It's much stronger than any normal defence against row hammer in that regard because flipping a single bit in plaintext changes ~half the bits in the ciphertext. It's similar to how Apple uses always on disk encryption instead of the normal means to limit run length in their NAND flash controllers. If the encryption is "off" it just means the decryption key is stored somewhere in the trusted enclave.