Comment by nonameiguess | Hacker News Reader

Comment by nonameiguess | Hacker News Reader

Parent Full thread

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.

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

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

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.

Reply on news.ycombinator.com