carlm42

Interesting graphs! Looks like over the last decade it's been mostly flat save for 2020/COVID. Still: GP mentioning that as a "problem" and a sign of a "planned economy" is kind of an odd fixation. As if that money went into a blackhole or something.

Citations needed.

I started as a sysadmin dealing with a Puppet 3 to 5 migration but thanks for assuming and being insulting.

It is easier in that if you have infrastructure already, it's trivial to add this on top. The primitives look also very familiar.

That on its own would be a good incentive for the AI bubble to pop ;-) As others have pointed out though, I'd be keen to see how much of it is gas turbines. I'm also not convinced that energy buildouts are seeing as much interest and by the time they come online prices will already have skyrocketed (that is, after the current skyrocketing).

We don't have enough energy production for massive AI buildouts. New energy capacity will not come online fast. National and regional grids will be stressed contributing to impacts on populations and industries. New energy capacity will be expensive and if carbon-intensive will accelerate climate breakdown. Additionally at current fossil fuel prices, energy prices (will) rise dramatically. Currently planned locations for buildouts are suboptimal at best, horrible at worst and vehemently opposed by local populations. That could be NIMBYISM, but in this case it's probably justified: who would want a noisy, ugly-looking grey cube raising electricity prices near their house? And that's just one angle. There are many more. Nothing to do with "AI will take our jobs", that's a pretty low-effort justification/theory.

The irony is that that would probably be Apple's policy with its own offices if a competitor came up with such a feature.

A single box may have that much resources available, but no software will use them efficiently alone. You end up having issues with NUMA, with your pagetable growing significantly forcing you to deal with hugepages and eventually memory fragmentation, and who knows what other kind of lovecraftian horror coming from the sheer complexity of a single system with that much resources. Turns out scaling vertically also has cost. That's why eventually you still want to scale horizontally. And that's not overcomplicating things for the fun of it, it's just tradeoffs.

Measuring a platform team's productivity in pure "hours saved" is missing a huge point: reliability. If your platform prevents even one outage every month, how much business value and capital are saved? That analysis is utterly absent from this article. It also seems to focus on "LLMs make code cheap" which is a half truth: LLMs make (so far) easy or messy code cheap. I'd bet that there too the analysis on reliability/stability is missing from the author's perspective.

I don't know where you live but I've been able to express myself without any form of approval. Granted, I tend to not encourage genocide or glorify fascist regimes, but that's just me.

Sad that the United States are pushing so hard to encourage the propagation of propaganda & lies. I'm not surprised given their history, but it's sad nonetheless.

My mental model is that each of these covers a different layer of the stack, from lowest to highest:

* hypervisor-framework handles the hypervisor bits, like creating virtual machines, virtualising hardware resources, basically a C API on top of Apple's hypervisor

* virtualization-framework is a higher-level API, meant to make it easy to run a full-blown VM with an OS and hardware integration, without having to reinvent the integration with lower-level primitives that hypervisor-framework provides

* containerization-framework uses virtualization-framework to run Linux containers on macOS in microVMs.

By analogy to not mix them up, it's a bit like KVM > QEMU > containerd.

Hope this helps!