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

GitHub issue - resolved

githubstatus.com

Post reply on HN
Print view View original

141–150 of 169 posts

Re: GitHub issue - resolved

#141

Post by substation13 »

capableweb wrote: post #73
substation13 wrote: post #56

Earlier quoted context omitted.

Google search is basically never down. AWS is basically never down. WhatsApp is basically never down. Time for GitHub to grow up?

> Google homepage is basically never down. The complexity difference between the Google search "app" (not counting the vast indexing infrastructure) and GitHub is also vastly different. > AWS is basically never down. Lol what? Have you used AWS? > WhatsApp is basically never down. Makes sense, Whatsapp always had a huge focus on reliable infrastructure, since day 0. Pays off I guess :)

I think you are nitpicking. My point is that companies (including Microsoft!) are capable of running large scale infra with much higher uptimes than GitHub. They want to put themselves at the center of our workflows (e.g. GitHub Actions) yet they are not delivering uptimes that are commensurate with that. What is their excuse?

Re: GitHub issue - resolved

#142

Post by capableweb »

substation13 wrote: post #141
capableweb wrote: post #73

Earlier quoted context omitted.

> Google homepage is basically never down. The complexity difference between the Google search "app" (not counting the vast indexing infrastructure) and GitHub is also vastly different. > AWS is basically never down. Lol what? Have you used AWS? > WhatsApp is basically never down. Makes sense, Whatsapp always had a huge focus on reliable infrastructure, since day 0. Pays off I guess :)

I think you are nitpicking. My point is that companies (including Microsoft!) are capable of running large scale infra with much higher uptimes than GitHub. They want to put themselves at the center of our workflows (e.g. GitHub Actions) yet they are not delivering uptimes that are commensurate with that. What is their excuse?

Yeah, I agree with you, bit nitpicky. I also agree that they shouldn't have an excuse, besides confessing their engineering standards are not up to the level of their ambition, which is why I never make anything in my infrastructure depend on anything GitHub, everything that I use GitHub for, I have alternatives setup for the inevitable ill-timed downtime I know will happen.

Re: GitHub issue - resolved

#143

Post by williamvds »

imglorp wrote: post #137
williamvds wrote: post #119

Earlier quoted context omitted.

Git avoids the problem where the central service being down gets in the way of local development. Even in Git, that central service going down means degraded collaboration. Normally a Git remote is just an ssh-accessible machine, and so pretty resilient. But GitHub is a lot more complex, so apparently that simple service went down, along with all the features they built on top of it

You don't actually need the central service. In an emergency, a team could work entirely over email via diffs like Linus does.

Yeah, true. In this case, I'm sure most teams did what mine did, and waited for the outage to be resolved. The development workflow and CI/CD is so tightly coupled to the Git remote, it would have taken a while to create and switch to another remote.

Re: GitHub issue - resolved

#144

Post by activitypea »

davemp wrote: post #94

Now's a good opportunity to ask about alternative Git hosts. What other services do HNers use? I've been unwilling to host any personal projects on GH after Copilot launched and it because clear that GH/MS doesn't really respect the authors of the code they host. Honestly open source in general has gotten a little less compelling to me after Copilot. The recent security issue at GH has also turned me off even more on…

We still use self-hosted GitLab. It's crazy expensive but we're completely locked in to their CI/CD pipelines plus we still enjoy using it ¯\_(ツ)_/¯

Re: GitHub issue - resolved

#145

Post by skywhopper »

lima wrote: post #122
davemp wrote: post #94

Now's a good opportunity to ask about alternative Git hosts. What other services do HNers use? I've been unwilling to host any personal projects on GH after Copilot launched and it because clear that GH/MS doesn't really respect the authors of the code they host. Honestly open source in general has gotten a little less compelling to me after Copilot. The recent security issue at GH has also turned me off even more on…

My company uses a self-hosted Gerrit instance. A bit of a learning curve, but the code review experience is SO much better than PRs (one commit == one unit of review, clean intra-diffs between different revisions of a patch, stacking of reviews simply by having multiple commits on a branch, UI is very snappy and responsive...). Self-hosting Gerrit is easy[1] because all its internal state is fully transactional, incl…

Gerrit looks ugly, and the admin story is a nightmare, but it's such a better experience for code reviews (plus you can actually enforce code review in a way Github cannot). I can't stand dealing with Github for code review after spending a few years using Gerrit.

Re: GitHub issue - resolved

#147

Post by bhouston »

sdfhbdf wrote: post #93
bhouston wrote: post #71

Earlier quoted context omitted.

I Think he was referring to Google Search in general. I've never witness since Google went live in 1998 any Google Search downtime. Probably happened but I can not remember it.

Google Search is still a RO system - you are mostly just retrieving information from a search index.

It is read-online but its read systems are relatively complex and work at scale.

Re: GitHub issue - resolved

#148

Post by bhouston »

ZiiS wrote: post #99
bhouston wrote: post #71

Earlier quoted context omitted.

I Think he was referring to Google Search in general. I've never witness since Google went live in 1998 any Google Search downtime. Probably happened but I can not remember it.

You don't notice when their indexers cannot write; preforming a search is basically RO.

It is still a relatively complex multi-machine RO operation. It isn't like serving a static site.

Re: GitHub issue - resolved

#149

Post by codeapprove »

skywhopper wrote: post #145
lima wrote: post #122

Earlier quoted context omitted.

My company uses a self-hosted Gerrit instance. A bit of a learning curve, but the code review experience is SO much better than PRs (one commit == one unit of review, clean intra-diffs between different revisions of a patch, stacking of reviews simply by having multiple commits on a branch, UI is very snappy and responsive...). Self-hosting Gerrit is easy[1] because all its internal state is fully transactional, incl…

Gerrit looks ugly, and the admin story is a nightmare, but it's such a better experience for code reviews (plus you can actually enforce code review in a way Github cannot). I can't stand dealing with Github for code review after spending a few years using Gerrit.

(shameless plug alert)

If you're looking for a drop-in improvement to GitHub's code review experience, you may be interested in CodeApprove (https://codeapprove.com).

It's got a lot of the things that make Gerrit appealing, but with less of a drastic workflow shift (still branch-based PRs) and a much nicer UI.

Re: GitHub issue - resolved

#150

Post by cesarb »

imglorp wrote: post #137
williamvds wrote: post #119

Earlier quoted context omitted.

Git avoids the problem where the central service being down gets in the way of local development. Even in Git, that central service going down means degraded collaboration. Normally a Git remote is just an ssh-accessible machine, and so pretty resilient. But GitHub is a lot more complex, so apparently that simple service went down, along with all the features they built on top of it

You don't actually need the central service. In an emergency, a team could work entirely over email via diffs like Linus does.

I once used another alternative: each member of the team runs git-daemon on their desktop to export their local repository, and adds the repositories exported by the other members of the team as git remotes. You can merge a coworker's master branch to your master branch whenever you want to get their changes (and the changes they already merged), which makes for a chaotic but fun development experience.
Post reply on HN