Live data from Hacker News

GitHub Broken Download URLs

github.com

61–70 of 101 posts

Re: GitHub Broken Download URLs

#61
post #53
post #16

This has also broken a bunch of packages in the arch user repository, for example https://aur.archlinux.org/packages/dendrite/ :(

This sounds for the better. Not having code mirrors (as other distribution channels) sounds not just insecure, but borderly malicious.

I suspect you have no idea what AUR is and how it works and furthermore, you have no experience with software packaging.

If a project is using github to publish releases, where else are consumers of that software going to get them from?

Having all sources of everything that is packaged backed up is a must for the official repository of a competent distro, but even in that case there is no reason not to use github in normal operation.

Re: GitHub Broken Download URLs

#62
post #53
post #16

This has also broken a bunch of packages in the arch user repository, for example https://aur.archlinux.org/packages/dendrite/ :(

This sounds for the better. Not having code mirrors (as other distribution channels) sounds not just insecure, but borderly malicious.

Depends what you mean by better. It's kind of annoying for me when trying to install some software I want to actually use, and I just can't.

Re: GitHub Broken Download URLs

#63
post #43

Earlier quoted context omitted.

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!

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.

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.

Re: GitHub Broken Download URLs

#64
post #23

Whether this specific problem is intentional or not, these kinds of problems show the issue with using a single centralized service for distribution of third-party dependencies. But it's just so much more darned convenient than hosting your own Git server! It would be super cool if there was a decentralized alternative to GitHub, that used Git under the hood. Perhaps one would upload their repositories to a node, whi…

Some software like gitea [1] can mirror github repositories (or vice versa). Some other software like fossil [2] is designed to do not just source code but also issue tracking etc. in a decentralised fashion.

It's definitely more work than just throwing it onto GitHub though, something more convenient would be really cool.

[1] https://gitea.io/ [2] https://fossil-scm.org/

Re: GitHub Broken Download URLs

#65
post #7

At least now I know why my nix builds are failing... Odd for something like this to slip through and not be rolled back immediately. Unless it was intentional, in which case it would be even more odd to not communicate this widely beforehand.

If Github doesn't at least monitor their 404 error rate for large-scale spikes, whoever is in charge of SRE should be fired. With no announcements and no response to a now two day old bug report, I see two possibilities: 1)Their monitoring of their infrastructure and monitoring of issues is shockingly incompetent for a company of their size and importance (the fact that it is a US holiday is irrelevant.) 2)This was 1…

From the discussion thread on GitHub[0]:

A change in the handling of URL schemes was deployed a couple of days ago that caused the regression being discussed here. Due to the amount of traffic that the archive endpoints see, and the high baseline of 404s on them, this regression did not cause an unusual increase of errors that would've caused our alerting to kick in. The change has just been rolled back, so the issue is fixed. We will investigate this issue further after the weekend and take the appropriate steps to make sure similar regressions don't happen in the future.

[0] https://github.com/github/feedback/discussions/8149#discussi...

Re: GitHub Broken Download URLs

#66
post #7

At least now I know why my nix builds are failing... Odd for something like this to slip through and not be rolled back immediately. Unless it was intentional, in which case it would be even more odd to not communicate this widely beforehand.

If Github doesn't at least monitor their 404 error rate for large-scale spikes, whoever is in charge of SRE should be fired. With no announcements and no response to a now two day old bug report, I see two possibilities: 1)Their monitoring of their infrastructure and monitoring of issues is shockingly incompetent for a company of their size and importance (the fact that it is a US holiday is irrelevant.) 2)This was 1…

You might want to not pick up your pitchfork so quickly.

> A change in the handling of URL schemes was deployed a couple of days ago that caused the regression being discussed here. Due to the amount of traffic that the archive endpoints see, and the high baseline of 404s on them, this regression did not cause an unusual increase of errors that would've caused our alerting to kick in. The change has just been rolled back, so the issue is fixed. We will investigate this issue further after the weekend and take the appropriate steps to make sure similar regressions don't happen in the future.

Re: GitHub Broken Download URLs

#67
post #7

At least now I know why my nix builds are failing... Odd for something like this to slip through and not be rolled back immediately. Unless it was intentional, in which case it would be even more odd to not communicate this widely beforehand.

Reproducible builds via IPFS when?

Re: GitHub Broken Download URLs

#68
post #7

At least now I know why my nix builds are failing... Odd for something like this to slip through and not be rolled back immediately. Unless it was intentional, in which case it would be even more odd to not communicate this widely beforehand.

If Github doesn't at least monitor their 404 error rate for large-scale spikes, whoever is in charge of SRE should be fired. With no announcements and no response to a now two day old bug report, I see two possibilities: 1)Their monitoring of their infrastructure and monitoring of issues is shockingly incompetent for a company of their size and importance (the fact that it is a US holiday is irrelevant.) 2)This was 1…

> If Github doesn't at least monitor their 404 error rate for large-scale spikes

"Is that a service we can charge for?!"

Re: GitHub Broken Download URLs

#69
post #67
post #7

At least now I know why my nix builds are failing... Odd for something like this to slip through and not be rolled back immediately. Unless it was intentional, in which case it would be even more odd to not communicate this widely beforehand.

Reproducible builds via IPFS when?

And then your IPFS pin service has a down time.
Post reply on HN