5 ms·

For your home setup: sure, it should be resolved soon, not too big of an issue. What's much more annoying is that this breaks CI/Docker builds. Right now you c

For your home setup: sure, it should be resolved soon, not too big of an issue. What's much more annoying is that this breaks CI/Docker builds. Right now you can't deploy new container images that depend on a MS repository. I hope it's resolved soon.

dvfjsdhgfv 5y ago
We had the same problems already in the 90s and resolved them by caching, it's unthinkable that the whole build is broken by a problem with an external dependence - if you assume everything will be 100% available you basically make sure a problem will happen.
- creshal 5y ago
  https://wiki.debian.org/AptCacherNg https://wiki.debian.org/AptCacherNg still exists and still works fine.
  - tambre 5y ago
    Aptly [0] is also really nice for maintaining mirrors and one's own Apt repositories though it is unmaintained. [0]: https://github.com/aptly-dev/aptly https://github.com/aptly-dev/aptly
- silon42 5y ago
  Not caching... mirroring or vendoring.
- rkeene2 5y ago
  I wrote "hashcache" [0] [1] for this for my Linux distribution (which is the build from source variety) to avoid issues with upstream going away, or worse changing the contents of a file. Many different caches can be used, in case one is down as well. Simple example download script at [2]. [0] http://hashcache.rkeene.org/ http://hashcache.rkeene.org/ [1] https://chiselapp.com/user/rkeene/repository/hashcache/ https://chiselapp.com/user/rkeene/repository/hashcache/ [2] https://kitcreator.rkeene.org/fossil/artifact/d546c4b48dfce807 https://kitcreator.rkeene.org/fossil/artifact/d546c4b48dfce8...
ohgodplsno 5y ago
As the other comment says: cache it yourself. Not only will you save time downloading it, avoid sudden version changes, your build environment should really not depend on pulling things out of your control every single time
- iso1631 5y ago
  The modern argument would be that you're more likely to have problems with your own cache than someone else, and you should just use caching as a service.
  - ohgodplsno 5y ago
    The modern argument is most likely made by people who sell caching as a service and have an interest in you blowing $500/month on a glorified FTP or a script to setup Artifactory.
    - Symbiote 5y ago
      But this is Microsoft's cache, so it is already essentially on the same network, and is free.
  - pdpi 5y ago
    It's a lot easier to remove yourself from the critical path if your cache has problems than it is to add the caching after the fact when a third party is having problems, though.
    - hnlmorg 5y ago
      Exactly this! You plan for failure. What happens if your cache fails? You fall back to Microsoft. But what happens if Microsoft fails and you don't have a cache? Well you build a cache in advance and default to that. Caches can also improve build time, allow for security tools to scan, and other such benefits too. So there are other benefits outside of creating a redundancy.
    - 5y ago

dvfjsdhgfv 5y ago

We had the same problems already in the 90s and resolved them by caching, it's unthinkable that the whole build is broken by a problem with an external dependence - if you assume everything will be 100% available you basically make sure a problem will happen.

creshal 5y ago
https://wiki.debian.org/AptCacherNg https://wiki.debian.org/AptCacherNg still exists and still works fine.
- tambre 5y ago
  Aptly [0] is also really nice for maintaining mirrors and one's own Apt repositories though it is unmaintained. [0]: https://github.com/aptly-dev/aptly https://github.com/aptly-dev/aptly
silon42 5y ago
Not caching... mirroring or vendoring.
rkeene2 5y ago
I wrote "hashcache" [0] [1] for this for my Linux distribution (which is the build from source variety) to avoid issues with upstream going away, or worse changing the contents of a file. Many different caches can be used, in case one is down as well. Simple example download script at [2]. [0] http://hashcache.rkeene.org/ http://hashcache.rkeene.org/ [1] https://chiselapp.com/user/rkeene/repository/hashcache/ https://chiselapp.com/user/rkeene/repository/hashcache/ [2] https://kitcreator.rkeene.org/fossil/artifact/d546c4b48dfce807 https://kitcreator.rkeene.org/fossil/artifact/d546c4b48dfce8...

ohgodplsno 5y ago

As the other comment says: cache it yourself. Not only will you save time downloading it, avoid sudden version changes, your build environment should really not depend on pulling things out of your control every single time

iso1631 5y ago
The modern argument would be that you're more likely to have problems with your own cache than someone else, and you should just use caching as a service.
- ohgodplsno 5y ago
  The modern argument is most likely made by people who sell caching as a service and have an interest in you blowing $500/month on a glorified FTP or a script to setup Artifactory.
  - Symbiote 5y ago
    But this is Microsoft's cache, so it is already essentially on the same network, and is free.
- pdpi 5y ago
  It's a lot easier to remove yourself from the critical path if your cache has problems than it is to add the caching after the fact when a third party is having problems, though.
  - hnlmorg 5y ago
    Exactly this! You plan for failure. What happens if your cache fails? You fall back to Microsoft. But what happens if Microsoft fails and you don't have a cache? Well you build a cache in advance and default to that. Caches can also improve build time, allow for security tools to scan, and other such benefits too. So there are other benefits outside of creating a redundancy.
  - 5y ago