grumbelbart2

> True. But I think "int" would be the right choice anyway in almost all case.

It's the worst choice. int is 32-bit on most 64-bit architecture/compiler-versions that matter.

Which options are there, really? There is re-write, fixing, and mitigation.

We have a lot of legacy code that probably contains many bugs that could be exploited.

We could either stop using that legacy code, i.e. re-write and move to a newer library / package. Or fix the old code.

I now believe that "fixing" the code is actually in reach for an organization such as Google, which has deep pockets, frontier AI models, and a history of working on open source. Spend a few billions to walk through every package that runs on a common Linux installation, find potential issues and robustify the code.

Mostly because we already used all suitable places. It also has a huge environmental impact, large upfront costs that you can only spend in bulk, permissions, lawsuits, protests from the local population and so forth.

> Fixing this issue would require new remotely-operated breakers to be installed, which is costly, and it's hard to justify installing them proactively just in case.

No, the fix for this issue is that the inverter of your local solar installation checks if the grid delivers a 50 or 60 Hz waveform, and breaks if it does not. This is pretty much the standard in any installation today, and it's mandatory whether you declare your installation or not.

Side note, there is recently a push to vary the allowed deviation from 50/60 Hz a bit for each installation. The risk is that if all installations stop delivering at, say 50.1 Hz, then if the grid exceeds that value for some reason, there would be a very sudden drop in supply since all solar installations shut off at the same time.

Some say water is never wet, it makes wet.

How would a single agent work that long, the context window would overflow pretty quickly, no?

It's mostly a scale thing. Transformers scale better when you have a lot of training data. (Not saying CNNs don't scale, but it's way more difficult to tune the hyper parameters).

For smaller training data sizes, transformers don't have a clear advantage over CNNs. CNNs are still the way to go if you have problems that are not too complex, and especially constraints regarding inference costs. Think of a small edge device / sensor that counts apples in your apple picking machine.

What we sometimes see is that a backbone is trained using transformers, then a smaller CNN is destilled from that (DinoV3 for example).

And by buying all of the available compute.

Uranium, Plutonium were created by fusion processes as well. Fission extracts energy put there by the fusion inside a dying star.

But those fibers disturb the crystal lattice of the ice, so surely there is some tradeoff?

It's also other devices. I used to get a notification that my wife's AirPods would be following me. It only got silenced when we formed an Apple family.

I know you are joking, but that is absolutely a possible trajectory. Reliable and cheap LLMs could lead to software that re-implements everything, instead of using libraries.

Did you do —apparent-size?

Battery tech and production methods are still evolving and improving way faster than turbine tech and production. Meaning this is more than just production capacity.

> 99% of people don't backup

This depends on your viewpoint. Using gmail for example is an implicit backup of your e-mails. Uploading your pictures to Facebook the same. The move from local, private compute and storage to the cloud solved this issue for many to a degree that it is now less important.