Live data from Hacker News

GitHub Packages Is Down

githubstatus.com

81–83 of 83 posts

Re: GitHub Packages Is Down

#81
post #66
post #57

Earlier quoted context omitted.

It's not even close to the same thing. Universities hosting mirrors piggybacked off academic networks; not just the computer kind but the social kind, where professors would regularly meet professors from other institutions at academic conferences. It was in the collective interests of the universities to set up mirrors to solve the pre-eminent issue of slow WAN networks. Today most companies need private package reg…

> the idea that GitHub is hosting everything in a single datacenter is laughable on its face. Personally I find the notion that GitHub is somehow magically superior to the rest of the entire internet a bit silly. I’ve worked on distributed systems my entire career, I have yet to find a single one that is completely immune to a datacenter outage, there is always some single point of failure not considered- often it is…

> you are basically suggesting that github, as a centralised system, is better equipped to deal with the distribution of packages than a literal distribution of package repositories?

No, that's not what I'm saying. I'm explaining why "inferior"-quality alternatives sometimes win: the market prefers a different metric. In this case, ease of operation, ease of setup, and price are more important than sheer uptime.

Re: GitHub Packages Is Down

#82
post #52

Earlier quoted context omitted.

you don't have to, but hb will ask you to if you have a saved credential because your quota on GitHub for downloading packages is much higher if you are logged in. anonymous stuff on GitHub is usually limited to 60 requests per hour per ip address. if you're authenticated, it's several hundred if not several thousand.

That sounds... problematic for people on big NATs? (e.g. universities?)

[deleted]

Re: GitHub Packages Is Down

#83
post #64

Earlier quoted context omitted.

I suspect this is the kind of advice that works for anyone, but would fail for everyone. That is, for most, it is a valid cost/benefit tradeoff to use the central option. Specifically, not just for them, but for everyone. If everyone was following this advice, it would likely start hitting scale/cost problems that would make running the mirrors of dubious value.

If you install packages on your linux infrastructure or docker images to provision anything, and those things are based on the “default” install, you are relying on the mirrors. That infrastructure is already “web scale”. It’s just a matter whether you make one image once and copy it thousands of times or if you actually spawn thousands of instances that talk to the mirrors. Setting up your own mirrors for internal u…

I meant for the sheer scale of how many are publishing to the mirrors more than the numbers that are pulling from them. But, fair that they are probably capable of more than I would expect, all told.
Post reply on HN