https://walletwallet.alen.ro/

You need an agent swarm to defend cyber-assets. No way we can respond at human speed.

Another consequence is that every public API with a bug bounty will be pen-tested up til the cost (in expectation) of running the AIs. We already see public AI-discovered vulns being reported to companies.

We've stumbled into general differentiable models..

Comments URL: https://news.ycombinator.com/item?id=48406115

Points: 6

# Comments: 0

The reason why things get worse is because of systemic problems: misaligned incentives, information asymmetry, diffuse responsibility, etc. It's actually hard to improve these aspects of large systems. Hence, why the world is an imperfect place.

If they weren't turned off at the billing cap, but were given some leeway instead, either that becomes the new hard limit, or GCP will have to give away the difference.

And there's no "middle ground" you could implement that makes sense either - like a "frozen" state. Preventing new writes to a GCS bucket breaks the writer app. Freezing VMs serving web traffic takes the site down.

Even if the service was shut down once the billing limit is hit, how long would GCP wait for the user to add funds or raise the limit? GCP would need to either keep the services in a hidden/frozen state or not turn them off / freeze them at all (in which case GCP would be giving away resources for free).

Maybe GCP can give users a heads-up when they're about to hit the limit? GCP already does - billing alerts do exist. It's just possible to blow past them if your usage is a massive spike.

Moreover, getting the hundreds of GCP services to implement a "frozen" state is difficult. It's hard enough getting everyone to listen to the "billing account disabled" signal, and (soft-)delete the resources (based on the resource, after some time interval). Given these billing overruns happen for smaller customers, it's not really worth solving the problem - which I don't think has a great solution to begin with.

1) Pulls you in with a catchy title, that at first glance seems like a dunk on Cal.com (whatever that is).

2) Takes the "we understand your pain" approach to empathize w/ Cal.com, so you feel like you're on the good vibes side.

3) Provides a genuine response to the actual problem Cal.com is dealing with. Something you can't dismiss out of hand.

4) But in the end of the day, the response aligns perfectly with the product they're promoting (a click away to the homepage!)

This mix of genuine ideas and marketing is quite potent. Not saying this is all bad or anything, just found it a bit funny. The mixed-up-ness is the point!

And the talk wasn't a random talk, but a memorial talk for Dijkstra: "The 2010 Edsger W. Dijkstra Memorial Lecture". I forgot this aspect as well!

a) finding a new theoretical frame that simplifies the space or solutions, helps people think through it in a principled way

b) finding ways to use existing abstractions, that others may not have been able to find

c) using non-technical levers, like working at the org/business/UX level to cut scope, simplify requirements,

The way you can make complexity work for your career, is to make it clear why the problem is complex, and then what you did to simplify the problem. If you just present a simple solution, no one will get it. It’s like “showing your work”.

In some orgs, this is hopeless, as they really do reward complexity of implementation.

What does it mean to say "we were promised flying cars", or "every city would have micro-factories, that 3D printing would decentralize production"?

The people creating these narratives may a) truly believe it and tried to make it a reality, but failed b) never believed it at all, but failed anyway, c) or be somewhere else on this quadrant of belief vs actuality.

Why not just treat it as, "a prediction that went wrong". I suppose it's because a narrative of promise feels like a promise, and people don't like being lied to.

It's a strange narrative maneuver we keep doing with tech, which is more future-facing than most fields.