Live data from Hacker News

GitHub was down

status.github.com

211–220 of 253 posts

Re: GitHub was down

#211
post #116

Earlier quoted context omitted.

I'm not "missing" anything. I worked at Google for 7 years much of which was spent working on, you guessed it, distributed systems infrastructure. You guard against this by carefully canarying things and putting robust testing, monitoring, and deployment procedures in place. A release might take a few days, but you can be reasonably certain your users won't be your guinea pigs, and if shit does hit the fan, rollback…

You're too advanced for the typical reader. It's a startup site with half the people not having a test environment.

Everyone has a test environment; some people happen to send prod traffic to it.

Re: GitHub was down

#212

Earlier quoted context omitted.

Go has a mirror of our GitHub project via this thing "Maintner" I wrote (running at http://maintner.golang.org/ ) that syncs GitHub in realtime to a log of mutations. (As well as syncing Gerrit and all its comments etc). So then we can slurp all of our GitHub & Gerrit history into RAM (takes about 5 seconds and 500 MB) via https://godoc.org/golang.org/x/build/maintner/godata#Get and walk it in-memory and do stuff wit…

> alternate web UIs on planes Could you expand on this? Sounds interesting. You mean like an offline UI powered by the in-memory mutation list?

I think they just meant lighter. They load quite a bit and on really high latency and slow connections it's painful to use.

Re: GitHub was down

#213

Earlier quoted context omitted.

DISCLAIMER: I work for GitLab. We have a feature to replicate GitLab to different locations (EEP). We call it "Geo", which stands for "Geographical Replication". Part of the "Geo" effort is Disaster Recovery which is under heavily development. We want with Disaster Recovery to be able to reliably promote any Secondary node to a Primary, so if your US datacenter melts down under a nuclear war, you can start working wi…

If your US datacenter melts down under a nuclear war, I can guarantee that none of your devs will give a damn about contributing to the code base. You might want to modify your scenarios.

In that event, how much would your "guarantee" be worth? b^)

Re: GitHub was down

#214
post #145

Earlier quoted context omitted.

A lot of package manager tools download their packages from Github. If you happened to be refreshing your dependencies at the time, or doing a clean build, then you'd be SOL.

Really? I was under the impression that most language package managers downloaded from a CDN. I know that pip, npm, yarn, cargo, and hex do, at least.

Homebrew I believe goes through GitHub. Many of the Vim plugin managers also do, or at least have the option. I think CocoaPods and Carthage, both for iOS development, do as well.

I think it's somewhat common for a new package manager to use Github as a kind of CDN for a while, until they get big enough they can do their own.

Re: GitHub was down

#215

Earlier quoted context omitted.

Everything is key based, so only key holders push to your repo. It's all based on the SSB protocol. I'd suggest reading https://github.com/noffle/git-ssb-intro to get an idea.

That states: "git-ssb's permissionless model has an interesting consequence: anybody can push to anybody else's git repository." The guide doesn't show any key-sharing in order to do that. Are you saying that's incorrect?

I don't want to give you the wrong answer so I've forward this question to the SSBC network for one of the core developers to answer better.

I'd be surprised if there was no security for pushes. The repos I've worked on did require an invite from the creator.

Re: GitHub was down

#216

If anyone is interested, I've been working with a git host that is actually distributed across a p2p network using SSB. see: https://github.com/clehner/git-ssb https://github.com/noffle/git-ssb-intro It's been working fairly well so far. We are using git-ssb to manage a few projects instead of putting them into Github.

Is there, at least theoretically, a way to prevent other people from pushing to my repo? That seems like it would suck re griefing for any project that might become even mildly politically sensitive for whatever reason.

Yes, so basically in a centralized permission model some authority (the database) decides if any write is authorized or not, but in decentralized, any peer just writes anything, and then the readers decide whether they interpret that as valid or not.

Here is a description of a model that embraces both any-one-can-edit with degrees of consensus on who is allowed to edit. http://viewer.scuttlebot.io/%25GKmZNjjB3voORbvg8Jm4Jy2r0tvJj... but if you decide that someone cannot edit it, from there perspective they still can, but they are just excluded from your perspective.

Re: GitHub was down

#217

Earlier quoted context omitted.

Lots of answers so I'll try to address them all here. It was a rethorical question. We know what GitHub offers. I'm not a fan of its UI, particularly on mobile, but that's beside the point. The point is, why we failed, once more, to have a distributed solution, even when the underlying tech assumes it. Email was the last widely successful distributed medium. And it's dying, unfortunately. Of course centralized servic…

We didnt fail, nobody built it (probably from lack of demand).

Nobody built it = fail to provide a solution

Re: GitHub was down

#218

Earlier quoted context omitted.

Is there, at least theoretically, a way to prevent other people from pushing to my repo? That seems like it would suck re griefing for any project that might become even mildly politically sensitive for whatever reason.

Yes, so basically in a centralized permission model some authority (the database) decides if any write is authorized or not, but in decentralized, any peer just writes anything, and then the readers decide whether they interpret that as valid or not. Here is a description of a model that embraces both any-one-can-edit with degrees of consensus on who is allowed to edit. http://viewer.scuttlebot.io/%25GKmZNjjB3voORbvg…

Your comment is entirely nonsensical in this context. I want a way to be able to publish a repo and have the people subscribing to the repo be able to only pay attention to my changes in an automated way. This software currently doesn't implement that, as far as the guide that was linked suggests. It is therefore utterly useless - every time someone decides to grief my repo, it requires manual intervention to resolve.

Once you have that very, very basic ability to replicate what people expect when they subscribe to a person's git repository, you can start playing with automatically merging together people's changes - but in practice, merge conflicts are a thing and there's no good way to resolve them. If you can come up with a way to automatically resolve merge conflicts, you'd be rich, frankly speaking.

Re: GitHub was down

#219

Earlier quoted context omitted.

That states: "git-ssb's permissionless model has an interesting consequence: anybody can push to anybody else's git repository." The guide doesn't show any key-sharing in order to do that. Are you saying that's incorrect?

I don't want to give you the wrong answer so I've forward this question to the SSBC network for one of the core developers to answer better. I'd be surprised if there was no security for pushes. The repos I've worked on did require an invite from the creator.

Marak It sounds like you are working with private repos. With git-ssb currently a repo is either public or private. Private repos are encrypted to a fixed set of recipients so only those keyholders can access it. Public repos are unencrypted.

Re: GitHub was down

#220
post #128

Earlier quoted context omitted.

I keep meaning to dig into Fossil (SQLite's VCS/Project Management system), but I have no faith I could convince a team to use it. Another model to look at is Trac, which had pretty extensive integration with SVN and integrated (ie, cross-linked) issue tracking and wiki, and stored all the data and change history in a svn repository.

> I keep meaning to dig into Fossil, but I have no faith I could convince a team to use it. Developer or Fossil and SQLite here: I agree. In my experience, you'd have better luck convincing the team to switch from vi to emacs. For all its many and well-documented faults, the Git/GitHub paradigm is what people want to use because it is what they are familiar with. All the same, I intend to keep right on using Fossil,…

The pushback will come in two forms.

First, a backend that works exactly like git is very different from one that works almost like git. You'll be blamed for other people's problems.

Second, you'll have to have a way to deal with commit history the way git does (arbitrarily, and able to be rewritten at any time)

Otherwise the first push -f or rebase breaks the whole thing.

Reading from and writing to a git backend (that is, making fit a client too) might be the safer option. Sort of like git-p4 in reverse.

Post reply on HN