What do you think about replacing gnu core-utils with uutils by default in nixos?

Development
1

I am curious to know what the NixOS community thinks about the rust rewrite of the GNU core-utils and implementing it on nixos by default. Recently ubuntu started experimenting with it, so I became a bit interested to know what the NixOS community’s opinion about this whole thing is and is there any plan of implementing these rust rewrites in nixos replacing gnu core-utils as well or continue with the gnu core-utils as default going forward.

1 Like
2

Sets a bad precedent with regards to weakening FOSS licensing.

21 Likes
3

20% of the gnu testsuite still fails: GitHub - uutils/coreutils: Cross-platform Rust rewrite of the GNU coreutils

There should also be a stronger reason to migrate than OOH RUST especially given the bootstrapping problems that rust introduces.

21 Likes
4

Here’s the forum post discussing it for reference: Carefully But Purposefully Oxidising Ubuntu - Project Discussion - Ubuntu Community Hub

I think there would be more benefit than only “OOH RUST” in making uutils the default – like those mentioned in the “But Why?” section of the above post – but I can agree those probably aren’t worth 20% of the test suite still failing (and portability concerns)

It seems Ubuntu is working with upstream though

There will certainly be a few rough edges we’ll need to work out. In my testing, for example, the only incompatibility I’ve come across is that the update-initramfs script for Ubuntu uses cp -Z to preserve selinux labels when copying files. The cp, mv and ls commands from uutils don’t yet support the -Z flag, but I think we’ve worked out a way to unblock that work going forward, both in the upstream and in the next release of Ubuntu.

so maybe one day we could more seriously consider this? But I don’t think we want most users on NixOS to experience these “rough edges” while they still exist. I would also be curious to see how many incompatibilities we come across in replacing the coreutils in Nixpkgs’ stdenv, rather than only testing on somewhat basic OS tooling

FWIW, you can (mostly) replace coreutils with uutils on your own system already with

1 Like
5

I should’ve been more specific - I meant that RIIR is usually comparing the theoretical arguments that rust is more secure based on disallowing UB (I can’t remember the last time I encountered UB in cp or mv, much less data corruption or such bugs) vs. the practical breakage of switching to the rust impl and forgetting that software is always going to be buggy, and new software is going to make new mistakes.

Or to rephrase, the two issues I mentioned are actual issues, not theoretical ones that the rewrites claim to address. Once those are addressed, then it may make sense to even consider a switch.

2 Likes
7

Has anyone looked into how many packages are rebuild when switching out core-utils with uutils? Is it basically just all of them since core-utils are in stdenv?

8

I would be against this.
I love Rust and believe many C utilities should be ported to Rust; however, the GPL is far more important.

Additionally, coreutils is not in need of a Rust rewrite. These are very mature utilities without a significant history of serious security vulnerabilities.

Regardless of my personal ideological concerns, uutils does not yet pass the GNU test suite; I therefore do not believe it is suitable as a drop-in replacement for coreutils in its current state.

Additionally, I assume this post is only referring to replacing the core utilities in users’ shell PATH, but I would also like to document that I believe replacing coreutils with uutils in stdenv would be a very bad idea in its current state, as it would cause a mass-rebuild with potentially many side effects for unknown benefit.

I have no problem with people opting to use uutils on their own systems, but I do not believe it qualifies as a sane default for NixOS today.

17 Likes
9

If this were to be implemented in NixOS, it can definitely have a place as a nixos module for those who want it (I could easily see this being a home-manager module).

I don’t see an argument against providing that option to users in the future but I think setting it as the default will be a very, very hard sell and setting it as part of stdenv would be out of the question in terms of the maintenance burden as others have pointed out.

I think the best course of action currently is to observe the results of Ubuntu’s experiment with uutils as with Ubuntu’s userbase a lot of practical data can be brought in so we can have a much stronger discussion about this in the future rather than presuming potential benefits.

10

Providing an option today would be fine. Possibly even avoids the hackiness of lib.hiPrio.

3 Likes
11

I think we shouldn’t because the standard Linux stdenv is intended as a “GNU/Linux” standard stdenv with things like gcc, coreutils, util-linux, etc. There’s a case to be made about compatibility, reliability, and whether the Rust implementation will survive.

6 Likes
12

For what it’s worth, you can already “opt into” uutils-coreutils for your own system by adding uutils-coreutils-noprefix to your system packages.

Edit: only skimmed the thread, now saw this was already mentioned, don’t mind me

2 Likes
13

dw about it. i made the post to know what the community thinks about this. so everyone’s replies are welcomed.

4 Likes
14

Replacing utilities like this would generally have the largest effect when used in the build environment. The problem is that in Nix, any dependency change forces a full rebuild of all downstream derivations. Even CA derivations wouldn’t help here since stdenv is included as a direct dependency of every single layer, so even if the outputs are identical, they still wouldn’t be able to short-circuit the builds.

For personal use, there’s not much reason to use a different package from the default build environment, since you’re going to need the latter anyways (even if you’re not actually compiling any packages since even the basic writeFile wrappers use stdenv), and if you really want to use a specific set, it’s pretty easy to do so.

P.S. The current nixpkgs derivations for uutils defer to the Makefile, which doesn’t seem to have been updated in a while and is missing a few units utilities. Setting cargo features might give a more complete set of utilities, but it wouldn’t provide the needed symlinks when installing without explicitly naming every single command (unless there was a way to list every enabled command in a way that can be parsed to generally the symlinks automatically).

1 Like