Who uses NixOS? Who are you people? (And good-bye)

Help
41

Oops, I meant to say, “the system can only see”, not “you can only see”. I meant that the nix store allows your current booted system to “see” parts of other systems. As NixOS is essentially a guest OS symlink’d into existence.

The NixOS related experience would be to look at /boot/loader/entries/nixos-generation-*, and it should show you the top-level store path for that entry (e.g. options init=/nix/store/s1zxsk897qidf8hpg4rraq1frbmcwjlq-nixos-system-nixos-22.05pre335103.6daa4a5c045/init).

You can just “peak” into that store path to see what that generation holds. You can also “switch” to that generation by substituting init with activate. And it’s like doing a nixos-rebuild switch to that generation.

3 Likes
42

The entire presentation is full of deadpan humor. I think you’ve missed that and taken a lot of it literally, which will certainly make it seem a very odd presentation indeed.

But the presentation does support some of what you’ve said, it’s hard to get started and become proficient.

7 Likes
43

Haskell seems to be a research language that is still evolving. This doesn’t stop people from wanting to use it in applications they use everyday. I know I do. It has meant that I have had to rewrite code because of language changes. In those cases the compiler (and the release notes) tells me most of what I need to know to fix it. I’m more annoyed by the time it takes for language changes to propagate through the libraries so I can rebuild my programs.

I don’t know where you got the idea that laziness was found to be a mistake. It adds a great deal of functionality to the language, and along with Haskell’s approach to currying, and monads, it is a main reason I choose to use the language. I think one of the improvements to python3 over python2 was its greater use of lazy data structures.

Currently I am overwhelmed by the number of new programming languages. I find that in order to consider the effort of learning a new one, I want it to provide something new for me to use in designing software. Most languages seems to be a reshuffling of old concepts into a syntax that the author likes.

Although I might have made different syntax choices than used by Haskell, they all seem to work together well. That is enough for me.

1 Like
44

I think the sentiment originates from this quote *The next Haskell will be strict* -Simon Peyton Jones http://www.cs.nott.ac.uk/%... | Hacker News

45

I see that there’s been some really tense conversation in here, but I want to throw in my own…

I jumped onto NixOS in 2014. I’m stuck on it because there are two features that I really value, but otherwise… the build tooling is a mess of esoteric, competing, and often broken, standards. The “blessed” ones (buildRustPackage, buildPythonPackage, etc) don’t reliably provide tooling to let me say “use this exact version of the compiler”, but instead force me to find an outside channel (say, Oxalica) and hope that it’s compatible.

Basically, after seven years of using this system in anger, I can’t actually build an application bundle from anything other than a pre-compiled binary or basic C source. And that frustrates me a lot.

11 Likes
46

See dream2nix @savannidgerinel

3 Likes
47

Yeah I think ZFS rollbacks to fix a broken OS would be complicated and could potentially break the OS even more. At least with NixOS you don’t need ZFS managing the nix store or root, you can rely on Nix rollbacks for that. You really just need ZFS managing home and maybe critical config in /etc and/or critical state in /var or elsewhere.

2 Likes
48

Just to throw in why I started using NixOS.
I always liked Arch but got bitten by it two times.
With Nix I should be able to recover far easier (and I already did after I messed up my display manager).
However Ubuntu LTS and Debian were to slow for me and pinning packages didn’t really work for me either.
With NixOS I’m able to easily use a package from unstable without it trying to update the rest of my system.
In addition I have a lot of side projects and a few of them I had to abandon because I wasn’t able to get them working again after I paused for a few months.
I could probably fix this without Nix as well but hope that it helps here with providing a standardized way.
So that when I for example need to build my LaTeX CV after a few years I can just update the text and and do a nix build and be done.
And last but not least I hope I can make the management of my personal servers a bit easier with NixOS and NixOPs or similar.

I agree with you that:

  • The learning curve is very, very steep.
    • But it feels a bit like test driven development to me, which feels quite relaxing compared to my previous approach (Ansible + Test VM => Production).
  • The Nix language is well lets say, not as pretty as Python but then I’m very biased in this regard.
    • I really do struggle here the most and have a hard time understanding what a .nix file does.
  • Good tutorials/HowTos are scarce but I reckon that is mostly because the community is quite small.
    • What I’ve found so far though was mostly very good and I was often able to puzzle together what I need with the provided examples.
  • Various command line tools, yeah sure there a lot of them but then in the end I just make my own alias/script and be done with it. It’s not like other programs in the Linux world are very consistent.
4 Likes
49

I think prior expectations matter a bit. I moved from Gentoo, and nixos-rebuild-switch is much less likely to shoot my foot than trying to work with Portage. I wouldn’t recommend NixOS to someone who isn’t already used to something like Gentoo or Arch, though.

btrfs rollbacks still don’t deal with the issues of accumulating a legacy of system packages, say if you do something like switch from pulseaudio to pipewire, so that’s one nice feature of generations and garbage collection. I had a habit of reinstalling the operating system at regular intervals to deal with this, NixOS somewhat automates something exactly like that.

6 Likes
50

I use NixOS because it makes it easy to ensure that all of the computers and VMs I use are identically configured. For example, if my employer gives me a new laptop, I can install NixOS and all of my favourite packages on it within an hour. In the past, a new laptop meant a week of lower productivity as I would regularly discover yet another package that I had forgotten that I need.

That’s the selling point for me. Sure, there are other advantages to using Nix and NixOS, but with added power comes added complexity. As a researcher, I mostly work on single-person projects, so fancy build systems are kinda overkill. Sure, I can set up different environments for different projects with Nix, but I personally rarely need that, and I could just use separate VMs for the few projects that need to be isolated.

I have come to appreciate rollbacks, using separate environments, and other features. But it has taken time to learn that stuff.

14 Likes
51

I use NixOS because my system is always in the state I’ve configured it for with my Nix configuration. I know there’s not going to be weird crap I forgot about, or odd inconsistencies between systems, and I can always undo any change by just deleting some Nix without having to remember what dozen steps I did eight months ago in the first place. This is why I won’t use plasma; I can’t configure it in a way that I can check into a git repo to track how it works. Everything that NixOS does, I can trace through Nix expressions to understand. There’s rarely any question about why something is where it is or how it got installed or enabled.

In short, it’s just a very unsurprising distro to me. It does what I expect and it gives me very obvious paths to discover what is going on, all while still using a very powerful configuration language that allows me to create quite useful abstractions.

17 Likes
52

I love the way this thread is going.

I just use NixOS because since I started using Nix+Home Manager on other distros, I found it difficult to detach myself from it. And when I decided to hop into NixOS, I was scared of Steam not being able to handle games in a simple way as I could do any other distro (I remember an issue with Among Us that made me think about it). But well, it worked, and that made me stay.

Maybe the only problem I have right now is that I need VMWare Player on it (please DO NOT try to recommend QEMU or Virtualbox, there are specific reasons for using it), but that’s not a huge issue.

5 Likes
53

I come from a system administration background, long term Linux user at home and work

Difficult to imagine to go back to a “normal” FHS Linux now, I really love NixOS and configuration.nix, even when I do not know too much about the Nix language I can build an environment I can work with, and maintain with ease :slight_smile:

Thank you everything and everyone NixOS!

5 Likes
54

Hi!

I’m a devops engineer with deep roots in system administration. Linux has been my go to OS since '97 (oh Slackware :slight_smile: ). Been trough a lot of distros over the time and finally found NixOS and got immediately bewitched :slight_smile: .

Can’t pretend I know the nix language and yeah it’s a mix of luck sometimes finding out how to do things, documentation is there but sometimes it does not agree on itself, but it’s a big community and usually answers are available right here.

I’m managing two laptops and a server at home with NixOS and once I got things going I’m really happy on how easy is to keep all configs declarative, the rollbacks saved my life a few times now, stability is (well usually) great even on unstable.

At work I used nix to finally get rid of the ever braking python venvs, whoever works with the Azure python SDK knows the pain.

Cheers,
Razvan

6 Likes
55

Yea… I tried to champion SemVer adoption, and some changes to how to capture and process breaking changes while working on AzureML. It’s very hard to convince people who have the, “what should we expose to costumers” mindset, but not a “what is the costumer’s experience” mindset.

2 Likes
56

This is a nearly perfect straw-man foil for NixOS lovers. But let me answer the main question and then the points of criticism.

I use NixOS for all my personal computing. I started with Nix on Ubuntu, then installed NixOS on my server (contributing to the Linode tutorial in the process), then installed it on every desktop system I could until I was confident enough to install it on my own, daily-driver, personal laptop. I love how my system is the way my single file config says it is. You don’t get that with any other system (aside from maybe Guix - a Guile Scheme port of Nix…?). Every change I make to my config results in a new Grub entry. I love showing off my system configs (server and laptop) to people who are interested in seeing it on discord, and most of the time, they tell me they’re going to try it out tomorrow (and sometimes they do!) What do they like most about it? They like the single config file. And I know, that’s not how most Nix power-users do it, but I really like having everything in one place…

Now on to the critiques!

  • Complexity: all these things evolved naturally. Nix is a (functional) build system, that’s very good at what it does. Because of the cache-ability, it grew into a package manager, naturally. That grew into an OS, naturally. It’s getting fairly well known that we should avoid using Nix as a package manager (via nix-env) to sell others on using it. I don’t bother with Home Manager yet, because I want to go as far as I can with a single config file - and since I’m the sole user of my system I just set it up the way I want it to be, system-wide. Not sure how we reduce the complexity here. Things should only be as complex as they need to be - and I think it’s about where it needs to be.

  • Documentation: the documentation effort is heroic - amazingly good for the numbers of people using NixOS. We need more and better - and we’ll get it as the community grows. But until then, when going off the well-beaten path, you need to be able to hold your own hand if you can’t get help in the various chat rooms (Matrix or Discord) or here on Discourse. That’s just the nature of it.

  • Geez, I’ve never heard of Pantheon’s Calendar. Maybe the packaging could be improved. There are other packages I’m hoping get improved too. But I’m really quite happy with the current quality of packages in NixOS, to be quite honest.

  • Another technology that may be at parity (I see others questioning if Debian’s rollbackability is really at parity) on a feature with NixOS is hardly a con for NixOS - it just makes evident that NixOS is worth copying, if you can.

  • Who gets upset that their OS supports something? I’m just speculating here, because I’m thinking their acting skills are pretty good - but perhaps it’s someone using tongue-in-cheek humor to make a point while giving a talk? Personally, I try to avoid sarcasm because people can’t tell if I’m joking or not. But it did seem to me that the speaker was going for a subtle bit of humor there. I’m hoping I got that right because that interpretation is most congruent with the rest of the talk.

  • Nerdy users.

Thanks for the compliment and I appreciate your post, because I’m thinking you were having a bit of a go at some humor yourself. It’s been an entertaining read and I have enjoyed reading the other responses and responding myself. I wish you well! When you inevitably come back, try not to troll us so good.

6 Likes
57

Full time linux user since early 2000s somewhere. I did the monad thing in university, but I work in embedded linux now, mostly C programming, and I do some devops on the side.

Rich Hickey (the Clojure guy) did a talk at strange loop called “Simple Made Easy”, which I think highlights a line of thoughts OP has; “simple things should be simple” - simple things may be simple, but simple things does not have to be easy. Monads are simple, but they are not easy. So is nix. Debian is easy, but it’s not simple. In my mind, Debian is more complex then Nix is.

10 Likes
58

Sorry I have to reply to this older post since this take was repeated few times and it’s imo at best misleading.

Haskell was intended as a research language, wasn’t it?

Haskell is a language designed by committee of language researchers interested in lazy evaluation first released in 1990. It could be said it has research roots yes. But you need to define what you mean by research language. If you mean language primary used for research then no, that’s not the case today. It would be possible to actually make a case that OCaml, which you seem to defend, is more of a research language but I spare readers of that.

Avoid success at all costs” and all that.

You probably read even this sentence badly. It doesn’t mean “we are, at all cost, avoiding success”. It means “we’re avoiding success at all cost”. “success at all cost” here is a single term referring to languages adapting sub optimal solutions just to please users. This doesn’t mean Haskell was not meant to succeed. That would be completely stupid – do so much work for nothing. It talks about not taking shortcuts and taking time to do things right.

once they realized that laziness was a mistake

Did they? Source? S. P. Jones just said that “laziness was what he was excited about at first the most but now he is more excited about purity”. The trick is that purity was necessity only because of laziness. You can have pure languages without laziness but it makes certain things tricky. With laziness some things become harder to reason about, sure (exceptions for instance). But it also enables certain patterns which would not be possible in strict languages.

they should have removed it.

You can’t just change evaluation strategy and pretend it’s the same language. If you want strict Haskell look at other options like PureScript or Scala.

Your Haskell program eating all your RAM is also a side effect.

My Haskell program does not do that.

Also I don’t know how this relates to nix. Is it because it’s also lazy? Well in nix laziness makes ton of sense doesn’t it? Or would you want to evaluate entirety of nixpkgs every time you need a single package compiling all the code in nixpkgs? Even Make is lazy to large extend.

I mean a lot of what you say are valid points every reasonable person should consider. Thanks for sharing that. I just don’t understand what is the motivation behind these poorly researched takes on Haskell, unrelated technology, especially since they only harm your case by making you look… wrong.

3 Likes
59

As much as we all want Nix to be simple to understand and easy to use, and as much as possible, I think we should continue focusing development effort in this direction, the fact is that the Nix way of doing things is a dramatic departure from tradition.

Anytime you are faced with a situation like that, it is going to bring on some “wtf” moments, and some confusion. I am not sure if 100% of that is avoidable. The payoff is that, once it has clicked, you realize that there is, in many cases, a much nicer way to manage the otherwise cambrian explosion of possible configuration states.

I’ve been using NixOS for my own personal dev machines, for over half a decade now, and I also use Nix for building containers and other devops related tasks at work, and in both cases I don’t see myself changing that workflow anytime soon.

The benefits of using Nix are very real (at least for me), but the journey is understandably rough sometimes, unfortunately. Its also not always perfect and sometimes compromises and escape hatches should be made for productivity’s sake.

In general I feel this is why often things just don’t change, not just in the software industry but in life as a whole, even if a new solution is technically superior in a lot of ways, the cost of switching is quite often just too high. That is a choice individuals and organizations have to make for themselves.

All we can, and should do is continue to focus on and improve UX and documentation to make that transition as seemless as humanly possible, for those who decide to take it.

12 Likes
60

I’ve been on this journey for ten years. I love nix for managing my environments.

But it is an excruciating multi-day-long trial and error effort for me to ever define a new derivation for Nix. I hate the process of bundling anything for Nix because there is an absolutely overwhelming mountain of implicit assumptions and divergent partial solutions to each and every programming language.

I stay with nix solely and utterly because of the environment wrangling, and because I never feel the need to do a 100% reinstall to get back to a clean system.

8 Likes