Live data from Hacker News

Incident with Github.com [resolved]

githubstatus.com

981–990 of 1001 posts

Re: Incident with Github.com [resolved]

#981
post #906

Earlier quoted context omitted.

What? No. The people that stay are the ones that don't care, that doesn't mean no one cares. That's a selection effect. The people that care left months or years ago. I'm one of them. It was really easy, Github doesn't offer anything special. Try and run a Pagerduty with the same level of attention to detail as Github. Far fewer people use Pagerduty casually. That Github has casual users and lazy users does not mean…

That might apply to personal users. But to businesses the switching cost is just too high. We had a discussion about it on our team. It was decided to keep using GitHub unfortunately.

Not all businesses have the same requirements. My company jumped ship months ago. We didn't consider switching to have significant cost, we did consider staying to have noticeable opportunity cost. Easy decision.

Re: Incident with Github.com [resolved]

#982

I think this is the curse of scale, but also of pseudo-leaders who think leadership is "pushing engineering to rapid-fire features for number go up." You tell engineers and engineering leaders to "just add this one feature, it's really important, what's the ETA? No, that's too late, the market will have moved on, this is existential, you're a bottleneck," fire, hire, fire, hire. Meanwhile the CEO feels great, because…

GitHub simply isn't an agent code building platform. They're a RoR git host from 2008 running on an ancient MySQL setup that by some miracle continues to stay up, some of the time.

Their APIs are garbage from an agentic perspective. Try using Terraform to curate your GH org of a few hundred repos. Just running the `tf plan` will take 10min, because it's making thousands of API calls. Where's the bulk and batch APIs? No such thing. They are simply not agentic scale. Want to rerun the plan for your entire cloud vendor with thousands of VMs, IAM roles, buckets, etc... it'll run faster than checking on your repo labels.

GH needs rewritten from the ground up. The "repo is everything" arch has been creaking and falling over form many years now.

Re: Incident with Github.com [resolved]

#983
post #666
post #485

Earlier quoted context omitted.

The biggest benefits of Git over predecessors were branching, 3-way merge, and history rewrites (in particular, rebase and squash). As much as Git fans wanted decentralization to be a major selling point, decentralization has never been a major selling point.

Not exactly decentralization but distribution was the main selling point. In comparison to SVN and other non-DVCs git did not need to continuously talk to the central server for history, "branch" creations, unlocking/locking files before changes, etc. Linus wanted a DVCS, but they wanted centralization and licenses were expensive, so he decided to launch the git initiative where he provided scaffolding and the rest c…

It was a selling point. Maybe even intended selling point. But it absolutely isn't the main selling point. Never was, never will. The big thing, the reason people ever started talking about Git outside Linux dev team, has always been branches. It's branches, not distribution, that made every SVN user in the world abandon it in exchange for Git. Saying distribution has been more important than branching is like saying automobiles replaced horses because of smell. Which, admittedly, was a big problem with horses, but come on.

Re: Incident with Github.com [resolved]

#984

Earlier quoted context omitted.

I want to second build kite - it’s an excellent piece of tech and is best described as “sane Jenkins” as a compliment. My only gripe is the pricing - it’s not designed for “small teams”. But I’d use it again in a heartbeat.

This week we've released a free plan and overhauled the mid-tier; am keen to hear whether this alleviates the 'small team' pain against others in market

I’m not working for a small team anymore but I can say this would have gotten us to use Buildkite again.

I think an in between tier would help, as it’s 4.5x the cost of GitHub per person, plus the cost of the runners. The idea of spending $42/mo on GitHub plus $180 on buuldkite is a hard sell, but the economics aren’t there.

Re: Incident with Github.com [resolved]

#985

Earlier quoted context omitted.

I understand the need to level-head the discussion and calming everyone. However, your "(you don't)" comment is not going to calm down all the people, who, you know, DO have a hotfix to push now, and DO have an angry customer that could not care less for which part of our infrastructure is breaking _their_ workflow. The only things would calm everyone down is guarantee that Microsoft would be paying for _our_ SLA bre…

It's past time to move your critical infrastructure off Github then, no?

That effectively means “stop using GitHub” though. Which is definitely worth considering but also kind of insane to think as the best option.

Re: Incident with Github.com [resolved]

#986

Earlier quoted context omitted.

https://damrnelson.github.io/github-historical-uptime/

First, that source is unreliable, particularly for before the acquisition. (We don’t know whether the data is accurate, it’s based on GitHub’s own self reporting.) Secondly, the scale is WAY off and makes it look far worse than it is. It makes it look like 99.5% availability is practically zero availability. Finally, GitHub’s availability is not a binary all-or-nothing proposition. They report incidents on a granular…

0.5% downtime is an hour a week. If that happens for 10 minutes a day at 11pm PT it doesn’t matter, if it happens for half a working day once a month, it’s a disaster.

Re: Incident with Github.com [resolved]

#989

Earlier quoted context omitted.

First off, there aren’t that many developers in the world compared to consumers. Taking every developer in the world and multiplying by 12x-24x is not a-lot compared to many consumer oriented sites. Second, you can’t ignore the payloads, even an AI mostly text push is nothing compared to, say, 10 iPhone pictures or one moderate video.

Developers aren’t what scaled commits/pushes are they claim it went from ~1 billion a year to doing more than that a month

So in other words, a 12x increase - which is exactly that I already responded to.

A 12x increase in volume should not be world ending for Microsoft given that the number of developers in the world is a pretty small baseline number to start from.

Re: Incident with Github.com [resolved]

#990

Earlier quoted context omitted.

This week we've released a free plan and overhauled the mid-tier; am keen to hear whether this alleviates the 'small team' pain against others in market

I’m not working for a small team anymore but I can say this would have gotten us to use Buildkite again. I think an in between tier would help, as it’s 4.5x the cost of GitHub per person, plus the cost of the runners. The idea of spending $42/mo on GitHub plus $180 on buuldkite is a hard sell, but the economics aren’t there.

That's good feedback, there's been a lot of discussion internally about how pricing has affected sentiment and what the trade-offs were from previous decision makers there over the last couple of years. Without it seeming like lip service, there is a 'startup' plan in the works, to sit between free and pro, sounds like it may be the right move as this isn't the first time we've heard it.
Post reply on HN