4 ms·

uutils already (optionally) builds that way. The GitHub release has a single 8.4M binary. That doesn't seem so bad, the GNU coreutils Debian package has an Ins

• est31 5y ago
  > The GitHub release has a single 8.4M binary. That's a definitely acceptable size, thanks for pointing that out. Yeah a bunch of symlinks should solve the issue. If the binary is kept cached in RAM at least, there should be no overhead in starting it. I think it's pretty rare to have environments that are so memory constrained that they can't hold onto 8 MB of RAM. Note that not all targets are that small though. Musl has indeed 8.3 MiB, but in coreutils-0.0.12-x86_64-unknown-linux-gnu.tar.gz, the size of the coreutils executable is 12.6 MiB. On the bright side, on the same target, a local build with the cargo features to reduce bloat enabled gives only 7.1M. All these numbers are acceptable.
  • deleted 5y ago
    [deleted]
• loeg 5y ago
  Is anything in coreutils setuid? That’s the only possible drawback I have in mind.
• ris 5y ago
  Yes, the only reason I say "solved" is that this approach will only help for suites of many small tools that ship together.