7 ms·

Please list the group of people you trust to manage 1,037,274 packages.

layoutIfNeeded 7y ago
(Of which 1,000,000 are slight variations of leftpad.)
hedora 7y ago
I trust these people to manage software packages: https://nm.debian.org/public/people/dm_all 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/ https://people.debian.org/~corsac/ perhaps number of packages is the wrong metric.
- GordonS 7y ago
  A lot of those packages are going to be versions months or sometimes years behind the latest version. I'm not convinced this is a model that can work for programming libraries.
  - umanwizard 7y ago
    It does work, in practice, and has for years. Every package in the Debian (or Ubuntu, or FreeBSD, etc.) package repos depends only on other packages in those repos and on the base OS. It works fine. Packages being months behind the latest version is a feature, not a bug — it means things will only be randomly changing under your feet rarely, with the exception of security fixes.
    - soulofmischief 7y ago
      But it doesn't work for libraries people will be using in development. Often you are waiting for a handful of packages to introduce specific features or bug fixes and need them the moment they are available. NPM isn't user space, it's dev space. Timeliness is the maxim.
      - umanwizard 7y ago
        I’m not a JS developer so maybe I’m missing something, but how do you use a library during development and not use it in production? In the C++ world, I can’t imagine a situation where you would need to depend on, for example, libjpg while developing, but not need to read JPEG files in prod/end-user-space.
        naniwaduni 7y ago
        In the C++ world, you almost certainly don't need headers in prod.
        umanwizard 7y ago
        Yes, true. What’s your point? You still need libjpg to be either statically linked into your executable or present on the target system.
        liveoneggs 7y ago
        headers are not libraries
        auslander 7y ago
        > I’m not a JS developer so maybe I’m missing something Yes, you have outdated respect for production quality. JS world is less concerned with such details.
        huehehue 7y ago
        There are a slew of dev-only dependencies in JS-land. Packages that run local servers for hot-reloading during development. Test runners, linters, TypeScript compilers, SCSS compilers, and so on. None of those things need to be included with the bundled product. Check out Electron or React starter apps for an example, their boilerplates should have dozens of examples.
        soulofmischief 7y ago
        Since another user explained that point, I would also add that in the "move fast and break things" environment of the web, for better or for worse, responsive and automated library updates are often desirable or even required functionality which can be tied to substantial real-world profits if something suddenly goes wrong somewhere in the stack.
    - gregmac 7y ago
      > Packages being months behind the latest version is a feature, not a bug — it means things will only be randomly changing under your feet rarely, with the exception of security fixes. If things are "randomly changing" by updates, that means the upstream package isn't following semantic versioning practices, and more importantly, isn't preserving backwards compatibility with their releases. That's a mark of bad software development practices, and it also isn't solved by an arbitrary wait period: that just means months after the breaking change is done, you finally notice and complain, but most maintainers are going to (rightfully) ignore you by that point. I'd make the same argument in general software quality: with new features, often come new bugs, so by delaying, you can delay introduction of those bugs. However, bugs are easier to fix the sooner they're found, so again, quick turn-around improves things, even if it sometimes causes short-term pain. This is one thing where NPM is definitely miles ahead of APT. With APT, you get a single version of each package, so it's all or nothing. With NPM, you can specify `1.1.x` so even if a version 1.2 or 2.0 comes out, you're on the stable old one. The closest thing that seems to happen with linux packaging is on a major version (with backwards-incompatible changes) a new package name is created with a "2" on the end, to signal this incompatibility -- how is that anything but a hacky workaround to not having proper versioning support?
      - voltagex_ 7y ago
        >With APT, you get a single version of each package, so it's all or nothing. It's definitely not used as often as in npm packages, but you can use =version after your package name to apt install a particular version, or apt pinning for more complex setups.
        Xylakant 7y ago
        The point your parent is making is that with mom, you can install one version of a package per project you’re working on, instead of one version on the system. Especially if you’re working on multiple projects or multiple versions of the same project, this is required.
    - trabant00 7y ago
      > Packages being months behind the latest version is a feature, not a bug I struggle to convince devs and management about this in the past few years. Everyone's gone crazy about latest and greatest set of features with no respect for stability, maintainability, etc.
      - tudelo 7y ago
        To be fair upgrading very old libraries because you hit a fixed bug to very new libraries can be a long process... but I never have worked on a project that stayed on new libraries continuously so... not sure how it works the other way.
  - justinclift 7y ago
    You may be correct for javascript, whose ecosystem is notoriously unstable and the equivalent of "building on sand". eg write some code in a JS framework, then go off and do something for 18 months. Come back and there's a very good chance the entire framework has been obsoleted and replaced, perhaps even several times. In JS land that's "Doh, well of course!". In sane ecosystems (eg not Ruby), not so much. ;)
    - deleted 7y ago
      [deleted]
    - halostatue 7y ago
      This is a problem for _any_ active development package, to the point where most language communities have (previously had) instructions on how to fix breakage of the language introduced by, for example, arbitrary Debian packaging restrictions without working with the language maintainers. I seen this in _any_ environment that has a relatively active package management system of its own (e.g., Ruby, Perl, and Python included)—and it _still_ happens in some Java cases. The only _sane_ thing to do is to completely ignore the OS package management system and to package your applications as relocatable install packages complete with all dependencies you need, modulo the minimal OS stuff required.
- krainboltgreene 7y ago
  > but those 18K do a lot more than NPM This is so hilariously wrong it's actually shocking it was written?
  - deleted 7y ago
    [deleted]
  - hnbroseph 7y ago
    why is it "so hilariously wrong"?
  - justinclift 7y ago
    Those packages provide pretty much every software capability computing has to offer. It's a pretty vast set of capabilities, though npm/javascript itself has gotten way out of hand over the last few years too. ;)
  - acheron 7y ago
    Indeed. I looked through the Debian packages and didn't see left-pad anywhere.
- toupeira 7y ago
  Looking at [1] and [2], in unstable it actually seems to be: - 31K source packages - which build into 136K binary packages - consisting of 1.2 billion lines of code [1] https://sources.debian.org/stats/ https://sources.debian.org/stats/ [2] https://packages.debian.org/unstable/allpackages?format=txt.gz https://packages.debian.org/unstable/allpackages?format=txt....
- SCLeo 7y ago
  Honestly, I think the reliability of those packages are not guarded by these people, but rather by the corresponding communities of those packages. If one of the community failed to secure its package from malicious people, these people at debian are not going to be able to stop it. Thus, those packages are still guarded by a huge community.
  - umanwizard 7y ago
    Why do you think this? OSes like Debian don’t just pull packages from upstream automatically. Packages have actual maintainers affiliated with the OS, not the upstream community, and it’s those maintainers who build packages for the OS repos.
    - ryacko 7y ago
      Not entirely true, Debian actually made OpenSSL less secure once: https://www.debian.org/security/2008/dsa-1571 https://www.debian.org/security/2008/dsa-1571
      - umanwizard 7y ago
        This doesn’t contradict my point. I never said that Debian maintainers are more trustworthy than upstream 100% of the time. I merely said that Debian packages are built, uploaded, and vended by Debian package maintainers, not by upstream. Whether that makes them more trustworthy or less is a different question.
    - oefrha 7y ago
      My software is packaged by Debian, and the update process is me notifying the Debian Developer (DD) responsible for the package of the new version => said DD pulling the new tarball from GitHub. Pretty sure no one’s gonna notice until after it’s pushed to Debian FTP if I introduce some subtle malicious code. Point is DDs don’t review version deltas for the most part, so when the upstream is compromised, they add little to your defense (other than security by outdatedness, I suppose).
- hnbroseph 7y ago
  > I trust these people why?
  - scbrg 7y ago
    Can't speak for parent, but because they have historically shown themselves to be trustworthy. I don't know much about the "NPM community," but judging from the bits I do hear, I'm not sure they have done the same. OTOH, I understand that as an outsider that only pay attention when shit blows up, I'm only seeing the bad parts.
  - varjag 7y ago
    There is a process for recruiting Debian devs where trustworthiness is a consideration. https://wiki.debian.org/DebianDeveloper#Advocating_a_Debian_Project_Member https://wiki.debian.org/DebianDeveloper#Advocating_a_Debian_... There is none for npm.
JustSomeNobody 7y ago
What do you propose should be done?
fock 7y ago
Tell me, why one needs packages such as this except for personal (and ultimately npm) marketing: https://github.com/sindresorhus/shebang-regex https://github.com/sindresorhus/shebang-regex - the whole thing smells
- inimino 7y ago
  You're being downvoted because that is mean-spirited, but the reason we needed these packages is to find out what the right size of package is. We now have a lower bound.
  - fock 7y ago
    I'm not sure what's mean-spirited about the simple statement that the size/complexity of the npm-eco-system arises only from personal/corporate business-decisions. But thanks for telling me anyways ;)
    - inimino 7y ago
      Business decisions and marketing are not the only reasons people write open source software and you would do well to remember it.

(Of which 1,000,000 are slight variations of leftpad.)

I trust these people to manage software packages: https://nm.debian.org/public/people/dm_all 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/ https://people.debian.org/~corsac/ perhaps number of packages is the wrong metric.

GordonS 7y ago
A lot of those packages are going to be versions months or sometimes years behind the latest version. I'm not convinced this is a model that can work for programming libraries.
- umanwizard 7y ago
  It does work, in practice, and has for years. Every package in the Debian (or Ubuntu, or FreeBSD, etc.) package repos depends only on other packages in those repos and on the base OS. It works fine. Packages being months behind the latest version is a feature, not a bug — it means things will only be randomly changing under your feet rarely, with the exception of security fixes.
  - soulofmischief 7y ago
    But it doesn't work for libraries people will be using in development. Often you are waiting for a handful of packages to introduce specific features or bug fixes and need them the moment they are available. NPM isn't user space, it's dev space. Timeliness is the maxim.
    - umanwizard 7y ago
      I’m not a JS developer so maybe I’m missing something, but how do you use a library during development and not use it in production? In the C++ world, I can’t imagine a situation where you would need to depend on, for example, libjpg while developing, but not need to read JPEG files in prod/end-user-space.
      - naniwaduni 7y ago
        In the C++ world, you almost certainly don't need headers in prod.
        umanwizard 7y ago
        Yes, true. What’s your point? You still need libjpg to be either statically linked into your executable or present on the target system.
        liveoneggs 7y ago
        headers are not libraries
      - auslander 7y ago
        > I’m not a JS developer so maybe I’m missing something Yes, you have outdated respect for production quality. JS world is less concerned with such details.
      - huehehue 7y ago
        There are a slew of dev-only dependencies in JS-land. Packages that run local servers for hot-reloading during development. Test runners, linters, TypeScript compilers, SCSS compilers, and so on. None of those things need to be included with the bundled product. Check out Electron or React starter apps for an example, their boilerplates should have dozens of examples.
      - soulofmischief 7y ago
        Since another user explained that point, I would also add that in the "move fast and break things" environment of the web, for better or for worse, responsive and automated library updates are often desirable or even required functionality which can be tied to substantial real-world profits if something suddenly goes wrong somewhere in the stack.
  - gregmac 7y ago
    > Packages being months behind the latest version is a feature, not a bug — it means things will only be randomly changing under your feet rarely, with the exception of security fixes. If things are "randomly changing" by updates, that means the upstream package isn't following semantic versioning practices, and more importantly, isn't preserving backwards compatibility with their releases. That's a mark of bad software development practices, and it also isn't solved by an arbitrary wait period: that just means months after the breaking change is done, you finally notice and complain, but most maintainers are going to (rightfully) ignore you by that point. I'd make the same argument in general software quality: with new features, often come new bugs, so by delaying, you can delay introduction of those bugs. However, bugs are easier to fix the sooner they're found, so again, quick turn-around improves things, even if it sometimes causes short-term pain. This is one thing where NPM is definitely miles ahead of APT. With APT, you get a single version of each package, so it's all or nothing. With NPM, you can specify `1.1.x` so even if a version 1.2 or 2.0 comes out, you're on the stable old one. The closest thing that seems to happen with linux packaging is on a major version (with backwards-incompatible changes) a new package name is created with a "2" on the end, to signal this incompatibility -- how is that anything but a hacky workaround to not having proper versioning support?
    - voltagex_ 7y ago
      >With APT, you get a single version of each package, so it's all or nothing. It's definitely not used as often as in npm packages, but you can use =version after your package name to apt install a particular version, or apt pinning for more complex setups.
      - Xylakant 7y ago
        The point your parent is making is that with mom, you can install one version of a package per project you’re working on, instead of one version on the system. Especially if you’re working on multiple projects or multiple versions of the same project, this is required.
  - trabant00 7y ago
    > Packages being months behind the latest version is a feature, not a bug I struggle to convince devs and management about this in the past few years. Everyone's gone crazy about latest and greatest set of features with no respect for stability, maintainability, etc.
    - tudelo 7y ago
      To be fair upgrading very old libraries because you hit a fixed bug to very new libraries can be a long process... but I never have worked on a project that stayed on new libraries continuously so... not sure how it works the other way.
- justinclift 7y ago
  You may be correct for javascript, whose ecosystem is notoriously unstable and the equivalent of "building on sand". eg write some code in a JS framework, then go off and do something for 18 months. Come back and there's a very good chance the entire framework has been obsoleted and replaced, perhaps even several times. In JS land that's "Doh, well of course!". In sane ecosystems (eg not Ruby), not so much. ;)
  - deleted 7y ago
    [deleted]
  - halostatue 7y ago
    This is a problem for _any_ active development package, to the point where most language communities have (previously had) instructions on how to fix breakage of the language introduced by, for example, arbitrary Debian packaging restrictions without working with the language maintainers. I seen this in _any_ environment that has a relatively active package management system of its own (e.g., Ruby, Perl, and Python included)—and it _still_ happens in some Java cases. The only _sane_ thing to do is to completely ignore the OS package management system and to package your applications as relocatable install packages complete with all dependencies you need, modulo the minimal OS stuff required.
krainboltgreene 7y ago
> but those 18K do a lot more than NPM This is so hilariously wrong it's actually shocking it was written?
- deleted 7y ago
  [deleted]
- hnbroseph 7y ago
  why is it "so hilariously wrong"?
- justinclift 7y ago
  Those packages provide pretty much every software capability computing has to offer. It's a pretty vast set of capabilities, though npm/javascript itself has gotten way out of hand over the last few years too. ;)
- acheron 7y ago
  Indeed. I looked through the Debian packages and didn't see left-pad anywhere.
toupeira 7y ago
Looking at [1] and [2], in unstable it actually seems to be: - 31K source packages - which build into 136K binary packages - consisting of 1.2 billion lines of code [1] https://sources.debian.org/stats/ https://sources.debian.org/stats/ [2] https://packages.debian.org/unstable/allpackages?format=txt.gz https://packages.debian.org/unstable/allpackages?format=txt....
SCLeo 7y ago
Honestly, I think the reliability of those packages are not guarded by these people, but rather by the corresponding communities of those packages. If one of the community failed to secure its package from malicious people, these people at debian are not going to be able to stop it. Thus, those packages are still guarded by a huge community.
- umanwizard 7y ago
  Why do you think this? OSes like Debian don’t just pull packages from upstream automatically. Packages have actual maintainers affiliated with the OS, not the upstream community, and it’s those maintainers who build packages for the OS repos.
  - ryacko 7y ago
    Not entirely true, Debian actually made OpenSSL less secure once: https://www.debian.org/security/2008/dsa-1571 https://www.debian.org/security/2008/dsa-1571
    - umanwizard 7y ago
      This doesn’t contradict my point. I never said that Debian maintainers are more trustworthy than upstream 100% of the time. I merely said that Debian packages are built, uploaded, and vended by Debian package maintainers, not by upstream. Whether that makes them more trustworthy or less is a different question.
  - oefrha 7y ago
    My software is packaged by Debian, and the update process is me notifying the Debian Developer (DD) responsible for the package of the new version => said DD pulling the new tarball from GitHub. Pretty sure no one’s gonna notice until after it’s pushed to Debian FTP if I introduce some subtle malicious code. Point is DDs don’t review version deltas for the most part, so when the upstream is compromised, they add little to your defense (other than security by outdatedness, I suppose).
hnbroseph 7y ago
> I trust these people why?
- scbrg 7y ago
  Can't speak for parent, but because they have historically shown themselves to be trustworthy. I don't know much about the "NPM community," but judging from the bits I do hear, I'm not sure they have done the same. OTOH, I understand that as an outsider that only pay attention when shit blows up, I'm only seeing the bad parts.
- varjag 7y ago
  There is a process for recruiting Debian devs where trustworthiness is a consideration. https://wiki.debian.org/DebianDeveloper#Advocating_a_Debian_Project_Member https://wiki.debian.org/DebianDeveloper#Advocating_a_Debian_... There is none for npm.

JustSomeNobody 7y ago

What do you propose should be done?

fock 7y ago

Tell me, why one needs packages such as this except for personal (and ultimately npm) marketing: https://github.com/sindresorhus/shebang-regex https://github.com/sindresorhus/shebang-regex - the whole thing smells

inimino 7y ago
You're being downvoted because that is mean-spirited, but the reason we needed these packages is to find out what the right size of package is. We now have a lower bound.
- fock 7y ago
  I'm not sure what's mean-spirited about the simple statement that the size/complexity of the npm-eco-system arises only from personal/corporate business-decisions. But thanks for telling me anyways ;)
  - inimino 7y ago
    Business decisions and marketing are not the only reasons people write open source software and you would do well to remember it.