Uutils 0.0.23 Implements More GNU Coreutils Functionality In Rust

[Akiko]

and that's before doing no_std shenanigans. (yes using gnu hurts here a lot). after doing the no_std stuff, the binary is 20k or so. not as small as musl granted, but small enough that I don't care.

Sometimes I really wonder if people actually read my message completely. I said I know this is possible, but if you do this, you drop most of what makes Rust secure and with that you drop the reason to use Rust. Then you can stick to C and still get smaller binaries. And btw you go right for the anecdotal fallacy, it doesn't matter if you care, this is not about personal needs, this is about generic embedded needs. And embedded sometimes has serious size restrictions and Rust does not fit these as well as C does. It just doesn't matter if your binaries are more secure if you can't put them in the available storage. And like I said, I also prefer Rust, but there are just places where using it just does not work.

[ClosedSource]

of those 71 crates, it makes it fairly easy to "audit" them,

No sane person wastes money auditing 71 external libraries. Regardless of how you personally don't "see an issue", it still exists. You end up locking to a certain version that you know works for you, or you constantly update and downgrade deps. This is common in Rust (check sccache project). It's a pain.

GNU Coreutils only depends on "acl attr glibc gmp libcap openssl" on Arch and it's safe to assume someone else is auditing those. The workload is much less.
The other point is that GNU Coreutils already exists. For a new project, Rust makes more sense. For old projects, most people won't bother with rewrites unless they have other motives such as personal exposure or practicing writing in Rust or some issue that Rust circumvents. In uutils case, it's good for them since publishing your efforts for free is always a commendable and respectable selfless act. But let's be reasonable here.

[jacob]

Rust requires LLVM meaning C++ meaning an architecture that has a C++ compiler. Your car keys probably have a C compiler.
You're absolutely right in that this is irrelevant because you can cross compile but the reason why minimal implementations of libc exist is because of what I just explained.

Rust doesn't necessarily require a C++ compiler. You can cross compile LLVM and the Rust compiler for your target architecture.

[ssokolow]

The reason for this is that people are reluctant to understand that Linux is the kernel and some kernel tools and nothing more. Everything else are GNU and/or third party tools.

/Rant over

That comes across as quite the non sequitur. I don't see how "everything else", including everything that predates Linux, taking a certain approach to development can be "because" people are reluctant to understand how Linux is different.

The sensible "because" is that, since Linux didn't provide a libc, it's the only kernel of note that provides stable syscall numbers instead.

[oleid]

Rust requires LLVM meaning C++ meaning an architecture that has a C++ compiler. Your car keys probably have a C compiler.
You're absolutely right in that this is irrelevant because you can cross compile but the reason why minimal implementations of libc exist is because of what I just explained.

True, you cannot run rust on 8 bit AVRs, but you can cross compile to on 8 bit AVR microcontrollers.

[ClosedSource]

Rust doesn't necessarily require a C++ compiler. You can cross compile LLVM and the Rust compiler for your target architecture.

This is pretty much what I said. You can cross compile. But this doesn't change why the choice to have busybox exists. Someone felt busybox was their straightforward solution.

[darkonix]

You won't get Rust binaries down to the size of C binaries, because C is basically Assembly in "readable" and Rust brings a bigger runtime to fight all the insecure issues.

Rust doesn't has a runtime. The security is provided by the compiler at compile time. Are you maybe thinking of something like Java or Python? If your project doesn't use Rust libraries and doesn't link the C library it should be nearly the same assembler-like runtime experience to a similar C program.

The reason for this is that people are reluctant to understand that Linux is the kernel and some kernel tools and nothing more. Everything else are GNU and/or third party tools.

/Rant over

Rust is officially supported in the Linux Kernel in the form of modules using basically what I mentioned above.

[moltonel]

Im not sure why it couldn't Is there any particular reason why not?

{gnu,uutils}-coreutils prioritize performance and features over install size, while busybox does the opposite. At the very least, coreutils are not a feature-wise drop-in replacement of busybox, both because busybox commands have much fewer options and because busybox has many more commands (shell, text editor, network utils, file compression, etc) that are outside the scope of coreutils.

i've already shown that as it is, uutils can adequately fit within very small size constraints thanks to the help of upx, so Im not sure Im understanding the point here. ofc im sure uutils will expand over time, but it's not like rust exactly does a good job of size optimization when building gnu libc statically. musl helps (but there are bugs surround it atm, I seem to hit this a lot https://github.com/rust-lang/libc/pull/3213)

My busybox install (using my distro's default busybox config) is 1.4M. Gnu-coreutils is 18M, uutils-coreutils is 10M, and you'd probably need at least 5 times that to add bash, util-linux, nano, tar, wget, and whatever else. UPX and linking tricks won't cut it, to compete with busybox's size you need a radically different approach. You could certainly try that in Rust, but not with a project that has "drop-in gnu-coreutils replacement" as its headline feature.

[moltonel]

No sane person wastes money auditing 71 external libraries.
[...]
GNU Coreutils only depends on "acl attr glibc gmp libcap openssl" on Arch and it's safe to assume someone else is auditing those. The workload is much less.

I'm tired of seeing this flawed argument. No sane person audits openssl for their pet project either, we all (hopefully) do a bit of due diligence, and trust the work of other reviewers and of the community at large. It's the same thing with Rust deps.

Having fewer deps means having more code. Auditing many small libraries is actually easier than auditing a handful of big ones, that are harder to dive into and that reinvented 20 different wheels. Is gnucoreutil's sha3 implementation good ? Is there an audit that looked at that part of the code specifically ? I worry much less when I see that uutils uses the same sha3 crate as is used and reviewed by the whole rust ecosystem. With a larger number of focused deps, you increase the chance of using code that has had many eyes on it.

Also, while it's a bit orthogonal to your argument, it is much easier to audit/review Rust code than C/C++ code. Because the especially gnarly parts are identified with `unsafe`, because the language gives many more assurances, because the type system allows you to reason much more locally, because error handling is much clearer, because the style and formatting is more consistent, etc. Comparing the audit comments of rustls vs openssl, it's clear which one was the more pleasant experience.

[ssokolow]

Rust doesn't has a runtime. The security is provided by the compiler at compile time. Are you maybe thinking of something like Java or Python? If your project doesn't use Rust libraries and doesn't link the C library it should be nearly the same assembler-like runtime experience to a similar C program.

Rust doesn't have a VM or a heavy runtime, but it does have a runtime... the same kind C does. Microsoft even talks about the CRT (C Run Time) in their docs.

These non-VM runtimes are responsible for things like translating the platform's command-line argument-passing convention (eg. the Program Segment Prefix in MS-DOS) into int main(int argc, char *argv[]) or one of its alternatives.

In that particular example, it's achieved by main not actually being the entry point from the OS's point of view. It's actually a function named _start which calls your main once it's finished setting things up. It's part of an object file that's commonly called something like crt0.o or gcrt0.o.