211–220 of 275 posts
Github has 84.92% uptime in the last 90 days according to https://mrshu.github.io/github-statuses I don't know how this is even remotely close to acceptable.
IMO that site overcounts downtime. If you filter for major and critical outages (the kind that make the front page of HN), the story is still bad but it’s not 84.92% bad. https://isgithubcooked.com/?severities=major.critical
Earlier quoted context omitted.
AI agents have changed the scalability properties of basically the entire internet. It used to be that GitHub could rely on a finite number of people interacting with their platform in real human ways in real observable patterns. So I'm assuming that they scale for those patterns, and optimize for the UI and UX hotspots. But now everyone's got a moltbot running 24/7, sometimes many, and it's completely overloading a…
Microsoft buys github. Microsoft forces AI usage down everyone's throats. AI bot usage takes down github. I have to assume that there are some serious fights going on between the poor SRE teams wanting to throttle bots, and MS not wanting to do anything to dissuade AI usage.
Earlier quoted context omitted.
But CI only increased by a factor of 2 since last year. Did they really not foresee that happening? And how does that affect git and api operations.
It really shouldn't. The technical summary they released[1] is a very interesting read from a software engineering perspective. It seems to be blindsided by the increased traffic and gives stats related to commits/PRs (which should be relatively cheap for github to process) without any insight into their web traffic or details on how much actions are costing them. If they were super transparent they'd release informa…
https://isolveproblems.substack.com/p/how-microsoft-vaporize...
https://www.kunalganglani.com/blog/microsoft-fedramp-failure...
Earlier quoted context omitted.
I wonder how many of those actions are really necessary
And how many of those actions do uncached downloads instead of building self-contained offline images... Speaking of which, I wonder if GitHub has implemented any HTTP interception for common mirror sites, like used by apt, etc.
I so wish this wasn't the case.
Earlier quoted context omitted.
Flawed reasoning all around. Machine code and object code will look the same given the same source code, target platform, compilation and linkin params etc. How is AI-Slop-Code even close to that?
"looking same" is not the requirement. "Working same" is. With proper test harness, the generated code can be controlled to "work the same".
Earlier quoted context omitted.
Everyone producing magnitude more code with AI agents. Numbers from GH COO here: https://x.com/kdaigle/status/2040164759836778878
So why aren't we seeing an explosion in feature shipping rate, or tech startups? If there is so much extra code, where is it going? Is everyone just creating giant piles of throwaway slop?
Earlier quoted context omitted.
I noticed the same https://news.ycombinator.com/item?id=47940213 . My working hypothesis is that, given that a filter was always required (prs and issues are likely rows in the same database with a bool property to distinguish them), someone thought it'd be good to use the search API uniformly. But search is on the derivative of the underlying data, in contrast to the specific APIs for listing issues and prs.
Working in an organization without a mono-repository I've actually found it extremely difficult to keep a tab on PRs and issues across multiple repositories. For a problem that should be resolved by a "For me" page that just lists out all your active incoming and outgoing PRs their multi-page solution involving search filters that often need to be reset feels extremely weak. I've worked on large multi-tenant solution…
These are in the top left hamburger menu from the Home dashboard (edit: actually on all pages).
Earlier quoted context omitted.
IMO that site overcounts downtime. If you filter for major and critical outages (the kind that make the front page of HN), the story is still bad but it’s not 84.92% bad. https://isgithubcooked.com/?severities=major.critical
2/9 9s is pretty awful.
Earlier quoted context omitted.
But CI only increased by a factor of 2 since last year. Did they really not foresee that happening? And how does that affect git and api operations.
It really shouldn't. The technical summary they released[1] is a very interesting read from a software engineering perspective. It seems to be blindsided by the increased traffic and gives stats related to commits/PRs (which should be relatively cheap for github to process) without any insight into their web traffic or details on how much actions are costing them. If they were super transparent they'd release informa…
The recent blog post you're linking to mentioned moving data only for webhooks off MySQL, not all relational data used by the entire site; and moving "performance or scale sensitive code out of Ruby", again not the entire codebase.
Do you have an official source suggesting these migrations are more comprehensive than that?