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

121–130 of 201 posts

Re: NixOS 22.11 “Raccoon”

#121

Post by lijogdfljk »

pmarreck wrote: post #115
melvyn2 wrote: post #108

Earlier quoted context omitted.

I have not used flakes at all for my NixOS server. To put it one way, why should I care?

(speaking as someone who hasn't actually fully converted over to flakes yet) Because it actually fulfills the original promise of Nix : Forever-reproducible builds. Anyone who's ever dealt with a lockfile across any stack that supports that idea in dependency definition, knows how this works and what it's good for.

Couldn't agree more. I love Nix (well, i have nits with the lang/UX), but Flakes is essential imo.

Using Nix without Flakes is going through 99% of the trouble for concrete, reproducible builds but then dropping the last 1%.

I had my non-Flake builds break like it was a mutable operating system. I just don't get why Flakes aren't the standard.

Re: NixOS 22.11 “Raccoon”

#122

Post by pxc »

aliqot wrote: post #23
codedokode wrote: post #5

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?

If you just want someone to shoot you straight: Documentation and naming conventions for Nix are absolute shit across the board. This will get downvotes, and people will say I'm wrong, but I'm 100% right. Go see yourself, it's bad. Language is called Nix, OS is actually called Nix, package manager is called Nix, just the whole thing seems like it was written in 1 week by a squirrel with 12 hands and a sack of ritalin…

This is mean, but it's not so blatantly false that it's worthy of downvoting.

Nix and Nixpkgs are messy, evolved things with a lot of history and quirks. They're also very powerful tools that can change the way you even approach computers. If you stick with them long enough, they may inspire you to extend and leverage them in creative ways... continuing the process of messy evolution. :)

Re: NixOS 22.11 “Raccoon”

#123

Post by pxc »

SuperSandro2000 wrote: post #57
tomrod wrote: post #39

Earlier quoted context omitted.

Completely repeatable setup. Like Docker, but works.

Docker is not repeatable. If I try to build the same Dockerfile in 12 months then I likely do not get the same output and it wouldn't be surprising if it does not build at all.

This fits with the usual definition of repeatable. Repeatable means that you can run the same steps, but if the steps are non-deterministic, repeating them doesn't guarantee the same result.

> it wouldn't be surprising if it does not build at all.

This part is a stronger point, and it's true. When you repeat something and what you get is not just a different version or variation but something with totally different or broken behavior, that seems bigger than an ordinary failure of reproducibility.

Re: NixOS 22.11 “Raccoon”

#124

Post by SuperSandro2000 »

hamandcheese wrote: post #118
1MachineElf wrote: post #101

Earlier quoted context omitted.

I appreciate your comment here, and the parent comment. I've been using OPNSense[0] as my router for the past several months. So far, I am quite happy with it, but I've also thought that NixOS would be the next step. My OPNSense router has 30+ VLANs and many layered firewall rules (my take on "zEr0 tRuSt") and so the task of converting it all to NixOS seems a little daunting. I appreciate the utility of OPNSense's we…

NixOS is great for a basic home router (I use it for my home router) but it’s networking config is still pretty rudimentary, and some things I would expect to work just don’t - i.e. port forwarding only works from outside your network, not inside. I haven’t done much with vlans yet so I can’t comment on that.

I would highly recommend to use systemd-networkd based networking which should be able to do almost everything if configured correct.

Re: NixOS 22.11 “Raccoon”

#125

Post by rgoulter »

melvyn2 wrote: post #108
thomastjeffery wrote: post #100

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 have not used flakes at all for my NixOS server. To put it one way, why should I care?

The UX is much nicer with flakes.

Flakes provide a consistent entry-point to a set of Nix files (rather than just a hoping that Nix files conform to some convention).

Nix flakes also let you get by with even less worry about the system state: e.g. you don't need to add channels or put your code in your user's overlays directory. You can just use the path/URI to a flake, and nix will take care of downloading all the inputs appropriately.

Re: NixOS 22.11 “Raccoon”

#126

Post by rgrmrts »

kvandy wrote: post #6

Seems like a good time to flatten my Dell windows 11 laptop and install Nix on it. I've really loved using NixOS in various VMs but the experience is so good I want to use it full time. Any recommendations on how to best set up pre boot encryption and opt in state these days?

I'm running NixOS on a Dell Precision laptop. I'm really happy with it!

Like the other reply suggests, I'm using ZFS and it's built-in encryption.

Re: NixOS 22.11 “Raccoon”

#127

Post by ochoseis »

notemaker wrote: post #83
colordrops wrote: post #77

Earlier quoted context omitted.

I wouldn't call them major problems. There are workarounds for running things without much effort if you want, e.g. FHS or steam run or distro box. For Python, you can create a virtual env and use it like any other machine. And if you do put in the effort to make a package, you'll never have problems figuring out how to install it in the future, and can share that gain with others. Making packages for nix is way easi…

Some packages won't work when installed via pip though, psycopg2 for instance.

Occasionally you can get packages with native dependencies to work by creating a nix shell that includes the dependent libraries. Sometimes that can mean using an FHS shell, which is indeed annoying.

It’s not elegant, but you can also usually find popular Python libraries in nixpkgs so they’re available in your shell’s “global” Python environment.

Re: NixOS 22.11 “Raccoon”

#128

Post by SuperSandro2000 »

pca006132 wrote: post #113
SuperSandro2000 wrote: post #46

Earlier quoted context omitted.

nixpkgs is already one of the largest package collections. There is a good chance your software is already included. The nix language itself is pretty straightforward and if you know haskell your should feel straight at home. You shouldn't use nixpkgs python packages as a replacement for your python development. That would also not work that great on other distros.

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/nixpkgs/unstable/#chap-hooks

5. It is quite the opposite. If the typical build instructions are ./configure; make; make install then you might only need to specify the install directory to $out and you are done. Looking at ldd is also not usually required when compiling from source.

Re: NixOS 22.11 “Raccoon”

#129

Post by SuperSandro2000 »

seqizz wrote: post #119
SuperSandro2000 wrote: post #46

Earlier quoted context omitted.

nixpkgs is already one of the largest package collections. There is a good chance your software is already included. The nix language itself is pretty straightforward and if you know haskell your should feel straight at home. You shouldn't use nixpkgs python packages as a replacement for your python development. That would also not work that great on other distros.

> .. if you know haskell .. And if you don't have any FP background you're just.. out of luck. /s

I must admit I got a long way with contributing without knowing much about functional programming. Most things done in mkDerivation especially the basic ones almost abstract the functional and lazy part away.

Re: NixOS 22.11 “Raccoon”

#130

Post by mattarm »

codedokode wrote: post #73
jauco wrote: post #35

Earlier quoted context omitted.

If you want to run nixos (i.e. the linux distro) then the configuration file is written in the nix language. Given that you’ll have to configure your installation, you’ll have to learn the nix language If you just want to use nix for packages, you can run any distro and install nix the package manager into it. This is a good way to dip your toes in the water. And in that case you can just use the cli commands for ins…

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 shell, but it works off of a configuration file written in the Nix language that you write. The programs that are available are controlled by environment variables such as PATH and MANPATH.

Nix is a big shift from the usual way of dealing with packages, programs, etc. It isn't really useful until you really make the effort to understand what is going on, learn the Nix language, etc. If you are not interested in "programming" your system, then it probably isn't for you.

Post reply on HN