Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
[miah: Mar 20 07:47] > Sounds like you've had this problem pop up before. Maybe the distro you're running is doing things wrong? Maybe you're building your partitions incorrectly? > I was just way too flip - sorry bout that.. not enough coffee. Sure I've had this problem, but it was long before RHS existed.. but my point is the RHS is just a standard while code is tangible and that goes to the crux of the 'what is static linking good for' question. static linking eliminates some environmental variables. In a very conservative environment like troubleshooting/debugging/recovery you want as few variables as possible because if everything were working in spec you wouldn't be in this unfortunate position to start with. So yeah, I think having a statically linked shell, ln, mount, cp, cat and maybe even a small vi is a good practice. e2fsck? it used to be very common for people to really screw up when upgrading libc. Typically you have something like: lrwxrwxrwx 1 root root 13 Nov 14 11:00 /lib/libc.so.6-> libc-2.2.5.so -rwxr-xr-x 2 root root 1260480 Oct 10 11:16 /lib/libc-2.2.5.so and you go and add a libc-2.2.6.so.. it was not uncommon for people to do "rm /lib/libc.so-6; ln -s /lib/libc-2.2.6.so /lib/libc.so-6".. but of course the ln would fail if it was dynamically linked. Yes, there was a way to do this right and avoid the pitfal, but fixing the screwup was a hell of a lot easier with some basic tools statically linked.
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |