Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The August 17 outage

github.blog

Post reply on HN
Print view View original

201–210 of 804 posts

Re: The August 17 outage

#201

Post by [deleted] »

OJFord wrote: post #107
arn3n wrote: post #78

Everyone suggesting that they simply charge users for commits to drive off AI-heavy users forgets that Github is owned by Microsoft, who has a big incentive to keep having developers use AI. I suspect that Microsoft would even prefer to have Github operate at a loss, if that loss were because all its users were using their models and paying for OpenAI subscriptions to generate the code.

> I suspect that Microsoft would even prefer to have Github operate at a loss, I assumed it does , do you know that it doesn't?

[deleted]

Re: The August 17 outage

#202

Post by johndough »

tremon wrote: post #145
blakesterz wrote: post #4

"Since April, monthly commits have grown from 1.4 billion to 2.9 billion. " Wow, that is some incredible growth in a really short time.

Why is Github talking about number of commits here, and not pushes? Are there a lot of tools/people using github as an online editing platform?

Bigger numbers sound more impressive.

"Our billion-dollar infrastructure crumbles under a tremendous flood of 50 PRs per second" would just sound embarrassing.

Re: The August 17 outage

#203

Post by joezydeco »

ivraatiems wrote: post #3

"We are committed to fixing these problems, as long as it doesn't involve buying things other than AI computers, hiring humans, or using non-Microsoft products." Calling Azure the solution to this problem when it is in fact the source of most of these problems is just fantastic doublespeak. Github is ripe for disruption and I hope it is disrupted soon.

The Azure horror stories are on this blog post and HN discussion.

https://news.ycombinator.com/item?id=47616242

Re: The August 17 outage

#205

Post by grim_io »

jdm2212 wrote: post #200
jordanb wrote: post #194

Earlier quoted context omitted.

Anyone who designs such a system should know to use an exponential backoff to avoid the thundering herd. Maybe copilot missed that while it was reviewing its own PR

Exponential backoff is the wrong answer in a highly available system in the typical case where (a) failure is expected and (b) you have nodes you are supposed to fail over to.

Why? You can retry, but there is nothing wrong with increasingly waiting slightly longer if we fail many times.

Re: The August 17 outage

#208

Post by ACCount37 »

cube00 wrote: post #132

> Errors in those services triggered a client-side retry loop that increased traffic during recovery Symptomic of a wider trend to avoid showing the user any error at all costs, even if that means they sit watching a spinner for 7 hours. > Delayed replies to a single internal endpoint triggered a latent retry bug in VS Code that amplified traffic by approximately 10x and caused delayed recovery for the Copilot Token…

"You can't seriously tell me that the unhappy leg of the code path has no test coverage."

Sometimes I forget how ignorant HN can be of real world software development and the bar of corporate code quality, and then bangers like this remind me of it.

Re: The August 17 outage

#209

Post by jeremyjh »

orf wrote: post #197
Brian_K_White wrote: post #168

Earlier quoted context omitted.

Commits are not expensive, pushes are. You can do any number of commits before you do one push, unless you are editing online, in which case every act is it's own commit & push. You can rig up a local ide to pathologically commit+push per save, but you can do literally anything, so what you can do is immaterial.

Do you have some GitHub architectural knowledge you’d like to share with us? A push pushes commits and blobs and trees and tags. It’s an interesting metric to track, but the core unit of complexity (and expense) worth tracking on GitHub’s side is obviously the commit. There’s a difference between pushing 1 commit and 100.

> There’s a difference between pushing 1 commit and 100.

There isn’t much. GitHub doesn’t run actions separately for each commit. It runs them on pushes. I’m trying to think of a thing that would happen for each commit in each push and coming up blank.

It does things like scan for references to issues to index, but it would just scan the log for a range.

I did disagree with GP though because there is no reason to assume that the ratio of commits to pushes has materially changed. So if that is the proxy they have always used for measuring growth, and they know it reliably does that then I think it’s a reasonable way to communicate this to this audience.

Post reply on HN