When comparing Red Hat Enterprise Linux vs Nix os , the Slant community recommends Nix os for most people. In the question“What are the best Linux distributions for a backend developer?” Nix os is ranked 8th while Red Hat Enterprise Linux is ranked 12th. The most important reason people chose Nix os is:
Since NixOS stores all its packages in isolation from each other in `/nix/store` and because of the declarative configuration model, upgrading NoxOS systems is extremely reliable. Furthermore, it gives you the ability to roll back upgrades.
Ranked in these QuestionsQuestion Ranking
Pro Greatly favours stability over anything else
RHEL favours stability over being up-to date. For this reason it ships with packages that may be up to two years behind in order to ensure stability over everything else.
Using older versions for packages means that they have been thoroughly tested and used in production for quite some time, and are ensured to play well with each-other.
This strategy has paid off quite a lot in the past. One example is the Heartbleed bug which left RHEL unaffected since it was using a two-year old OpenSSL library which did not have the bug.
Pro Rapid security updates
Pro Each version is supported for a really long time
Each released version of RHEL is supported for around ten years by Red Hat with constant bug fixes and security updates.
Pro Built-in disaster recovery solutions through clusters
RHEL has several built-in solutions for disaster recovery. For example, it comes with pacemaker which can be configured to manage multi-site and and stretch clusters across multiple geographical locations for disaster recovery and scalability. It can also be configured to trigger notifications when the status of a managed cluster changes by using enhanced pacemaker alerts.
Pro Applications don't have to take into account potentially breaking changes in libraries
Since RHEL backports all updates and bug fixes to older versions in order to maintain package compatibility across releases, applications hosted on Red Hat Linux don't have to worry about potential breaking changes in libraries they use, especially language libraries.
Pro Best support as far as hardware goes
This distro is by far the one with the largest number of certified server-class hardware.
Pro Built-in support for containers
Comes with built-in management tools for containers (Atomic CLI, Cockpit) and a container runtime in the form of Docker engine.
Pro Upgrading the system is extremely reliable
Since NixOS stores all its packages in isolation from each other in
/nix/store and because of the declarative configuration model, upgrading NoxOS systems is extremely reliable. Furthermore, it gives you the ability to roll back upgrades.
Pro Extremely reproducible state of installation
Every package in your system is generated from a configuration file. This makes it very easy to reproduce that environment. Just copy the config file into a new machine and it's done.
Pro Great for Haskell development
It has all of hackage in it's package manager (which is confusingly named "nix" as well) due to being based around hashing and allowing you to compile in a sort of virtual machine (really just changing the PATH variable temporarily) it solves many of the versioning problems that you commonly have with cabal. Here's a tutorial (there's many others as well) http://www.cse.chalmers.se/~bernardy/nix.html.
Also I should note that you can use the package manager a la carte on Mac and most any linux distro.
Pro Versatile snapshot system
You can use and test snapshots without rebooting. Booting into snapshots or test configurations is possible without risking the system's stability.
Pro Has docker like system built in
Pro Allows parallel configurations for multiple projects
As everything is isolated, you can have on the same machine multiple configurations to meet project requirements that would be mutually exclusive on other OSes.
Con You need to buy a license
RHEL is a commercial Linux distributions and it's rather expensive as well, the cheapest license costs $349.
Con The configuration language is hard to figure out
For good reason. It's a purely functional language. However not even close to bash.