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.

> 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.

> 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.