That’s an economic concept, not a dig at consumers. It’s well known (hell, there’s a nobel laureate for it) that humans are irrational when it comes to economics.
Weirdly, I live in a somewhat rural part of Brazil, and all providers are small players. They’re all offering 1Gi FTTH and are now competing on price. Meanwhile, the closest metro area still suffers with cable internet topping at 600M and low availability.
Some big cities have seen a surge of small providers too, which has been great for consumers.
That said, I dont buy the “natural monopoly” argument at all, especially trying to compare it to water supply.
That doesn’t align with my experience. It feels more like a trojan horse. Client and Server rarely (should) share code, and people that are really good at one discipline aren’t that good at the other. Maybe LLMs will change that.
The company in question profits heavily from the open source nature of LibreOffice. They're a big government vendor in Europe, mainly because their codebase is perceived as open source.
Reasons 1-3 could very well be done with ClickHouse policies (RLS) and good data warehouse design. In fact, that’s more secure than a compiler adding a where to a query ran by an all mighty user.
Reason 4 is probably an improvement, but could probably be done with CH functions.
The problem with custom DSLs like this is that tradeoff a massive ecosystem for very little benefit.
That’s just not true at all. Even if 100% of the population keeps 2x guns at home, at 9.5M people that would mean 19M guns. The US has more than 20x that many owned by civilians.
That’s exactly how it has been working for me in code. I have a bunch of different components and patterns that the LLMs mix and match. Has been working wonderfully over the past few months.
No, it isn’t that simple. Who bears the most weight depends on the elasticity of the curve on each side. This is confirming demand is more inelastic, which causes it to bear the burden, but could have been the other way around.
No a k8s dev, but I feel like this is the answer. K8s isn't usually just scheduling pods round robin or at random. There's a lot of state to evaluate, and the problem of scheduling pods becomes an NP-hard problem similar to bin packing problem. I doubt the implementation tries to be optimal here, but it feels a computationally heavy problem.