Live data from Hacker News

Why I love NixOS

birkey.co

81–90 of 323 posts

Re: Why I love NixOS

#81
post #62

nix & nixos are by far the worst way to manage system configuration, except for any other way that's been tried. imagine if there was something with declarative system configuration _not_ written in an insane undebuggable recursive nightmare of a language/stdlib? oh well, I'll keep using it, because what other options are there?

guix would like a word

+1, Guix is quite good with some tricks up it's sleeve compared to Nix.

I am not a fan of S-expressions but using scheme is more reasonable than nix+bash to me.

On the negative side, guix can be slow. It is also not a very pragmatic os. NixOS does non-free firmware and drivers without issue. You need to jump through some hoops for this with Guix. This is not an issue if you plan to run guix in a VM though.

Re: Why I love NixOS

#82
post #75

I tried NixOS and failed miserably. I've pointed at to the Fedora Atomic distros, which are also immutable, and apparently incomparably easier to setup. I'm tempted to give it a shot, with the extra bonus that I've never dabbed with a fedora-based distro.

I tried fedora silverblue for a while, but the way it works is that it builds a new root fs image whenever you change the installed packages, this makes system package changes take comparatively long vs a traditional os. They suggest installing most apps via flatpak, which is okay as long as you can deal with flatpak idiosyncrasies. I also tried fedora coreos for a vm + container host, but found the recommended metho…

In all fairness, Nix is similarly slow.

Re: Why I love NixOS

#83

Earlier quoted context omitted.

guix would like a word

I mean it's pretty wild to take s-expressions and not call them extremely terrible to read. The nix language sucks really badly, but I gladly take it over writing S-expressions.

It reads almost the exact same as any functional C-style language. Not to mention that specifically for Guix, you're going to be writing the (name value) form for 99% of it.

Re: Why I love NixOS

#84
post #13

doesn't it use up a lot of disk space compared to other distros because of the way everything is set up?

Yep disk space and learning curve are the two major downsides to Nix. The former has never been a problem for me in practice, just run garbage collection once a month. The latter was a big problem, but is now mitigated for most people by LLMs.

Disk space is not an issue as long as you don't try to install the entirety of Texlive.

Re: Why I love NixOS

#85

The problem I have with nix is that I just don't need another hobby. Keeping everything up to date in an ever changing environment like an os just looks like chore. I install my system and image it every week and keep maybe the initial and a monthly snapshot. Why would nix be better in my case? Maybe I am missing something essential but I also don't bork my system that often tbh.

The configuration system is way more stable than it seems. You write it once and then pretty much never touch it again.

Re: Why I love NixOS

#86
post #4

Although I’ve never committed to using nix system-wide, I do enjoy nix-based using https://devenv.sh/ for the very reasons described in the article. It’s much easier than local containers for development.

Can you help me understand why devenv is needed instead of a shell like this/what is gained? { pkgs }: pkgs.mkShell { nativeBuildInputs = with pkgs; [ # build tools cmake ninja gnumake pkg-config ]; buildInputs = with pkgs; [ # java jdk8 # compilers gcc clang llvmPackages.libcxx # libraries capstone icu openssl_3 libusb1 libftdi zlib # scripting (python3.withPackages (ps: with ps; [ requests pyelftools ])) ]; # capst…

To be honest, I don’t know. I just enjoy the simplicity of devenv. It’s the right amount of user friendly.

Re: Why I love NixOS

#87
post #32

I'd love NixOS more if they had any decent documentation. Everything seems scattered around a dozen forums, a hundred old blog posts, and a thousand issues of "this work on my machine (3 releases ago)".

It doesn't help that there are two NixOS wikis. nixos.wiki and wiki.nixos.org. wiki.nixos.org claims that nixos.wiki is outdated and unofficial. But both appear to receive updates, and which one wins the SEO game is a coinflip whenever i google a nixos question.

nixos.org is the official wiki. It will take time for search ranking to beat the old one.

Re: Why I love NixOS

#88
[From the article "Why I love NixOS"]

> There is also community-maintained support for FreeBSD, though I have not used it personally

I have tried to use the nix package manager on FreeBSD recently. I tried doing some basic things without success. Seems quite broken and unusable, which is a pity because nix on macOS seems decent. FreeBSD is much closer to Linux so there is no technical reason why nix can't be a success on FreeBSD.

nix on FreeBSD just needs more contributors to fix bugs and make popular packages work ! I wonder if it will ever happen. FreeBSD is niche and nix is somewhat niche (still). It's a double niche problem !

Re: Why I love NixOS

#89
post #4

Although I’ve never committed to using nix system-wide, I do enjoy nix-based using https://devenv.sh/ for the very reasons described in the article. It’s much easier than local containers for development.

Can you help me understand why devenv is needed instead of a shell like this/what is gained? { pkgs }: pkgs.mkShell { nativeBuildInputs = with pkgs; [ # build tools cmake ninja gnumake pkg-config ]; buildInputs = with pkgs; [ # java jdk8 # compilers gcc clang llvmPackages.libcxx # libraries capstone icu openssl_3 libusb1 libftdi zlib # scripting (python3.withPackages (ps: with ps; [ requests pyelftools ])) ]; # capst…

devenv also has tasks/services. For example you need to start redis, then your db, then seed it, and only then start the server. All of that could be aliases, yeah, but if you define them as aliases you can have them all up with `devenv up`. It even supports dependencies between tasks ("only run the db after migrations ran")

Re: Why I love NixOS

#90

The problem I have with nix is that I just don't need another hobby. Keeping everything up to date in an ever changing environment like an os just looks like chore. I install my system and image it every week and keep maybe the initial and a monthly snapshot. Why would nix be better in my case? Maybe I am missing something essential but I also don't bork my system that often tbh.

Nix isn't really much of a hobby. It does require some learning because it's different, and front-loading the work to build your config, but after that it's amazingly reliable and easily extendable. You can keep everything up to date with a single command.

The advantages:

- Declarative code describes your system. Maybe your install + imaging flow is good enough, but there are many reasons why it's technically inferior. There's no need for imaging Nix, because it's always reproducible by default. Rollbacks are rebooting to a previous config, not a timestamped blob of snowflake state.

- It replaces whatever tools and glue you have to build your system. You don't need to worry about bootstrapping tools, or config management tools' version compatibility, or bespoke ordering of imperative steps to build the system. All the management tools are built into the system. Everything "just works" automatically.

- If you manage multiple machines the benefits are compounding.

- There are other interesting bits that are covered in the article, that you get for free just due to the nature of nix. It's good for building, and has no friction to experimenting with specific tools or environments, without polluting your system.

It's a commitment to get past the initial learning and config build, but afterwards it significantly lessens the "hobby" aspects of computer management. There are just entire classes of problems that don't exist for Nix. Either your config works, or it doesn't, and the rollback guarantee is explicit and built-in.

Post reply on HN