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.
GitHub was down
211–220 of 253 posts
Re: GitHub was down
#212Earlier 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?
Re: GitHub was down
#213Earlier 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.
Re: GitHub was down
#214Earlier 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.
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
#215Earlier 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'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
#216If 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.
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
#217Earlier 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).
Re: GitHub was down
#218Earlier 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…
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
#219Earlier 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.
Re: GitHub was down
#220Earlier 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,…
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.