stacktrace

Agreed, it makes no sense to send out 404. Unless some agent finally went rogue with absolute permission and did `rm -rf`

As is Claude

Ahh, thanks for pointing it out. But it's rather interesting that Claude recognised the outage quicker on their status page than Grok.

Not just claude, even grok seems to be down - https://status.x.ai/

If I didn't know any better, I would have said Grok is using Claude behind the hood. But definitely curious now why it’s happening with both these LLM providers around the same time

We use Grype for container vulnerability scanning, but the recent `GHSA-2xp9-vwfh-vxw4` (CVSS 9.5 rating) vulnerability, which was initially reported on repository advisory on 25th Aug, was completely missed by our scanners. Even our socket.dev scans returned nothing related to vulnerability

The advisory exists through GitHub’s repository-advisory API:

- GET /repos/vercel/next.js/security-advisories/GHSA-2xp9-vwfh-vxw4

- HTTP 200

- state: "published"

- severity: "critical"

- published_at: "2026-08-25T16:16:28Z"

but it's completely missing from the public DB's our scanners rely on:

- https://api.github.com/advisories/GHSA-2xp9-vwfh-vxw4 - HTTP 404

- https://api.osv.dev/v1/vulns/GHSA-2xp9-vwfh-vxw4 - HTTP 404

There's already a blog published by Vercel about this, which is seriously concerning because some developers might not know about it until it's too late.

Is this delay expected? If so, how is everyone covering this gap in the scanning pipeline?

> It's still a big issue that the models will make up plausible sounding but wrong or misleading explanations for things, and verifying their claims ends up taking time. And if it's a topic you don't care about enough, you might just end up misinformed.

Exactly! One important thing LLMs have made me realise deeply is "No information" is better than false information. The way LLMs pull out completely incorrect explanations baffles me - I suppose that's expected since in the end it's generating tokens based on its training and it's reasonable it might hallucinate some stuff, but knowing this doesn't ease any of my frustration.

IMO if LLMs need to focus on anything right now, they should focus on better grounding. Maybe even something like a probability/confidence score, might end up experience so much better for so many users like me.

Will you consider it a stalemate if no party is able to make any further moves?

Really cool project! We had a situation a while back where some of our e2e tests needed the DB to be in very specific states. Technically we could have handled it with fixtures/transactions/schema resets, but doing that cleanly across a bunch of tests was pretty painful in our setup at the time

For a few edge-case scenarios we ended up mocking the DB layer (which obviously stops being a true e2e test). Something like PgLite would've been a perfect middle ground - real Postgres, zero container overhead, easy to spin up isolated instances per test, and a clean slate for every run.

Elixir is a great tool for exploring and cross-referencing the Linux codebase but for a new person, Linux can come across as very intimidating and complicated. The above explorer makes it very interesting to explore the codebase. This is kind of like an interactive book on Linux internals, with every topic being referenced through code.

> API rate limit exceeded for 106.51.68.199. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)

The GitHub APIs that you are using to list files are getting rate-limited in my case. If somebody else is also facing this issue, just use a VPN or something like Cloudflare Wrap to change your ip - this should fix the issue.

P.S If you are the main dev, giving an option to the visitor to sign in using Github or use a caching layer will be really helpful to make this accessible for the new user.

Exactly. AWS has its own quirks and frustrations, sure but at the end of the day, I’m not using AWS just for raw compute. I’m paying for the entire ecosystem around it: security and access management, S3, Lambda, networking, monitoring, reliability guarantees, and a hundred little things that quietly keep the lights on.

People can have different opinions on this, of course, but personally, if I have a choice, I'd rather not be juggling both product development and the infrastructure headaches that come with running everything myself. That trade-off isn’t worth it for me.

Very interesting read! But I want to point out a small correction - the DNS collapse issue at HAProxy, along with O(N^2), also had some O(N^3) code paths, which is just mind-blowing.

Also, I believe this should be the correct GitHub issue link - https://github.com/haproxy/haproxy/issues/1404

> Production Lesson: Code that "works fine" at small scale may still hide O(N²) or worse behavior. At hundreds or thousands of nodes, those costs stop being theoretical and start breaking production.

> Even an improvement of a few second per iteration can compound into hours of time savings, both for you and your fellow contributors

Completely agree with this. I’ve recently been dealing with building few CI workflows, and honestly, I was very frustrated by how much time everything was taking. A lot of that frustration came from having nothing to do while waiting for the CI to pass, and I could clearly see how much time all of it was costing me.

Looking back, I realize that I’ve wasted far more time during my normal development workflow because of small inefficiencies here and there.

This has led me to believe that the human mind is much more prone to thinking linearly than in a compounding way.

This type of possibility really worries me. Archive.is is much closer to actual history in many ways. If the data there starts getting corrupted or biased, there’s no way to know if what was truly there.

The idea that the permanent record of the internet could hinge on the ethics of one stranger behind a server rack is deeply unsettling.