3 ms·
> npm’s download stats are naïve by design: they are simply a count of the number of HTTP 200 responses we served that were tarball files, i.e. packages. This m
by MuffinFlavored 3y ago
> npm’s download stats are naïve by design: they are simply a count of the number of HTTP 200 responses we served that were tarball files, i.e. packages. This means the number includes:
>
> automated build servers
>
> downloads by mirrors
>
> robots that download every package for analysis
When we talk about how we can help the planet climate change wise, there has to be a huge amount left on the table when it comes to build environments recreating themselves from scratch multiple times a day (CI/CD without "proper" caching) at a huge scale
I wonder what 1 person driving an EV does for the planet vs 1 commercial airliner vs 1 developer implementing "cache" at a huge company/project
- acdha 3y agoI do have to say that was the silver lining to Docker Hub starting to rate-limit. So many people finally got around to implementing caching once it broke builds, and then it was usually accompanied by realizing that they’d left a significant amount of build time on the floor for what was usually a very modest amount of work.
- BobbyTables2 3y agoImagine if Docker’s cache understood package managers. Then rebuilding a container when the dependent upstream packages hadn’t changed would do absolutely nothing. Today we only chose between rarely rebuilding and excessively doing so.
- viraptor 3y agoOr move to nixpkgs builds instead of docker and get package/file level caching, while also being able to create a docker image as a result.