BTW, I decided to give up on NixOS. It’s not that I don’t know Haskell. I do, or rather did (up to, but not including monads). OCaml is a better language IMHO, because it’s eager. I think the creator of Haskell admitted that laziness was a misfeature long ago. But I’m not trying to start a debate here.
Anyway, I gave NixOS a try in a VM after watching some tutorials on YouTube. Here are my impressions:
CONS:
The complexity is offensive. No other word for it. Simple things should be simple. There should be one, and preferably only one obvious way of doing things. NixOS took this motto and did the opposite, with its cacophony of nix, nixos-*, nix-env, home-manager, etc. etc. It’s not that the complexity could not be overcome. I’m sure it can all be learned. I just find it distasteful.
On top of that, all this complexity seems to be poorly documented. Even when you follow instructions the best way you can, they often don’t work.
nixos.org says “if a package works on one machine, it will also work on another”. I don’t think this is accurate, since there is state in ~ and /var, so while e.g. Pantheon’s Calendar worked for the maintainer, it didn’t work for me. Moreover, a package can depend on others without requiring them at build time. I kind of knew this line was misleading going in, but still, let me register my complaint.
I’ve learned that ZFS/BTRFS + Debian can achieve rollbacks too, which is a cons for NixOS, since everything is relative.
The RedHat talk that you all loved had the opposite effect on me. Who the heck gets upset that his OS supports some filesystem out of the box?! Who finds this relatable? Or the best talk they ever watched? People very different from me, I guess. I like it when stuff works.
PROS:
This community here is obviously a plus. I don’t think there is a distro with nerdier users.
Anyway, bye, and thanks for trying to help. I might pop back if I change my mind, but I probably won’t.
Some valid points. I’m using Nixos for a while and I know what you’re talking about when saying too complex. I recently tried to switch to flakes and nope’d back hard, since I couldn’t understand what is going on at most examples I saw on github. I guess one needs FP background for it.
Even when you follow instructions the best way you can, they often don’t work.
Problem is, they “do” work, but for a limited time. Implementation changes, which needs a change on the .nix files, which makes some documents obsolete.
Since there is state in ~ and /var , so while e.g. Pantheon’s Calendar worked for the maintainer, it didn’t work for me
There are limits. Nixos fixes reproducibility issues up to a point. Some (including me) pushes a bit more with managing ~ states with home manager etc. so we’d have more solid output, but yeah, can’t do magic.
a package can depend on others without requiring them at build time
Never had such issue, runtime dependencies also included in packages.
I think Nix-on-non-NixOS is the best onramp to NixOS proper. It’s how I started, and it definitely makes the complexity a lot less offensive. I would not recommend anyone to start out with NixOS cold turkey.
I guess from entire-ecosystem-integration and documentation and language-non-laziness point of view Guix could be a better fit for you. But if you only want rollbacks and are not burned much by package conflicts, probably still not worth the trouble.
PS. I don’t like almost anything I know about Haskell, so no, not only Haskell users. On the other hand I gave up on NixOS and built my own NixOS-like system because NixOS still integrates things too much.
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.
