Live data from Hacker News

Gx: A package management tool built around IPFS

github.com

41–46 of 46 posts

Re: Gx: A package management tool built around IPFS

#41

Developer here! i didn't expect to wake up to my github feed being destroyed by this. gx was originally a response to being frustrated with go's package management system, so i wrote gx and gx-go to handle go dependencies in a nice(ish) way. We made the decision to keep gx itself as agnostic and extensible as possible, package manager logic is largely the same across the board, so why not provide a nice base layer fo…

jbenet here. We're all very excited about the dev interest in gx and ipfs! thanks! we did not expect attention on it this soon! Please check it out, try it, and give us feedback! Please know though that things are still super early, and very rough! We do not think our pkg mgment efforts are UX ready for end users who want something strictly better today. But they are ready for early adopters who want to think or hack…

Great work on this stuff.

Question about package managers built on ipfs, and ipfs in general: how do you ensure the packages/files you depend on will always be available? Is the idea that there would be at least one entity pledging to host every package for eternity, or if you depend on obscure packages would it be wise to run your own mirror of the packages you use? Or something else?

Re: Gx: A package management tool built around IPFS

#42

Earlier quoted context omitted.

jbenet here. We're all very excited about the dev interest in gx and ipfs! thanks! we did not expect attention on it this soon! Please check it out, try it, and give us feedback! Please know though that things are still super early, and very rough! We do not think our pkg mgment efforts are UX ready for end users who want something strictly better today. But they are ready for early adopters who want to think or hack…

Great work on this stuff. Question about package managers built on ipfs, and ipfs in general: how do you ensure the packages/files you depend on will always be available? Is the idea that there would be at least one entity pledging to host every package for eternity, or if you depend on obscure packages would it be wise to run your own mirror of the packages you use? Or something else?

Thanks! Many answers:

- storing is super cheap. seeding not v expensive. i think the entire npm reg is - (soon can ship entire registries in USB keys!)

- many individuals and orgs should keep/replicate what they depend on

- tools like ipfs-cluster will help organize nodes like a RAID array

- can pay services to back things up (on service infra in vogue)

- can pay _the network_ to back things up -- see http://filecoin.io

Re: Gx: A package management tool built around IPFS

#43

Earlier quoted context omitted.

jbenet here. We're all very excited about the dev interest in gx and ipfs! thanks! we did not expect attention on it this soon! Please check it out, try it, and give us feedback! Please know though that things are still super early, and very rough! We do not think our pkg mgment efforts are UX ready for end users who want something strictly better today. But they are ready for early adopters who want to think or hack…

Great work on this stuff. Question about package managers built on ipfs, and ipfs in general: how do you ensure the packages/files you depend on will always be available? Is the idea that there would be at least one entity pledging to host every package for eternity, or if you depend on obscure packages would it be wise to run your own mirror of the packages you use? Or something else?

When I want files available on IPFS, I just pin them to the appropriate machines.

    Ipfs pin add [key]
And my material now has another seed machine. It works, and is clean and efficient. One thing: I share everything in a directory, so the root directory name gets clobbered with the multi hash, and all the files in it retain their pretty names.

Re: Gx: A package management tool built around IPFS

#44

Earlier quoted context omitted.

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

This comment demonstrates that you do not have any criticism at all regarding this project. While reading it I could only think of Visual Source Safe and Git, which I believe counters your entire premise.

Re: Gx: A package management tool built around IPFS

#45

Earlier quoted context omitted.

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

This comment demonstrates that you do not have any criticism at all regarding this project. While reading it I could only think of Visual Source Safe and Git, which I believe counters your entire premise.

Git was created basically because there wasn't an open source implementation of BitKeeper, and BitKeeper was unique in its function. If at all possible Torvalds would have stayed away from making Git (in fact he said so himself). This is different than reinventing a wheel with existing functionality. I don't see how VSS relates, since it's used for different things (like comparing Oracle to SQLite?)

Re: Gx: A package management tool built around IPFS

#46

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…

Doesn't npm have something like Composer's composer.lock?
Post reply on HN