Hacker Newsnew | past | comments | ask | show | jobs | submit | lclarkmichalek's commentslogin

There's also the converse argument, to governments that look to infrastructure as the secret to all prosperity - America succeeds without infrastructure, somehow.


Natural monopolies exist, for sure. Your insurance example is odd though - insurance markets are generally highly competitive. The recent cases where we’ve seen a loss of competition in the market (CA home insurance, for example) have been driven by regulators imposing price controls.

The issue with healthcare is that providers have leverage over insurers, not that there is a lack of competition for insurance.


No, the problem with insurance is not that providers have leverage over insurers. The problem is that people buying insurance have imperfect information about what that insurance will and won't cover when they buy it. Even after you get insurance trying to find a list of things that are covered if impossible. Even if you call the insurance company, they won't tell you.

How is a discerning buyer supposed to choose insurance based on anything but price when that is the only information available?

Then there's the entire bureaucracy that is medical billing. You have to know which obscure codes for diagnosis can be used with which, similarly obscure, codes for treatment. None of those codes ever exactly match what is happening to the patient, so you have to choose one that is close enough and hope the insurance agrees.

You ever wonder why it takes 6+ months to get a medical bill? That's why. It has to be processed by the medical billing bureaucracy until it bears only the slightest resemblance to reality and then shuttled back and forth between the provider, the insurance filing system, and the insurance underwriter. Only once that is done can they send you a bill.

How much cheaper could providers offer service if they didn't have to pay dedicated staff to play some perverse game of telephone with the insurance company?


The usual issue is the addition of control loops without much understanding of the signals (CPU utilization is a fun one), and the addition of control loops without the consideration of other control loops. For example, you might find that your cross region load balancer gets into a fight with your in-process load shedding, because the load balancer's signals do not account for load shedding (or the way they account for the load shedding is inaccurate). Other issues might be the addition of control loops to optimize service local outcomes, to the detriment of global outcomes.

My general take is that you want relatively few control loops, in positions of high leverage.


What does this have to do with the topic being discussed?


Because it is about people speculating on events that seem connected to their own experience, but in actuality aren’t, because they don’t understand the breadth of the distribution of the abstraction they are discussing.

This happens when your terms are underspecified: someone says “Netflix’s servers are struggling under load” and while people in similar efforts know that basically just equivalent to “something is wrong” and the whole conversation is basically esoteric to most people outside a few specialized teams, these other people jump to conclusions and start having conversations based on their own experience having to do with what is (to them) related (and usually fashionable, because that is how most smaller players figure out how to do things).


In short, people with glib answers tend to rely on over simplified models that don’t reflect reality.


It does happen in prod. Usually due to virtual FSes that rely on get_next_ino: https://lkml.org/lkml/2020/7/13/1078


That method is wrapping and not checking for collisions? I would not call that a problem of running out then. It's a cheap but dumb generator that needs extra bits to not break itself.


There is a limit on reliable usage of the FS. Call it what you want. The user doesn't particularly care.


What I'm trying to say is that the problem you're describing is largely a separate problem from what kbolino is describing. They are both real but not the same thing.


I think a fair few of them were created because they knew a bit too much about FOQS


Personally, there's no way I'd want a customer initiated operation to trigger something like terraform or mess with DB schemas. On the security side, it would significantly complicate the permissions structure from the application to the database. And on the performance side, I have absolutely no mental model for how operations like that scale, and how trivial of a DoS I'm exposing myself to. At the same time, I love the isolation (mostly operationally, the security & privacy side is also nice) that db-per-customer would bring. If this product helps bridge the gap, then it sounds good to me.


Last project I worked on was a mix of on prem software and cloud software.

The cloud counterpart had 600+ mongodb databases split amongst 3 Mongo clusters.

The integration team took usually 2 weeks to setup the on premises software, and the cloud stuff took about a minute. The entire setup for the cloud was a single form that the integration team filled in with data.

The point I'm trying to make, is that if your customers require separate infra, they can wait a bisuness day to be setup. Meanwhile they can play on a sandbox environment.

It's also doable in fully automated fashion, but you will have to have strong identity and payment verifications, to avoid DoS, and in those cases usually contracts fly around.

That's for the b2b side.

For b2c, usually you rely on a single db and filter by column ID or similar, which can easily be abstracted away.


You rather explained the value prop of this product then. The benefits of isolation without the 1 business day wait.


What exactly is the value prop tho? To a technical person 1 business day wait seems dumb, but few businesses move that fast where waiting a single day matters.


But it'll take 10 business days to get an OK from management and other departments.


Doesn’t astronomy already use TAI, which has no leap seconds?


Astronomy is a big field. In my field it is either UTC or TDB.


Penalties for being on your phone while driving are fairly different between different countries. In the UK it's 6 points and £200 if you're caught. It's a fair deterrent


Last I heard, it was around $100 here. But I can't imagine that it's enforced. If you walk three blocks downtown without seeing a drive using a phone, you aren't looking.


In addition to lighter penalties, there's no enforcement of the law in much of the U.S.


The impact on the energy market always seems a tad misstated in these articles. Datacenters are often funded through corporate power purchase agreements, committing them to purchasing power directly from the generator over periods of multiple years. Those CPPAs are often tied to the development of new renewable energy generation (ex: https://www.matheson.com/insights/detail/matheson-advises-br...). Now, that still puts pressure on the grid for transmission, raises the marginal cost of renewable energy, and in cases where the generator cannot meet demand, presumably increases demand on other generation sources. But it makes the “40% of energy being used by DCs” stat seem a little misleading - a reasonable amount of generation exists because of these DCs.

(I work for Meta, who’s Clonee datacenter is mentioned in this article)


EirGrid previously claimed it would be able to allocate 1,800MW of electricity to new data centers, but had been receiving additional requests of up to 2,000MW. They also projected that demand from data centers could account for 27% of all electricity demand in the country by 2029, up from 11% in 2020.

https://www.eirgridgroup.com/site-files/library/EirGrid/All-...

Absolute peak energy demand in Ireland is about 5,500MW. 70% of Ireland’s electricity will come from renewable sources by 2030, without taking into account the footprint of these data centres - so there's a few different perspectives on this one.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: