mmbleh

Yeah, our traffic is more from automated systems/servers, nothing from mobile

It is because the IPv6 rollout has not been consistent. Some assign /64 per machine, some assign /64 per data center. Some even go the other way and do a /56 per machine. We've had to build up a list of overrides to do some ranges by /64 and others by /128 because of how they allocate addresses. This creates extra burden on server operators and it's not surprising that some just choose not to deal with it.

Yeah, absolutely no expectations for the future. My point was more that while there may be clear benefits for users, IPv6 presents real problems for service operators with no clear solutions in sight.

Given that GitHub also offers free services for anonymous users, I can imagine they face similar problems. The easiest move is simply to just not bother, and I can't blame them for it.

Anonymous rate limits for us are skewed towards preventing abusive behavior. Most users do not have a problem, even there is a CGNAT on IPv4.

For IPv6, if we block on /128 and a single machine gets /64, a malicious user has near infinite IPs. In the case of Linode and others that do /64 for a whole data center, it's easy to rate limit the whole thing.

Wrong assumption or not, it is an issue that is made worse by IPv6

IPv6 is very difficult to implement and enforce reliable rate limits on anonymous traffic. This is something we've struggled a lot with - there is no consistent implementation or standard when it comes to assigning of IPv6 addresses. sometimes a machine gets a full /64, other times a whole data center uses a full /64. So then we need to try and build knowledge of what level to block based on which IP range and for some it's just not worth the hassle.

Maybe a different take, but as someone that manages a large public API that allows anonymous access, IPv6 has been a nightmare to try and enforce rate limits on. We've found different ISPs assign IPv6 addresses differently - some give a /64 to every server, some give /64 to an entire data center. It seems there is no standard and everyone just makes up what they think will work. This puts us in an awkward place where we need abuse protections, but have to invest into more complicated solutions that were needed for IPv4. Or we give up and just say if you want to use IPv6, you have to authenticate.

Does anyone have any success stories from the server side handling a situation like this? Looks like cloudflare switched to some kind of custom dynamic rate limiting based on like addresses, but it's unrealistic to expect everyone to be able to do such a thing.

CVE response time is a toss up, they all patch fast. Chainguard can only guarantee zero active exploits because they control their own exploit feed, and don't publish anything on it until they've patched. So while this makes it look better, it may not actually be better

Yep, agree that comms have a lot of room for improvement. We do have initial delete capabilities of manifests available now, but functionality is fairly basic. It will improve over time, along with automated policies.

40/hour is higher than the current limits for authenticated free users.

(I work there) If you have a support contact or AE they can tell you if you need an official source. Marketing communications should be sent out at some point.

These platforms do cache quite a bit. It's just that there is a very high volume of traffic and a lot of it does update pretty frequently (or has to check for updates)

The storage enforcement costs have been delayed until 2026 to give time for new (automated) tooling to be created and for users to have time to adjust.

The pull limits have also been delayed at least a month.

These dates have been delayed. They will not take effect March 1. Pull limit changes are delayed at least a month, storage limit enforcement is delayed until next year.

Step one for me is just educating people on how cloud providers charge for resources. So many people don't understand everything that goes into an AWS bill.

Take AWS for example - everyone seems to account for lambda runtime cost, but a lot of people forget/ignore execution cost, API Gateway cost, bandwidth costs, etc. Or they'll account for S3 storage but not S3 API costs.

While good tagging certainly helps figure out where money is spent, sometimes it's too late since things have been built on bad architectures based on misunderstandings of charges.

Interesting reaction. This could also be interpreted as making it _more_ reputable, by removing abuse and cruft, allowing engineering time to be focused on things that provide value to end users.

> It's the ecosystem that every contender would love to be.

Trying to clarify - do you mean other JS ecosystems? Outside of JS, NPM is usually used as what not to do, not as an aspiration.

The article explains it a bit further - you _can_ just close the notification and skip the update as a free user. The difference being the "pro" option ignores the update completely versus it popping back up periodically.

If you read the blog post, anyone can dismiss the notification and skip the update. The option is about ignoring all updates for a particular update.

Kinda, but it isn't consistent.

They've been steadily improving/fixing it, but for some resources, tagging new resources via the console is a 2 step process - it creates the resource THEN adds the tags. They are fixing these things so it's all added at once.

What this does is block the ability to create some resources via console since you can't add tags at creation

Yup, that's exactly how I recommend clients to write lambdas for API purposes... Such a great balance of getting per request pricing while retaining all existing tooling for building APIs

Differing opinion - I think RDS Proxy is the wrong approach. Adding an additional fixed cost service to enable lambda seems like an indicator of a bad architecture. In this case the better approach would likely be to just use a Fargate container which would have a similar cost and fewer moving parts.

By the time you pay a fixed cost for the proxy on top of what you already pay for the RDS server, it'd be a far simpler architecture with less moving parts to just run a Fargate container (or better yet, AWS would offer a Google Cloud Run competitor)

The Data API, while still rough around the edges, at least keeps the solution more "serverless-y". Over time it should get easier to work with as tooling improves. At the very least, it won't be more difficult to work with than DynamoDB was initially with it's different paradigm.

For services that truly require consistently low latency, lambda shouldn't be used anyway, so the added latency of the data api shouldn't be a big deal IMO.

For those reasons, I view the RDS Proxy as an ugly stopgap that enables poor architecture, whereas the Data API actually enables something new, and potentially better. So I'd much rather AWS double down on it and quickly add some improvements.

I wonder if as the platforms merge, if AWS will make Fargate into a Google Cloud Run competitor, or if that'd take away too much from Lambda

GCR runs containers like Fargate, but scales to zero like lambda, so you only pay for usage

Google Wave came out a few years too early...

The original comment was hasty, I admit. But there are a lot of ways to tackle these issues.

Radar clutter, attenuation, penetration, etc are all affected by wavelengths. By using multiple frequencies, you can get a better idea of what is and isn't really there. As far as interference, there are ways to filter out noise. The car presumably knows how fast it is going. Therefor, it can do doppler filtering on the received waves. IE... car knows it sent waves at 50 GHz and is traveling at 60 mph. It knows to expect a response at ~54 GHz from the front and 50 GHz from the side.

For tracking objects, you can use a pulse-doppler radar [0] to get both range and rate information.

[0] https://en.wikipedia.org/wiki/Pulse-Doppler_radar

From the "How it works" Google self driving car page: "Sensors Lasers, radars and cameras detect objects in all directions"

It uses many kinds of sensors. Yes I know about clutter, I've spent quite a lot of time in the radar industry. But by combining data from radars of multiple wavelengths, it becomes pretty feasible. Though yes, difficult.

https://www.google.com/selfdrivingcar/how/

The sensors are primarily radar based. Mud/snow won't really affect them.