Oxidizing Fedora: Try Rust and Its Applications Today | Hacker News Reader

Oxidizing Fedora: Try Rust and Its Applications Today

fedoramagazine.org

103 pointsrayascott31 comments

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) which is similar to find.

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

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.

Unfortunately this doesn't seem to be something developers are very interested in nowadays. While it would improve the overall system it would also hurt the solid compatibility and introduce further headaches for the user, possibly being attributed to the software.

Would be nice if it did happen, though.

I would very much prefer if it did not happen. It does not really bring any benefits, but only brings horrors. Go and Rust both live in a statically linked state of bliss that should not be tainted.

http://harmful.cat-v.org/software/dynamic-linking/

I agree. There are certainly many cases where static linking makes a lot of sense. The redundancy of statically linking a few self-contained applications can be negligible and the reduced administrative burden can be a great value. But a hypothetical future Rust-heavy distribution, with hundreds of programs, may be an exception.

I sometimes wonder what a lightweight "Rusty" distribution for consumer electronics applications might look like. You can go a long way with the Busybox monolithic binary approach, but that might be a pain for development and software updates at some point.

Interesting, giving the package search a look, I thought they were dynamically linked.

Debian has a “debcargo” tool to turn crates.io packages into Debian ones so that they can do this.

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.

sln is on the way out too...

https://www.spinics.net/lists/fedora-devel/msg241326.html

I wonder why the distros don't ship a static-core alternative package for all this stuff statically-linked, for people who actually care about improving the odds of recovering their systems in the face of random filesystem corruption which may break dynamic linking or fat fingered commands run as root.

Zbyszek's comment about systems being cattle is very telling. What the hell are the these guys running on their laptops/desktops? I can see that attitude if you're only considering GNU/Linux as a substrate for running cloud instances and containers, but I use GNU/Linux as my main personal operating system on systems I absolutely do not view as cattle.

Grrrr.

I think the assumption today is that is easy to boot from some alternative media (usb/cdrom/pxe) into what used to be called a "live cd" (like Knoppix). Once there you can mount your existing partitions and attempt to fix any issues. The Fedora CDs have provided a "rescue" option since as long as I can remember and this attempts to find and mount your existing installation. There is also a rescue option in the grub boot list but I have never needed to use it.

The Fedora docs also describe two further rescue and emergency modes available from the grub menu: https://docs.fedoraproject.org/f27/system-administrators-gui...

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

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.

IIRC this is thought as a deliberate temporary solution because Rust does not yet has a stable ABI. There is no fundamental obstacle to build dynamically linked (shared) libraries in Rust.

How about replacing the core utilities?

https://github.com/uutils/coreutils

That seems like something that wouldn't be super valuable to put in place until all of the commands are completed, or at least close to completed.

already been done: https://github.com/redox-os/coreutils

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

So much fun over three small letters...

Oh! Well that pleases me.

They've made strides, but there are still things missing (there's a list halfway down the page). Perhaps one could just use the tools that are complete and fall back to GNU for everything else, though last time I tried to do that cleanly it didn't play well with the packages. (I may just be missing options to do a partial build)

Maybe instead of making it the system-wide default, you could use it for specific sensitive applications. That would make it more feasible to work around the missing features.

I'd love to know how this project compare to the similar Go based project go-coreutils.[0]

[0] https://github.com/ericlagergren/go-coreutils

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

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

don't mind all but the rainbow file permissions

I don't mind the color scheme but I think they overdid it. Not every bit of the permissions needs a different color. That makes it harder to read, for me.

I wonder how it looks on a white background? I definitely agree that they went overboard with colorizing the output.

My other question is are they working on a non ASCII layout that makes exa less awkward to type? The fact that "ls" uses two home row keys and the second is on the left hand (so the right is free to reach for enter) is not a coincidence.

I usually go a step further and alias 'ls' to 'd', reducing one keystroke on one of the most common operations.

Looks like Fedora's missing fd https://github.com/sharkdp/fd

It will be available in Fedora 28+: https://koji.fedoraproject.org/koji/packageinfo?packageID=25...

Great! I had only searched https://apps.fedoraproject.org/packages

Reply on news.ycombinator.com