Hello everybody,
I’m new in this forum and I’d like to compare Arch linux to NixOS.
What are the main pro’s/cons of NixOS instead of Arch?
Is NixOS highly customizable like Arch?
Is it not bloated (background)?
Is the Nix packet manager strong/fast enough?
Is NixOS easily administrable?
Why NixOS instead of the others?
Are the packets strongly verified/secrured?
And last but not least: Why is NixOS ranked at the 60th place on distrowatch 
.
Thanks guys.
I won’t mention any upsides that are due to Nix, since you can also use Nix on Arch. For me the most important attractors are:
git and you can build the same system over and over again. I have all our desktops and servers defined using NixOS declarative configuration. So, I can roll out each configuration on a new machine in seconds.Cons:
Yes. I would say even more, because it is easy to override derivations and thus build your own variation on a package.
Depends on your NixOS configuration 
.
Nix is the main selling point. But, you may want to read the Nix page first, since it gives a nice overview of the benefits:
Yes. Especially because it is declarative. You don’t execute a series of commands and edit a bunch of files. But you write a specification of your system and then instantiate it. This means that every system is fully-specified, it’s easy to reproduce, it’s easy to undo things (just remove it from your configuration and switch to that new configuration).
If you are unsure if NixOS is for you, I would first just try Nix on Arch Linux. Then you can explore Nix from the comfortable environment that you know. If you like it, you could use home-manager with Nix on Arch, to give you a taste of declarative configurations without switching fully to NixOS yet. If you like declarative configuration, you will soon want to do this for your whole system, that’s probably a good moment to switch to NixOS .
Thanks Daniel 
If you are unsure if NixOS is for you, I would first just try Nix on Arch Linux.
You can also try NixOS in a virtual machine.
I want to add qualify I think-
You can get started with your first package on day 1. But random things need familiarity with random components and nix has a lot. I’d say it’s a very unpredictable learning curve. (If my definition of Learing curve is correct )
If you’re not a programmer you’d probably find nixos frustrating. Might want to start with just nix.
I might counter with, “Why do you want to switch from arch to nixos?”
In addition to what @danieldk mentioned above, I would add a couple of things:
That being said, if you are a distro hopper planning to pop over to nixos as your next hop there are a few things to consider
The Reddit post that inspired me to try out nixos (and thereafter delete all other Linux partitions mint, arch)
Another note on the learning curve: NixOS is by far not as mature as more popular distributions. So while the underlying system is very robust and you can do almost anything in NixOS, often you have to dig through documentation, source code or even come up with something on your own, to get an idea working.
But one cannot overstate the delight of knowing that once something works, it will always work and is easy to reproduce at any time (given of course you keep everything properly pinned and declarative). You do not get this with any other distribution.
And last but not least: Why is NixOS ranked at the 60th place on distrowatch
Huh, that’s strange. It should be top 10.
I can only assume this is because:
At least once another company requested to replace NixOS with some more common distro/technology, because it doesn’t want to manage experimental things. So I guess “experimental” status for NixOS is a problem for corps.
And last but not least: Why is NixOS ranked at the 60th place on distrowatch
Huh, that’s strange. It should be top 10.
I guess Linux is not that correlated with in-depth computer knowledge (anymore) for NixOS to have a shot at top-10. It is costly to learn NixOS if you don’t know what all the things you should fill in about filesystem mean.
Also, I guess NixOS should have low DistroWatch page view count: what DistroWatch says about each distro is more or less irrelevant for choosing or not NixOS (it is about completely different tradeoffs with basic expectations violated). Looked at the DistroWatch page: mmmm, a long-dead mailing list address (should we do something about it, by the way?)
And last but not least: Why is NixOS ranked at the 60th place on distrowatch
The answer lies within the methodology of the ranking I guess.
all visits are logged. Only one hit per IP address per day is counted.
The DistroWatch Page Hit Ranking statistics are a light-hearted way of measuring the popularity of Linux distributions and other free operating systems among the visitors of this website. They correlate neither to usage nor to quality and should not be used to measure the market share of distributions. They simply show the number of times a distribution page on DistroWatch.com was accessed each day, nothing more.
Right. And also, because NixOS is so different from the other distros, there’s not much point in spending time on DistroWatch comparing it to them. When I was trying various versions of Arch, for example, I would look at DistroWatch for information about Manjaro etc., causing page hits. With NixOS, I look elsewhere for information, and there are no derived distros to find out about at all (except Guix, which also doesn’t have much on DistroWatch).
So I think DistroWatch is a useful source for comparisons of SOME distros with SOME others, but not at all for comparison of NixOS with anything else.
Systemd needs to add telemetry and publicly log installations and usages. Would be nice to know what features are often used and the areas of improvement. Perhaps distros can learn from one another
Another plausible explanation is that NixOS is just far less popular . I know quite some people who use or used Arch, but I can’t think of one NixOS user among my friends/colleagues.
That is a great idea !
Maybe all distribution developers could include a package that sends a request to a server that counts the number of installation on new machines.
The software should be secure enough to prevent any fraud.
Haha…unless it was opt-in, that would cause a nightmare with the privacy minded. Of course, if it was opt-in, the data would be terrible.
Not really. If it’s anonymized, there should be no reason to make it opt-in, or even opt-out.
An opt-out telemetry is as good as useless. Most people who would opt out are “power users” and their half-knowledge about the telemetry FUD often makes then switch it off and then wonder why their beloved feature is no more.
Hey why did you kill jumplists, I used them and loved them! (Windows 7 jumplists were only used by power users and extensively used by power users, at least in my sample of college friends)
There is… It’s called “law”.
Collecting user data, even anonymized, has to be opt in as I understand European laws
Well, given the published scientific research about deanonymization of datasets, not many can prove convincingly that they anonymize data well enough. And won’t be bought by Google eventually.
Well, everyone has seen the DownThemAll story, and Mozilla definitely had the download figures… So there is not always a convincing argument that exact knowledge of the usage of marginal features will help.
The biggest misconception is already in the title.
You do not have to switch your distribution ever.
You can achieve almost everything with almost every distribution. It might be a bit more work with this or that distribution than with another one, but its probably possible.
Personally the main reason to switch from Arch Linux to nixOS was Archs lack of ZFS support, and I wanted to drop BTRFS for a couple of reasons, of which one was its unreliability.
Other benefits I have from this transition is, that I have a centralised place and unified syntax to do my system configuration, and another place for the users configuration.
I can get similar recent programs as in Arch by simply overriding some attributes of a package. Updating software beyond what was given upstream in Arch always required me to manually check out from the ABS, tinker with PKGBUILD files, sandboxing the build of the package and then manually installing that package, and probably even miss update builds when I forgot to set the revision counter in the PKGBUILD to 0…
Similar for packages which you would like to have installed with a different set of flags than those provided upstream.