You are not logged in.
Pages: 1
Hi
I just saw this on the suckless dev mailing list and I thought that it might be interesting for a number of Arch users:
http://lists.suckless.org/dev/1210/13050.html
Being bitten by the glibc migration (like many others) - I think that a static "core" sounds very attractive and musl libc is evolving nicely.
Other future plans also look very interesting: getting mksh as system shell rather than Bash might give some performance benefit (like debian/ubuntu went for Dash, just that mksh is more capable).
As soon as I get time, I will set up an alternative root partition and try to boot a Starch-based install.
Any thoughts?
My AUR packages
Any package of mine is up for grabs. If you think you could mantain it better - just contact me!
Offline
I don't think much performance critical stuff should be using bash these days (at least not in [base]).
Offline
Good to know Still, it will be interesting to see how this develops. My first attempts to install a base system from the starch repositories failed due to missing dependencies. I wonder if I first will have to install base from Arch [core] and then update to Starch...
My AUR packages
Any package of mine is up for grabs. If you think you could mantain it better - just contact me!
Offline
sorry for the necromancy, I just wanted to share an update that the Starch project got a webpage.
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!
My AUR packages
Any package of mine is up for grabs. If you think you could mantain it better - just contact me!
Offline
great project, very interesting to me
Offline
Interesting... though I am not sure that I am interested in trying it, I like the idea. There is also the ArchServer project, which is also still in its infancy. Though the idea of a static Arch is somewhat similar. http://www.archserver.org/
I really like Starch's "The Arch Way".
Offline
There is also the ArchServer project, which is also still in its infancy
Infancy... I'd say has been and died...
Offline
so, what's the "profit" for using software that compiled against uclib?
sorry for my curiosity.
just looking around.
Offline
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.
Offline
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.
My AUR packages
Any package of mine is up for grabs. If you think you could mantain it better - just contact me!
Offline
That really does not cover any of the supposed advantages of static linking - which is the point of this project.
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.
Offline
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.
My AUR packages
Any package of mine is up for grabs. If you think you could mantain it better - just contact me!
Offline
so, if the "trait" of static linking (slower as alan said before) then static linking doesnt fit for huge system.
i mean, i have a full kde installed in my system.
is it right?
again, sorry for my curiosity.
just looking around.
Offline
normally statically linked stuff are faster - especially the first time they are executed. But we can all agree that big and complex pieces of software (like KDE) probably are better off being dynamically linked. For core utilities and programs made according to the unix philosophy, however, static linking makes sense.
My AUR packages
Any package of mine is up for grabs. If you think you could mantain it better - just contact me!
Offline
Static linking is awesome imho for fundamental stuff, e.g. your package manager, fdisk, cfdisk, mdadm etc. because when they are, the executables are droppable into any linux rescue system. Especially nice for dedicated servers that offer a recovery system that runs in RAM only which you can (ab)use to install arch on the dedicated server.
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.
Last edited by IncredibleLaser (2012-12-11 16:45:44)
Offline
There was once a static pacman floating around, exactly for such purposes.
Offline
It's going to be very interesting what the suckless guys will create in their own distribution sta.li!
Offline
Pages: 1