681–690 of 827 posts
Does this series of tweets [0] seem rather odd to anyone? He seems to be calling people soulless and pondering his own "Power and Responsibility". [0] https://twitter.com/izs/status/712510512974716931
Earlier quoted context omitted.
It's not one less thing to think about which is exactly the point. If you install 1 dep and it has 100 deps you now have 101 things to think about.
Or, you could look at it, it's 101 fewer things to think about. Besides, we're talking about a package that doesn't have any dependencies.
Earlier quoted context omitted.
Let's remember that NPM Inc has also been toying with the idea of banning IPs associated with "bad people" for behaviour outside of NPM itself. In other words: they think it's morally justifiable to ban a company's IP address(es) from the NPM service because one of their employees said something objectionable on Twitter (not involving NPM or any of its representatives). And what should the company do if their employe…
Care to give a source for that claim?
The entire ordeal happened back in January (I think), around the same time as some other npm drama (e.g. https://github.com/nodejs/node/issues/3959 and https://github.com/nodejs/TSC/issues/21 and https://github.com/nodejs/NG/issues/26, leading up to https://github.com/nodejs/NG/issues/29) -- the twitter incident gets referenced in some of the comments.
There are however plenty of comments by NPM representatives (including izs) that they see it as a moral obligation to uphold their CoC even beyond the scope of NPM itself (implying what izs proposed).
There's a fundamental divide going on between people who think open source (code, not communities) should be attached to certain moral values and those thinking it should be agnostic of social issues. Similar to the Open Source vs Free Software divide in the 1990s.
Except while the FSF was the one arguing on moral grounds before, the new movement is actually in conflict with one of the main concepts of the GPL: authors should not be able to restrict how code can be used and by whom (i.e. you can't prohibit people from using code for evil if it should be GPL compatible).
Earlier quoted context omitted.
"echo" is not versioned and delivered on its own. It's part of gnu coreutils (which contains ~ 100 utilities), or part of various BSD core distributions (more than 100 utilities, plus the kernel and libc), and also built-in to shells.
IMO that doesn't change anything. The fact that in JS land it would be it's a standalone module means you get more choice in what you need (no need to pull down 100 programs if you only need 1 or 2).
Choice can be a bad thing too - when there are 10 different modules for doing a moderately complex thing, you have to figure out which one is best for your project, and whether it's still actively maintained, bugs are fixed, how do they feel about making breaking changes, etc.
Earlier quoted context omitted.
There are a near-infinite set of complexities in legal cases. Trying to create a formalism for such laws would require solving the entire field of ethics to decide at which point something might be considered "reasonable doubt".
> to decide at which point something might be considered "reasonable doubt". As far as I know this is a mostly done problem (google "statistics").
Does this series of tweets [0] seem rather odd to anyone? He seems to be calling people soulless and pondering his own "Power and Responsibility". [0] https://twitter.com/izs/status/712510512974716931
That is some serious highfaluting language going on in those tweets. Something something if you play the game something something...
Earlier quoted context omitted.
IMO that doesn't change anything. The fact that in JS land it would be it's a standalone module means you get more choice in what you need (no need to pull down 100 programs if you only need 1 or 2).
More choice, but now you need 50 different modules from 50 different authors to duplicate what would be in one good standard library, any of which could have bugs or be pulled out from under you for a multitude of reasons that are beyond your control. Choice can be a bad thing too - when there are 10 different modules for doing a moderately complex thing, you have to figure out which one is best for your project, and…
Not necessarily, take a look at lodash and friends. There is nothing stopping bundling of tiny modules into big "libraries" to be used.
As for the rest, you need to do that validation anyway. But if it were bundled in a large library there is MUCH more code that you need to review.
with something like the module "left-pad", it's a no brainer to use the library. I know that it's under an EXTREMELY open license, the code is really small, and by vendoring your dependencies (you are vendoring your dependencies right?) this whole issue would have been a 5-10 minute fix that only needed to be done when you want to upgrade your dependencies next time.
Earlier quoted context omitted.
Sure there's a technical way to do it: you unplug the server hosting it (or more likely, your hosting provider does that for you). No court is going to shed any tears over fact this has wider consequences than if you'd been able to comply with a narrower takedown request.
This combined with the cost of hosting (I remember the ruby community freaking out over rubygems costs a couple years ago) makes me think maybe we're evolving towards decentralized dependency hosting. Something like Storj where users offset hosting fees with blockchain payments when dependencies are fetched.
I applaud this action and while I'd like to point the finger at NPM, there's no real other method to fix historical package versions that depend on this. It is worth pointing to the silly state of NPM packages: Who decided that an external dependency was necessary for a module that is 17 lines of code? module.exports = leftpad; function leftpad (str, len, ch) { str = String(str); var i = -1; if (!ch && ch !== 0) ch =…
> Developers: less dependencies is better, especially when they're so simple! No! The opposite of that. Lots of little µframeworks, defining composable and generic types, is much better than a giant monolith. The Swift Package Manager is taking this approach, and I think it's great: https://github.com/apple/swift-package-manager#modules The caret character doesn't appear anywhere in the semver spec, so whatever that…
Trivial dependencies are a code smell, a liability, and an operational headache.
Earlier quoted context omitted.
A more accurate story would be: A young man is giving a piece of wood for free to a beggar. Then one day, when the beggar has constructed a house using the wood, the young man asks it back : - But you gave it to me! - It was for free, so don't dare you to complain If it was given with the (maybe implicit) clause that there was no limit of time, I don't see how the thing being free give you the right to take it back,…
It's more like the young man telling the beggar that he can come cut the wood from his land for free. Then one day the young man stops letting the beggar cut his wood for free. He's not taking back the wood that's already been cut. The problem is if the beggar wasted the wood he did take, and took for granted the assumption that he would always be able to get more. Relying on something continuing to exist on the inte…