Live data from Hacker News

My experience with NixOS

blog.patchgirl.io

41–50 of 95 posts

Re: My experience with NixOS

#41

I recently switched to NixOS and have essentially configured my OS from scratch in less than a week and now use it as my main system. The thing to remember about NixOS is it’s not a distribution of KDE or Gnome or manager of anything, it’s a declarative way of configuring those things and allows you to easily roll back changes to entire OS. It’s a little bit of investment to get started but one you get rolling it’s s…

> manipulate your whole OS in the similar pragmatic way to you iterate code in a git repo

I've been trying to do this for ages with a dotfiles repo and some git aliasing. I really want to try it out, though. Any gotchas or hidden pitfalls I should look out for?

Re: My experience with NixOS

#42

I recently switched to NixOS and have essentially configured my OS from scratch in less than a week and now use it as my main system. The thing to remember about NixOS is it’s not a distribution of KDE or Gnome or manager of anything, it’s a declarative way of configuring those things and allows you to easily roll back changes to entire OS. It’s a little bit of investment to get started but one you get rolling it’s s…

[deleted]

Re: My experience with NixOS

#43
post #41

I recently switched to NixOS and have essentially configured my OS from scratch in less than a week and now use it as my main system. The thing to remember about NixOS is it’s not a distribution of KDE or Gnome or manager of anything, it’s a declarative way of configuring those things and allows you to easily roll back changes to entire OS. It’s a little bit of investment to get started but one you get rolling it’s s…

> manipulate your whole OS in the similar pragmatic way to you iterate code in a git repo I've been trying to do this for ages with a dotfiles repo and some git aliasing. I really want to try it out, though. Any gotchas or hidden pitfalls I should look out for?

One common beginner mistake is attempting to modify files in the immutable store directly. Don't do that. The system is read only for a reason.

Also make sure you allocate enough space on your root partition so you don't have to run garbage collection all the time.

Re: My experience with NixOS

#44
post #3

Forgive me for using buzzwords, but what's the "cloud native" story on NixOS? Can I easily create containers and update my orchestrator's deployment? Can I abstract things like AWS Lambdas into this immutable build structure?

https://grahamc.com/blog/nix-and-layered-docker-images

Re: My experience with NixOS

#45
post #41

I recently switched to NixOS and have essentially configured my OS from scratch in less than a week and now use it as my main system. The thing to remember about NixOS is it’s not a distribution of KDE or Gnome or manager of anything, it’s a declarative way of configuring those things and allows you to easily roll back changes to entire OS. It’s a little bit of investment to get started but one you get rolling it’s s…

> manipulate your whole OS in the similar pragmatic way to you iterate code in a git repo I've been trying to do this for ages with a dotfiles repo and some git aliasing. I really want to try it out, though. Any gotchas or hidden pitfalls I should look out for?

My tip: don't use nix-env to install packages like it's Aptitude or Pacman, use `nix run` if you need a package temporarily, home-manager if you need a user-level package permanently, or just straight up change the configuration.nix to include the package as a system-wide one.

If you use nix-env you're just polluting your environment in an imperative way and that is pretty much going against Nix' declarative nature.

Re: My experience with NixOS

#46
post #43
post #41

Earlier quoted context omitted.

> manipulate your whole OS in the similar pragmatic way to you iterate code in a git repo I've been trying to do this for ages with a dotfiles repo and some git aliasing. I really want to try it out, though. Any gotchas or hidden pitfalls I should look out for?

One common beginner mistake is attempting to modify files in the immutable store directly. Don't do that. The system is read only for a reason. Also make sure you allocate enough space on your root partition so you don't have to run garbage collection all the time.

You might want to enable automatic gc either way just so it's cleared out every now and then.

https://nixos.org/nixos/options.html#nix.gc

Re: My experience with NixOS

#47
post #43
post #41

Earlier quoted context omitted.

> manipulate your whole OS in the similar pragmatic way to you iterate code in a git repo I've been trying to do this for ages with a dotfiles repo and some git aliasing. I really want to try it out, though. Any gotchas or hidden pitfalls I should look out for?

One common beginner mistake is attempting to modify files in the immutable store directly. Don't do that. The system is read only for a reason. Also make sure you allocate enough space on your root partition so you don't have to run garbage collection all the time.

I made the switch from Arch about a week ago. So far, great experience. I love the fact that my system state is reproducible and if I use version control on my dotfiles, I basically have a full backup of the look and feel of my workstation. VFIO with GPU passthrough works flawlessly. Setting up FDE with LUKS during and after the install was a breeze as well. Really enjoyed the whole experience.

Being able to switch between wildly different possible system configurations like xorg+i3 and wayland+sway by executing a few commands and having version control while doing so is incredible.

However one thing I'm struggling with now is "overlays". Simply trying to get "electrum" to install but nixpkgs has 3.3.8, I am looking to build 4.0.0a from HEAD of master. This should be simple to do with something like overlaying this portion from file electrum/default.nix [0]

  src = fetchurl {
    url = "https://download.electrum.org/${version}/Electrum-${version}.tar.gz";
    sha256 = "1g00cj1pmckd4xis8r032wmraiv3vd3zc803hnyxa2bnhj8z3bg2";
  };
with something like:

  fetchFromGitHub {
    owner = "spesmilo";
    repo = "electrum";
    sha256 = "LATESTHASH";
  };
But for the life of me, I can't figure out how to do this overlay stuff. ( In fact I'd appreciate any help on this otherwise at this point I'm even jokingly considering an Arch container :) )

Python, NodeJS and Ruby development might also be slightly frustrating if you are used to installing things globally.

[0] https://github.com/NixOS/nixpkgs/blob/master/pkgs/applicatio...

Re: My experience with NixOS

#48
post #29

Earlier quoted context omitted.

GNU Guix 1.1.0 was released just hours ago, so now is a good time to try it: https://news.ycombinator.com/item?id=22877788 :-) Rumor has it that Guix will be included in a future Debian release too. It is already available in Arch, Gentoo, and OpenSUSE.

It’s really great that functional package managers are getting all this attention! Nix package manager can run on Arch and Gentoo and OpenSUSE also.

nix doesn't have a package on OpenSUSE so you need to manually instlal, guix does have one though

Re: My experience with NixOS

#49
There's a good write up of how Cardano, the blockchain project, uses Nix.

Not surprising, given that Nix was a academic research project, and Cardano has a good network of academic researchers working to solve hard blockchain problems.

https://iohk.io/en/blog/posts/2019/02/06/how-we-use-nix-at-i...

Re: My experience with NixOS

#50

Earlier quoted context omitted.

Sure. Given code which works for a lot of people, versus some organization composed of people, the fault is probably with people and not with code. This follows from the formal properties of code as mathematical objects, plus the property of probabilistically-checked proofs: If code works for a lot of people, then the code is expected to work generally with high probability. Moreover, there are lots of folks having p…

I don't think Nix works for a lot of organizations as a package manager. It works for a lot of individuals for a different use case (NixOS). If you're mostly installing existing packages from nixpkgs onto a NixOS box, that probably works very well--users don't need to know much about the expression language or the nature of their dependency tree. If you're using it as a development tool, users are going to need to in…

Nix has a way of exposing complex and low-quality build systems. Many pieces of the Python ecosystem fall into this category. For example, it wasn't Nix's fault that psycopg2 had a dependency on postgresql C header files, nor was it Nix's fault that the postgresql headers had to be rearranged for psycopg2's build to work. Nix basically reveals the full complexity of the package's actual build environment, and for some packages the work required to make a reliable build is overwhelming. Some easier to use systems have people doing this work for you, like the Debian project. Others rely on luck to supply dependencies. The thousands of Dockerfiles that run "apt-get update" are a great example of this.

After using Nix for a while you start to reflexively shy away from software with low-quality build systems. Nix is not easy to use, but it's best of breed in terms of software supply chain auditability and malleability (anything in the system can be trivially modified or patched). If you can move to an "easy" system, that may be the appropriate trade-off for you, but it means you may be in a domain where these properties are unimportant.

Post reply on HN