Live data from Hacker News

Gx: A package management tool built around IPFS

github.com

31–40 of 46 posts

Re: Gx: A package management tool built around IPFS

#31
post #27
post #26

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.

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

#32

Especially 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…

Adding in a good way to do signed packages and repos is very high priority for us. If you have ideas on that, i'd love to discuss things here: https://github.com/whyrusleeping/gx/issues/47

Thanks!

Re: Gx: A package management tool built around IPFS

#33
post #31
post #27

Earlier 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?

Currently no, you only download content you have requested, and you can remove any content you have not pinned to hold onto via a garbage collection command. When bitswap is more mature you may get more content on your system, but that will probably be configurable.

Re: Gx: A package management tool built around IPFS

#34
> 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

#35
post #34

> 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.

Note: debian have a similar projecthttps://wiki.debian.org/ReproducibleBuilds

Re: Gx: A package management tool built around IPFS

#36
Whenever 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, 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

#38

Whenever 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."

Re: Gx: A package management tool built around IPFS

#39

I'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)

We also need an IPFS source cache, not just binary cache. It would be an immutable source mirroring for all of our dependencies allowing reproducible builds from source (which is sometimes required as not all compiler flags are specified by default). I've had tons of problems buildings from source in Nix because upstream source urls break.

Re: Gx: A package management tool built around IPFS

#40

Whenever 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."

When a corporation makes a tool, it's to do some job it needs to do. Usually features are added over time to provide for the requirements of its users and various teams. In this way, it only does what it needs to do, and is usually kept around a long time, used by everyone, and rarely replaced, because it can always be modified to fit a new feature. It ends up being pretty feature-complete and useful (which is sad because they usually end up locked up as intellectual property).

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.

Post reply on HN