Sta.li: Static Linux
sta.li
Sta.li: Static Linux
1–10 of 99 posts
Re: Sta.li: Static Linux
#2Re: Sta.li: Static Linux
#3Not sure about "changing code during runtime", but one of the great benefits of dynamic-link libraries are for writing plugins. And I don't think it would take much time for an app to look up its own plugin folder.
Re: Sta.li: Static Linux
#4It's an admirable initiative, but I'm pretty sure that at this point sta.li has been in the "design phase" for years. It's vaporware. I'd love to be proven wrong, though.
Re: Sta.li: Static Linux
#5It's an admirable initiative, but I'm pretty sure that at this point sta.li has been in the "design phase" for years. It's vaporware. I'd love to be proven wrong, though.
Re: Sta.li: Static Linux
#6Re: Sta.li: Static Linux
#7Re: Sta.li: Static Linux
#8"Also a security issue with dynamically linked libraries are executables with the suid flag. A user can easily run dynamic library code using LD_PRELOAD in conjunction with some trivial program like ping. Using a static executable with the suid flag eliminates this problem completely."
Have the authors actually tried this? Using LD_PRELOAD with suid programs won't work.
Re: Sta.li: Static Linux
#9> Linking a stripped hello world program with glibc results in 600kb. Linking it with uclibc in about 7kb.
That's nice for uclibc, but we're typically linking dynamically. The comparison should be between dynamically and statically linked binaries. A stripped and dynamically linked hello world results in a 6kb program on my machine (glibc).
There's also a lot of handwaving on memory usage in the FAQ.