6 ms·

Significantly bigger than the C version. Rust: 73M source: https://packages.debian.org/experimental/rust-coreutils https://packages.debian.org/experimental/rus

Significantly bigger than the C version. Rust: 73M source: https://packages.debian.org/experimental/rust-coreutils https://packages.debian.org/experimental/rust-coreutils C: 17M https://packages.debian.org/unstable/coreutils https://packages.debian.org/unstable/coreutils Note that no size optimization that been done and there is a lot ways to do it in Rust https://github.com/johnthagen/min-sized-rust https://github.com/johnthagen/min-sized-rust In term of performance, well, it depends on the binary. For example for cp, most of the time is spending copying the files. For the factor command, some work happened to make it faster https://github.com/uutils/coreutils/commits/master/src/uu/factor https://github.com/uutils/coreutils/commits/master/src/uu/fa... (getting closer). Using Rust also opens some great capabilities like parallelism. But this makes sense only for complex commands. For example, doing a parallel "df" isn't super interesting (I tried it was too expensive just to start threads to do it). Anyway, performances should be a focus but only after correctness is implemented.

arp242 6y ago
You can use it as a single binary that's linked to the actual tool name, like busybox. That binary is just 9.6M (0.0.4 from their GitHub, Linux/amd64). The Debian version ships with separate binaries though (109 of them), and is much larger. There is probably a lot of duplication as many tools use the same Rust libraries for flag parsing and whatnot which are compiled in the binaries. This is why those 73M compresses down to just 8M.
- alerighi 6y ago
  First, symlinks are not really portable, for example they don't work on Windows, or in ancient UNIX systems. Also, that way every command executes with the same privileges because it's the same binary. And at least in Linux capabilities are bounded to a binary. So for utility that necessitate of special capabilities (e.g. ping, passwd, sudo, etc) this approach will not work. Yes, it works on busybox since everything is owned by root on the typical system so nobody cares about privileges. Finally, you need to load in memory every time you run a single binary all the thing needed by all the other binaries, even for the `true` binary. To me is stupid. The solution exists, and exists since ever, and it's encapsulating common functionalities in shared libraries, and have very small binaries linked to only the libraries they use. Unfortunately Rust choose not to support them for stupid reasons like problems that were resolved decades ago.
  - Blikkentrekker 6y ago
    > The solution exists, and exists since ever, and it's encapsulating common functionalities in shared libraries, and have very small binaries linked to only the libraries they use. Unfortunately Rust choose not to support them for stupid reasons like problems that were resolved decades ago. Rust has a stable a.b.i., simply not it's own stable a.b.i. as distinct from C's. `repr(C)` is what gives a stable a.b.i. in Rust.
_flux 6y ago
> For example, doing a parallel "df" isn't super interesting Actually I would enjoy that. Sometimes slow filesystems (e.g. stuck nfs) prevent the whole list from being displayed, or displayed only up to some point. If ctrl-c let me break out the command yet list all the collected data (preserving non-parallel order), it would be nice at times. Bonus: list skipped mountpoints to stderr..
gpm 6y ago
> For example for cp, most of the time is spending copying the files. As it turns out, cp can be made significantly faster by using (very) modern kernel APIs: https://wheybags.com/blog/wcp.html https://wheybags.com/blog/wcp.html 20 512MiB files wcp 3.97s, 2579.59 MiB/s cp 8.44s, 1213.38 MiB/s rsync 17.26s, 593.33 MiB/s
viraptor 6y ago
> For example for cp, most of the time is spending copying the files. There's a lot of ways to "copy a file" though. Finding the right buffer sizes, making concurrent read/write ops for different backend devices, and many other things can influence this. A good cp is not trivial.

arp242 6y ago

You can use it as a single binary that's linked to the actual tool name, like busybox. That binary is just 9.6M (0.0.4 from their GitHub, Linux/amd64). The Debian version ships with separate binaries though (109 of them), and is much larger. There is probably a lot of duplication as many tools use the same Rust libraries for flag parsing and whatnot which are compiled in the binaries. This is why those 73M compresses down to just 8M.

alerighi 6y ago
First, symlinks are not really portable, for example they don't work on Windows, or in ancient UNIX systems. Also, that way every command executes with the same privileges because it's the same binary. And at least in Linux capabilities are bounded to a binary. So for utility that necessitate of special capabilities (e.g. ping, passwd, sudo, etc) this approach will not work. Yes, it works on busybox since everything is owned by root on the typical system so nobody cares about privileges. Finally, you need to load in memory every time you run a single binary all the thing needed by all the other binaries, even for the `true` binary. To me is stupid. The solution exists, and exists since ever, and it's encapsulating common functionalities in shared libraries, and have very small binaries linked to only the libraries they use. Unfortunately Rust choose not to support them for stupid reasons like problems that were resolved decades ago.
- Blikkentrekker 6y ago
  > The solution exists, and exists since ever, and it's encapsulating common functionalities in shared libraries, and have very small binaries linked to only the libraries they use. Unfortunately Rust choose not to support them for stupid reasons like problems that were resolved decades ago. Rust has a stable a.b.i., simply not it's own stable a.b.i. as distinct from C's. `repr(C)` is what gives a stable a.b.i. in Rust.

_flux 6y ago

> For example, doing a parallel "df" isn't super interesting Actually I would enjoy that. Sometimes slow filesystems (e.g. stuck nfs) prevent the whole list from being displayed, or displayed only up to some point. If ctrl-c let me break out the command yet list all the collected data (preserving non-parallel order), it would be nice at times. Bonus: list skipped mountpoints to stderr..

gpm 6y ago

> For example for cp, most of the time is spending copying the files. As it turns out, cp can be made significantly faster by using (very) modern kernel APIs: https://wheybags.com/blog/wcp.html https://wheybags.com/blog/wcp.html 20 512MiB files wcp 3.97s, 2579.59 MiB/s cp 8.44s, 1213.38 MiB/s rsync 17.26s, 593.33 MiB/s

viraptor 6y ago

> For example for cp, most of the time is spending copying the files. There's a lot of ways to "copy a file" though. Finding the right buffer sizes, making concurrent read/write ops for different backend devices, and many other things can influence this. A good cp is not trivial.