Hacker News Reader

Comment by simmons | Hacker News Reader

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.

View on HN

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.

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.

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.

Reply on news.ycombinator.com