Rust-Written Coreutils v0.0.18 Released With Improved GNU Compatibility

[FireBurn]

So just emerged this on Gentoo to compare sizes:

* Final size of installed tree: 8536 KiB ( 8.3 MiB)
* sys-apps/coreutils-9.2-r2: 1.9M (quickpkg)

* Final size of installed tree: 12396 KiB ( 12.1 MiB)
* sys-apps/uutils-coreutils-0.0.18: 3.4M (quickpkg)

So it is bigger, but not much bigger

[Vistaus]

uutils exist for the same reason toybox exists.

What do the creators of The Sailor Song and Tarzan & Jane have to do with this?

https://en.wikipedia.org/wiki/Toy-Box

[ehansin]

If you are not familiar with bat ("a cat(1) clone with wings"), you might want to check it out. I use it all the time, love it:

https://github.com/sharkdp/bat

[anarki2]

Either way, static linking is dumb, so you should almost never use it. It's been figured out 20-something years ago, but some people just never learn.

[trapexit]

Either way, static linking is dumb, so you should almost never use it. It's been figured out 20-something years ago, but some people just never learn.

Strongly disagree. It's extremely useful for general distribution and for something looking to be the core of a system I would want them statically compiled to limit breakage in catastrophic situations.

[stormcrow]

Either way, static linking is dumb, so you should almost never use it. It's been figured out 20-something years ago, but some people just never learn.

This is why there's no such thing as "common sense". Factual knowledge is often not common, and people aren't sensible.

There are reasons to want static binaries from all-in-one executables that bring their own library code for environment control or single-task environments, to preventing library call hijacks in higher security environments. After all, near universal honoring the user settable LD_LIBRARY_PATH makes it trivially easy to maliciously intercept dynamic library calls in Linux distros.

[ClosedSource]

The glory of open source. You can publish all sorts of useless things and people will use them religiously.

[dremon_nl]

Either way, static linking is dumb, so you should almost never use it. It's been figured out 20-something years ago, but some people just never learn.

It's actually other way around: the dynamic linking should be killed once and for all. It's an endless source of PITA and frustrations. It should be killed just because of symbol versioning, ABI (in)compatibility and the lack or portability across systems.

[TheJackiNonster]

This is why there's no such thing as "common sense". Factual knowledge is often not common, and people aren't sensible.

There are reasons to want static binaries from all-in-one executables that bring their own library code for environment control or single-task environments, to preventing library call hijacks in higher security environments. After all, near universal honoring the user settable LD_LIBRARY_PATH makes it trivially easy to maliciously intercept dynamic library calls in Linux distros.

How is statically linking better for security? If you find a critical vulnerability in a popular library and patch it, now your users need to replace their entire system instead of one library to apply the patch... great. I can't see how that might backfire when users decide your patch is too bloated and leave the vulnerability wide open.

I don't think one or the other is systematically better. But for most package management on Linux distributions dynamic linking is the way to go. Because otherwise your users will be annoyed to the point they refuse to use your software. The only way not annoying your users with static linking is delaying patches which in case of security critical things is a pretty bad solution.

[dremon_nl]

How is statically linking better for security? If you find a critical vulnerability in a popular library and patch it, now your users need to replace their entire system instead of one library to apply the patch... great. I can't see how that might backfire when users decide your patch is too bloated and leave the vulnerability wide open.

There are two issues with this most commonly used example:
1. You can also look at the different angle: if your popular library introduces a critical vulnerability then suddenly all applications which depend on it are vulnerable until the patch is released and applied.
2. Patching a vulnerability always has a chance of breaking ABI for the library. So in practice distro maintainers just rebuild all dependencies anyway instead of figuring out what might be accidentally broken.