Isn't IPFS based on bitcoin technologies? Does it have the problem that bitcoin had (still has?) where you have to download the entire blockchain -- which in this case is the entire network? I'm guessing this has been solved since I last heard about the issue...
Not at all. It's more like a giant bittorrent full of everyone's git repos.
Gx: A package management tool built around IPFS
31–40 of 46 posts
Re: Gx: A package management tool built around IPFS
#32Especially after all the NPM drama, I'd be really interested in a distributed package manager that: (1) Validates that the specific revision of a package you're dependent on hasn't changed (i.e. checksum of the package stays the same), and (2) On upgrade, validates that ownership of the package hasn't changed (i.e. package is signed by the same person), or that any change in ownership is authorized/authenticated and…
Thanks!
Re: Gx: A package management tool built around IPFS
#33Earlier quoted context omitted.
Not at all. It's more like a giant bittorrent full of everyone's git repos.
Ok, so my question still stands, does this mean I will be eventually downloading the entire IPFS network onto my computer? What is the solution to that problem?
Re: Gx: A package management tool built around IPFS
#34This is something that we should have all moved to years ago. Our drives are big enough for most shared libraries to move away from. Though I am intrested on how they handle something like KDE and KDE applications.
Re: Gx: A package management tool built around IPFS
#35> Nix builds packages in isolation from each other. This ensures that they are reproducible and don’t have undeclared dependencies, so if a package works on one machine, it will also work on another. This is something that we should have all moved to years ago. Our drives are big enough for most shared libraries to move away from. Though I am intrested on how they handle something like KDE and KDE applications.
Re: Gx: A package management tool built around IPFS
#36Package managers have a long history of being poorly implemented. Look at CPAN, RPM, Alien, Pacman, Nix, etc as examples of what was a good idea, but still has various flaws. We already have everything we need, it's just not all built into the same tool. Adding new technology to a new tool doesn't make a better tool, it just makes yet another incomplete tool.
Re: Gx: A package management tool built around IPFS
#37I'm really hoping someone adds an IPFS binary cache system for Nix/NixOS. (Nix already packages tons of Go/python/javascript/rust libraries and binaries)
Re: Gx: A package management tool built around IPFS
#38Whenever I see "complicated technology of which there are 1000 implementations" combined with "built around X" I think somebody just wanted an excuse to play with X and has no intent on building a good tool. Package managers have a long history of being poorly implemented. Look at CPAN, RPM, Alien, Pacman, Nix, etc as examples of what was a good idea, but still has various flaws. We already have everything we need, i…
If I were to grant your comment the same amount of charity as you have granted this project, I would summarize it as, "This project has problems like all the rest. If you don't make it better, it's lame."
Re: Gx: A package management tool built around IPFS
#39I'm really hoping someone adds an IPFS binary cache system for Nix/NixOS. (Nix already packages tons of Go/python/javascript/rust libraries and binaries)
Re: Gx: A package management tool built around IPFS
#40Whenever I see "complicated technology of which there are 1000 implementations" combined with "built around X" I think somebody just wanted an excuse to play with X and has no intent on building a good tool. Package managers have a long history of being poorly implemented. Look at CPAN, RPM, Alien, Pacman, Nix, etc as examples of what was a good idea, but still has various flaws. We already have everything we need, i…
I think it would be relevant to this discussion to point out the flaws in Nix rather than vaguely refer to them. Please explain how to make the more complete tool from any of the 5 package managers you mentioned. If I were to grant your comment the same amount of charity as you have granted this project, I would summarize it as, "This project has problems like all the rest. If you don't make it better, it's lame."
Non-corporate tools, on the other hand, are typically made by people who need to do something and want to do it their own way. It's not that they couldn't make due with an existing tool - the functionality probably existed in another tool or tools - they just want to do it differently, with some kind of interesting twist. The end result? Reinventing the wheel with maybe one new feature, and missing all the ones they didn't need/want. Do this a hundred times and you have a hundred tools that are useful to some people, but not most people.
I'm not saying it's lame, i'm saying it's a waste of engineering effort.