For the most part I do “creative coding”, e.g. artworks and installations for museums, galleries, live performance, etc. I also do a lot of sound design and music production.
I use NixOS for its up-to-date-ness, easy rollbacks, reproducibility, flexibility and declarative nature (no “steps” to remember other than nixos-rebuild switch). It makes setting up machines for installations, sharing configuration and remote deployment/management so easy without needing layers of indirection like VMs or containers. It also means that once my pro-audio environment is working nicely (a miracle on Linux), it just continues to work even when moving to different machines because everything about my setup is declared in the configuration files.
Haskell programmers, mostly?
Nay, but Rust programmer yes.
I do agree that it’s seemingly complex at first - I think I’d attribute this to two things:
unfamiliarity: I think it’s necessarily different to what we’re used to make great leaps in progress. The design rethinks so much about what it means to be a distro or package manager and avoids so many common problems as a result.
I think Nix is still finding its feet, e.g. nix-env still being recommended in the docs (if it were up to me I think I’d remove the command altogether), flakes still in the works, nothing along the lines of home-manager being “blessed” yet, etc.
Still, these seem like solvable issues, and I’m yet to come across a distro as promising as NixOS. I’m curious about Guix, but mostly because in my mind it looks like NixOS with a lisp and I’ve been curious about learning lisp.
This isn’t completely true. Haskell developers are highly overrepresented in this demographic.
There are several reasons for this, but Nix itself is inspired by Haskell. In addition, the Cardano ecosystem exclusively makes use of Nix, which necessitates that many Haskell engineers use it.
The company that mostly funds Nix development (Tweag) is also a Haskell consultancy. You’ll notice many Haskell-isms in the language, such as builtins.foldl'. The reason for the ' is because the Haskell foldl is lazy, while foldl' is strict in its accumulator. The concept of “thunks” also largely comes from Haskell.
This is your last chance. After this, there is no turning back.
You take the blue pill - the story ends, you wake up at your shell and believe whatever you want to believe. Continuing to run installers mutating your system in blissful ignorance. Not questioning whether - perhaps - your package dependencies are incomplete. Accepting that one version is more than any person ever needs. Never worrying how to get here all over again.
You take the Nix pill - you stay in wonderland and I show you how deep the rabbit hole of reproducibility goes.
if you liked the premise of nix/nixos, you should check on the state of the ecosystem in some months/years when flakes will be the norm, documentation integrated into the codebase and community grows into the size of the project(right now it’s clear that nixpkgs is too large for current size of the community, which is why it’s not always a smooth ride, but it will only get better, as long as the community grows, which it does)
I started using Nix in order to install things in a computer lab that the sysadmins wouldn’t install for me. I didn’t really care about the Nix design at that time except that it worked and that (with a pivot root environment) I could use its binary caching.
I later tried NixOS because I liked the idea of defining my whole environment in a single file. This forced me to package some things I wanted to use on NixOS, and while complex packages could be kind of awful, I was very impressed by how easy it was to write packages for Nix in general compared to writing DEB and RPM packages. I was also impressed by the override functionality in Nixpkgs (despite its heterogeneity of multiple, similar mechanisms), which makes customizing packages crazy easy.
When I got help working on some of the tougher packages, I realized that the NixOS community was absolutely full of exceptionally smart and helpful people. I’ve not been very involved in the community in recent years, but it’s still clear to me that that’s one of NixOS’ greatest strengths.
For me, Nix reinforced my interest in FP even more than the other way around. After college I got my first job at a startup where I got to do some FP (not in Haskell), although I’ve since moved on more to the DevOps side of things.
Nix is complex, and the command line tooling can be clunky. The amount of choice within the Nix ecosystem can be overwhelming, due to the propagation of competing, third-party tools. The dynamic character of Nix can lead to some really surprising and unhelpful error messages. The Nixpkgs codebase itself is as essential a reference for me as any of the manuals, unfortunately.
Despite all of that, I actually feel better than ever about Nix! I find the language very well-suited to its task, and the recent improvements in error messages are very welcome. Despite some minor gripes, I much prefer the new CLI, and I’m glad that flakes will finally provide some blessed conventions for pinning packages and providing repository metadata for projects written in Nixlang. The documentation for Nix has improved a lot since I started using it. The community is still outstanding. So that’s why I’m still here.
Oh, minor point here: I don’t think the upsetting thing was that an experimental filesystem that can only be run on a special fork of the Linux kernel is well supported. It was two things:
The advice he got on how to achieve this was so simple that he couldn’t believe it was useful or on-topic advice. So he was initially annoyed at receiving (what he thought was) bad advice from someone who (he thought) wasn’t really listening to his problem and (he thought) didn’t understand how experimental bcachefs still was/is.
When that simple advice did work, it laid waste to all his overcomplicated plans about how to approach the problem. There might be some playful anger in this, but the experience is mostly delight, like in being amusingly duped by a brilliant magic trick. You find yourself thinking how the hell did you do that, you clever bastard!? It’s a feeling that your expectations of what’s even possible have been subverted. It’s perplexing but it’s also joyful.
Hopefully that makes it a little more relatable.
(This is the thread for the talk under discussion.)
I’m not sure what to make of this… comes off as passively hostile.
I would argue that, at it’s core, nix is simple. It’s only remarkable abstraction is the creation and realisation of a .drv. And that includes anything from just bytes pulled from the internet to a package.
I will say that the cli situtation is not… great right now. And we are in kind of a transition state. nix-env probably does more harm than good, but made sense before home-manager. And it’s still awkward to point people to a community project.
I’m not sure about that, the official manuals should work.
Some of the DE programs make a lot of assumptions about services being available. This is more true of gnome, but probably true of others. This is likely band-aided at the nixos module level, but probably impossible to do at the package level.
For things like PATH, XDG_DATA_DIRS, and other contextual; this can be achieved with wrapping. Example
Those are rollbacks at a dataset level, and you can only view one-at-a-time as they share a mount point. To successfully do rollback using a fs feature, you will also need to make sure that the ordering of your mountpoints are correct, which just a consistent concern. NixOS you have all of the existing system generations available, and there’s a separation of concerns about system configuration and system state.
I think we watched a different video. He was having trouble getting bcachefs on root on another system, but was successful with nixos with just a single line change.
You also don’t have to understand how derivations work to get the basic idea of Nix, which is just that every possible variant of a package gets installed to a unique location that becomes read-only after build time.
To make mastering (or even just choosing!) the in-ecosystem tooling used to execute that idea feel equally simple, though, would be a new achievement.
I don’t understand why the system config that the end users tweak needs to be in a Turing-complete language.
Even if for some reason (that I don’t understand) /etc/nixos/configuration.nix must be a program in a Turing-complete language, why on Earth isn’t “I want a C++ plugin in my VS Code” a simple boolean?!
etc. etc. etc.
What I think NixOS needs is a GUI / TUI configuration tool: maybe like about:config in Firefox, or like Cygwin. You type in its search box “vscode”, it shows a bunch of options, including the option to enable the C++ plugin. You toggle it, and that’s it.
I use Haskell nearly on a daily basis and I am extremely happy about this language. I don’t think it is fair to say something should be removed just because you do not like it. I like Haskell and don’t want it to be removed.
I agree with you in this aspect. I asked myself quite often already. Why do we need another language just to configure a system? Couldn’t we use Haskell? (Haha). More seriously: couldn’t we use TOML, Dhall? And I think part of the community is moving towards this idea. See, for example, GitHub - tweag/nickel: Better configuration for less.
Maybe you jumped on the train a little bit too early? For me, it was definitely worth jumping on this train earlier than later.
nixos.org says “if a package works on one machine, it will also work on another”. I don’t think this is accurate,
I’ve also found this particularly annoying… when I started learning Nix/NixOS I wasted quite a bit of time to this as it muddled my mental model of what Nix/NixOS can/can’t do (particularly on non-NixOS systems), how it compares to docker, etc.
I get that reproducibility is hard to sell but there has to be a better way than lying about what Nix does
