That’s not a fair comparison at all. Busybox is specifically optimized for size, and to accomplish that, leaves out a large number of GNU compatibility features; uutils is designed to mimic GNU as closely as possible, and I’m assuming that the binary you’re looking at is not the “small-release” build. Just to see what that looks like, I’ve built it that way now and that puts it under 7 MiB; still much larger than busybox, but it shows how much the optimization choices matter.
That’s not a fair comparison at all. Busybox is specifically optimized for size, and to accomplish that, leaves out a large number of GNU compatibility features
Such as? busybox provides a nice interactive shell, awk, bc, wget and much more. I know GNU awk has a lot more features than posix awk but awk is not part of the uutils anyways.
busybox also implements [[ from bash, none of this is provided by uutils or coreutils.
EDIT: busybox also provides grep while the uutils/coreutils don’t.
I’ve built it that way now and that puts it under 7 MiB; still much larger than busybox, but it shows how much the optimization choices matter.
I’m assuming this uses -Os which means performance hit, (iirc busybox also uses -Os so it is fair comparison), still we are looking at 7x larger binary.
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 has been written with size-optimization and limited resources in mind.
Neither of these is true for uutils, which is specifically targeting perfect GNU compatibility. I don’t think there is a comparable Rust project for minimized utilities.
The utilities in BusyBox generally have fewer options than their full-featured GNU cousins
Note: GNU cousins, not GNU coreutils.
GNU awk, GNU grep, bash, wget, etc will give you a lot more features than the busybox equivalents. However the uutils nor coreutils implement those features at all.
If anything the comparison is not being fair to busybox because busybox implements a lot more utilities.
I really don’t think these are clearly comparable. I would rather see two more similar projects with comparable functionality that are both attempting to optimize for program binary size.
That’s not a fair comparison at all. Busybox is specifically optimized for size, and to accomplish that, leaves out a large number of GNU compatibility features; uutils is designed to mimic GNU as closely as possible, and I’m assuming that the binary you’re looking at is not the “small-release” build. Just to see what that looks like, I’ve built it that way now and that puts it under 7 MiB; still much larger than busybox, but it shows how much the optimization choices matter.
Such as? busybox provides a nice interactive shell,
awk
,bc
,wget
and much more. I know GNU awk has a lot more features than posix awk but awk is not part of the uutils anyways.busybox also implements
[[
from bash, none of this is provided by uutils or coreutils.EDIT: busybox also provides grep while the uutils/coreutils don’t.
I’m assuming this uses
-Os
which means performance hit, (iirc busybox also uses -Os so it is fair comparison), still we are looking at 7x larger binary.From the busybox “about” page:
Neither of these is true for uutils, which is specifically targeting perfect GNU compatibility. I don’t think there is a comparable Rust project for minimized utilities.
Note: GNU cousins, not GNU coreutils.
GNU awk, GNU grep, bash, wget, etc will give you a lot more features than the busybox equivalents. However the uutils nor coreutils implement those features at all.
If anything the comparison is not being fair to busybox because busybox implements a lot more utilities.
Busybox
ls
has 26 flags. GNUls
has 60.fair, in that case the comparison is even since busybox provides a shell, awk, grep, wget among other 395 utils, uutils it is 115.
I really don’t think these are clearly comparable. I would rather see two more similar projects with comparable functionality that are both attempting to optimize for program binary size.