HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
uutils
coreutils
Rust2013–2026
uutils / coreutils

coreutils

Cross-platform Rust rewrite of the GNU coreutils

138Distinct people
162Mentions
1Explicit recommenders
24.4KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Cross-platform Rust rewrite of the GNU coreutils

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

Link to the actual implementation: https://github.com/uutils/coreutils I love these re-implementations of things. Technology advances by the continued reinvention of the wheel,…

enriquto used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 12:54:37 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year162 dated mentions

Observed mentions: 2013-11-29 22:30:28 UTC to 2026-10-04 10:18:24 UTC.

01020302013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments20132014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 6 mentions; 1 submissions, 5 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 8 mentions; 1 submissions, 7 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 12 mentions; 0 submissions, 12 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 17 mentions; 1 submissions, 16 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 23 mentions; 6 submissions, 17 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 10 mentions; 1 submissions, 9 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 9 mentions; 1 submissions, 8 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 10 mentions; 1 submissions, 9 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 28 mentions; 4 submissions, 24 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 26 mentions; 5 submissions, 21 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC110
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC615
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC707
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC817
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC12012
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC303
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC202
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC17116
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC23617
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC1019
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC918
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC1019
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC28424
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC26521

From the project README

An excerpt from the repository, fetched Nov 12, 2026.

Read the project’s introduction
uutils coreutils uutils coreutils is a cross-platform reimplementation of the GNU coreutils in Rust. While all programs have been implemented, some options might be missing or different behavior might be experienced. We provide prebuilt binaries, manpages, and shell completions from main branch at https://github.com/uutils/coreutils/releases/tag/latest-commit . The latest stable tag https://github.com/uutils/coreutils/releases/latest also exists for reproducible products and packagers. Bug reporters should use binary from latest commit. Minimal compatible glibc version is same with ubuntu-latest runner. Use coreutils-*-musl if coreutils-*-gnu is not compatible with your system. Goals uutils coreutils aims to be a drop-in replacement for the GNU utils. Differences with GNU are treated as bugs. Our key objectives include: Matching GNU's output (stdout and error code) exactly Better error messages: at a terminal, a parse error is shown as a compiler-style report with a caret under the argument at fault, where GNU prints a single line (see error diagnostics); scripts and pipes still get the plain GNU message Providing comprehensive internationalization support (UTF-8) Continuously improving performance; significant slowdowns relative to other coreutils implementations are treated as bugs Extensions when relevant (example: --progress) uutils aims to work on as many platforms as possible, to be able to use the same utils on Linux, macOS, *BSD, Windows, WASI and other platforms. This ensures, for example, that scripts can be easily transferred between platforms. uutils coreutils ships by default on Ubuntu since version 25.10. Documentation uutils has both user and developer documentation available: User Manual Developer Documentation Both can also be generated locally, the instructions for that can be found in the coreutils docs repository. Use weblate/rust-coreutils to translate the Rust coreutils into your language. You can try the utilities in your browser through the WebAssembly playground, without installing anything. Requirements Rust (cargo, rustc) GNU Make (optional) Rust Version uutils follows Rust's release channels and is tested against stable, beta and nightly. Building There are currently two methods to build the uutils binaries: either Cargo or GNU Make. Building the full package, including all documentation, requires both Cargo and GNU Make on a Unix platform. For either method, we first need to fetch the repository: git clone https://github.com/uutils/coreutils cd coreutils Cargo Building uutils using Cargo is easy because the process is the same as for every other Rust program: cargo build --release Replace --release with --profile=release-small to optimize binary size. This command builds the most portable common core set of uutils into a multicall (BusyBox-type) binary, named 'coreutils', on most Rust-supported platforms. Additional platform-specific uutils are often available. Building these expanded sets of uutils for a platform (on that platform) is as simple as specifying it as a feature: cargo build --release --features windows # or ... cargo build --release --features unix # or ... cargo build --release --target wasm32-wasip1 --no-default-features --features feat_wasm To build SELinux-specific features, including chcon and runcon, ensure that libselinux and libclang are installed on your system. Then, run the following command: cargo build --release --features unix,feat_selinux To speed up the checksum utilities (md5sum, sha1sum, sha224sum, sha256sum, sha384sum, sha512sum, and cksum) by using OpenSSL's libcrypto instead of the pure-Rust digest crates, enable the openssl feature: cargo build --release --features openssl By default OpenSSL is built from source and statically linked into the binary, so no runtime dependency on system libcrypto/libssl is added. To link dynamically against the system libcrypto instead, set OPENSSL_NO_VENDOR=1 at build time. MinGW (Windows) needs OPENSSL_STATIC=0 too for dynamic linkage. The speedup is largest on CPUs without SHA-NI hardware acceleration. aws-lc backend is used on MSVC. Setting AWS_LC_SYS_NO_JITTER_ENTROPY=1 at build time is recommended to reduce size of binary. If you don't want to build every utility available on your platform into the final binary, you can also specify which ones you want to build manually. For example: cargo build --features "base32 cat echo rm" --no-default-features If you want to build the utilities as individual binaries, that is also possible: cargo build --release --bins --workspace --exclude coreutils --exclude uu_runcon --exclude uu_chcon Each utility is contained in its own package within the main repository, named "uu_UTILNAME". To build selected individual utilities, use the --package [aka -p] option. For example: cargo build -p uu_base32 -p uu_cat -p uu_echo -p uu_rm GNU Make Building using make is a simple process as well. To simply build all available utilities (with debug profile): make In release mode: make PROFILE=release To build all but a few of the available utilities: make SKIP_UTILS='UTILITY_1 UTILITY_2' To build only a few of the available utilities: make UTILS='UTILITY_1 UTILITY_2' Installation Install with Cargo Likewise, installing can simply be done using: cargo install --path . --locked This command will install uutils into Cargo's bin folder (e.g. $HOME/.cargo/bin). This does not install files necessary for shell completion or manpages. For manpages or shell completion to work, use GNU Make or see Manually install shell completions/Manually install manpages. Install with GNU Make To install all available utilities (PROFILE=release by default): make install To install using sudo switch -E must be used: sudo -E make install To install all but a few of the available utilities: make SKIP_UTILS='UTILITY_1 UTILITY_2' install To install only a few of the available utilities: make UTILS='UTILITY_1 UTILITY_2' install To install every program with a prefix (e.g. u
Read the full README on GitHub

What Hacker News says

162 sources
I wonder might this be partly due to licensing concerns given uutils have acknowledged they've copied GNU GPL code. From their latest release notes (https://github.com/uutils/coreutils/releases/tag/0.12.0): "Also, some contributions had carried comments and code over from GNU coreutils, against our own rule that uutils is an original implementation. We reviewed the tree and rewrote what we found, in comments and in the few functions that followed the C too closely"
In OpenBSD Developers Reject Uutils Coreutils
People switching or upgrading from soon-EoL versions beware: Ubuntu now defaults to uutils, which are reimplementations of GNU utils that deliberately do attempt to not read the original source (to be legally cleared to not comply with its copyleft expectations). The "correct" behavior is not always evident from POSIX, so uutils is by design an imperfect imitation with a long way to go for bug-by-bug compatibility. While most data loss severity bugs reported in the 25.10 round of testing [1] have been resolved, the sheer volume of unexpected breakage suggests that there are more to be discovered. Most impacted are unit tests and shell scripts that expect some utility to return syscall errors in stderr and propagate it to a non-zero exit code, where on Ubuntu 26.04 they might silently swallow (apparent, partial or complete) failure to exec
Read the rest
ute the requested action. (Also, uutils binaries are ridiculously large, but this is not such big deal: Ubuntu has for many years already built rather large initramfs and has yet to make progress in automatically detecting which firmware blobs cannot possibly be needed on a given system. I did run into an "undersized" partition layout because of Rust duplication.. but only on systems upgraded from ancient times before this was the norm.) [1]: https://github.com/uutils/coreutils/issues?q=is%3Aissue+%28l...
In Upgrade your desktop: Ubuntu 26.04.1 LTS is now available
Neat. I touched this code about 8 months later to avoid the per-block elapsed() call: https://github.com/uutils/coreutils/commit/cf7b90bbe7cb87099... Mirrored the way I implemented status=progress in FreeBSD dd, though there the flag was set by a SIGALRM timer: https://freshbsd.org/freebsd/src/commit/4767c42c1146459eb751... It would appear GNU dd 9.9 still does a call for every block. Low-hanging fruit if anyone fancies it: dd if=/dev/zero of=/dev/null count=100000000 status=progress 51200000000 bytes transferred in 18.644004 secs (2746191200 bytes/sec) target/release/dd if=/dev/zero of=/dev/null count=100000000 status=progress 51200000000 bytes (51 GB, 48 GiB) copied, 20.8772 s, 2.5 GB/s gdd if=/dev/zero of=/dev/null count=100000000 status=progress 51200000000 bytes (51 GB, 48 GiB) copied, 23.6744 s, 2.2 GB/s
In Ubuntu 26.10 completes transition to Rust-based coreutils
Docs full of emojis, this is another AI slop?! Tangential note: there is already a community effort[1] to rewrite GNU commandline tools into Rust and Canonical shipped the rust version of the /bin/utils in Ubuntu 26.04 Resolute Raccoon by default[2] in their "oxidizing" initiative.[3] PS: Linus Torvalds has confirmed that the existing Linux kernel will never be fully rewritten in Rust.[4] Let's see how well that statement age. [1]: https://github.com/uutils/coreutils [2]: https://canonical.com/blog/canonical-releases-ubuntu-26-04-l... [3]: https://discourse.ubuntu.com/t/carefully-but-purposefully-ox... [4]: https://news.ycombinator.com/item?id=41355731
In Linux 0.11 rewritten in idiomatic Rust, boots in QEMU
Looks like it doesn't really fuzz much. https://github.com/uutils/coreutils/tree/main/fuzz/fuzz_targ... Maybe these tests aren't even fuzz tests? https://github.com/uutils/coreutils/blob/main/fuzz/fuzz_targ... Even the tests that look ok are not that good in my opinion because there is no structure to it: https://github.com/uutils/coreutils/blob/main/fuzz/fuzz_targ... It should also try to generate mostly correct but slightly wrong things instead of just dumping random data into it. Seems to also not expect some fuzz tests to even pass in the CI: https://github.com/uutils/coreutils/blob/a07879b8ab2bb8fe5e0...
In Bugs Rust won't catch
Canonical's usage of uutils is likely for marketing. But the codebase itself was developed for fun, as an excuse for people to have a hands-on way to learn Rust back before Rust was even released, with a minor justification as being cross-platform. From the original README in 2013: Why? ---- Many GNU, linux and other utils are pretty awesome, and obviously some effort has been spent in the past to port them to windows. However those projects are either old, abandonned, hosted on CVS, written in platform-specific C, etc. Rust provides a good platform-agnostic way of writing systems utils that are easy to compile anywhere, and this is as good a way as any to try and learn it. https://github.com/uutils/coreutils/blob/9653ed81a2fbf393f42...
In Bugs Rust won't catch
Where are these rust fans? Are they in the room with us right now? You’ve constructed a strawman with no basis in reality. You know what actual Rust fans sound like? They sound like Matthias Endler, who wrote the article we’re discussing. Matthias hosts a popular podcast Rust in Production where talks with people about sharp edges and difficulties they experienced using Rust. A true Rust advocate like him writes articles titled “Bugs Rust Won’t Catch”. > Such rewritten software packages should remain for years as optional alternatives to the originals. This project was started a decade ago. (https://news.ycombinator.com/item?id=7882211) > must first present to the world the results of a huge set of correctness tests and performance benchmarks Yeah, you can see those in https://github.com/uutils/coreutils. This project has also worked with
Read the rest
GNU coreutils maintainers to add more tests over time. Check out the graph where the total number of tests increases over time. > before the substitution idea is even put forward I partly agree. But notice that these CVEs come from a thorough security audit paid for by Canonical. Canonical is paying for it because they have a plan to substitute in the immediate future. Without a plan to substitute it’s hard to advocate for funding. Without funding it’s hard to find and fix these issues. With these issues unfixed it’s hard to plan to substitute. Chicken and egg problem. > less bugs Fewer.
In Bugs Rust won't catch

Showing the 15 most recent of 162 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.