This needs to be extended, made easier, and every programming language should do it by default. This means that regardless of when you released some software, you can pin how it works, so even if you upgrade the library 10 years later, it will work the same way (as long as the library keeps the old version of the function). Glibc allows specifying the version of a function at call time, so that you can call a specific version of a function in a library.
But clearly the solution needs to happen in the software, not in how we install it. We just kick the can down the road to a random package manager and hope for the best. It all exists because the software itself has no way to express its own compatibility with other functions or dependencies. The dependency hell, the conflicting versions, the filesystem hash trees, the DSL. Rather, let's make pink wallpaper, pink sofas, pink chairs, pink rugs, and then say that we've solved the problem, because you can barely even see the elephant now. Nix is intended to find complicated ways to work around the problems in those development patterns. There are clearly major inherent limitations in how software is developed that led us here. Moreover, it seeks to be a monolithic proprietary solution rather than a collection of loosely-coupled layers that can be interchanged.īut what irks me is that it doesn't fundamentally change anything. Of the many problems it has are assumptions about development models, deployment models, and operational models. Nix is an academic's solution to a large problem space based on a single principle ignoring several real limitations in order to shoehorn itself into an existing box of a problem.
0 kommentar(er)
