I was interested in NixOS until I saw no reference of a specific software I want. Literally not a single search result.

So, I guess its biggest flaw for me is that it cannot beat Arch Linux’s catalogue. So, maybe in a year I’ll check again.

I don’t believe NixOS prevents you from using the standard terminal commands or editing config files. It hooks you up with a different set of tools, ones which are better in some respects, but it doesn’t force you to use them.

nix-env -iA is there for a reason, they recognize that sometimes perfection is the enemy of good #^-#

Well Linux isn’t an operating system, it’s a kernel. The difference is really just the design philosophy of the package manager. As someone very experienced with NixOs, people are starting to catch up with it, but it’s much more advanced than the docker kubernetes mess most developers end up working with.

I’ve been using replit to host some small projects, it’s a real pain as replit is so heavily relied on nix packages.

Linux is a kernel. At the beginning, software, especially userland software mimicked Unix conventions. There is very little requiring that anything work the way it does, except for inertia and convention. As cloud native conventions gain steam, a lot of them are working their way backwards into things like Nix. Having spent some time working with things like K8s and Packet and cloud-init quite a bit, I welcome declarative instantiating and configuration at the OS level, at least for those use cases. Stuff like Ansible, Chef, Puppet, Salt etc have been the middleware between the legacy OS layer stuff and a declarative CM system, but they all have an absolute pile of complex scripts and tests to make sure that when you say “I want this package installed”, it knows how to do it correctly and safely on the target system. Using a leaner declarative model at the package level makes it a lot simpler to declare the desired state.

I am pretty bearish that it will ever see overwhelming adoption for desktop users, but I see it having a ton of relevance when you want to orchestrate a whole butt load of server instances

I don’t know if you’ve used Emacs, but NixOS almost feels to Linux how Doom Emacs is to GNU/Emacs. Not including all the benefits like reproducability, it feels like a reliable framework placed on top of Linux in the same was Doom Emacs is a framework on top of Emacs.

Having been in a similar situation to you, I say go for it. Arch taught me the basics about Linux that I think everyone should know to understand what Nix does under the hood, but as soon as I saw how well NixOS worked on my secondary machine I switched my primary over and I’m not regretting it in the slightest.

That’s not to say Arch is a bad distro, in fact I’d say 99% of my Linux knowledge comes from that excellent community, it really is KISS, but it makes no secret out of what this actually means: making it simple for the maintainer by delivering an almost untouched upstream, which I agree brings the ecosystem forward as it pushes toward a bazaar model where everything works together without the distributor doing too much work of their own. But if you want to keep a system clean in the long run, at one point you realize that you need a system like Ansible (which for me retrospectively has shortcomings that can only be fixed in the underlying system) or Nix integrated in your base system, which NixOS does.

I feel like that’s not really true beyond surface level. Sure, if you just use NixOS’s existing configuration and nothing else, you might not really come into contact with how it works under the hood, and I totally get how that might be your first impression. But I often write such modules myself and I think the low-level parts you use there are still very similar to how standard Linux systems work. The root filesystem doesn’t use the standard layout but it is still used inside packages and inside your current system link (/run/current-system/sw), for example.

Packages themselves too I would say aren’t too different from how they work on e.g. Gentoo (which also has a lot of abstraction around the actual build commands with eclasses), of course with the exception of the language.

The thing that I would say is very different is actually configuring packages, that’s true. But in the end that just usually places a configuration file somewhere and you can read how that gets put together in the module’s source code. NixOS isn’t the only system that does that, I think Ansible does it to an extent, for example, or openSuSE’s YaST.

Every distro has stuff that is only applicable to itself. NixOS does have more than usual of that, that’s true. But if you want to learn “pure Linux”, build an LFS system ;) In my experience NixOS knowledge is still useful in other distros and the other way around.

From what I’ve heard from NixOS users, your intuition seems right. When you learn NixOS, you learn NixOS rather than Linux. The question is, what your goals are. If you want to get a job as a Linux sysadmin, you’d probably be better off using a more common distro. But if you just want to use Linux privately, dive into whatever seems most exciting to you or fulfills your needs the best.

I don’t think NixOS is used by many companies, so it’s not really a skill that will likely lead to employment. Most companies use containers and tools like ansible which is accomplishing something similar to nix.