41–50 of 82 posts
Least reliable service that I pay for by a long shot.
Have you tried Bitbucket? While it lacks a lot of the social integration, it has the benefit of giving you 5 free private repositories.
Earlier quoted context omitted.
Must not pay for very many services? https://status.github.com/graphs/past_month
To be fair 99.77% uptime isn't very good.
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.
I find it somewhat odd that, given git's emphasis on distributed version control, we see so many git users have centralized themselves quite heavily on GitHub. 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 u…
You can also add multiple urls to your remotes. When you push, it'll go to all of them. I do this at home with a tiny server on a mini-atx box and github. Set it and forget it. 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.
I find it somewhat odd that, given git's emphasis on distributed version control, we see so many git users have centralized themselves quite heavily on GitHub. 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 u…
git remote add my_other_server_that_is_not_github git://my.oth.er/server/that/is/not/github.gitI find it somewhat odd that, given git's emphasis on distributed version control, we see so many git users have centralized themselves quite heavily on GitHub. 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 u…
How is it at all odd? Github offers a convenient platform for using git. People use it. 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…
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
I find it somewhat odd that, given git's emphasis on distributed version control, we see so many git users have centralized themselves quite heavily on GitHub. 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 u…
Even worse is other tools that rely on Github, like Homebrew (Mac OS X package manager) which breaks in various silly ways when Github is down. 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.
Earlier quoted context omitted.
To be fair 99.77% uptime isn't very good.
That isn't fair at all. 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%…
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.
Earlier quoted context omitted.
They have a typical master/slave setup with memcached on the front. http://www.slideshare.net/err/inside-github
Since they're using MySQL, is there a technical reason (as opposed to historical/lack of time reason) they're not using Galera Cluster? 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.
Why Unicorn Why!
So, what's better than Unicorn ?