GitHub Faces 'Major Service Outage' [Update] (github.com) 39
Code repository GitHub is facing a major service outage, it said moments ago. Earlier today, the company said it was facing a minor service outage. The downtime comes less than two weeks after it was facing another "minor service outage," which lasted for several hours. The cause for today's disruption remains unknown. The open source company's Twitter feed suggests it has faced several issues over the past few months.
Update: GitHub reports all the services are now operational.
Update: GitHub reports all the services are now operational.
This is why I use GitLab (Score:1)
Re:This is why I use GitLab (Score:4, Insightful)
GitLab also doesn't have the growing pains that GitHub faces at scale. When GitLab reaches that scale, either 1) they'll have the same issues, or 2) it'll have already been solved by other projects (like GitHub), and they would have learned from where others implemented fixes and new solutions already.
Re:This is why I use GitLab (Score:4, Insightful)
For me, GitLab scales great in one respect: I can host a completely isolated instance of gitlab. So if it's an internet wide repository, I pretty much have an obligatory github mirror of it because that's the 'proper' thing to do. However when github goes down as it tends to do, it's not a huge deal because my team can still collaborate on our own instance of gitlab.
Re: (Score:1)
Build your own GitLab (Score:2)
GitLab scales great in one respect: I can host a completely isolated instance of gitlab.
Case in point: Build your own GitLab appliance with a Raspberry Pi [gitlab.com]. I wonder if anyone else has built an appliance to run Savane, the SourceForge fork powering the GNU Savannah repository farm.
Re: (Score:2)
So, what you're saying is that I get to avoid all the growing pains of GitHub by sticking to GitLab, and free ride on GitHub's growing pains? Plus use a more open solution? What's the downside?
really? (Score:2)
Maybe is down, because everyone is checking if is really down...
Re: (Score:2)
An interesting theory... DDOS a service provider by posting a story on Slashdot saying that service is down. Everyone here starts hammering the service, and - viola!
Re: (Score:2)
Re: (Score:2)
Maybe is down, because everyone is checking if is really down...
Are they checking because it's down or is it down because they are checking. The world may never know.
Probably (Score:2)
because of systemd issues. Nah in all seriousness its probably the feds installing backdoors.
This is why git sucks. (Score:1, Funny)
Re: (Score:2, Funny)
Re: (Score:2)
Microsoft Team Foundation Server: It never fails under load.
(Because there is no load)
Re: (Score:1)
The good and the bad (Score:2)
Re: (Score:2)
Of course, even if that's the case, it's easy enough to change origin or add a new remote if it becomes intolerable. I tend to have an 'internal' remote and a 'public' remote, and 'upstream' so that github going down is no big deal, but when it's up people new to projects can find it and submit pull requests when it can.
Basically opportunistically taking advantage of 'everyone is on github' without the downsides of 'screwed when it goes down'.
Re: (Score:1)
Re: (Score:3)
Not to mention all the open source projects that rely on GitHub for distribution. I wonder how much Node.js development gets done when GitHub is down.
Other peoples computers (Score:2)
That's what the cloud be.
Excessive Dependency Syndrome (Score:5, Insightful)
I've spent a 20+ year career in IT, and have noticed the trend over the last decade has been to rely almost fully on a service you don't control for a key part of operations. Most of my work has been with Azure lately, and Microsoft is shifting from releasing updates in packaged format that they publish and host to just pumping it out onto GitHub. There was a story last year about how tons of web projects were broken when a developer removed a portion of functionality from a JavaScript framework hosted publically -- and it turned out to be a trivial sting-manipulation function.
There is nothing wrong with not reinventing the wheel every time and using other peoples' resources. There is something very wrong with assuming that third parties will keep their systems running 100% of the time and never have bad days. Even Microsoft won't guarantee that Azure regions, of which most are _collections_ of fully redundant data centers, will be fully available all the time and that your applications will never experience downtime. You should never assume a resource will be published in the same place and remain online forever, nor should you rely fully on a third party service to provide your only means of providing the service you're providing.
Re: (Score:1)
Re: (Score:2)
I agree with your general sentiment. Software devs cares less and less about good packaging and publishing a manageable low frequency stream of 'releases' for folks to consume, but not uselessly long token release cycles. Part of this is overconfidence in continuous integration, part of it is a misunderstanding of 'Agile', part of it is that on the whole developers are currently a bit spoiled by the way industry worships the skill of software development so they don't have to do things like make lives eas
Re: (Score:1)
Re: (Score:2)
Can in part blame containers and things like ansible/puppet/chef/salt.
They are all useful tools for adequately skilled admins to manage what they put together, but increasingly it's been a crutch of software devs to not bother doing good packaging and release management. So what if a hapless admin is slapped with some inscrutible stack trace or syntax error? So what if you get lazy and you ship a vulnerable system library that got updated by the distro vendor ages ago? The alternative would be spending a
As of 14:00 EDT (Score:2)
The status page reports "Everything operating normally."
That's why you have backups (Score:2)
You don't host your code on GitHub *only*, right?
You have mirrors on GitLab, Savannah, and a public repository at project's website (say, git.example.org), a local copy on your machine, and - of course - a copy stored safely at an off-site backup location (Tarsnap, S3, hubiC, etc.). I thought so.
The fact that GitHub went down is just a minor inconvenience to you, right?