141–150 of 175 posts
Earlier quoted context omitted.
Which can go down too.
Still, a lot less risky. Self-hosted hub is something you have more control over and is less likely to be DDoS'ed by some Chinese harm-wishers.
Earlier quoted context omitted.
Ok, but I thought the business model here was to be the facebook of code repository. And I don't see the later suffering as many outage as the former (maybe because I am not all day long on FB, mind).
Because people aren't DDOSing Facebook by telling their CI servers to constantly refetch all the dependencies every goddamn build.
Git clients probably supply some anonymous but consistent identifying information when doing a standard pull... per-client rate limiting, anybody?
It's a nice idea[l] at least; practically speaking there's enough bandwidth to keep the current disaster ticking over, so... :(
The common complaint is that when github goes down so do issue trackers/project management/docs etc. What are the equivalent alternatives for these systems that are distributed, so tolerant to downtime. If you are in a situation that you're using a DVCS but relying on centralised everything else, and saying that you're unable to work because your Issue tracker/CI server is down, have you really gained anything over t…
http://fossil-scm.org/
Earlier quoted context omitted.
You could have separate centralized servers for each project, though, instead of one big point of failure for all the projects.
That would make the downtime less correlated, but if it was higher in aggregate, would it be a net benefit?
Earlier quoted context omitted.
Ok, but I thought the business model here was to be the facebook of code repository. And I don't see the later suffering as many outage as the former (maybe because I am not all day long on FB, mind).
Because people aren't DDOSing Facebook by telling their CI servers to constantly refetch all the dependencies every goddamn build.
If only we had a version control system that didn't rely on a central hub...
We do, it's called Fossil! http://fossil-scm.org/ Fossil tracks issues (tickets), documentation, and wiki pages at the same level as it tracks code, so when you clone a Fossil repo, everything gets downloaded to your local computer. You can then respond to tickets and perform repo maintenance offline, syncing everything to the server when you're back up. Edit: A few weeks ago I got a job a one-hour train ride away. I…
Earlier quoted context omitted.
Depends how his deployment pipeline is plumbed in. If he's dependent on Travis for builds (for example), he can't just switch.
Depending on services from others for your own business without having a SLA is just a disaster waiting to happen. Along the lines of "two is one, one is none", anything that you don’t own or where you don’t have a SLA has to be considered not existing for a business.
Earlier quoted context omitted.
Oh, I agree. But I still think Git, even over IPFS, has significant failings. Mainly, how do I share the issues and other problems that Github has did their own GUI for? Fossil SCM seems to fit that bill. As another user said, they can address issues in a local, non-connected manner, and then merge the issues back to main. The last piece would be to use IPNS so you can have the same key for a changing package. I just…
> Mainly, how do I share the issues and other problems that Github has did their own GUI for? I think this should not be done in the same system as where people store their source repos. Mixing the two is convenient, but can stifle innovation. Better to have flexible and well documented abstractions and good separation of concerns.
Could you elaborate?
I think I've heard the argument before, but I don't really see how. These outages show up again and again, partly because people cannot access the project issues.
If only we had a version control system that didn't rely on a central hub...
We do, it's called Fossil! http://fossil-scm.org/ Fossil tracks issues (tickets), documentation, and wiki pages at the same level as it tracks code, so when you clone a Fossil repo, everything gets downloaded to your local computer. You can then respond to tickets and perform repo maintenance offline, syncing everything to the server when you're back up. Edit: A few weeks ago I got a job a one-hour train ride away. I…
Off-topic, but I'd reccomend that you install HTTPS Everywhere: https://www.eff.org/https-everywhere - the fact that you are linking the HTTP version means you don't have this very basic extension that really improves your security.
It's interesting to me to see all the services that depend on or integrate with GitHub in some way, as they all have problems at times like this. My side project https://statusgator.com shows currently a dozen different services all posting warnings or down notices on their status pages. It's mostly CI services and the like, all which break in some way when GitHub is down.
> It's mostly CI services and the like, all which break in some way when GitHub is down. It boggles my mind. If you're not adding a new dependency to the project, your CI server should never hit GitHub when doing builds. Who sets those things up without local cache?