Github major service outage
status.github.com
https://status.github.com/
status.github.com
Whenever GitHub runs into problems like this, it reminds me of when a team's CVS or Subversion servers used to go down. It could be a pretty disruptive occurrence, if it wasn't resolved quickly. While git can theoretically handle this better, in practice the use of GitHub, for instance, renders git just as susceptible.
Creating and hosting a repo locally (or offsite) is trivially easy, and though it might not be as friendly or natural as it would be with git on a daily basis, it's not impossible either.
If Github were to explode forever tomorrow, active projects would just take their locally cloned repositories, and put them online somewhere else and carry on committing (albeit sans github's awesome social tools). That's the real power git offers us.
It's just a fact of reality that most projects centrally organize through a few bottlenecks. It's easier for people to remember where to go, if there's only one place to go to. But if you're really concerned about it, i suppose you could build a tool to automatically sync a github repo w/ another 3rd party host if you wanted (or visaversa).
So even if bugs.kde.org were to go down, we'd still be able to fix code at git.kde.org, and use the lists.kde.org mailing list archives to lookup bug details as a backup. We'd probably use a mailing list system that doesn't suck like kde.markmail.org or GMANE for that last part, but that's just shaving the yak...
Is there a git tool to share your remotes in a repository?
One could use a distributed issue tracker like "Bugs Everywhere"[1] or git-issues[2]. Are there ways to "sync" them with Github's issues?
[1]: http://bugseverywhere.org/ [2]: https://github.com/jwiegley/git-issues
It's crazy how GitHub's entire product is so easily marginalized by comments like this. I don't know if you meant to do it, but I think it is a serious problem with hacker culture. It's the kind of thinking that tricks startups into "knowing" they can do a better job than established competitors in spaces they know close to nothing about, because they "know" they can execute better. I speak from personal experience here.
I can guarantee that no amount of "adding some scripts/utilities" will get near what GitHub's service offers.
Just because you tried and failed, doesn't mean every try will fail.
I don't think they were saying that a few scripts and utilities would get you what github offers. I think they were saying with some scripts you could automatically fall over to another mirror when github goes down, then switch back when it's up (updating the repo on github when it's available again).
The word "add" here is important, as it's talking about having github and something else. So you get github (with all their social stuff...) AND what the scripts add, which is more reliability.
There's no reason you can't do the same thing with a small box in the office and get the best of both worlds.
Anyone happen to know a way around this specifically? Trying to install some stuff and brew just bails after getting 5xx from github.com.
Periodically you can merge upstream into your clone to get updated recipes. (e.g., the aforementioned cronjob can mirror master from github to remotes/upstream/master in your repo, then separately you merge that into your master).
Your servers are now immune to github outages[1] and you can review recipe updates before your servers update to those recipes.
[1] unless of course the recipes you're using are hosted on github. But you could recursively mirror those sources too and modify the recipes as needed.
edit: I'm on a mobile device but I can provide further details the next time I'm in front of a keyboard in case this wasn't clear.
Yeah, the problem I was having at the time was that Homebrew was trying to fetch a tarball hosted on Github. I was just whinging though, that was the only time I've ever hit that particular snag.
The system you propose would be great, but more work than switching to running headless Linux VMs on OSX for most dev work ;) This is something I have been drifting toward for a while now, using Vagrant.
git remote add my_other_server_that_is_not_github git://my.oth.er/server/that/is/not/github.gitIt isn't odd. Almost nobody understands distributed version control, and fewer actually need it.
A big part of the reason that GitHub is popular is that git is way too complicated for most people to use. They don't understand the CLI or the concepts, and need a shiny web UI to abstract the (admittedly terrible) interface.
Most people need branching, merging and committing to a canonical repository. Even the groups that could theoretically benefit from distributed repos (larger, far-flung organizations), tend to be hamstrung by the complexity that they introduce, and therefore in practice tend set up a small number of canonical repositories...just like every other version control system, but more complicated and confusing.
It's 99.770% for a single month, immediately following a major event. If you sampled yesterday (or tomorrow, assuming no further issues) it would be higher. If you just look at today, it's at the much lower at 95.871%. If you assume no availability issues for the last 12 months (not true, but the point remains) then it's 99.981%. During an actual outage, availability was at the unacceptable 0%.
Unfortunately they don't provide 12mo stats, which is what you typically want if you're going to start calculating nines of availability.
Github, if they're honest about their 12 month uptime levels would be lucky to be a single 9 service. Their uptime is Terrible with a capital T. But you know what? Until there's something better everyone is going to keep using them, right?
Great services with values that are hard to find become damn near irreplaceable even with terrible uptime. This is an obvious place to compete; if you made a github clone that simply stayed online you could win market share during every downtime. However cloning github would not be trivial.
And therein lies the problem and the answer to why we accept their terrible uptime levels. They give us something we can't get elsewhere: social coding and easy centralization.
Not to mention that often when they have issues it only affects a subset of customers.
Pointing out that someone whose point I agree with is using bad math as evidence is not disagreeing with the point, it's asking that people who agree with me behave like honest, civilized, human beings---I don't care that you've already gone through the hassle of getting your pitchforks out of storage.
Speaking of which... your accusation that they are lying means that Github has had nearly 37 days of total outage this year---that they're down for two and a half hours a day, every day, for a year straight. And by honest, I assume you mean "they are lying", as opposed to "they are using a different definition of uptime than I would like." Naturally, you have some evidence for these claims, right?
Also, technically something with 98.9999% uptime would still be a single 9 service...
I'm in the process of migrating an existing datastore to MariaDB+Galera, and so far it seems like everything I could hope for in a clustered RDBMS.
The biggest win for Galera is high-availability that actually works with minimal effort. (I've never experienced a high-availability solution not based on multi-master/all-nodes-hot principles that didn't cause more problems than it solved.)
They also claim some scalability wins at the front end, but I haven't really tested that, and am content with the performance not being terrible.
You've never had to prime a query cache on a MySQL server, have you? :)
git://github.com/{user}/{repo}.git
https://github.com/{user}/{repo}.git
EDIT: working, give it 30 seconds to start.
Anyways, Github is nice. Use it with caution. It cannot be full blown Enterprise ready grade service yet.
Typically I was in the middle of setting up a development environment on a new machine which has a lot of composer dependencies....
Oh well will have to go drink coffee in the sporadic sunshine :).