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.
Habitat can solve this: https://www.habitat.sh/
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.
How do you manage dependencies? I mean, if that is true, why do they ship so outdated versions only?
It’s very nice to ship a static LTS, while their standard repos get literally just new major versions of their browsers.
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.
Has anyone tried or does anyone have any thoughts on NixOS and Nix package manager?
Multiple versions
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.
A lot of people who develop the above-mentioned Habitat used the Nix package manager before.
So i consider it as a fine thing 
There is Guix also, it’s based on Nix: https://www.gnu.org/software/guix/
For those interested in Docker containers…
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.
