Uutils 0.0.13 Released For GNU Coreutils Replacement In Rust

[sinepgib]

Patch accepted! https://archlinux.org/packages/commu...ils-coreutils/
Now down to 18MB installed size

[sinepgib]

OK, I found the issue in Arch packaging. I'll try to send a patch on Saturday.
Basically, the script is using GNU Make rather than Cargo. The project's GNUMakefile checks whether `MULTICALL iseq y` and uses `install` rather than using the Cargo.toml config. So, adding that flag to the PKGBUILD should fix it.

EDIT: well, I sent it. It was a one-liner anyway.

[sinepgib]

My Gentoo packages are about the same sizes, for some reason it compiled uutils as separate binaries instead of a unified one as per upstream default. If you build the standard way and strip the resulting binary, you should be under 10MB. File a bug on your distro's package.

OK, that's what I expected. I think I'll try to send my first patch for Arch configs this week then

EDIT

If I have to guess, something like the following might have happened. First, whoever built it set it to make hard links rather than symbolic ones. Then the tar step made a copy for each path rather than a single one for the inode. I think you can configure tar to use hard links instead, tho symbolic links are probably easier to work with.

[sinepgib]

Is this a joke? This must be a joke, right?

I noticed that a few months ago and stopped me from installing. Supposedly they follow the single binary approach, so it's unclear to me why it's that big. Maybe the packager did something wrong there?

[moltonel]

Is this a joke? This must be a joke, right?

My Gentoo packages are about the same sizes, for some reason it compiled uutils as separate binaries instead of a unified one as per upstream default. If you build the standard way and strip the resulting binary, you should be under 10MB. File a bug on your distro's package.

[NobodyXu]

Is this a joke? This must be a joke, right?

I just clone the repository and compile it on my MacBook Air 2020 with command:

cargo build --release --features macos

And the coreutils is roughly 9.2M and support the following command:

coreutils 0.0.13 (multi-call binary)

Usage: coreutils [function [arguments...]]

Currently defined functions:

[, arch, b2sum, b3sum, base32, base64, basename, basenc, cat, chgrp,
chmod, chown, chroot, cksum, comm, cp, csplit, cut, date, dd, df,
dircolors, dirname, du, echo, env, expand, expr, factor, false, fmt,
fold, groups, hashsum, head, hostid, hostname, id, install, join, kill,
link, ln, logname, ls, md5sum, mkdir, mkfifo, mknod, mktemp, more, mv,
nice, nl, nohup, nproc, numfmt, od, paste, pathchk, pinky, pr, printenv,
printf, ptx, pwd, readlink, realpath, relpath, rm, rmdir, seq, sha1sum,
sha224sum, sha256sum, sha3-224sum, sha3-256sum, sha3-384sum, sha3-
512sum, sha384sum, sha3sum, sha512sum, shake128sum, shake256sum, shred,
shuf, sleep, sort, split, stat, stdbuf, sum, sync, tac, tail, tee, test,
timeout, touch, tr, true, truncate, tsort, tty, uname, unexpand, uniq,
unlink, uptime, users, wc, who, whoami, yes

[jarekZ]

https://archlinux.org/packages/core/x86_64/coreutils/
Packaged size: 2.7 MB
Installed size: 16.4 MB

https://archlinux.org/packages/commu...ils-coreutils/
Packaged size: 9.4 MB
Installed size: 112.6 MB

Is this a joke? This must be a joke, right?

[ssokolow]

I mean... yes is just a special case of "stdin/stdout is slow" and the severe bottleneck does require acknowledgement and effort to work around... as I mentioned, however... most other text processing commands can be buffered into a single read/write so that's much less of an issue.

My point is that these things sometimes turn out to be more than they appear, so it's good to withhold judgment.

[Luke_Wolf]

You'd think that, but not necessarily. Take a look at A Little Story About the `yes` Unix Command by Matthias Endler.

I mean... yes is just a special case of "stdin/stdout is slow" and the severe bottleneck does require acknowledgement and effort to work around... as I mentioned, however... most other text processing commands can be buffered into a single read/write so that's much less of an issue.

[Ironmask]

Round and round and round again ! Notice how lots of stuff is rewritten every couple of years.

Hope the same thing does not happen when Bust/Dust/Gust (The super compiler released to fix Rust memory corruption - coz some n00bs failed to learn and use the language correctly ) is released.

Why do people who don't know Rust write like this?
Wouldn't be easier just to give a scan over the official Rust book instead of posting psychotics rants?