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

My experience with NixOS

blog.patchgirl.io

Post reply on HN
Print view View original

61–70 of 95 posts

Re: My experience with NixOS

#61

Post by bamboozled »

downerending wrote: post #59
rudolph9 wrote: post #32

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…

> I recently switched to NixOS and have essentially configured my OS from scratch in less than a week That doesn't exactly scream ease of use .

You can get up and running in probably a day (you need to learn a few things), I'm guessing what they mean is, configured exactly how they want.

I had a similar experience with NixOS and I love it.

Re: My experience with NixOS

#62

Post by chongli »

downerending wrote: post #59
rudolph9 wrote: post #32

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…

> I recently switched to NixOS and have essentially configured my OS from scratch in less than a week That doesn't exactly scream ease of use .

NixOS isn’t easy to use. It’s very powerful though. It gives you the ability to configure your whole OS, including all of your packages and configurations, in one declarative file. It reproduces the entire installation from this file in a way that’s fully immutable and hash-perfect (with minimal building from source). Very cool.

Re: My experience with NixOS

#63

Post by downerending »

chongli wrote: post #62
downerending wrote: post #59

Earlier quoted context omitted.

> I recently switched to NixOS and have essentially configured my OS from scratch in less than a week That doesn't exactly scream ease of use .

NixOS isn’t easy to use. It’s very powerful though. It gives you the ability to configure your whole OS, including all of your packages and configurations, in one declarative file. It reproduces the entire installation from this file in a way that’s fully immutable and hash-perfect (with minimal building from source). Very cool.

It does sound pretty awesome. Maybe I'll try a hit with VirtualBox.

Re: My experience with NixOS

#64

Post by takeda »

lidHanteyk wrote: post #10
throwaway894345 wrote: post #6

Earlier quoted context omitted.

Our organization tried Nix for many years. Most of our problems were around usability, lack of documentation (including zero docstrings or type annotations in nixpkgs), and the overt unfamiliarity of the Nix expression language (asking a whole organization to learn something that seems deliberately cryptic isn't a recipe for success), and a long tail of other things. Still, at its core Nix for package management seem…

To me, this is a success story; your organization wasn't sufficiently flexible to adopt new technologies which require rethinking the fundamentals of package management. Take this as a warning sign and re-orient your organization. I do wonder about the "deliberately cryptic" nature of Nix's expression language. It is, in fact, deliberately designed for simplicity, to be a basic syntax for a language that is purely fu…

Agree, nix itself is actually fairly simple. What it is hard though is functional programming, an that's the biggest road block for developers that are used to imperative programming.

Places that use functional language for their code base don't have problems picking it up. It is especially big in Haskell community, because Haskell is also lazily evaluated.

People might wonder why not use language that more people are familiar? The reason for it is that purely functional and lazily evaluated language is basically behind Nix's biggest strengths. Purely functional means for the same inputs(architecture + source code + dependencies + configuration options + etc) you should get the same output, there's no mutable state the languages always starts the evaluations from a known state.

Why lazily evaluated? That makes the Nix only evaluate things that are necessary to obtain given derivation.

I think when people talk about Nix being confusing they really mean NixPkgs. Which is like a stdlib of Nix. The thing is that Nixpkgs in a constant flux people who work on it work on different components somewhat independently. Also often they realize better ways of doing things, and often the documentation doesn't keep with it. I think that Nix needs some kind of mechanism for literate programming where documentation would live together with the code and would be updated at the same time. There are some effort for example like the NixOS options page is generated from the source, but that's just just small part of Nix and only applies to NixOS.

I also would love if nix would standardize on how to pin nixpkgs. I recently discovered Niv[1] and it makes reproducible builds so much easier. I think Nix also needs some opinionated tooling to create dev environment for each supported languages, currently people need to do it themselves, and it takes a lot of research.

I think Niv + lorri + direnv make dev experience extremely enjoyable. For example a python project set up that way. Once you enter the directory, you have the exact version of Python installed that has all the dependencies (of course with locked versions) and all extra development tooling that developers need with exact same versions. All you need is just run the application and it just works every time. If somebody broke something you can easily use git bisect to find when and why it broke.

Nix fails to document though how a new user get to that point, and desperately needs help there.

[1] https://github.com/nmattia/niv

Re: My experience with NixOS

#65

Post by brotherjerky »

therein wrote: post #47
mbakke wrote: post #43

Earlier quoted context omitted.

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 b…

Can you share the passthrough setup?

Re: My experience with NixOS

#66

Post by throwaway894345 »

beefee wrote: post #50
throwaway894345 wrote: post #28

Earlier quoted context omitted.

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 som…

It's not Nix's fault, but that doesn't make it cheaper to deal with. Whatever you want to say, `pip install psycopg2` just works because someone else already dealt with the packaging problem.

Re: My experience with NixOS

#67

Post by berti »

beefee wrote: post #50
throwaway894345 wrote: post #28

Earlier quoted context omitted.

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 som…

Read your way down this thread and note that every defence of Nix is merely shifting the blame in it's entirety to some other part of the ecosystem. Rightly or wrongly that's a big problem for Nix if it intends to gain widespread acceptance.

Re: My experience with NixOS

#68

Post by takeda »

throwaway894345 wrote: post #28
lidHanteyk wrote: post #25

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…

You're right about Python, is harder than it needs to be, it took me a while before I understood how it could be seamlessly integrated with it.

If it helps anyone, here's example where I put my Nix understanding to make it seamlessly usable: https://github.com/takeda/example_python_project

If you use direnv + lorri you just need to enter directory (if not just type nix-shell) and suddenly you have everything you need and the application is installed (try executing "hello" which will execute the python code, if you modify hello.py it immediately takes effect as if you were using "pip -e")

If you call "nix build" you'll get a result directory with "result/bin/hello" that just works as if it was a binary program (don't need to worry about dependencies)

I think nix needs a tooling that does all of the ground work of setting up dev environment for the most popular languages, because it gets really confusing.

Re: My experience with NixOS

#69

Post by Ericson2314 »

Shoue wrote: post #45
darau1 wrote: 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?

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.

To distill that to one sentence, home-manage is NixOS for dotfiles and you can use it on Non-NixOS Linux, I believe, too.

Re: My experience with NixOS

#70

Post by takeda »

berti wrote: post #67
beefee wrote: post #50

Earlier quoted context omitted.

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 som…

Read your way down this thread and note that every defence of Nix is merely shifting the blame in it's entirety to some other part of the ecosystem. Rightly or wrongly that's a big problem for Nix if it intends to gain widespread acceptance.

It's true somewhat though, but it's a problem is not easy to solve for Python.

The problem is that Python supports C extensions, and for example the psycopg2 package has an extra dependency on a libpq which it expects to have installed on the system i.e. if you were using a docker you would do something like yum install postgresql-devel otherwise it will fail. Python won't install it for you and it doesn't even have a way to relay (except for error message) that such package is needed.

Many people actually get stuck with this and won't know what to do, but quick google show that package is needed they install and everything works. Nix is functional and doesn't have state so you can't just invoke nix-env -i postgresql and now everything will start to work, that behavior would actually ruin reproducibility. Nix instead expects that the C dependency is also provided otherwise it will refuse the build.

That's what OP meant where he said Nix exposes weak build systems.

Anyway, there was significant progress in making things better in python, it is still not awesome, but it is very close. Actually the biggest pain point right now is to setup a build environment that's convenient to use.

I recently created a template that shows how to do it: https://github.com/takeda/example_python_project

It uses pip2nix and it can automatically figure out all python dependencies, the packages like psycopg2 need an additional entry like this: https://github.com/takeda/example_python_project/blob/master... because PyPI packages don't specify any system dependencies.

Post reply on HN