51–60 of 279 posts
Earlier quoted context omitted.
> That's just shifting the trust to a different (smaller) group of people. Practically speaking, shifting trust from a large, anonymous group of people, to a small group of people who are known and trusted by the community is a pretty good solution.
Please list the group of people you trust to manage 1,037,274 packages.
I have been installing purescript using Nix from https://github.com/justinwoo/easy-purescript-nix for a while now. It works quite well and I get to avoid npm.
Not actually malicious. It doesn't steal user data, drop malware, or damage a computer. Just crashes the library. Looks like another developer-developer slap fight.
While people give reasonable counter-arguments here to your point, it gets me thinking - I wonder if we could find a truly benign form of "malicious code" that "good guys" could use to find attack vectors before the "bad guys" do. Perhaps there could be a website set up to get pinged by "malicious" installers? Perhaps it displays stats of some sort? It could turn into a friendly game.
I’m on my phone at the moment but if you (or anyone else) has the knowledge/interest in taking a look at what I’ve done I’d love to release it with a partner.
Earlier quoted context omitted.
> That's just shifting the trust to a different (smaller) group of people. Practically speaking, shifting trust from a large, anonymous group of people, to a small group of people who are known and trusted by the community is a pretty good solution.
Please list the group of people you trust to manage 1,037,274 packages.
They “only” manage ~18K packages, but those 18K do a lot more than NPM:
https://people.debian.org/~corsac/
perhaps number of packages is the wrong metric.
Earlier quoted context omitted.
I beg your pardon, but if I am using this library as part of a shipping piece of software-as-a-service, and I am in the middle of shipping a new feature when suddenly things mysteriously crash... If I later discover that the crash was put there deliberately, I am going to call that malice, and malice that has directly impacted a functioning business and its customers. It's no different than a disgruntled person putti…
The refund for the amount you paid for the library is on its way. Once again I'm reminded about that sentence someone once said. With random open-source libraries you're dealing with something someone else put out there just because they wanted to, having any kinds of expectations that someone will or won't do something is seriously short-sighted and even pretentious. Do you go around running random .exe-s you find f…
There is absolutely zero chance that you can put malware into an open source project, give it away, and then when sued, stand up and say, "It was free, what do people expect?"
You can call me pretentious until night turns back into day, and maybe I am, but the thing we're discussing is a matter of law, and it there are nuänces above and beyond what random people on the Internet would like to believe about how giving software away works.
(edited to add a pretentious diæresis)
Earlier quoted context omitted.
Please list the group of people you trust to manage 1,037,274 packages.
I trust these people to manage software packages: https://nm.debian.org/public/people/dm_all They “only” manage ~18K packages, but those 18K do a lot more than NPM: https://people.debian.org/~corsac/ perhaps number of packages is the wrong metric.
I'm not convinced this is a model that can work for programming libraries.
Another reminder of how annoying it is for a package system to have unqualified package names. Having to ask someone to gift a `purescript` package shouldn't even be a thing. It should've been `@shinn/purescript` and the compiler developers just create their own `@whatever/purescript`. This is something Elm and many others got right. https://package.elm-lang.org/ It's just infinitely, obviously better. You see all so…
These are the social issues associated with a hostile fork.
Earlier quoted context omitted.
The refund for the amount you paid for the library is on its way. Once again I'm reminded about that sentence someone once said. With random open-source libraries you're dealing with something someone else put out there just because they wanted to, having any kinds of expectations that someone will or won't do something is seriously short-sighted and even pretentious. Do you go around running random .exe-s you find f…
You are not a lawyer, because if you were, you would be aware that there is case law establishing that just because you don't charge for it, doesn't mean you aren't providing an implied warranty and aren't taking implied liability. There is absolutely zero chance that you can put malware into an open source project, give it away, and then when sued, stand up and say, "It was free, what do people expect?" You can call…
Earlier quoted context omitted.
Perl (cpan), Python (pip or conda), Ruby (gem), and Rust (cargo) all behave as NPM does, so that doesn't seem to be the explanation here.
cargo, at least, does this for the reason Fellshard gives - the Rust team essentially commissioned a copy of Ruby's bundler, without considering whether there was anything to learn from any other language's ecosystem.