Any options to replace GNU coreutils on Linux?

Question

I've been thinking about discontinuing the use of GNU Coreutils on my Linux systems, but to be honest, unlike many other GNU components, I can't think of any alternatives (on Linux). What alternatives are there to GNU coreutils? will I need more than one package? Links to the project are a must, bonus points for naming distro packages.

Also please don't suggest things unless you know they work on Linux, and can reference instructions. I doubt I'll be switching kernels soon, and I'm much too lazy for anything much beyond a straightforward ./configure; make; make install. I'm certainly not going to hack C for it.

warning: if your distro uses coreutils removing them could break the way your distro functions. However not having them be first in your $PATH shouldn't break things, as most scripts should use absolute paths.

Solution 1

busybox the favorite of Embedded Linux systems.

BusyBox combines tiny versions of many common UNIX utilities into a single small executable. It provides replacements for most of the utilities you usually find in GNU fileutils, shellutils, etc. The utilities in BusyBox generally have fewer options than their full-featured GNU cousins; however, the options that are included provide the expected functionality and behave very much like their GNU counterparts. BusyBox provides a fairly complete environment for any small or embedded system.

BusyBox has been written with size-optimization and limited resources in mind. It is also extremely modular so you can easily include or exclude commands (or features) at compile time. This makes it easy to customize your embedded systems. To create a working system, just add some device nodes in /dev, a few configuration files in /etc, and a Linux kernel.

You can pretty much make any coreutil name a link to the busybox binary and it will work. you can also run busybox <command> and it will work. Example: if you're on Gentoo and haven't installed your vi yet, you can run busybox vi filename and you'll be in vi. It's

• Arch Linux - community/busybox

• Gentoo Linux - sys-apps/busybox

• Alpine Linux - based on BusyBox and uClibc, here's an overview

Solution 2

This is an older topic, I realize. However, this solution was never mentioned and comes up relatively high on google for "Linux with bsd userland".

There's another solution: heirloom. I know it works on Arch, and it's packaged in the AUR (look at gnu2sysv, for instance). This will replace Arch's coreutils package and provide the heirloom equivalents. You can read about the whole thing on arch's wiki: https://wiki.archlinux.org/index.php/Base2heirloom

Solution 3

Check out uutils.

This is a cross platform implementation of the GNU coreutils that is written in Rust. It is MIT licensed. At the time of writing this answer it is not 100℅ complete (missing some crucial ones like ls and cp), but many other ones are done.

Comments

[Admin]

Curiously, why you looking for alternatives?

[Admin]

@tshepang more or less so I can say to an even stronger degree that I don't use GNU wares and thus it's not GNU Linux and also just to make my cli usage more robust.

[Admin]

@xeno "More robust"? Also keep in mind that your system (including kernel) is largely built with GCC and depends on GLibC :)

[Admin]

@tshepang there's uclibc which IIRC ubuntu or debian was switching to at some point, but I could be wrong. gcc is one of the few things I can't think of any alternatives for. I don't really consider busybox a viable alternative for me, but it is one that I know.

[Admin]

@xeno Debian is actually now using EGLIBC, which sort of a fork of GLibC. But it follows GLibC closely, so the diff ain't that big.

[Admin]

@tshepang maybe that's what I'm thinking of. fork or no if it's not a GNU project, it must not be GNU.

[Admin]

Both Clang and tcc could (at one time, anyway) compile the Linux kernel.

[Admin]

There are people working on a GNU userland on a BSD kernel, but I haven't heard of the other way round. Really switching kernels would be easier. You can try it first in a VM if you're shy.

[Admin]

The Glendix project is trying to build a Plan9/Linux distro, but it seems to be far from usable and it requires kernel patches, so it's not a valid answer to your question.

[xenoterracide]

feel free to modify this with links to your distro

[xenoterracide]

how would I go about installing BSD tools on a Linux distro? where would I get them?

[xenoterracide]

also, this is a favorite on embedded, so though an alternative it's probably not going to be enough to replace GNU for my desktop/server environment

[jsbillings]

FreeBSD's entire OS is available via CVS freebsd.org/cgi/cvsweb.cgi/src, however, getting the BSD userland to compile under a Linux kernel would be rather difficult. GNU's userland is probably more portable than BSD, since GNU's userland (at least at the beginning) was built to be portable between multiple kernels.

[xenoterracide]

that sounds like a PITA, sure if it's reasonably possible someone somewhere has packaged it at least once for linux.

[jsbillings]

Yeah, I'm not sure it's even possible. It'd probably be easier to just install FreeBSD and enable linux compatibility. You can easily get the GNU coreutils working under FreeBSD, but not vice-versa.

[xenoterracide]

this isn't a question about "which distro" can I use, it's about replacing coreutils on Linux. Unless you're referring to opensolaris coreutils? also is this less of a PITA than the FreeBSD option?

[bahamat]

The source code for OpenSolaris is just Solaris. The Solaris source code up until svn_14x was released by Sun/Oracle under CDDL. There are basically three main heritages for Unix userland. "Genetic" Unix (Solaris, AIX, True64, etc., which came from AT&T code and is largely closed, but Solaris was open for a time), BSD (which finally stood on it's own as of 4.4-lite) and GNU. But I think that moving away from GNU will be equally difficult (or easy) wether you go with BSD or Solaris. Or you can get really ambitious and make xenocore-utils ;-)

[maxschlepzig]

This is the only practical solution atm, if you don't want to hack C. And busybox versions should be pretty standard conforming.