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.

Governments have sued DRAM companies for price fixing and forming cartels before: https://en.wikipedia.org/wiki/DRAM_industry_price_fixing. They can absolutely step in and if there are evidence of price fixing or anti-competitive behaviours, can impose fines. The choice of whether to do that though is political.

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!

Yeah per your edit that'd be for 256GB RAM which puts that into serious dollar category. For comparison I checked what AWS asks for for the same spec and that'd be $4616/month (for a db.m8gd.16xlarge), and that doesn't even yield you an actual NVMe. You can of course build the same for cheaper on Hetzner but again then you're on the hook also for the operations of the thing, which at that size is possibly non-trivial.

On Hetzner you will be on the hook for managing the database though, and DBA is most certainly a full-time job if you have a serious use-case for it.

It depends a bit on your cloud provider but some of them have an offering that doesn't always match your needs or their pricing might be much more expensive at equal performance.

You're pointing out exactly what bothered me with this post in the first place: "we moved from microservices to a monolith and our problems went away"... ... except the problems had not much to do with the service architecture but all to do with operational mistakes and insufficient tooling: bad CI, bad autoscaling, bad oncall.

So it's 2025 and we're building more disposable electronics? I'm sorry but I think the EU is not the problem here.

The person you're replying to asked if it was fun. Consider that my sarcasm was meant to be sort of tongue in cheek and not incredibly serious, which is a very different kind of tone from other comments in this chain.

Honestly, if the bus/delivery driver needed a mid-shift break to deal with some life stuff, yeah by all means, I personally think they should be able to do that kind of stuff (though maybe we start by giving them bathroom breaks?). The business hiring them should adapt.

It's called a work-life balance. I know, crazy idea.

Similarly to other replies (but my own opinion): it's not a huge source of revenue today, on a single customer basis, compared to our biggest customers, sure. But our goal is to provide potential customers that can't justify larger scale, 3-nodes databases, something they can build on and grow on our platform. We would never want to pull the rug on paying customers: we want to enable them :-) sure it's not a huge part of our revenue, but that's not the goal. We just want to provide a great product, in a way that's affordable to everyone. You of course don't have to take my word, but I think it makes business sense to do this and not pull the rug. Compare to a free tier where you bleed money in the hopes that customers will end up paying you. Hope isn't a good business strategy right? :-)

(Planetscale employee) This is very different though: it's not a free tier, it's an actual single node DB as a paid product. It's definitely not a good fit for every usecase, but if you have a hobby project it's a great way to start with plenty of room to scale if/when you get actual usage