3 ms·
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 rec
by newnewpdro 9y ago
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.
- jburgess777 9y agosln is on the way out too... https://www.spinics.net/lists/fedora-devel/msg241326.html https://www.spinics.net/lists/fedora-devel/msg241326.html
- newnewpdro 9y agoI 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.
- jburgess777 9y agoI 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-guide/kernel-module-driver-configuration/Working_with_the_GRUB_2_Boot_Loader.html#sec-Booting_to_Rescue_Mode https://docs.fedoraproject.org/f27/system-administrators-gui...
- the_why_of_y 9y agoStatically linked binaries on the root filesystem for recovery were obsoleted by initrd/initramfs many years ago.
- newnewpdro 9y agoYou'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.