I have to say that that "surprisingly simple" thing is happening more and more for me on NixOS as well.

Recently a customer wanted me to use Fedora (I never visited the RPM side of the world before), and after truly the worst installer I've ever used, the actually system was nice. I do like Cockpit.

But then I needed to install an initrd that would me unlock the full disk encryption via SSH (it's a remote headless box). It took me half a day and a forum post to get it to work. I wrote a full page of notes for next time. Then the Firewall: I hit a bug (plus user error) which left me wrestling with a non-existent Tailscale interface for a while (it warns you for non-existing interfaces, but not with only a case mismatch, it then lets you do everything as if the interface exists), but after some hours I was done setting the zones, another page of notes and commands to enter to get to the desired state.

These configurations are both 1 or 2 lines in a NixOS config file. And that "work" is now done for all my NixOS servers.

You could argue that NixOS hides a lot of complexity, but so do Dracut and Firewalld of course. Nix is difficult, it's a high level abstraction. But it also just a bunch of key-values, and write-once, deploy everywhere.

▲

CraigJPerry 6 hours ago | parent | next [-]

>> You could argue that NixOS hides a lot of complexity

They both have the same complexity in that scenario. Underneath it's very comparable configuration for both but Nixos provides an easy abstraction for that specific case.

If you can stay on the happy path with nixos then it's pretty lovely. I've even adopted nix-darwin for my mac's too.

I'd still deploy Redhat/Fedora over nixos on anything revenue generating though. The problem is when you have to come off the happy path in nixos and now you're debugging some interestingly written c++ code that evaluates a language that has a derivation expressing what you wanted done. Contrast with the redhat situation, it's simpler but less convenient in the general case.

	▲	rgoulter 5 hours ago \| parent \| next [-]
		> The problem is when you have to come off the happy path in nixos and now you're debugging some interestingly written c++ code that evaluates a language that has a derivation expressing what you wanted done. I agree that Nix or NixOS are risky tools. But it's not a problem that the `nix` program is written in C++. A lot of the friction comes from the tension between NixOS's idiosyncratic design & its constraints, against the often 'dirty' way software is practically written. For example, roughly, Nix's ideal software follows `./configure && make && make install`, where nix can then symlink the dependencies & maintain these in a read-only store. -- Whereas, say, Python wheels break this (because the precompiled binaries assume shared libraries are available globally). When you run into friction with NixOS, you may need to understand things with a depth and breadth which aren't required with more common Linux distributions. (Including e.g. maybe needing to understand the rather large and obscure nixpkgs).
	▲	an hour ago \| parent \| prev \| next [-]
		[deleted]
	▲	hombre_fatal 4 hours ago \| parent \| prev \| next [-]
		Do you have examples of times you've had to dig into the nix language like that, at least at a high level? Just curious. I haven't run into anything like that myself. Using nix for three months now, the main "pain" I run into is that I want app config files to remain writable by the app, but home-manager ethos is understandably against that -- and this is what you want on servers. So I've had to vibe-code my own HM module for claude code, keepassxc, cursor, etc. and use activation to merge my nix settings into those files if they exist. That way when I rebuild, my nix config can assert a subset of the config I care about without locking the app out of writing to config -- and this makes more sense for personal desktop computing. Though I put pain in quotes because it's still 10x better than what I was doing before, and an LLM can do it just fine.
	▲	teekert 5 hours ago \| parent \| prev [-]
		I do agree with that. But as a result I've gotten pretty good at whipping up podman containers with various bases to solve such issues.

▲

poelzi 6 hours ago | parent | prev | next [-]

The difference is, you can create proper abstraction modules that put everything together, from dependencies, to config files, firewall rules etc and have nice options for your abstraction.

No other system provides this in that sane way. I used countless configuration systems, from custom bash hacks, ansible, chef, puppet, salt - I have seen a lot.

Nix is just on another level. Never going back

▲

unshavedyak an hour ago | parent | next [-]

My problem with those abstractions is:

1. That the error messages for them i find to be awful. They really need to take inspiration from Rust to help users know exactly where the API error is happening relative to your code. I've spent quite a lot of time toggling things on and off to try and find which part of code, or which package, is causing a specific failure.

2. I've not found the APIs that the abstractions provide to be stable in the same way my Rust crates/etc are. Something can randomly break between updates and i'm not sure what caused it. Takes me quite a while of digging through source to find the root cause, and digging through Nix source i find extra painful.

All around i hate this side of Nix. A lot. However it's enough of "another level" that i stay with it and don't switch away.. I use it for my Linux machines and my Mac laptop. It makes so many things so easy, the majority of the time.. but when something goes wrong.. it's super painful.

	▲	packetlost 31 minutes ago \| parent [-]
		As someone who up until recently would have agreed with you, both of these are fundamentally familiarity issues. Nix's error messages really aren't that bad, but chances are there's exactly one line out of 200 that tells you what's wrong. Learning to read stack traces for a new language is part of learning that language. I've not had issues with Nix APIs, at least not Nixpkgs or the language builtins. When something does break for me, it's usually some random JavaScript package that had some external dependency change. Nixpkgs is pretty well organized and I find navigating it not that hard once you read the packaging guidelines. find / fzf / ripgep / etc. are all great at this, as file and folder names are critical to the organization of nixpkgs. The big turning point for me was trying to build and package a non-trivial application and build a NixOS module for it.

▲

rgoulter 5 hours ago | parent | prev [-]

> The difference is, you can create proper abstraction modules that put everything together, from dependencies, to config files, firewall rules etc and have nice options for your abstraction.

Yes, this is an understated benefit.

The declarative interface is nice.

That NixOS configs are modular allows you to create those abstractions. -- In the same sense terraform modules are "infrastructure as code", NixOS modules are "system configuration as code".

▲

vegabook 6 hours ago | parent | prev | next [-]

Yeah once you've used Nix[OS] and home-manager, it's hard to go back to apt or brew or the dreaded "sudo make install" without feeling like you need to have a shower afterwards. And I was a loyal Ubuntu person for like 15 years. It's especially true if you're a dev installing and uninstalling all day long.

▲

pzmarzly 6 hours ago | parent [-]

With homebrew, you can have Brewfile that can serve as declarative source of truth.

I try to install all software via homebrew, mise (https://mise.jdx.dev/), and scoop (https://scoop.sh/), and setting up a new machine now takes me minutes. Meanwhile I don't need to deal with Nix language.

▲

embedding-shape 5 hours ago | parent [-]

> With homebrew, you can have Brewfile that can serve as declarative source of truth.

for homebrew, while Nix configuration is for everything. I never used a Brewfile before, so looked at https://github.com/Lissy93/Brewfile/blob/master/Brewfile but it just looks like a list of packages. What about the configuration for those packages? Or your own custom patches for them? Runtime parameters? Environment variables?

There is so much more going on in the typical developer environment that it doesn't seem like (to me, an uneducated fool) Brewfile would be enough to actually serve as a declarative source of truth, except for Homebrew-specific things.

	▲	the_gipsy 4 hours ago \| parent [-]
		Versions? Compatibilities? Just pulling latest doesn't cut it.

▲

mhitza 3 hours ago | parent | prev | next [-]

> unlock the full disk encryption via SSH

I'd like to read more about this. Are you open to sharing your notes?

▲

rowanG077 7 hours ago | parent | prev [-]

This has been my experience as well. Before I switched to NixOS I used ubuntu for 2 years. I never grokked the ways of apt and how or why it would "randomly" brick my system in some way. With NixOS this has never happened. `nix-shell` is dead simple, adding packages to environment is dead simple, never has it bricked my system. The hard part of NixOS is if you want to do advanced things with the actual nix language, and of course the horrible error messages.

In terms of all the linux systems I have used, NixOS seemed to least magical to me in terms of what is happening under the hood.

▲

xnoreq 6 hours ago | parent [-]

What?! Insane take. NixOS is where the most "magic" happens, over and under the hood. It brings it's own language!

Simple package based distros like Arch basically just extract archives. Very few packages trigger post-install steps which usually just (re)generate something like initrd.

Afaik, bricking Ubuntu is either due to user error (e.g. mixing incompatible package sources) or the devs released broken/buggy packages...

▲

tkz1312 5 hours ago | parent | next [-]

If you're not making changes to the bootloader it's essentially impossible to brick nixos: updates are fully atomic and every change can be rolled back by booting into an old generation.

This combined with the fact that the full source code for the system is contained within a single monorepo that I can checkout and grep through makes NixOS the easiest to understand and most transparent distro I have ever used.

	▲	embedding-shape 5 hours ago \| parent [-]
		> updates are fully atomic and every change can be rolled back by booting into an old generation Well, the updates themselves yeah, but not what data they use. You cannot always rollback database upgrades for example, without also having to rollback the data source of the database. In most cases you're right though. I'm saying this as someone who is a fan of NixOS and use it on all my servers because I tend to forget what I do if I just ssh in and fix stuff. Although I'm on Arch/CachyOS on all other hardware.

▲

gf000 5 hours ago | parent | prev | next [-]

> Simple package based distros like Arch basically just extract archives. Very few packages trigger post-install steps which usually just (re)generate something like initrd.

Sure it's simple, just like 80% solving the problem is usually significantly simpler than solving it 100%. Nix (and its generation) is the only package manager that actually works.

Try installing kde and gnome, then uninstalling both and check how many packages remain.

Nix can do that with the whole world with nothing residing.

▲

jcgl 3 hours ago | parent [-]

> Try installing kde and gnome, then uninstalling both and check how many packages remain.

Sounds like a package manager or package problem. Competent package managers (e.g. dnf) remove unneeded packages and all their owned files. Albeit, I think with apt you need to do a manual autoremove to remove orphaned packages.

Not suggesting that they're equivalently powerful compared to nix, but this specific thing shouldn't be a problem with traditional package managers.

	▲	polivier an hour ago \| parent [-]
		A common issue with most package managers is that if you have A installed, and then you install B which depends on C, and that C happens to also be an optional dependency of A, then uninstalling B will not uninstall C as C won't be orphaned (because of A).

▲

sigmonsays 2 hours ago | parent | prev | next [-]

I think you uncovered the actual reason without saying it.

- in traditional package manages, the dependency is global, and potentially breaks everything else installed.

- in nixos, package is isolated to the environment and can co-exist on its own, for the purpose of one application.

▲

rowanG077 5 hours ago | parent | prev [-]

I never used arch so I can't comment on that.

I'm comparing it to my experience with Ubuntu where packages can have complex install dependency flows that can destroy your system at any time. They also pollute your entire system. This is simple in the same way assembly is a simple way to program. You can do anything and destroy anything. It's essentially spaghetti code but in OS form.

You can say it's "user error" or "packaging error", which is arguably true, but this "user error" and "packaging error" literally does not exist in NixOS. Installing a package is unable to touch anything outside of it's own designed nix store folder. That is why it's so much simpler to understand for me. I can check the nix store path and see what a package has. I can fearlessly install a package without worrying my system will break. I don't have to worry about residual dependencies remaining on my system.

The nix language itself ain't it though, I agree.