EDIT: actually, the more I think about it, I'd love to see that - just a tarball of all up2date static binaries needed to install arch from any linux rescue system, no matter which libs it provides. Would make some stuff easier.
]]>That really does not cover any of the supposed advantages of static linking - which is the point of this project.
I did not list advantages of using static linking vs dynamic linking. The original question was what the advantages was with uclibc (and musl) and I answered that in context of static linking, where they clearly are better than glibc.
Then the whole fundamental debate of static-vs-dynamic: I think both have their places. Big and complex stuff like KDE would never be useful as a static project. On the other hand, a system designed for static linking from the ground up (like Plan9) performs really well (and especially in that case, static linking is also critical for the most interesting features of that OS, which are private namespaces and being distributed so executing a program locally or remote is not different).
There are several advantages to static binaries - one nice one is that you avoid "dependency hell" and really old binaries can still execute on a modern kernel.
Personally I think the robustness and performance of static linking would do really well as a core for a distro (all critical components + package manager) and that dynamic stuff would then run in chroots/jails.
]]>Edit: just because I feel like it...
Disadvantage: you have to recompile everything that links to a library if there is a security issue found. Not just the library itself.
And this one is better....
Disadvantage: it is slower. That is right. SLOWER. You may think you need to load less libraries. But consider the C library. The first time a program using it is loaded, it is faster to be statically linked. But from then on, the shared library is nicely cached and is faster than the static versions which requires reload for every piece of software.
Which leads me to the only advantage:
Advantage: you are robust to library mix-ups such as incomplete upgrades of issue such as the /lib symlink where the linker could not be found.
]]>so, what's the "profit" for using software that compiled against uclib?
sorry for my curiosity.
uclibc and musl are smaller libc:s. If you would do static linking against glibc, you would end up with hugely bloated binaries. That and also that glibc basically actively discourages the use of static linking (Depper basically tried to exterminate the use of static linking). Especially musl libc is very interesting since it also comes with a permissive licence which steers clear of the shady grey legal area of copyleft licences (including LGPL) and static linking.
]]>Infancy... I'd say has been and died...
Oh yeah, I guess August was a while ago... I didn't actually look at the page, I just remembered hearing about it a while back.
]]>There is also the ArchServer project, which is also still in its infancy
Infancy... I'd say has been and died...
]]>I really like Starch's "The Arch Way".
]]>I have been running some packages from those repositories and I am very happy with it. I think that whenever it reaches maturity, having a base installation static and then schroot into a dynamic Arch environment (for example for a GUI) whenever needed could be quite nice!
]]>