It’s a shame to see all this effort going toward replacing core GPL licensed utilities with permissive ones. It seems like a particularly common thing in the Rust community.<p>It feels disrespectful of the intentions of the work that went into the tools that are being cloned.
> Instead of modifying all the packages that depend on GNU coreutils (known as the package sys-apps/coreutils in Gentoo), I modified the GNU coreutils package to instead install uutils coreutils.<p>That's not the way to do it (in Gentoo). He should have added coreutils to /etc/portage/profile/package.provided. Portage would then assume the package is installed even if it's not. This is used to install self-built binaries or packages from other distributions instead of packages provided by portage.<p><a href="https://wiki.gentoo.org/wiki//etc/portage/profile/package.provided" rel="nofollow">https://wiki.gentoo.org/wiki//etc/portage/profile/package.pr...</a>
No, please don't! At least, not if you aren't equipped to handle the fallout yourself and not until these tools are further refined!<p>I'm a fish-shell developer and I just dealt with a user that was getting bizarre test failures. Turns out the developers didn't account for basic things like the normalcy of `cat` having its output fd closed mid-stream (e.g. you are piping cat to something and that something exits before cat does) and their vesrion bails with an exception dumped to stderr instead of silently closing with a non-zero exit code.
If you read the article, it’s a guy playing around on his system to see if hacking this thing with that thing works.<p>If you only read the comments, you think Gentoo was switching out core utils and doing it in the worst technical way possible.
Unlike some other commenters, I believe having alternatives to coreutils is beneficial. Since I started using Unix, I've worked with HPUX, IRIX, SunOS, Solaris, *BSD, Linux, Xenix, and probably a few others I've forgotten. This diversity in implementations necessitated standardization. Nowadays, 90% of the systems I use are various Linux distributions, and I often encounter packages that implicitly assume on specific versions like GNU make or GNU tar. Having alternatives encourages better compatibility and flexibility across different systems.
Aren't the Rust binaries significantly larger? Wouldn't that be a problem for embedded system and containers?<p>I'm also sceptical to the whole idea. There are tons of more interesting problems to solve than replacing an stable solution with a new one just because you don't like GPL.
I think the author swapped problems #1 and #2. The first one (name clash between different packages) is triggered only if the binaries are called the same, that is after you fix the second one (binaries having uu- prefix).<p>Problem #5 is not well explained: if /usr/bin and /usr/sbin are conflated, how could cowsay not find its templates? Paths relative to the two directories are the same. For example, if cowsay is looking for its templates in ../share/cows, such relative path points to the same destination no matter if the binary is in bin or sbin.
Gentoo Linux will always have a special place in my heart. I learned so much about Linux doing Stage 1 installs back in 2002. I also learned patience with the long compile times and I heated my apartment during the winter. Pentium 4s kicked off a lot of heat. :)<p>Leaving the should uutils be used over coreutils debate aside, this was a fun read for me and the urge to install Gentoo one one of my many old Thinkpads is flaring up hard.
Two thoughts on the whole "alternate" thing:<p>1. When I first learned about the alternatives system, I initially assumed that it <i>was</i> in use for every single binary - that there was an alternatives selection to decide what provided /bin/ls, and one to choose /bin/sh, and one to determinue /bin/chmod, etc. (I mean, /bin/sh sometimes <i>is</i> depending on your distro and how they feel about bash/dash/ash but you get the idea.) And honestly I still kinda feel like that's a good idea, though it leans toward redoing how packages work in a way that reminds me of nix and Gobo; /bin becomes just a symlink farm pointing into per-package bin directories.<p>2. Although this kind of bulk-replacement is a good initial test, I feel like letting packages directly depend on GNU coreutils or not is maybe a good way to go - you can test packages one by one and switch them to point to a virtual package as they're validated, thereby letting the package manager properly manage dependencies by giving it enough information to asses the situation.
What motivates the uutils project? I get rewriting things in language X. I don't really get naming your thing the same name, making a pretty website for it, and apparently trying to replace the original thing.
> Similar to busybox, coreutils uutils was being installed as a single binary, and each entrypoint (i.e. ls) was just a symlink to that binary.<p>What can go wrong ? /s<p>One tool to rule them all.
> This Gentoo setup has /bin, /sbin, /usr/bin, and /usr/sbin all merged.<p>I hope this isn't going to be the norm in the future, but Gentoo has been making my life difficult for years as it is... it's as if the developers don't test or use what they are forcing on everyone.