Uutils 0.0.24 Advances Rust-Written Coreutils Implementation

[moltonel]

did you strip uutils by chance?

Not sure how they get 12mb, my uutils binary is 9.3mb (actually slightly smaller than the previous release). The overall uutils package (Gentoo) remains smaller than the coreutils one, at 10.6 vs 18.8mb (with coreutils adding translations, and uutils adding shells completion).

IMHO the distro's package size is what really matters, and when 10mb is too big you want neither coreutils nor uutils. Rust's base binaries size can matter, but is irrelevant here. Kloczek and Jstoik just enjoy any excuse to rant against Rust in all-caps. To put it nicely, they're not interested in constructive discussion.

[Quackdoc]

So please check memory usage on those devices.

memory usage is marginally higher for the initial load, but the total file savings helps a lot for my use case. Im not running into memory issues but I do run into storage issues on some of my stuff, Below is the size storage when I build musl (so totally statically linked unlike gnu which dynamically links to libc etc)

RUSTFLAGS='-C panic=abort -C strip=debuginfo' cargo build --target=x86_64-unknown-linux-musl --release
.rwxr-xr-x  8.8M quack 28 Jan 20:54  coreutils
.rwxr-xr-x  8.1M quack 28 Jan 20:49  coreutils-nosym
.rwxr-xr-x  2.2M quack 28 Jan 20:49  coreutils-nosym-upx​

Not sure how they get 12mb, my uutils binary is 9.3mb (actually slightly smaller than the previous release). The overall uutils package (Gentoo) remains smaller than the coreutils one, at 10.6 vs 18.8mb (with coreutils adding translations, and uutils adding shells completion).

IMHO the distro's package size is what really matters, and when 10mb is too big you want neither coreutils nor uutils. Rust's base binaries size can matter, but is irrelevant here. Kloczek and Jstoik just enjoy any excuse to rant against Rust in all-caps. To put it nicely, they're not interested in constructive discussion.

there is a lot of different configs that can be done, my default coreutils binary is actually 13M when I build since by default I build with target-cpu=native and zero size optimizations like stripping debuginfo as of some time yesterday

[jstoik]

did you strip uutils by chance? There are a few things you can do to trim file sizes

No, that felt like cheating. I did add the PROFILE=release override, though, to ensure it would use the same profile as the cargo install build.

[ssokolow]

No, that felt like cheating. I did add the PROFILE=release override, though, to ensure it would use the same profile as the cargo install build.

Less than a week ago, there was a blog post about making stripping the default behaviour.

The TL;DR is that release profiles already strip what they compile, but the standard library is shipped as a precompiled "optimizations+debug symbols" build that's used by both debug and release profiles and it's the (pretty useless without the other symbols) symbols that are being kept. They did the work to get to the point where it could be on by default, but turning it on by default slipped through the cracks.

[ssokolow]

I do not understand why in this case rust generates DSOs. All should be linked into kernel. In't it?

That's such a non-sequitur that I have no idea how to respond to it.

I was talking about Rust choosing to distribute parts of the standard library as "third-party" packages so that you can depend on a specific API version independent of what toolchain version you're using.

Try to have look on Solaris where something like proces separation on VFS layer is done without any user space libraries of flatpacks.

Irrelevant. This is about the side of Flatpak that uses a Docker-like builder-and-runtime system to ensure "if it works on the developer's machine, it'll work on the user's machine" and that ABI compatibility mismatches between packages and their dependencies can't happen.

Solaris can't magically force GTK upstream to only break ABI in development releases and major version bumps. (Look for the ones that are minor versions but don't have green 100% status.)

Again .. why not link everything into kernel?

Because that's the equivalent to what C++ and Python are doing. There's a reason it's a trope in the Python community that "the standard library is where dependencies go to die".

Before the 3.x break, Python had urllib and urllib2 in the standard library and everyone advised people to use Requests... which has an internal urllib3 that they explicitly say will never be going into the standard library if they have anything to do with it. Likewise for other things like various "Use Twisted instead" network protocol implementations.

[mdedetrich]

Because that's the equivalent to what C++ and Python are doing. There's a reason it's a trope in the Python community that "the standard library is where dependencies go to die".

Indeed and this is for most other languages as well because when something goes into stdlib its API and behaviour basically becomes frozen forever unless you want to do a backwards breaking change to the language.

[kloczek]

memory usage is marginally higher for the initial load, but the total file savings helps a lot for my use case. Im not running into memory issues but I do run into storage issues on some of my stuff, Below is the size storage when I build musl (so totally statically linked unlike gnu which dynamically links to libc etc)

Seems you don't know how page cache is working.
How did you measure RAM usage?

[kloczek]

Irrelevant. This is about the side of Flatpak that uses a Docker-like builder-and-runtime system to ensure "if it works on the developer's machine, it'll work on the user's machine" and that ABI compatibility mismatches between packages and their dependencies can't happen.

Again: separation on VFS layer can be done without any user space prosthetics which is possible to overcome as everything is working in the same process space.

Solaris can't magically force GTK upstream to only break ABI in development releases and major version bumps. (Look for the ones that are minor versions but don't have green 100% status.)

Of course it can. Using exact DSOs can be done even on old Solaris 7 with only ld,so abilities in which configuration on execute exact binary you can be used DSO from completly different location. Look on clre man page https://docs.oracle.com/cd/E88353_01...#REFMAN1crle-1

Because that's the equivalent to what C++ and Python are doing. There's a reason it's a trope in the Python community that "the standard library is where dependencies go to die".

Before the 3.x break, Python had urllib and urllib2 in the standard library and everyone advised people to use Requests... which has an internal urllib3 that they explicitly say will never be going into the standard library if they have anything to do with it. Likewise for other things like various "Use Twisted instead" network protocol implementations.

I don't see that. Please point on exact python PEP spec about that.

[kloczek]

Because that's the equivalent to what C++ and Python are doing. There's a reason it's a trope in the Python community that "the standard library is where dependencies go to die".

Before the 3.x break, Python had urllib and urllib2 in the standard library and everyone advised people to use Requests... which has an internal urllib3 that they explicitly say will never be going into the standard library if they have anything to do with it. Likewise for other things like various "Use Twisted instead" network protocol implementations.

BTW. twisted module is not part of the standard python modules.
Seems you do not understand that some pypi modules interfaces are time to time deprecated and it is normal part of the code evolution and has nothing to do with python standard modules.

[Quackdoc]

Seems you don't know how page cache is working.
How did you measure RAM usage?

no idea what you are trying to imply with the page cache comment, I ran applications until I oom triggered or crash, if I don't oom or crash, and my performance doesn't degrade, that's all I care about, I don't care about some stupid number on paper, I care about something actually working for what I need it to.