4 ms·

I'd disagree: The way modern Linux distros work is that a number of volunteers who pay attention to what's going on upstream package software for users and dev

I'd disagree: The way modern Linux distros work is that a number of volunteers who pay attention to what's going on upstream package software for users and developers. When something gets weird these volunteers change their behavior and prevent the users from being harmed (the recent Audacity mess is a great example of this.) I don't think people pushing eg cargo/node/snap appreciate how safe this has made their OS and languages that rely on distro package managers (such as C.) You get the safety that you might expect from an app store without actually restricting anyone's freedom. It's very much like a church with elders preventing people from being captured by vices and whatnot. Yes it has issues but it works shockingly well, much better than many of the alternatives.

rlpb 4y ago
Also, most distros have the concept of stable releases. This provides a very valuable "focus point". It means that we don't just have to rely on the maintainers. Users can review packages for reasonable behavior too, and this isn't made futile by constantly changing packages. Users and maintainers can focus on just the stable release and at a reasonable cadence, and this focus point being the same for all users means that it has value to everyone else, too.
lucideer 4y ago
This is ultimately about scale though. It's easier for Linux because of the relative number of contributors to distro repos. Ubuntu has 10s of thousands of packages. NPM has well over a million. The average update frequency is also much higher, as is the number of contributors per-package.
- infamia 4y ago
  > Ubuntu has 10s of thousands of packages. NPM has well over a million. The average update frequency is also much higher, as is the number of contributors per-package. Node's culture of tiny libraries (partly caused by Javascript's tiny standard lib) is a big part of the problem and increases the number of potential supply chain issues.
  - danShumway 4y ago
    It's not that Ubuntu has fewer packages because it's 30x more efficient with how it packages software -- it has fewer libraries because it has less software and less developer attention. It's not at all uncommon for me in Debian systems to have to search out non-distro repositories to pull from. And that's even before we get into the issue that Ubuntu/Debian repositories aren't rolling release. I often find myself jumping outside of the official Ubuntu repos even for software that they provide, just because they're out of date; it's one of the biggest reasons why I eventually moved to Arch. Yes, JS dependency chains are out of control. No, that's not the only reason why there are over a million packages on NPM. No, the solution to the scalability problem of human-curated package managers can't be, "well, we just won't scale." Adding a bigger standard library to JS would not be enough to get rid of 970,000 npm packages.
  - lucideer 4y ago
    Node's culture of tiny libraries is overstated. See https://news.ycombinator.com/item?id=30989539 https://news.ycombinator.com/item?id=30989539 What standard libs are you comparing? Node's to what other language? I've seen so many commenters say this, but still not sure what the magical thing that can't be achieved with Node built-ins is... Developers don't write libs because you can't do it with built-ins, the write libs because developers like to write code and NPM is easy to use.
    - infamia 4y ago
      > Node's culture of tiny libraries is overstated. See https://news.ycombinator.com/item?id=30989539 https://news.ycombinator.com/item?id=30989539 You need thousands of packages for a pretty standard React application (which requires hundreds of base packages). That's a cultural problem in Node's packaging community that injects risk into the packaging ecosystem. > What standard libs are you comparing? Node's to what other language? I've seen so many commenters say this, but still not sure what the magical thing that can't be achieved with Node built-ins is... Brandon Eich himself has said that JS has a purposefully small standard library. https://www.infoworld.com/article/3048833/brendan-eich-javascript-standard-library-will-stay-small.html https://www.infoworld.com/article/3048833/brendan-eich-javas... JS' standard library is small compared with Python's for example. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... https://docs.python.org/3/library/ https://docs.python.org/3/library/
horsawlarway 4y ago
This is literally EXACTLY how releases are supposed to work for companies using any package manager out there. A number of [employees] who pay attention to what's going on upstream package software for users. When something gets weird these [employees] change their behavior and prevent the users from being harmed. The problem is - much like a church with elders (and linux distros - frankly) - quality varies dramatically. Some of them prevent people from being captured by vices, some of them diddle the kids. Same here: Some companies take the appropriate steps to lock down dependencies and only update after a thorough vetting. Some pull the latest packages on every push to master.
danShumway 4y ago
The problem is that as you get deeper into Linux, you become progressively more and more likely to install your own packages from source, and then all of that curation goes out the window. I'm not 100% convinced that the number of volunteers for package managers like Arch are actually sufficient to catch malware even in its current form; I think they get a lot of benefit out of desktop Linux being a relatively low-value target. But I'm really not convinced that their approach would be scalable if they actually had to scale at the level of npm. From what I can tell, Arch only has in the neighborhood of 13,000 packages[0], and it doesn't easily allow installing arbitrary versions[1]. I have nothing but praise for Linux, but none of the main distros have anything close to the amount of developer activity that the npm ecosystem has. And that's when curation breaks down: Arch solves the problem of not having a ton of packages in the main repos by allowing multiple upstreams, by supplying AUR, and by compiling packages from source. But once you drop down into AUR, it's a lot more dangerous and would be a lot easier for people to push malicious code. And if you're pulling Makefiles off of Github, all of that goes out the window -- and there are good Linux software packages that encourage that behavior. Not to mention the number of Linux software packages that straight up just give you a shell script to run that configures and installs the rest of the program (looking at you, Calibre). If you're lucky and you're using Arch, then you might be able to just install Calibre from the main repo. But that's also kind of Arch-specific, on Debian systems it's much more likely that you jump out of the main repos because they're out of date and you want the most recent version; you either start pulling from a dev-controlled upstream or you start running the shell scripts to install that software. ---- Don't get me wrong, I actually think that from a curation perspective, the way Linux package managers work is the best available solution we have for human moderation for software. A single large curated list that fits everyone's needs is impossible, it does not scale[2]. The only scalable solution for curation is to have a lot of separate curated lists that people can subscribe to; and then to recursively have curated lists of lists. However, curation is not a magical catch-all solution against malware, particularly when you get AUR and source compilation in the mix. Curated lists are one layer of security, and need to be combined with other sandboxing techniques, with user education, and with (when possible) minimizing the number of packages people need to install. It's not as simple as saying, "the volunteers won't let anything bad happen" -- and I definitely wouldn't say that Linux package security is a solved issue, I think a recognition of some of the weaknesses of that model is part of the reason we're seeing so much effort going into Flatpak[3]. ---- [0]: https://archlinux.org/packages/ https://archlinux.org/packages/ [1]: Yes, you can roll back but it's not really something that's advised to do for specific packages. Generally, your system will run smoother if you keep everything up-to-date and don't pin specific versions. [2]: We've seen this with both iOS and Android, you either make a limited list that doesn't meet everyone's needs, or you have bad curation. Sometimes both. Splitting up lists does a lot to help solve that problem. [3]: Although in the spirit of having multiple curated lists, I wish we'd start to see more popular upstreams than just Flathub.

rlpb 4y ago

Also, most distros have the concept of stable releases. This provides a very valuable "focus point". It means that we don't just have to rely on the maintainers. Users can review packages for reasonable behavior too, and this isn't made futile by constantly changing packages. Users and maintainers can focus on just the stable release and at a reasonable cadence, and this focus point being the same for all users means that it has value to everyone else, too.

lucideer 4y ago

This is ultimately about scale though. It's easier for Linux because of the relative number of contributors to distro repos. Ubuntu has 10s of thousands of packages. NPM has well over a million. The average update frequency is also much higher, as is the number of contributors per-package.

infamia 4y ago
> Ubuntu has 10s of thousands of packages. NPM has well over a million. The average update frequency is also much higher, as is the number of contributors per-package. Node's culture of tiny libraries (partly caused by Javascript's tiny standard lib) is a big part of the problem and increases the number of potential supply chain issues.
- danShumway 4y ago
  It's not that Ubuntu has fewer packages because it's 30x more efficient with how it packages software -- it has fewer libraries because it has less software and less developer attention. It's not at all uncommon for me in Debian systems to have to search out non-distro repositories to pull from. And that's even before we get into the issue that Ubuntu/Debian repositories aren't rolling release. I often find myself jumping outside of the official Ubuntu repos even for software that they provide, just because they're out of date; it's one of the biggest reasons why I eventually moved to Arch. Yes, JS dependency chains are out of control. No, that's not the only reason why there are over a million packages on NPM. No, the solution to the scalability problem of human-curated package managers can't be, "well, we just won't scale." Adding a bigger standard library to JS would not be enough to get rid of 970,000 npm packages.
- lucideer 4y ago
  Node's culture of tiny libraries is overstated. See https://news.ycombinator.com/item?id=30989539 https://news.ycombinator.com/item?id=30989539 What standard libs are you comparing? Node's to what other language? I've seen so many commenters say this, but still not sure what the magical thing that can't be achieved with Node built-ins is... Developers don't write libs because you can't do it with built-ins, the write libs because developers like to write code and NPM is easy to use.
  - infamia 4y ago
    > Node's culture of tiny libraries is overstated. See https://news.ycombinator.com/item?id=30989539 https://news.ycombinator.com/item?id=30989539 You need thousands of packages for a pretty standard React application (which requires hundreds of base packages). That's a cultural problem in Node's packaging community that injects risk into the packaging ecosystem. > What standard libs are you comparing? Node's to what other language? I've seen so many commenters say this, but still not sure what the magical thing that can't be achieved with Node built-ins is... Brandon Eich himself has said that JS has a purposefully small standard library. https://www.infoworld.com/article/3048833/brendan-eich-javascript-standard-library-will-stay-small.html https://www.infoworld.com/article/3048833/brendan-eich-javas... JS' standard library is small compared with Python's for example. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... https://docs.python.org/3/library/ https://docs.python.org/3/library/

horsawlarway 4y ago

This is literally EXACTLY how releases are supposed to work for companies using any package manager out there. A number of [employees] who pay attention to what's going on upstream package software for users. When something gets weird these [employees] change their behavior and prevent the users from being harmed. The problem is - much like a church with elders (and linux distros - frankly) - quality varies dramatically. Some of them prevent people from being captured by vices, some of them diddle the kids. Same here: Some companies take the appropriate steps to lock down dependencies and only update after a thorough vetting. Some pull the latest packages on every push to master.

danShumway 4y ago

The problem is that as you get deeper into Linux, you become progressively more and more likely to install your own packages from source, and then all of that curation goes out the window. I'm not 100% convinced that the number of volunteers for package managers like Arch are actually sufficient to catch malware even in its current form; I think they get a lot of benefit out of desktop Linux being a relatively low-value target. But I'm really not convinced that their approach would be scalable if they actually had to scale at the level of npm. From what I can tell, Arch only has in the neighborhood of 13,000 packages[0], and it doesn't easily allow installing arbitrary versions[1]. I have nothing but praise for Linux, but none of the main distros have anything close to the amount of developer activity that the npm ecosystem has. And that's when curation breaks down: Arch solves the problem of not having a ton of packages in the main repos by allowing multiple upstreams, by supplying AUR, and by compiling packages from source. But once you drop down into AUR, it's a lot more dangerous and would be a lot easier for people to push malicious code. And if you're pulling Makefiles off of Github, all of that goes out the window -- and there are good Linux software packages that encourage that behavior. Not to mention the number of Linux software packages that straight up just give you a shell script to run that configures and installs the rest of the program (looking at you, Calibre). If you're lucky and you're using Arch, then you might be able to just install Calibre from the main repo. But that's also kind of Arch-specific, on Debian systems it's much more likely that you jump out of the main repos because they're out of date and you want the most recent version; you either start pulling from a dev-controlled upstream or you start running the shell scripts to install that software. ---- Don't get me wrong, I actually think that from a curation perspective, the way Linux package managers work is the best available solution we have for human moderation for software. A single large curated list that fits everyone's needs is impossible, it does not scale[2]. The only scalable solution for curation is to have a lot of separate curated lists that people can subscribe to; and then to recursively have curated lists of lists. However, curation is not a magical catch-all solution against malware, particularly when you get AUR and source compilation in the mix. Curated lists are one layer of security, and need to be combined with other sandboxing techniques, with user education, and with (when possible) minimizing the number of packages people need to install. It's not as simple as saying, "the volunteers won't let anything bad happen" -- and I definitely wouldn't say that Linux package security is a solved issue, I think a recognition of some of the weaknesses of that model is part of the reason we're seeing so much effort going into Flatpak[3]. ---- [0]: https://archlinux.org/packages/ https://archlinux.org/packages/ [1]: Yes, you can roll back but it's not really something that's advised to do for specific packages. Generally, your system will run smoother if you keep everything up-to-date and don't pin specific versions. [2]: We've seen this with both iOS and Android, you either make a limited list that doesn't meet everyone's needs, or you have bad curation. Sometimes both. Splitting up lists does a lot to help solve that problem. [3]: Although in the spirit of having multiple curated lists, I wish we'd start to see more popular upstreams than just Flathub.