The full scope of things hash functions are commonly used for requires at least four algorithms if you care about performance and optimality. It is disconcertingly common to see developers using hash algorithms in contexts where they are not fit for purpose. Gotta pick the right tool for the job.

TBH, your assertion reads like chemistry word salad. It doesn’t parse.

Supercomputing is another domain that has deep insights into scalable systems that is famously so insular that ideas rarely cross over into mainstream scalable systems. My detour through supercomputing probably added as much to my database design knowledge as anything I actually did in databases.

This is why even above-ground bunkers are almost always buried underneath a giant mound of dirt instead of being bare concrete. It is a cheap structural multiplier that greatly increases the amount of explosive required to damage the insides. It is also very cheap. A bunker buster is a very heavy and specialized munition which limits its scope of practicality.

There are entire civil engineering textbooks that focus exclusively on the types of scenario you are alluding to. It is a very mature discipline and almost all of it has been tested empirically.

I used to have a civil engineering textbook that was solely about the design of structures to resist the myriad effects of nuclear weapons. It was actually pretty damn interesting. Civil engineers have contemplated at length just about every structural scenario you can imagine.

It was how I learned to design code for supercomputers and is remarkably effective at generating extreme efficiency and scalability in diverse contexts. Importantly, it generalizes to systems of every shape and size. While it is difficult to get good results on a supercomputer if you don’t understand this, it works just as well for a random web app.

Many petabytes fit in a single rack and many data sources generate several petabytes per day. I'm aware of sources that in aggregate store exabytes per day. Most of which gets promptly deleted because platforms that can efficiently analyze data at that scale are severely lacking.

I've never heard of anyone actually storing zettabytes but it isn't beyond the realm of possibility in the not too distant future.

With larger virtual memory addresses there is still the issue that the ratio between storage and physical memory in large systems would be so high that cache replacement algorithms don't work for most applications. You can switch to cache admission for locality at scale (strictly better at the limit albeit much more difficult to implement) but that is effectively segmenting the data model into chunks that won't get close to overflowing 64-bit addressing. 128-bit addresses would be convenient but a lot of space is saved by keeping it 64-bit.

Space considerations aside, 128-bit addresses would open up a lot of pointer tagging possibilities e.g. the security features you allude to.

IR missiles must accelerate to ~Mach 2.5 over a very short distance to maintain lock and close the distance for the purpose of air intercept due to the short-range of the guidance. IR seekers are lightweight and compact, which lends itself to quick acceleration.

This short-range performance profile can be maintained with a heavier warhead using a larger, heavier rocket motor. This has cost, weight, size, etc implications but that isn't a reason to not do it in isolation.

The upgraded IR missile is still short-range but now it has a footprint similar to long-range radar missiles and those have a similarly large warhead. It erases the major technical advantages of IR missiles (cheap, light, small) without addressing their major deficiency (short range).

You could build an IR missile with a heavy warhead but it doesn't make much sense. The quick acceleration requirement creates a lot of engineering pressure to reduce weight, which can only be meaningfully achieved by reducing warhead size.

It has never been compute-intensive. Current hypersonic kinetic-intercept missiles use ancient MIPS R3000/4000 class CPUs.

IR is useful for terminal guidance only due to very limited engagement distances at which it can get lock (see also: MANPADS). One of the objectives of non-IR stealth is that it eliminates the mid-course guidance needed for long-range missile engagements, which largely requires radar. Note also that sophisticated "IR-guided" missiles are not "heat-seeking", that is mostly a movie trope. They use imagers that include part of the IR spectrum.

The short range of IR terminal guidance limits the size of the associated warhead. US aircraft are designed and tested to survive being hit with warheads in this size class. An F-35 is expected to eat an IR-guided missile and get back home.

The F-35 definitely saw it coming. The article casually ignores the widely documented base capabilities of the aircraft that make it what it is.

That said, F-35 is an export design with limited IR stealth. The US uses IR stealth on non-export 5th gen designs and all of the 6th gen designs. This was one of the compromises to make the design "exportable".

This places an upper bound on the complexity of the patterns you can learn. At the limit you could spend 100% of resources building a maximally accurate model of a single thing but there are limits to ROI. Pre-digested learning makes it more efficient to acquire heuristics but it doesn't change the cost of representing it.

Some simple state machines are resistant to induction by design e.g. encryption algorithms.

You can't replace the larger simulation required (i.e. more state/RAM) with a faster processor.

This is also a common basis for the concept of "free will": no computer can model its own behavior such that it can reliably predict it.

To a squirrel all humans are equally, unfathomably intelligent.