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

NixOS 22.11 “Raccoon”

nixos.org

Post reply on HN
Print view View original

191–200 of 201 posts

Re: NixOS 22.11 “Raccoon”

#191

Post by ttarr »

nh2 wrote: post #144

Something that isn't stated in this thread yet is how easy NixOS makes version upgrades. I maintain multiple pet servers. When I used Ubuntu, doing release upgrades cost me ~6 hours per server per upgrade every 2 years. Most of that time went into merging updated upstream configuration files with my changed configuration files, often for silly stuff like upstream changing tabs to spaces in the config file syntax. Wit…

How about isolation, how do you manage that? Are services ran under different containers, VMs or namespaces?

Re: NixOS 22.11 “Raccoon”

#192

Post by chriswarbo »

rgoulter wrote: post #163
chriswarbo wrote: post #150

Earlier quoted context omitted.

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…

> Setting up Home-Manager without flakes requires adding a channel (or requires using a NixOS module, which only works on NixOS).

From the home manager documentation ( https://nix-community.github.io/home-manager/index.html#sec-... ):

> If instead of using channels you want to run Home Manager from a Git checkout of the repository then you can use the programs.home-manager.path option to specify the absolute path to the repository.

Re: NixOS 22.11 “Raccoon”

#193

Post by lvncelot »

smoldesu wrote: post #59
lvncelot wrote: 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.

It's very new. Just a year ago you still had to partition/install everything by hand, which was a pain but still worth doing.

Yeah, that was what I remembered, hence the surprise. It wasn't too bad, coming from arch, but creature comforts are welcome nonetheless.

Re: NixOS 22.11 “Raccoon”

#194

Post by rgoulter »

chriswarbo wrote: post #192
rgoulter wrote: post #163

Earlier quoted context omitted.

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…

> Setting up Home-Manager without flakes requires adding a channel (or requires using a NixOS module, which only works on NixOS). From the home manager documentation ( https://nix-community.github.io/home-manager/index.html#sec-... ): > If instead of using channels you want to run Home Manager from a Git checkout of the repository then you can use the programs.home-manager.path option to specify the absolute path to…

Neat, though I hope I helped your curiosity regarding why people find flakes useful.

With home-manager, you can declare a flake configuration where home-manager is an input; and then applying the configuration is pretty hands-off since Nix will fetch the appropriate revisions of the inputs.

I think that using flakes is more convenient than the alternatives. (Having to add a channel; or, as you point out, cloning the repository in a consistent path on each system you use & then running that).

Re: NixOS 22.11 “Raccoon”

#195

Post by pxc »

rgoulter wrote: post #194
chriswarbo wrote: post #192

Earlier quoted context omitted.

> Setting up Home-Manager without flakes requires adding a channel (or requires using a NixOS module, which only works on NixOS). From the home manager documentation ( https://nix-community.github.io/home-manager/index.html#sec-... ): > If instead of using channels you want to run Home Manager from a Git checkout of the repository then you can use the programs.home-manager.path option to specify the absolute path to…

Neat, though I hope I helped your curiosity regarding why people find flakes useful. With home-manager, you can declare a flake configuration where home-manager is an input; and then applying the configuration is pretty hands-off since Nix will fetch the appropriate revisions of the inputs. I think that using flakes is more convenient than the alternatives. (Having to add a channel; or, as you point out, cloning the…

I'd say the real alternatives are probably the json-based, pre-flakes pinning tools like Niv, nix-wrangle, and nix-thunk.

They're still less convenient for me than flakes because they don't have great integration with Nix's profile managers (nix-env, nixos-rebuild, home-manager). But they do have fewer quirks in some ways, since they don't try to enforce pure evaluation like the flakes implementation does. They don't worry about whether the pinning happens inside a git repo or whatever.

(I think some orgs that use Nix in production are still using Niv, and haven't touched flakes. Niv is certainly still maintained.)

Re: NixOS 22.11 “Raccoon”

#196

Post by astro1 »

colordrops wrote: post #74
madjam002 wrote: post #54

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…

Can you share your router configs? I'd love to have a NixOS based router.

https://gitea.c3d2.de/zentralwerk/network

Re: NixOS 22.11 “Raccoon”

#197

Post by chriswarbo »

pxc wrote: post #195
rgoulter wrote: post #194

Earlier quoted context omitted.

Neat, though I hope I helped your curiosity regarding why people find flakes useful. With home-manager, you can declare a flake configuration where home-manager is an input; and then applying the configuration is pretty hands-off since Nix will fetch the appropriate revisions of the inputs. I think that using flakes is more convenient than the alternatives. (Having to add a channel; or, as you point out, cloning the…

I'd say the real alternatives are probably the json-based, pre-flakes pinning tools like Niv, nix-wrangle, and nix-thunk. They're still less convenient for me than flakes because they don't have great integration with Nix's profile managers (nix-env, nixos-rebuild, home-manager). But they do have fewer quirks in some ways, since they don't try to enforce pure evaluation like the flakes implementation does. They don't…

I used to use Niv, but these days I find it more convenient to just call `builtins.fetchGit` where it's needed, rather than faffing with external files/tools (although https://hackage.haskell.org/package/update-nix-fetchgit can be useful). It's certainly much nicer than the "olden days" of `nixpkgs.fetchgit`, which required an "impure" copy of Nixpkgs (like ) in order to fetch a pinned copy!

I tend to have a single git repo with my system config, which uses import-from-derivation to grab a bunch of other stuff; and defines a single "package" that's a big `buildEnv` of all the programs I want. That seems to work fine across NixOS (on an old i686 Thinkpad), an old Ubuntu desktop, macOS (a couple of work laptops; old one used nix-darwin, new one just uses nix-env), and I'm currently trying it on nixos-mobile (on my Pinephone).

Re: NixOS 22.11 “Raccoon”

#198

Post by nh2 »

ttarr wrote: post #191
nh2 wrote: post #144

Something that isn't stated in this thread yet is how easy NixOS makes version upgrades. I maintain multiple pet servers. When I used Ubuntu, doing release upgrades cost me ~6 hours per server per upgrade every 2 years. Most of that time went into merging updated upstream configuration files with my changed configuration files, often for silly stuff like upstream changing tabs to spaces in the config file syntax. Wit…

How about isolation, how do you manage that? Are services ran under different containers, VMs or namespaces?

No.

A main reason people use containerisation is to work around the problem that different versions of libraries and binaries cannot coexist in classical Linux distributions. This problem does not exist in NixOS.

The services are declared as NixOS modules, which manifest as plain systemd services on the server.

Systemd has its own set of options for resource/security isolation, and some NixOS modules use them where possible, for example: https://github.com/NixOS/nixpkgs/blob/8d559672bedd54034b711d...

Re: NixOS 22.11 “Raccoon”

#199

Post by Cloudef »

mattarm wrote: post #130
codedokode wrote: post #73

Earlier quoted context omitted.

I remember reading that nix unlike all other distros can install multiple version of the same package and I want this feature, but I guess programming a package config might be too much for me. Maybe I'll try nix package manager then.

> nix unlike all other distros can install multiple version of the same package The above is sometimes true and sometimes not. For the most part, Nix can install multiple versions of a program but only one can be in use at any given time. Nix is for the most part shell based workflow (as in bash, zsh, etc.). The `nix-shell` command lets you switch out the packages (and versions of packages) that are used in any given…

This is only true if you want multiple versions in the same global environment. If you really want them in global environment, you can create meta package that aliases with symlinks. Otherwise you can use nix-shell to get any environment you want.

Re: NixOS 22.11 “Raccoon”

#200

Post by pmarreck »

SuperSandro2000 wrote: post #128
pca006132 wrote: post #113

Earlier quoted context omitted.

I think there are a few problems here: 1. Packaging requires knowing more than just the language, you should also know how files are being linked, what to look for when you got an error. If you only know haskell, you may not know this. 2. If you wrote the correct script, it just works. But if you wrote something wrong but syntactically correct, finding the issue may not be that trivial, in my experience the trace is…

1. Yes, you need to know some more things but in particular not linking. I have no idea about linking or what to do when it fails with weird symbol errors. If you have a standard autotools, cmake or meson setup it might be as easy as just adding the packages to nativeBuildInputs and it works. The more custom stuff the project does the more you need to hold it hands. 3. For example here https://nixos.org/manual/nixpkg…

FYI this comment ended up making something work that I couldn't get working (as a side project) for at least 2 months; I did not realize that providing certain things as nativeBuildInputs might make package sub-dependencies build correctly (so for example, I have an Elixir project which depends on a NIF which is a compiled C++ or Rust project which is automatically built when I build the main Elixir project). Moving those to that suddenly made it work!

So thank you for that! There's not a lot of docs I found out there (yet?) about getting sub- or sub-sub-dependencies to build correctly in multi-layered projects that depend on different language technologies and build toolchains (where a traditional linux distro makes A LOT of assumptions that "just so happen" to work!), but at least now that I got this working, I can lock it down with a flake and in theory be good to go for a while! (or at least have a rollback strategy if something borks!)

Post reply on HN