5 ms·

Yea, i don't really get the distrust of the ecosystem tbh. Yea, i agree the `0.x` stuff is annoying/concerning, but the volume of dependencies feels very.. meh.

Yea, i don't really get the distrust of the ecosystem tbh. Yea, i agree the `0.x` stuff is annoying/concerning, but the volume of dependencies feels very.. meh. I use NixOS for example. The number of things i download is _insane_ when i build my system. This isn't a Rust or JavaScript "problem", it's just how natural distribution of work occurs. People build off of the work of their peers. And if you reduce the friction of work distribution, like how NPM and Crates do, you naturally get a lot - sometimes to a comical degree. However are we going to expect crate authors to repeatedly reinvent wheels? Would we trust them if they did?

user-the-name 5y ago
I would say that this is why reducing friction this way is not actually a good thing. It has disastrous effects on the entire ecosystem when including a dependency is too easy. It means people will not question whether they should be including a dependency, because it is so easy to do.
- lijogdfljk 5y ago
  I don't think the issue is "too easy" here, but the lack of downstream verification tools. If you had a clear metric for all the parts that go into a library you wouldn't worry about how many there were. And if the library author likewise cared about their libraries metric, they wouldn't arbitrarily choose low-quality libraries. Friction isn't useful here imo. Trust is just as bad with high friction, just maybe less moving pieces. Not having verified metrics seem to me the real problem. Some sort of safety rating that bubbles up from all the dependencies. Changes to software owners would also have to cause issues in this system too.
nonameiguess 5y ago
This doesn't ring true to me. I get that you need to have some dependencies. But if you go build Linux From Scratch, you get a total of 68 packages, most of which are part of the GNU project and come from common authors. That gets you an entire operating system. On the other hand, when I was writing a book using mdbook and wanted a plugin that does token replacement, it pulled in 238 dependencies. To do token replacement. Up that to the scale of an entire operating system written in Rust, and now what are you looking at? At least thousands. Supply chain auditing eventually becomes impossible if you have a separate vendor per function. Put another way, if you go and build Firefox from source, the number of Rust crates and NPM modules it pulls in automatically during its own build is more than the total number of packages in Linux From Scratch and Beyond Linux From Scratch combined. Not every library needs to be the size of glibc, but Rust and Node have gone too far in the opposite direction. I don't know what you have in your Nix build, but even Linux From Scratch is already bloated because it includes a bunch of build and test tools you don't need to just run an OS. The Arch base system is 27 packages.
- halpert 5y ago
  Is an operating system really a fair comparison? Most libraries depend on the operating system, and the usage of OS independent libraries would be limited to mostly operating systems. Not a very big market.
- lmm 5y ago
  > But if you go build Linux From Scratch, you get a total of 68 packages, most of which are part of the GNU project and come from common authors. That gets you an entire operating system. Sure, because dependency management for C is a joke^H^H extremely cumbersome and so you get coarse-grained packages that bundle lots of functionality and are a pain to upgrade. Why is number of dependencies something you care about? Bundling 10 functions together and calling them a library doesn't make them any easier to audit than auditing them individually, all it does is bloat programs that only needed one of them. Getting supply chain attestation to scale is a legitimate problem, but a solvable one - e.g. we could have organisations that would vouch for a large range of authors or packages.
  - deleted 5y ago
    [deleted]
- lijogdfljk 5y ago
  > I get that you need to have some dependencies. But if you go build Linux From Scratch, you get a total of 68 packages, most of which are part of the GNU project and come from common authors. Well to be clear, i'm talking about the dozens of applications primarily that make "my workstation". All the crap and varying duplicated versions, all of it. Much of my dependencies aren't JavaScript or Rust based, and there are still dozens if not hundreds of dependencies. Is Nix at fault for letting me too easily install things? Maybe each individual app needs to have less dependencies? My workstation is built on leagues of other dependencies, is my workstation less secure because of it? Probably. Would installing less things be more safe? Sure... but throwing away my computer would be too. The problem isn't the count imo. The problem is how we vet them. To not only judge a library/app, but to automate a way to bubble up this vetting. To let consumers know that the one package/library/etc they chose to use increased their risk by a significant amount. To know when a package updates that it is no longer secure, as it is owned by a different author. etc. In summary: It's easy for me to install packages on my OS. Most OSs in fact. Making it more difficult to install wouldn't help me make safer choices.

user-the-name 5y ago

I would say that this is why reducing friction this way is not actually a good thing. It has disastrous effects on the entire ecosystem when including a dependency is too easy. It means people will not question whether they should be including a dependency, because it is so easy to do.

lijogdfljk 5y ago
I don't think the issue is "too easy" here, but the lack of downstream verification tools. If you had a clear metric for all the parts that go into a library you wouldn't worry about how many there were. And if the library author likewise cared about their libraries metric, they wouldn't arbitrarily choose low-quality libraries. Friction isn't useful here imo. Trust is just as bad with high friction, just maybe less moving pieces. Not having verified metrics seem to me the real problem. Some sort of safety rating that bubbles up from all the dependencies. Changes to software owners would also have to cause issues in this system too.

nonameiguess 5y ago

This doesn't ring true to me. I get that you need to have some dependencies. But if you go build Linux From Scratch, you get a total of 68 packages, most of which are part of the GNU project and come from common authors. That gets you an entire operating system. On the other hand, when I was writing a book using mdbook and wanted a plugin that does token replacement, it pulled in 238 dependencies. To do token replacement. Up that to the scale of an entire operating system written in Rust, and now what are you looking at? At least thousands. Supply chain auditing eventually becomes impossible if you have a separate vendor per function. Put another way, if you go and build Firefox from source, the number of Rust crates and NPM modules it pulls in automatically during its own build is more than the total number of packages in Linux From Scratch and Beyond Linux From Scratch combined. Not every library needs to be the size of glibc, but Rust and Node have gone too far in the opposite direction. I don't know what you have in your Nix build, but even Linux From Scratch is already bloated because it includes a bunch of build and test tools you don't need to just run an OS. The Arch base system is 27 packages.

halpert 5y ago
Is an operating system really a fair comparison? Most libraries depend on the operating system, and the usage of OS independent libraries would be limited to mostly operating systems. Not a very big market.
lmm 5y ago
> But if you go build Linux From Scratch, you get a total of 68 packages, most of which are part of the GNU project and come from common authors. That gets you an entire operating system. Sure, because dependency management for C is a joke^H^H extremely cumbersome and so you get coarse-grained packages that bundle lots of functionality and are a pain to upgrade. Why is number of dependencies something you care about? Bundling 10 functions together and calling them a library doesn't make them any easier to audit than auditing them individually, all it does is bloat programs that only needed one of them. Getting supply chain attestation to scale is a legitimate problem, but a solvable one - e.g. we could have organisations that would vouch for a large range of authors or packages.
- deleted 5y ago
  [deleted]
lijogdfljk 5y ago
> I get that you need to have some dependencies. But if you go build Linux From Scratch, you get a total of 68 packages, most of which are part of the GNU project and come from common authors. Well to be clear, i'm talking about the dozens of applications primarily that make "my workstation". All the crap and varying duplicated versions, all of it. Much of my dependencies aren't JavaScript or Rust based, and there are still dozens if not hundreds of dependencies. Is Nix at fault for letting me too easily install things? Maybe each individual app needs to have less dependencies? My workstation is built on leagues of other dependencies, is my workstation less secure because of it? Probably. Would installing less things be more safe? Sure... but throwing away my computer would be too. The problem isn't the count imo. The problem is how we vet them. To not only judge a library/app, but to automate a way to bubble up this vetting. To let consumers know that the one package/library/etc they chose to use increased their risk by a significant amount. To know when a package updates that it is no longer secure, as it is owned by a different author. etc. In summary: It's easy for me to install packages on my OS. Most OSs in fact. Making it more difficult to install wouldn't help me make safer choices.