
Oxidizing Fedora: Try Rust and Its Applications Today - rayascott
https://fedoramagazine.org/oxidizing-fedora-try-rust-applications-today/
======
VohuMana
Been using ripgrep for a while now, I love it. One other Rust tool people
might find useful is fd
([https://github.com/sharkdp/fd](https://github.com/sharkdp/fd)) which is
similar to find.

~~~
steveklabnik
fd was left out of this article because it’s in the version of Fedora after
the one the article is based on, incidentally.

------
simmons
I just installed Fedora 27 in a VM out of curiosity. As far as I can tell from
a quick glance, it looks like these Rust executables (ternimal, tokei)
statically link their dependent Rust crates (including the Rust standard
library), which is the typical approach to building Rust programs. I do wonder
if someday we'll see distributions arranging a common dependency realm (as
much as possible) among their Rust programs so that shared libraries can be
used to reduce the total memory and storage footprint.

~~~
newnewpdro
It's kind of funny how GNU/Linux used to intentionally have everything
statically-linked that was involved in bringing up the system and needed for a
rescue recovery session, so you could still administer a system even if your
dynamic shared libraries were hosed.

Now I see people tout statically-linked binaries as if it's some kind of new
thing brought by Golang and Rust. Though this may be a result of modern glibc
being somewhat hostile towards and incompatible with static linking, so maybe
the blame should fall on GNU for that one.

Netscape used to distribute statically-linked binaries for a number of *nix
platforms as a way to avoid this problem all the way back in the 90s. All it
needed was an X display server and stable kernel interfaces.

Eventually GNU/Linux changed to the point that everything was dynamically
linked to the point that only `sln`, a statically linked `ln` was all you had
to work with in lieu of a working dynamic linker to fix the system.

~~~
the_why_of_y
Statically linked binaries on the root filesystem for recovery were obsoleted
by initrd/initramfs many years ago.

~~~
newnewpdro
You're only considering the boot process.

The initrd/initramfs serves to provide a minimal userspace required by more
complex root storage arrangements before we can pivot root.

Sure I can reboot a system with hosed dynamic libraries into its initrd and
use that userspace to try fix things. But I can also reboot onto any other
rescue medium. The moment you've introduced a reboot into the recovery process
there's myriad solutions, the introduction of the initrd didn't make a
significant difference in this regard.

The historically statically-linked /bin /sbin stuff (yes, once upon a time not
everything was shoved under /usr like the post-systemd world) could be used to
fix broken dynamic libs without even requiring a reboot.

------
phkahler
How about replacing the core utilities?

[https://github.com/uutils/coreutils](https://github.com/uutils/coreutils)

~~~
empath75
already been done: [https://github.com/redox-
os/coreutils](https://github.com/redox-os/coreutils)

~~~
cbcoutinho
The `uutils/coreutils` repo is a rust re-write of the GNU coreutils. The repo
you posted is a rust re-write of the BSD coreutils

~~~
phkahler
Oh! Well that pleases me.

------
majewsky
exa is a prime example of how too much color absolutely ruins an otherwise
good UI.

~~~
sotojuan
Meh, persona choice. I really like the default color schemes.

~~~
jamespo
don't mind all but the rainbow file permissions

------
abrowne
Looks like Fedora's missing fd
[https://github.com/sharkdp/fd](https://github.com/sharkdp/fd)

~~~
CUViper
It will be available in Fedora 28+:
[https://koji.fedoraproject.org/koji/packageinfo?packageID=25...](https://koji.fedoraproject.org/koji/packageinfo?packageID=25842)

~~~
abrowne
Great! I had only searched
[https://apps.fedoraproject.org/packages](https://apps.fedoraproject.org/packages)

