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.

Ensuring a code base indefinitely supports arbitrary architectures carries a substantial code architecture cost. Furthermore, it is difficult to guarantee testing going forward or that the toolchains available for those architectures will continue to evolve with your code base. I'm old enough to have lived this reality back when it was common. It sucked hard. I've also written a lot of code that was portable to some very weird silicon so I know what that entails. It goes far beyond endian-ness, that is just one aspect of silicon portability.

The expectation that people should volunteer their time for low ROI unpleasantness that has a high risk of being unmaintainable in the near future is unreasonable. There are many other facets of the code base where that time may be better invested. That's not "anti-portable", it is recognition of the potential cost to a large base of existing users when you take it on. The Pareto Principle applies here.

Today, I explicitly only support two architectures: 64-bit x86 and ARM (little-endian). It is wonderful that we have arrived at the point where this is a completely viable proposition. In most cases the cost of supporting marginal users on rare architectures in the year 2026 is not worth it. The computing world is far, far less fragmented than it used to be.

It really sucks that so much of that catalog is no longer available for all intents and purposes.

Most other elements don’t seem to matter too much. Baroque, industrial, ambient, etc are all effectively equivalent in most regards.

That said, I tend to lean toward 1990s atmospheric drum-and-bass (pretty much anything released by Good Looking Records) as a good default. That genre maximizes things that seem to help while minimizing things that seem to detract.

I am against all conscription on principle but I know why militaries made the pragmatic choice to selectively target men even if I don’t agree with it. These things have been studied to death, been put into practice by many countries, and the solutions are all quite bad in their own way.

Strict gender-blind standards drives strong gender segregation by role which in practice produced adverse second-order consequences. Also political blowback in a number of countries because the roles most women could qualified for in practice were perceived as lower status. Unequal standards create a whole raft of other social and operational problems.

To put it another way, all of these problems exist even in the absence of conscription.