7 ms·

> 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 s

> 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.

krainboltgreene 7y ago
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.
    - 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.
hanniabu 7y ago
In my opinion there should be different namespaces, similar to what the parent mentioned. There can still be the public namespace as there is now, but there can also be ones registered, such as google/mysql-golang. The other alternative is that it's just linked to Github/Gitlab, but then you run into potential naming collision issues.

krainboltgreene 7y ago

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.
  - 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.

hanniabu 7y ago

In my opinion there should be different namespaces, similar to what the parent mentioned. There can still be the public namespace as there is now, but there can also be ones registered, such as google/mysql-golang. The other alternative is that it's just linked to Github/Gitlab, but then you run into potential naming collision issues.