Hacker News Reader

Comment by rowanG077 | Hacker News Reader

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.

View on HN

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...

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.

> 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.

> 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.

> 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.

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).

That's interesting. I'm surprised. Just some cursory websearching and didn't see anything that gave a solution here for DNF at least. Funky! Seems like there should be a way to deal with this.

I'm a relative newbie with Nix, but I recently installed a Gnome extension through Home Manager, and then removed it again. It left some native functionality unusable because the install flipped a pref and the dev had forgotten to revert that on uninstall. They fixed it quickly and it was nice and all, but it's still somewhat unpredictable to me when I will run into such cases.

Well to be fair, nix packages (as in the actual packages and not the modules/services) also mostly just extract archives. I mean the entire system is built on the assumption that 'config && make && make install' is how the thing is built.

Then nix layers way more nicety on top by offering modules, but nothing prevents you from ignoring all that and just using installing packages.

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.

They also do a really sloppy job of marking why packages were installed in the initial installation media... A bunch of packages that are not critical get marked as manually installed (so they don't go away if you remove the things that depend on them). At the same time, a bunch of packages that are actually critical don't get marked as manually installed. This means that you can remove a package you don't want and then autoremove will start wanting to uninstall critical parts of your system.

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.

Yeah, I have never, ever broken Ubuntu by installing packages. People are talking in this thread like Ubuntu or other distros are super fragile, but they really aren't.

Agree to disagree, I guess.

I've found three "hotspots" that break Ubuntu at a pretty high rate of incidence: 1) Upgrading to the next distro release 2) Installing or updating Nvidia drivers using the built-in management tool 3) Changing to a different kernel "series" (such as switching to a hardware enablement kernel)

In all these cases, I've found that the process stands a solid (hand-waving: 20%) chance of stopping in the middle, requiring manual resolution of broken packages.

Reply on news.ycombinator.com