On Mon, 2021-02-01 at 05:23 -0500, Andrew Udvare wrote:
> > 
> >  1. Nothing is shared between packages so build time and disk 
> >     usage skyrockets.
> 
> This is NodeJS and 99% of stuff is plain JavaScript. Many packages
> are tiny. More time will be spent unpacking tiny distfiles and re-
> arranging them the way Node/Yarn/etc like to see them.
> 

10 is small, but 10 factorial is not. With node, every dependency of
every dependency of every dependency of every dependency... is bundled
and installed. No matter how small each individual package is, the big-
O is what kills you. It really shouldn't take 114MiB of code in 15,092
files and 1,875 directories to display a bullet list:

  https://dev.to/leoat12/the-nodemodules-problem-29dc


> In Rust and Go, with Portage the distfiles are deduplicated as much
> as possible. But it's highly likely that one would have (Rust)
> random-1.0.crate and random-1.1.crate in distfiles because two
> packages need different versions. Wasteful? Yes except when those two
> packages are really necessary.

I wasn't really thinking about the distfiles, because you can delete
them after. Everything you build in Rust and Go gets linked into an
executable and takes up space in the executable, which is installed and
has to stay there.


> >  2. The number of updates and thus the amount of work required
> > also skyrockets, for the same reason: when nothing is shared, you 
> > have to update each package whenever a dependency of a dependency 
> > of a dependency... changes.
> 
> I'm not sure what you are referring to here.

The same big-O problem. If you actually update a bundled package when
its dependencies are updated, you'll be updating every ebuild multiple
times a day.


> >  3. There are no security updates, ever. If you use anything
> > written 
> >     in Rust or Go on Gentoo, or if you use anything that uses 
> >     anything written in Rust or Go, or..... it will NEVER get a 
> >     security update. No one even bothers looking for security
> >     issues in these languages because the "find a bug then fix it"
> >     algorithm is infeasible.
> 
> I'm also not sure what you mean here. Docker is written in Go
> primarily and gets security updates just fine.

You think it does, which is precisely the problem. The big-O issue
makes it completely infeasible to do security updates for Go packages.
If someone tells you they are, they're lying. What they mean is "if
someone reports a problem, we fix it," which just punts to it being
mathematically "impossible" to find and report the problems. People
might look for problems in docker itself, or in the latest version of
some library it uses, but nobody is looking for security issues in the
specific version of library A used by the specific version of library B
used by the specific version of library C used by the specific version
of library D used by docker.


> >  4. You do get to do updates with e.g. "emerge -puDN @world", but
> > not really, because no one is actually updating Gentoo packages
> > every time a dependency of a dependency changes.
> 
> That's because for Go, the most important thing is the binary. It
> doesn't have a concept of shared libraries. What goes into a Go
> binary is the latest version of its own code and the acceptable
> version of the dependencies. All .go source files, no libs.

Go has dynamic linking since forever.

Obviously I agree that having everything managed by portage is nice,
but the benefits that you get out of having a rationally-developed C
library installed with portage and the latest Go doohickey installed
with portage are wildly different. The Go stuff takes a lot more work,
and you get a lot less out of it -- to the extent that maybe it's not
worth all the trouble (and we shouldn't be installing vulnerable stuff
on everyone's machines).




Reply via email to