FreeBSD 11.0 amd64. with the ability to build custom ports it makes shipping the stack we want super easy. The ports tree includes by default an OTP 19.0, OTP 18.0, and a “latest OTP” by default so keeping both a consistent erlang release as well as keeping OS (particularly OpenSSL) patches up to date is pure cake.
I have found recent linux to be an unmanageable dog’s breakfast of random changes that require continual re-tooling just for the sake of it, and getting patches committed to upstream FreeBSD is reasonably straightforward. I don’t recall ever managing to get through Debian’s arcane processes successfully myself.
I summed this up in 2 posts, one personal and another one on the iwantmyname blog hope its interesting reading. Comments and questions welcomed.
Yeah, I see this similar. While I am happy with my package manager, is it still the case that we at Linux based distros - and even in FreeBSD and so on - are lacking behind Windows for some decades, since its possible there to simply install another version, while we are here bond to the dependencies.
At least with both debian/ubuntu and redhat style repo’s you can install older versions just fine, and you can ‘pin’ an install to prevent auto-upgrading as well. All of that is easily controllable at least with those 2 setups (apt/yum), unsure about others.
The repo managers, both apt and yum anyway, will use the latest set of dependencies that fulfill all requirements of installed applications. If there is a conflict between pinned applications then you have a few options, either unpin something to let it choose a better matching version based on all other constraints, or don’t install one of your pin’d applications straight and instead install it as a standalone flatpak or something.
You can have multiple versions or variants of a package installed at the same time. This is especially important when different applications have dependencies on different versions of the same package — it prevents the “DLL hell”. Because of the hashing scheme, different versions of a package end up in different paths in the Nix store, so they don’t interfere with each other.
An important consequence is that operations like upgrading or uninstalling an application cannot break other applications, since these operations never “destructively” update or delete files that are used by other packages.
Functional package language
Packages are built from Nix expressions, which is a simple functional language. A Nix expression describes everything that goes into a package build action (a “derivation”): other packages, sources, the build script, environment variables for the build script, etc. Nix tries very hard to ensure that Nix expressions are deterministic: building a Nix expression twice should yield the same result.
Because it’s a functional language, it’s easy to support building variants of a package: turn the Nix expression into a function and call it any number of times with the appropriate arguments. Due to the hashing scheme, variants don’t conflict with each other in the Nix store.
I might try it out on my new laptop after some more reading and YouTube videos.
Last week, the CentOS Atomic SIG released an updated version of CentOS Atomic Host (7.1707), a lean operating system designed to run Docker containers, built from standard CentOS 7 RPMs, and tracking the component versions included in Red Hat Enterprise Linux Atomic Host.
The release, which came as part of the monthly CentOS release stream, was a modest one, including only a single glibc bugfix update. The next Atomic Host release will be based on the RHEL 7.4 source code and will include support for overlayfs container storage, among other enhancements.
Outside of the Atomic Host itself, the SIG has updated its Kubernetes container images to be usable as system containers. What’s more, in addition to the Kubernetes 1.5.x-based containers that derive from RHEL, the Atomic SIG is now producing packages and containers that provide the current 1.7.x version of Kubernetes.