Hacker News new | ask | show | jobs
by seoaeu 1667 days ago
Comparing uptime between comparable services is reasonable. (Though I will say that having used some GitHub competitors, counting the number of features really overlooks the actual user experience between them.)

Comparing uptime between a production service and a single personal server however isn’t reasonable. You haven’t even said what your server actually does, only that it rarely goes down!
1 comments
fartcannon 1667 days ago
His point is that if everyone had their own server, everyone would have better uptime than they currently get using github.

The complexity and load of github is the problem.

link
notriddle 1667 days ago
The problem is that you’re computing the probability of one service going down, when I actually care about the union of the downtime of all of the services that I need (or, equivalently, the intersection of their uptime).

If every Arch package hosted its own source code, then even if each one of them has better uptime than GitHub, at least one of them is probably going to go down every single day (assuming their uptime is uncorrelated).

If you can personally centralize all of your own work on a server that you host, like a company-run Mattermost or something, and you have someone who can be on call to keep it up, do it. The result will, as you’ve described, be simpler and better than GitHub. But expecting every individual to run their own Git server is just stupid, because then my project is going to wind up depending on dozens of separately-hosted Git servers and I’m back to taking the intersection of their uptimes to compute the uptime of the whole system. There’s a sweet-spot here; GitHub is above the sweet spot, but a lot of “FOSS projects” (the kind that have a single maintainer) are below it.

link
fartcannon 1666 days ago
I remain unconvinced. If github goes down, it goes down for everyones projects. If everyone ran their own servers, only one or two packages would go down at a time. So instead of 100% its like 0.1%. And since they're simpler, as per OPs comment, they'd stay up longer. So a distributed git, as it was originally intended to be used, is more robust than a single point of failure like github.

Perhaps githubs value is elsewhere.

link
notriddle 1666 days ago
For a lot of use cases, there really isn’t any important difference between 100% and 0.1%. If any of the source tarballs are unavailable, then I can’t produce a build, and the fact that some of them are available isn’t much consolation. I’m blocked either way.

Especially for an organization like Arch Linux, the solution is really obvious; maintain your own mirror. Debian and Fedora do it, so can they.

link
fartcannon 1666 days ago
Just to clarify, if 100% of all packages go down, thats much worse than 100% of just your needed packages.

But I agree: mirrors is the key!

link
AshamedCaptain 1666 days ago
> There’s a sweet-spot here; GitHub is above the sweet spot, but a lot of “FOSS projects” (the kind that have a single maintainer) are below it.

That's what I'm putting into question, specifically for Github.

link