Live data from Hacker News

Another GitHub outage in the same day

githubstatus.com

231–240 of 298 posts

Re: Another GitHub outage in the same day

#231

Earlier quoted context omitted.

Hey from the GitHub team. Outages like this are incredibly painful and we'll share a post-mortem once our investigation is complete. It stings to have this happen as we're putting a lot of effort specifically into the core product, growing teams like Actions and increasing performance-focused initiatives on key areas like pull requests where we're already making solid progress[1]. Would love if you would reach out to…

For what it's worth, I doubt that people think it's the engineering teams that are the problem; it feels as though leadership just doesn't give a crap about it, because, after all, if you have a captive audience you can do whatever you want. (See also: Windows, Internet Explorer, ActiveX, etc. for how that turned out) It's great that you're working on improving the product, but the (maybe cynical) view that I've hear…

>I doubt that people think it's the engineering teams that are the problem

Did you forget Microsoft engineering response to Casey Muratori "Extremely slow performance when processing virtual terminal sequences"?

"I believe what you’re doing is describing something that might be considered an entire doctoral research project in performant terminal emulation as “extremely simple” somewhat combatively."

https://github.com/microsoft/terminal/issues/10362#issuecomm...

followed by Casey producing evidence for his 'extremely simple' claim in couple of days.

Re: Another GitHub outage in the same day

#232
post #203

Earlier quoted context omitted.

Hey from the GitHub team. Outages like this are incredibly painful and we'll share a post-mortem once our investigation is complete. It stings to have this happen as we're putting a lot of effort specifically into the core product, growing teams like Actions and increasing performance-focused initiatives on key areas like pull requests where we're already making solid progress[1]. Would love if you would reach out to…

Can you guys stop adding new features for a while please and just make what’s there more reliable?

GitHub will prioritize migrating to Azure over feature development

4 months ago on HN: https://news.ycombinator.com/item?id=45517173

Re: Another GitHub outage in the same day

#233
post #45

Earlier quoted context omitted.

You would kind of expect with the pressure of supporting OpenAI and GitHub etc. that Azure would have been whipped into shape by now.

AZDO has been in KTLO maintenance mode for years.

I always felt that AZDO is basically TFS rebranded, so yeah, not much actions since they killed Source safe.

Re: Another GitHub outage in the same day

#234
post #19

I wonder if GitHub is feeling the crush of fully automated development workflows? Must be a crazy number of commits now to personal repos that will never convert to paid orgs.

IME this all started after MSFT acquired GitHub but well before vibe coding took the world by storm. ETA: Tangentially, private repos became free under Microsoft ownership in 2019. If they hadn't done that, they could've extracted $4 per month from every vibe coder forever(!)

Why would every vibe coder necessarily use private repos?

IIRC they were kinda forced to make private repos free because competitors like Gitlab had it and they felt threatened.

Re: Another GitHub outage in the same day

#235

Earlier quoted context omitted.

Even just a year or two ago its web interface was way snappier. Now an issue with a non-trivial number of comments, or a PR with a diff of even just a few hundred or thousand lines of changes causes my browser to lock up.

Which website lets you load PRs with 1000 lines and it’s fast? Honest question, it’s not gitlab.

I’ve really enjoyed Gitea wherever I’ve used it.

Re: Another GitHub outage in the same day

#236
post #159
post #121

Earlier quoted context omitted.

Really? I’d be interested to hear more. Disclaimer: I work in Microsoft (albeit in a quite disconnected part of it, nothing to do with GitHub or Copilot).

Not even Microsoft employees like Copilot. Maybe start why not even your coworkers can use your own slop. https://www.theverge.com/tech/865689/microsoft-claude-code-a...

Sure I love Claude Code too - I use it plenty outside of work. But funnily enough I’ve been asking myself about whether to get my org on board with internal Claude Code trials and was struggling to truly articulate what we were losing versus the Copilot cli. There are some feature gaps - but the pace of work is super and experience is pretty good for me.

No one should hit Microsoft over the head for giving people access to Claude code - choice and competition is good!

Re: Another GitHub outage in the same day

#237
post #121

Earlier quoted context omitted.

Really? I’d be interested to hear more. Disclaimer: I work in Microsoft (albeit in a quite disconnected part of it, nothing to do with GitHub or Copilot).

In testing for my workflows copilot significantly underperforms the SOTA agents, even when using the exact same models. It's not particularly close either. This has lead to 2 classes of devs at my company a) AI hesitant, who for many copilot is their only interaction, having their worst fears confirmed about how bad AI is. b) AI enthusiasts who are irritated by dealing with management that don't know the difference p…

Interesting - these head to head comparisons you’re doing with the same model - what harnesses are you comparing, say Claude code / codex versus copilot cli?

> I'm not sure if its understood how bad it really is within the org.

I can’t speak to that, but there’s a lively culture of people using internal tooling who also extensively use 3p products on projects outside work and are in a reasonable position to assess how well GH copilot works.

Re: Another GitHub outage in the same day

#238

Earlier quoted context omitted.

Literally everyone who has used Github to look at a pull request in say the last year has experienced the ridiculous performance issues. It's a constant laughing point on HN at this point. There is no way you don't know this. Inviting to take this to a private channel, along with the rest of your comment really, is simply standard corporate PR.

Yes agreed it's been a huge problem, and we shipped changes last week to address some of the gnarly p99 interactions. It doesn't fix everything and large PRs have a lot of room to be faster. It's still good to know where some worst performance issues are to see if there's anything particularly problematic or if a future change will help.

FWIW, I find the new React-based diff viewer worse than the old server-rendered page. I disabled the preview for this reason. It does have some nice features but overall it feels more finicky. I would think that in theory this should be better at handling large diffs but I'm not sure that that's the case, and at least the UX feels more choppy.

Re: Another GitHub outage in the same day

#239

Earlier quoted context omitted.

I for one am shocked--SHOCKED, I say!--to learn that anything bad could happen as a result of a) putting everything in "the cloud" and b) handing control over the entire world's source code to the likes of Microsoft. Who could have POSSIBLY foreseen any kind of dire consequences?

Nobody. Nobody at all could have seen it. Microsoft is cool now, haven't you seen VSCode? They do Open Source, they run Linux, they've joined the fold, the tiger shed its stripes.

More like a wolf in sheep clothing

Re: Another GitHub outage in the same day

#240

Earlier quoted context omitted.

The new design/architecture allows them to do great stuff in the name of efficiency; for example, when browsing through some parts of the UI, it's now much more capable of just updating the part of the page that's changed, rather than having to reload the entire thing. This is a significantly better approach for a lot of things. I understand that the 'updating the part of the page that's changed' functionality is now…

> for example, when browsing through some parts of the UI React allows this? I didn't realize that I needed React to do this when we used Java and Js to do this 20 years ago. I also didn't realize I needed React to do this when we used Scala and generated Js to do this 10 years ago. JFC, the world didn't start when you turned 18.

> I understand that the 'updating the part of the page that's changed' functionality is now dramatically slower, more unresponsive, and less reliable than the 'reload the entire thing' approach was, and it feels like browsing the site via Citrix over dial-up half the time, but look, sacrifices have to be made in the name of making things better even if the sacrifice is that things get worse instead.

I don't think they were being serious.

Post reply on HN