Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NixOS and my descent into insanity

ersei.net

Post reply on HN
Print view View original

111–120 of 120 posts

Re: NixOS and my descent into insanity

#111

Post by __MatrixMan__ »

fsflover wrote: post #64
jm4 wrote: post #13

NixOS is awful except for everything else out there. The learning curve is... steep. The documentation sucks. You have to learn a new OS because a lot of your prior Linux knowledge no longer applies. But, man, it's so slick when you get it working. It's so easy to understand your system and how it's set up. There's no weird stuff changing between updates that you don't know about. You don't have to merge new configur…

> NixOS is awful except for everything else out there. Except Qubes OS that allows using original GNU/Linux distributions virtualized with a convenient interface.

I have enjoyed using Qubes in the past, it's definitely a cool feeling having everything controllable via an abstraction that its author probably wasn't designing for. Feels powerful.

But at the end of the day, those VM images, and any snapshots made, are opaque blobs of bits. Whatever shape they're in, you have nowhere to look to determine why they are the way they are--no recipe for recreating that state and sharing it with others (unless you want to share it ALL with others, and then only with others on the same architecture). You've got a lot of control, but only over these chunks of whatever happened to be there at that time.

You're sort of trapped in one dimension. You can use snapshots to move backwards and forwards in time, but if the following paths don't lead to the same system state in some subtle way you're not going to know about the difference:

path one:

> add foo | add bar | remove foo

path two:

> add bar

Re: NixOS and my descent into insanity

#112

Post by nurple »

MuffinFlavored wrote: post #78
whateveracct wrote: post #59

Earlier quoted context omitted.

Ansible does not even begin to accomplish what Nix does.

I’d be curious to learn more if you could share please

The only way ansible could be somewhat like nix is if you reinstalled the same exact version of the target OS each time before you run your playbook. The problem is that ansible, puppet, salt, chef, et al, are simply tools to mutate the giant bag of state that is a Linux OS. Even then getting to the same end state is a suspect proposition unless you're extremely diligent in pinning things like exact package versions and ensure tasks run in the exact same order every time.

While these tools are good at making certain changes, and are even pretty good at detecting and eliding already-done work, they are _not_ idempotent. There are nearly no modules that properly handle unmaking their changes, so once you mutate that bag of state you're left with a state vector that is barely better than completely undefined.

If you're familiar with these tools you have no doubt deployed undo-this-change tasks that you leave in the tasklist until you're fairly confident it's run on every system the do-this-change tasks ran on. Even if a module does attempt to offer an undo-the-state functionality, you can't just remove it, you have to first configure it to run in the "undo" configuration before you remove it.

Re: NixOS and my descent into insanity

#113

Post by pkulak »

jm4 wrote: post #43
jamespwilliams wrote: post #31

Earlier quoted context omitted.

I agree that NixOS (and Nix) is difficult to learn and the documentation is generally poor, which I realise is what you’re getting at in your comment, But I do think we should keep in mind what an incredible project NixOS is. NixOS isn’t just some other Linux distro, repeating pretty much what every distro has done for 40 years. It’s a complete rethink of how a Linux distribution and package manager should work, from…

Oh, I agree. It's why I put up with NixOS. I love what I can accomplish with it. It's a tool for making your own distro. It basically makes the impossible possible. What I'd like to see now is to make the difficult things easy.

The new installer is pretty great. My son’s desktop got hosed recently from ignoring updates and getting too far behind, so I used the visual Nix installer to put a Gnome desktop on there for him. He installs everything from Flathub anyway, so he hasn’t even noticed. Every once in a while I’ll hop on and update it. Silverblue would work about as well, I’d imagine.

Re: NixOS and my descent into insanity

#114

Post by pkulak »

FireInsight wrote: post #25
jm4 wrote: post #13

NixOS is awful except for everything else out there. The learning curve is... steep. The documentation sucks. You have to learn a new OS because a lot of your prior Linux knowledge no longer applies. But, man, it's so slick when you get it working. It's so easy to understand your system and how it's set up. There's no weird stuff changing between updates that you don't know about. You don't have to merge new configur…

I use uBlue https://universal-blue.org/ with a custom image. It's basically Fedora Silverblue & co, except I can declare my default packages and Flatpaks and stuff in a YML file and then just rebase to the custom image that was built. I use Nix home-manager for configuring my shell and GTK, and plan to do as much with it as possible. It's genuinely one of the most stable feeling Linux systems I've run, especially wit…

Once Nix can install without disabling selinix, it could be holy grail territory.

I personally moved from UBlue to NixOS because I was a bit bored of running my whole life in Distrobox, and didn’t like being so dependent on GitHub. NixOS gives me everything I liked from Silverblue with the flexibility of something like Arch. Plus, Home Manager is amazing. The big downside of container-based images is that you can never touch your home directory. Now instead of Silverblue plus Chezmoi plus like 7 Bash scripts and a Distrobox, it’s all just one Nix config.

Re: NixOS and my descent into insanity

#115

Post by MuffinFlavored »

rgoulter wrote: post #108
MuffinFlavored wrote: post #52

Earlier quoted context omitted.

> You have to learn a new OS because a lot of your prior Linux knowledge no longer applies. This is what confused me the most. Nix (CLI tools / language syntax) NixOS (A Linux distro that has CLI tools, but also some CLI tools that are only available on this distro and not others, aka "nix" doesn't really work on Debian) Flakes vs "configuration" I just wanted to like "terraform apply" a system configuration on my De…

> I just wanted to like "terraform apply" a system configuration on my Debian install. I think 'like Terraform, but for the system configuration' is an apt description of NixOS . -- i.e. NixOS is a Linux distribution built around using Nix to generate the system config. The Nix package manager itself happily works on other Linux distributions. (And on macOS). > ... Ansible ... Nix's main focus is on packages. It happ…

> The Nix package manager itself happily works on other Linux distributions. (And on macOS).

But not the "Nix system config manager", which is grouped under the same set of CLI tools, is that right?

> Nix's main focus is on packages.

Packages or system configuration or both?

Re: NixOS and my descent into insanity

#116

Post by fsflover »

__MatrixMan__ wrote: post #111
fsflover wrote: post #64

Earlier quoted context omitted.

> NixOS is awful except for everything else out there. Except Qubes OS that allows using original GNU/Linux distributions virtualized with a convenient interface.

I have enjoyed using Qubes in the past, it's definitely a cool feeling having everything controllable via an abstraction that its author probably wasn't designing for. Feels powerful. But at the end of the day, those VM images, and any snapshots made, are opaque blobs of bits. Whatever shape they're in, you have nowhere to look to determine why they are the way they are--no recipe for recreating that state and sharin…

> no recipe for recreating that state and sharing it with others

Did you consider to use the Salt Stack, which is integrated into Qubes? https://forum.qubes-os.org/t/saltstack-challenges-and-experi...

Re: NixOS and my descent into insanity

#117

Post by __MatrixMan__ »

fsflover wrote: post #116
__MatrixMan__ wrote: post #111

Earlier quoted context omitted.

I have enjoyed using Qubes in the past, it's definitely a cool feeling having everything controllable via an abstraction that its author probably wasn't designing for. Feels powerful. But at the end of the day, those VM images, and any snapshots made, are opaque blobs of bits. Whatever shape they're in, you have nowhere to look to determine why they are the way they are--no recipe for recreating that state and sharin…

> no recipe for recreating that state and sharing it with others Did you consider to use the Salt Stack, which is integrated into Qubes? https://forum.qubes-os.org/t/saltstack-challenges-and-experi...

No, I was using Qubes in 2019 before that integration occurred. That does seem like it would scratch the itch.

Do Qubes users treat Salt Stack formulae as packages these days?

Re: NixOS and my descent into insanity

#118

Post by yencabulator »

yjftsjthsd-h wrote: post #49
unshavedyak wrote: post #44

Earlier quoted context omitted.

I'm currently trying (and failing, lol) to switch to Nickel Nix. Nix OS/Pkgs is just amazing, but i'm near being entirely done with Nix Lang. Lazy + Dynamic is just a recipe for an awful developer experience. As far as i can tell no one (thus far) has been able to explain a reasonable and concrete way to tell what any given variable is within a Nix source file. `nix repl` works decently for some cases, but many not -…

For building packages, don't you kind of need it to be lazy? I don't want to compile and install all of nixpkgs.

When you're programming in any old non-lazy language, your functions don't get automatically called, it's only when you put that call in code that's being executed. If you don't mention a thing in your main, that thing has no reason to get executed.

Nix is lazy because the whole point of the original work was "what if package management, but FP". The resulting /nix/store etc system has very little to do with FP and is, in fact, built by imperative bash scripts.

Re: NixOS and my descent into insanity

#119

Post by fsflover »

__MatrixMan__ wrote: post #117
fsflover wrote: post #116

Earlier quoted context omitted.

> no recipe for recreating that state and sharing it with others Did you consider to use the Salt Stack, which is integrated into Qubes? https://forum.qubes-os.org/t/saltstack-challenges-and-experi...

No, I was using Qubes in 2019 before that integration occurred. That does seem like it would scratch the itch. Do Qubes users treat Salt Stack formulae as packages these days?

Not precisely, but a lot is going on in this direction: https://github.com/QubesOS/qubes-issues/issues/1939.

Re: NixOS and my descent into insanity

#120

Post by rgoulter »

MuffinFlavored wrote: post #115
rgoulter wrote: post #108

Earlier quoted context omitted.

> I just wanted to like "terraform apply" a system configuration on my Debian install. I think 'like Terraform, but for the system configuration' is an apt description of NixOS . -- i.e. NixOS is a Linux distribution built around using Nix to generate the system config. The Nix package manager itself happily works on other Linux distributions. (And on macOS). > ... Ansible ... Nix's main focus is on packages. It happ…

> The Nix package manager itself happily works on other Linux distributions. (And on macOS). But not the "Nix system config manager", which is grouped under the same set of CLI tools, is that right? > Nix's main focus is on packages. Packages or system configuration or both?

> But not the "Nix system config manager", which is grouped under the same set of CLI tools, is that right?

The `nixos-rebuild` command is what you'd use to apply a NixOS configuration (that's NixOS only). (I believe it's possible to run the command to build a configuration on non-NixOS).

Whereas, the other nix CLI programs are mainly `nix-build`, `nix-shell`, etc. which are now grouped under a single `nix` command.

> Packages or system configuration or both?

I'd say packages.

That people like NixOS for its declarative system configuration is incidental.

Nix's key idea is symlinking everything. You put a package in some directory under /nix/store, where the address is computed from that package's inputs. (e.g. what compiler to use, what compiler flags to use).

If you build the same package with different inputs (e.g. different compiler versions), these packages can exist alongside each other in /nix/store. Nix can then build a PATH using whichever package you want to use. It's able to come up with ~/.nix-profile/bin and ~/.nix-profile/include (and share, etc.), symlinking to the stuff in /nix/store.

NixOS essentially 'just' applies that idea, but symlinks stuff under /etc to whatever /nix/store package has the system configuration. (Plus uses systemd services, and a few other things).

e.g. when I `readlink /etc/hosts`, it resolves to `/nix/store/n5ijm9zzkcm7qglsqrfvnixih0q7dskb-host`, or /etc/fstab to /nix/store/xb7jmzd0wy0wy4vihh0q17m81kmqgc7y-etc-fstab.

Post reply on HN