Ricardo Wurmus <rek...@elephly.net> writes: > Hartmut Goebel <h.goe...@crazy-compilers.com> writes: > >> Anyway: IMHO missing "dynamic binding" is one of the major drawbacks of >> functional deployment, as it requires updating (and esp. downloading) >> much more packages compared to a rpm/deb based system. > > At the same time static binding is also one of the major advantages as > deployments are stateless and thus much more predictable, reliable, and > inspectable.
Indeed. We are having the same dynamic vs. static debate at the systems level that has been going on at the programming language level for a while. And for both situations, we still have to find the right equilibrium between the two approaches, which both have their good and bad aspects. At the systems level, the last decades have seen a strong emphasis on dynamic binding, in particular with the dominance of dynamic linking and shared libraries. This has lead us into dependency hell to which we have found quick-hack solutions (coarse-grained packages such as Docker containers) and then more thorough ones (Nix and Guix). Now the challenge is to put the right dose of dynamic binding back into mostly static systems, and in the right place. For Guix, I'd say the right place is the individual profile, and in particular the user's default profile, so /usr/bin/env looks like a good start. My current way of doing my work with Guix is to play dynamically in my default profile but deploy stable applications in –pure environments. That's a bit more work than what I could dream of, but it's sooooo much better than everything else I have used before that I am not complaining. Cheers, Konrad.