Live data from Hacker News

NixOS 22.11 “Raccoon”

nixos.org

161–170 of 201 posts

Re: NixOS 22.11 “Raccoon”

#161
post #88

Earlier quoted context omitted.

Nix feels to me like a cool but somewhat hacky v1 of a really great idea. I'm hoping someone creates a much more elegant successor. If Nix is CVS or even Subversion, I'm hoping for Git.

The neat thing about the functional design of Nix is that you don't have to reinvent the wheel: just make better steering. Everything about Nix can be trivially refactored. Every part is neatly isolated from the rest.

> Everything about Nix can be trivially refactored. Every part is neatly isolated from the rest.

Tweaking a few NixOS modules it replacing a package is easy, but neither the Nix codebase nor Nixpkgs is characterized by perfect modularity or uniform layering.

Re: NixOS 22.11 “Raccoon”

#163

How long are we going to sit on our hands and pretend flakes aren't the only way forward? Am I just missing something?

I've not bothered with flakes (yet?); mostly because I don't quite understand/appreciate what they're for/add. They're apparently better than using channels, and env vars like NIX_PATH; but I don't bother with those either. I just use `fetchgit`/`fetchFromGitHub` with specific commit IDs, and that seems mostly reproducible. I've got Nix repos dating back about 8 years, and the only reason some commits can't be reprod…

One thing flakes enable is "easily run some other source".

e.g. to run the latest build of Nix from the GitHub repository NixOS/nix on the master branch, it's:

  nix run github:NixOS/nix/master
Or (say) the Helix editor has a flake.nix; so a similar command would work for that. -- Being able to use nix code without having to fetch the source first is pretty neat.

A less contrived example of where this is useful is with Home Manager. Setting up Home-Manager without flakes requires adding a channel (or requires using a NixOS module, which only works on NixOS). -- Whereas with flakes, you can declare Home Manager as an input, so that applying the Home Manager configuration can be done with less effort.

Flakes are like "nix's nix". With nix, you benefit from putting in effort to declare the inputs of some package, and how its outputs are constructed. With nix flakes, you declare where the Nix code you're using comes from.

Re: NixOS 22.11 “Raccoon”

#164
post #63

Earlier quoted context omitted.

> What are its weaknesses? I think is easier to see this with what is their main strength: A declarative/reproducible OS setup. Is AMAZING for server deployment (like what you put in a docker file but that not mutate after it). But I don't think will be so nice for day to day use. That is where a mutation OS is easier.

The biggest weakness is the built-in expectations it has on how packages install/operate. There are some patterns that will not fit into the box easily (e.g. native-compiled gems/node packages). Also since things are declarative, that means things like e.g. updating bash aliases has additional friction vs the traditional way of editing the file directly.

> updating bash aliases has additional friction vs the traditional way of editing the file directly

Additional friction (not much imo), but you will actually be able to move that bash plugin that does that thing you didn’t even realize were not available in a vanilla shell.

Re: NixOS 22.11 “Raccoon”

#165
post #154

How long are we going to sit on our hands and pretend flakes aren't the only way forward? Am I just missing something?

Well they are - but there are a couple of things blocking it from becoming the default. I think the main thing is this PR: https://github.com/NixOS/nix/pull/6530 - Eelco Dolstra gave a talk on this recently as well if you wanna know more: https://www.youtube.com/watch?v=JE-vLFMTXxM Another thing that comes to mind is the ability to parametrize flakes so that they can be configured from the CLI: https://github.com/Nix…

I check on that lazy trees PR like twice a week, lol. It's my most anticipated Nix PR for some time now. I imagine I'm not the only one!

Re: NixOS 22.11 “Raccoon”

#166
post #28

Earlier quoted context omitted.

I wonder why Nix doesn't give every package a FHS env by default. In 2022 chroot and overlayfs should be available everywhere. Wouldn't that solve a ton of problems?

A FHS adds slight overhead to a package and to launch times. It also shadows part of the file system. For example /lib would probably be different for every other program which would be even more confusing.

Plus nix allows more than possible with FHS alone. What if your package has to use multiple versions of a single dependency? You are back to square one, for no good reason.

Re: NixOS 22.11 “Raccoon”

#167
post #137
post #2

> Graphical installer I've recently installed NixOS on an old Thinkpad I got from work, and I was pleasantly surprised by the graphical installer. Even though NixOS is far from a beginner distro, removing friction in the initial installation process is a good thing.

I was also pleasantly surprised, especially by how easy it was to setup disk encryption. I probably wouldn't have done so otherwise.

I set up LUKS with NixOs like 5 years ago without any prior experience and it was straightforward (just followed the docs). I wish that dealing with nix/nixos was always that easy...

Re: NixOS 22.11 “Raccoon”

#168
post #139

Earlier quoted context omitted.

That's true! Whenever I demo Nix for someone in person, the first trick I do is > Look ma, no /usr/lib and right after that it's a chat about the Nix store, and then a tour of what all those ugly hashes let you achieve. I guess when I wrote that comment I was mostly thinking about what it's like to administer NixOS on a personal system over the moderate term, not the initial shock and wonder of hiking through the glo…

My personal administration involved a lot of digging through installed software's FHS to figure out how things worked. Especially coming up through Slackware. It's probably a learning style thing. Mutable distros you directly edit stuff in /etc, then build your knowledge on top of that foundation. Whatever better practices you end up adopting, you're still ultimately modifying files in /etc (and probably elsewhere).…

Another thing is that the nixos option searcher[1] links to the nix source code that implements the option, so you can go digging through how things work. It's definitely an extra layer of abstraction vs editing /etc/foorc but I have copied what those things do into my configuration.nix and made changes to poke at stuff.

1: https://search.nixos.org/options

Re: NixOS 22.11 “Raccoon”

#169

I might want to try some new Linux distribution so I wonder: what doesn't work in nix? What are its weaknesses? What about devices with non-free firmware?

you can't run binaries built for other distributions, without patching them

Haha, sometimes it goes the other way round.

The vpn client at work wasn't available for the latest ubuntu and the old version did not work due to changes in some libs. Wrapping it with nix providing the right libs was way easier and much more replicable than manually building the required stuff. Did in on my machine and than 3 mins to do the same for a colleague.

Re: NixOS 22.11 “Raccoon”

#170

Earlier quoted context omitted.

Yeah I used to use pfSense but hated having a load of config and firewall rules created manually, it all felt quite brittle. Moved to NixOS almost 5 years ago now and haven’t looked back, my router config is in Git and I’m able to make changes with confidence. Best part is making a change/installing an update and being able to rollback if I mess something up. I also use Nixus to push new configs which has a nifty fea…

How are you managing the VM’s on NixOS? A couple years ago I was searching for a good way to declaratively manage them, and the best I came up with was libvirt + terraform + nixos-generators for images. It feels like you should just be able to set them up as systemd units, but I couldn’t figure it out. microvm has caught my eye recently but I haven’t played with it yet: https://github.com/astro/microvm.nix

The VMs themselves are a mix of some manually created ones (the VM configs are still NixOS though), and some IaC VMs which I just use Terraform and the libvirt provider. It's a bit clunky but I wouldn't want to embed the VM config in the hypervisor configuration as the VMs can be live migrated to other hypervisors.

MicroVM looks awesome though, thanks for the pointer!

Post reply on HN