Can you build/test/run your organization's software from 5 days/months/years ago - across multiple platforms, systems, and ecosystems - reliably?
Can you develop, build, manage, and maintain your software without fear?
Do you want a system do the bookkeeping for proper software dependency management? Or do you want people to do it by hand?
Do you want a declarative system, or try to remember and keep track of all the changes you've ever made by hand?
You don't get these things for free, but if you value them, then Nix is the tool for you. Or at least learn about it so that you can learn from the decades of accumulated knowledge.
next 30 seconds:
I can confidently compile and run multiple incompatible versions of software simultaneously. I can build projects from years ago. I can package large projects from different ecosystems (python 2/3, c/c++, go, Javascript, Octave, Rust) and be confident they will not interfere with each other. I can try bleeding edge software with no risk to it interfering with my system. It is faster and less hassle than juggling various Docker containers and VMs. It protects me from dependency hell. Using Nix to manage an operating system (ie: NixOS) then gives me those benefits for my entire machine. Then I get even more benefits when using Nix on any other (not even necessarily NixOS) machine by pushing around package closures and managing a simple binary cache.
But overall: it makes me more productive. It is my secret weapon to manage the complexity of software development. The benefit is not on day 1, but on day 100 and day 1000.
NixOS takes PL concepts from the 80s such as {structured, functional, declarative} programming and retro fits them onto a modern Linux vehicle in a miraculous fully-reproducible way.
Once you've had a taste, using anything else will feel like poking your hard drive with a stick.
Also:
NixOS: Be the distro maintainer you never wanted to be.
Meanwhile, in the real world, the thought of getting Nvidia's binaries running inside NixOS on their Jetson platform (based on a completely different version of libc) to make it a usable system, fills me with fear.
Oh yeah, I have a jetson nano and I wouldn't even bother.
I've even switched away from zfs to btrfs because anything not in-kernel is a constant pain. However, it's worth getting compatible hardware (OSS friendly) for the benefit IMO. It's my daily driver on a frame.work laptop.
Where did the pain come from? "boot.kernelPackages = config.boot.zfs.package.latestCompatibleLinuxPackages;" is supposed to make sure there is no pain in that case.
Yet choosing between the two is not difficult: Nvidia provides me with real performance (stuff I gladly pay for), whereas NixOS provides me with "just" some convenience during installation. NixOS is a cool idea that might have worked incredibly well until about a decade ago, but the world has moved on and we have GPUs now which bring new headaches.
It's more doable on NixOS than on most distros, but the real problem is you're trying to run out-of-tree code. The world isn't going to stop for you (or for all the android devices) so it becomes mainline or GTFO. On reflection I think this is a good thing, despite it meaning I can't play with nvidia things. AMD APUs are good enough these days.
I think it's perfectly possible to use it, you'll just have to do some of the work yourself. The linked jetpack module seems to demonstrate that. Of course, if it's just a few utilities you need you might be able to `patchelf` most of them yourself.
According to the link Nvidia themselves have left the jetson behind, and from memory and a quick search it doesn't look like any other distros support it either.
You can load that support through a NixOS module, though. That's the case for every ARM-based NixOS system to my knowledge, from Apple Silicon to my Rockchip home server.
I think that's going to be very painful though, because Nvidia provides binaries for cuda, cudnn, etc. that depend on one version of libc, whereas NixOS depends on another version of libc.
NixOS is the first meaningful counterpoint to Pike's "Systems Software Research is Irrelevant" talk. Or, put another way, the most meaningful advancement in UNIX in about 30 years. (Nix is itself 20 years old).
Not OP, but here's my take: I have two machines, one with NixOS, one with Mac. I use the same configuration on both. Keeping both machines in sync is a matter of two commands, adding a new machine is also a matter of two commands.
I have tried multiple orchestration options before, but they always fail in some way, ansible for example always work until I have to run something from scratch, then it fails miserably because of something that changed after the 20th time I've ran the script. On Nix, that's not even a consideration.
How do you configure and install low level hardware drivers? Aren't these different on both systems? And wouldn't proprietary drivers rely on hardcoded versions of libc, for example, causing a dependency hell?
> wouldn't proprietary drivers rely on hardcoded versions of libc, for example, causing a dependency hell?
You can have multiple copies of glibc on NixOS and it's fine as long as you don't need two different versions of it in the same process. Have you run into this on NixOS?
First enables nvidia modesetting, second enables the driver, and the third enables opengl, with a special flag to also enable it for 32bit stuff (like old games on steam).
By shedding the constraints of the FHS [0] it's able to completely rethink how the different components of an operating system interact with each other. It's like going from assembly to a language with functions. Dependencies can be analysed, can be encapsulated. Your OS becomes the output of a build file, not some porcelain edifice of /etc/ files. 'Rollback' is nonsensical, you just run the old build.
I boot to a tmpfs root so all my changes are ephemeral unless I deliberately save them, it's a fresh install on every boot.
NixOS is the distro for people that want to give up on the concept of a distro. If you want to abandon the entire concept of system libs and set up a custom environment (or if you're lucky, have someone else write the multiple config files) every time you want to run something, NixOS is for you. If you want to embrace the fragmentation in linux and make it so no dev can ever expect a consistent set of libs, NixOS is for you. If you want to play around like your home desktop computer is for a business and do some cargo culting, NixOS is for you.
That's not to say nix is bad. But NixOS definitely is.
> NixOS is the distro for people that want to give up on the concept of a distro
Indeed! NixOS is for people who are done distrohopping. It's for people who see through the superficial differences between distros and realize that their most essential differentiators are their own tooling (package managers, initial ramdisk management system, init system, etc.), and that the massive landscape of distros actually boils down to a handful of configurations in terms of those key choices, with some defaults lightly sprinkled on top.
Once you reach that point in your Linux journey, you generally don't care very much about those defaults, and what makes a distro interesting or appealing is a solid foundation that suits your preferences. The rest is easy to swap out or modify to your liking.
> If you want to embrace the fragmentation in linux and make it so no dev can ever expect a consistent set of libs, NixOS is for you
Indeed, NixOS is not a platform designed to serve as a ready-made target for proprietary software that wants to just make assumptions about what is present and hope for the best. But it does support Flatpak, Podman, Docker, Steam, etc., for devs that want to distribute software that targets some other such runtime instead of distributing source code.
> If you want to [...] set up a custom environment [...] every time you want to run something
The above is massively exaggerated, but kinda yeah. Years before I took up NixOS, I learned how to package software for a few distros and developed some tooling preferences. I realized that with some basic packaging skills, I could run any system I thought was interesting, stable, or useful and just package what is needed along the way. So when I came to NixOS, occasionally having to package things was not a big problem for me. Such users are a great fit for NixOS, and the NixOS community has a lot of them.
Set up your whole system in a config file. If you mess something up you can rollback any time (or in fact boot directly into past versions). You can patch bugs anywhere in your dependency tree easily. C/C++ packaging works. You can also deploy these configurations to remote machines.
Not sure about those two you mentioned but Ansible as a similar tool does not have state. It needs to run every command and check what changed. Nix, from my understanding, does have state so it can be more efficient.
The cool thing about Nix is that everything is compiled into a big immutable content-addressed store. Then switching the configuration is a matter of ensuring if that particular config has been built and switching some symlinks to the right place in the store.
I'm not sure if I've ever tried to pitch Nix or NixOS.
I can't imagine going back (and might give up computers to live in a tree if I had to), but I don't really try to ~convert people who aren't ready for it.
I'll share if I suspect someone is ready, or if I see them struggling on something it ~solves. I might lend a little time helping them bootstrap a basic environment for a project so that they can see benefits upfront.
But I want them to sell themselves on it. This is mostly because Nix is a bit of work, and I feel like slowly selling myself on its vision by reading different articles circa 2015-2017 was an important precondition for succeeding when I finally decided to take the plunge after my previous Windows system flamed out in early 2018.
This is a good answer, if not a directly helpful one if OP was looking for new slogans.
One friend of mine has recently taken up Nix with a lot of enthusiasm, and by far the moments that have driven him forward the most were his own successes with his Nix-based projects. I've definitely hyped it up before in front of him, and I've definitely helped him along a couple times. But over and over, it's been actually using a capability that was new to him that got him worked up and excited to try more new things.
In the past three weeks I've explored two use cases:
1. Macbook setup via nix-darwin + home-manager. Now that I've put in the time, I'm going to use it for my personal and family laptops. I would probably not recommend anyone else do this if they have not previously used Nix. Very high ramp given the benefits.
2. Dev environments[1]. I started using nix+direnv for my side projects. This was quick and easy to get started with and has been great. Would recommend anyone look into it via the link below.
It's like Nix-Darwin but without any setup issues, spared from breakage related to OS upgrades, but also with fewer escape hatches (Flatpak is the main easy one it does provide, also steam-run) for app installation. If you do enjoy Nix-Darwin once you get it going and you at least somewhat enjoy Linux desktops, you'd probably enjoy it as a daily driver.
I would say that for users new to the Nix ecosystem, NixOS on a spare machine is the most gentle and pleasant way to introduce the module system and declarative Nix config. It tends to be smoother than Home Manager or Nix-Darwin, and it's a lot more complete than either, both because it has more users. But a spare machine is a good choice for those who aren't yet sure that they like or care about Nix, because if something is missing or non-obvious, the only way out is through— you have to dive deep.
NixOS is so mature these days compared to when I first picked it up, though. Packaging work just to get by on the day-to-day is way more rare, and there are a lot more examples around. A Linux hobbyist who is prepared to struggle a bit can definitely just dive right in and have a good time, for sure.
Cool! There were definitely some hacks/issues with nix-darwin though most of my time was probably spent porting my neovim config[1] (still working on it) which should mostly carry over if I want to check out NixOS. I'll probably take the spare machine approach as you mentioned.
Nice! I've been playing around with NixVim¹ for my neovim config on macOS/Nix-Darwin at work, but I haven't done much with it since I mostly use Emacs with Evil.
Neovim is my 'spare editor', so my needs for it are simple. :)
Have you tried / are you going to try devenv or devbox for development environments? I'm curious to know what other people think. As for me I'll try it as soon as I finish reinstalling my macos.
I have not tried either yet. There seems to be a few of these nix-based dev envs coming out which is one reason I became curious. I wanted to learn baseline nix before jumping into any of these.
If you are using nix-darwin to set up your macos, I'd be curious to hear about your experience.
I've answered your question on another conversation, so here's my second example: I've borked my system last week doing some forbidden incantations. I've then restarted, chose a previous revision on Grub, and there I was with everything just the way it was before.
On another distro, that would be at least a day of work lost setting up stuff.
EDIT: lol I've replied on the wrong comment, at least it's the same author...
I think it’s very impressive how NixOS seems to have better UX (easiest distro to use) than any distro I have ever tried despite all the horrible UX issues (Nix is a very bad language, lack of documentation etc.). All because immutability, declarativity and system configuration being just setting an option is so big of a win. And I don’t even know Nix lang.
The community is working hard on that topic, while also trying to prioritize what's the most critical aspects for folks. Anything that sticks out the most for you?
The insanely steep learning curve, for something that manages packages. Nix will never take off until you ditch the DSL and get documentation in shape. Otherwise Nix will continue being a system developed by very smart engineers for very smart engineers.
I think the UX problems with Nix are well documented and understood. The developers behind it just need to focus. For that focus to take place, the project needs to be placed under better stewardship.
nix is a build tool, not a package manager. Misunderstanding nix as a package manager (and the dumb marketing on its website) is what leads to frustration (along with, of course, docs).
Don’t forget the documentation! “getting started” bugs that outright breaks your install if you actually try to follow them; WONTFIX, you should just know how to do it.
I've seen you post about this before, I think, and I am curious about the details. How did you install Nix and what were the sections of the manual that broke things for you?
Last time I checked (~year ago) this wordage was still on the documentation page; someone seems to have hit in January. It seems to be missing now though.
Six years with a basic “run this and your path through the documentation stops” issue IMO is a project not worth my time; they clearly don’t want new users.
Yeah this is a documentation footgun for some¹ users, and unfortunately is more likely to hit new users and dabblers than the experienced or dedicated Nix users who can just step over it. It sucks.
It's true that the information in that section² of the manual is correct, and also true that those snippets are not instructions, so the manual is not instructing anyone to do a thing that will break their computer... but if some Nix profile is the only thing putting Nix on your PATH and you switch away from that profile, you will naturally no longer have Nix on your PATH, and the next Nix command you try to run will fail. The docs should warn you about that in this section, and the application should also warn you on any actions that might leave your PATH Nixless like this.
There's another problem here, I think only hinted at in that GitHub issue, in that if you switch to an empty or nonexistent profile and start a new shell, the `/bin` path in your profile won't be added to your shell's PATH on shell startup because it doesn't exist. And then when you do install something to that profile, it won't be on your PATH until you start a new shell.
The issue you filed should be reopened as a documentation bug, and a new issue should be created about warning users on operations that might render their PATHs Nixless.
If anyone does hit this or something similar: you can just run nix-env or any other Nix binaries directly from the Nix store, or from one of the other still-existing profile links under /nix/var/nix/profiles, e.g. /nix/var/nix/profiles/per-user/$USER/bin/nix-env, to switch your profile back.
--
1: Namely, Nix users whose Nix binaries are provided in a per-user profile and are running Nix as the relevant users. NixOS users, Nix-Darwin users, System Manager users, users of regular old multi-user Nix installs, and users who install Nix itself via their distro's package manager aren't affected.
NixOS: Intentionally breaks compatiblity with a lot of scripts and binaries due to not having /usr/bin/bash and not putting libraries in a standard location despite the fact there is still /usr/bin/env and a bunch of symlinks to things under some obscure folder in /run. It will make sure that every user has to learn Nix because you won't be able to run things from the internet without going through Nix's documentation trying to figure how to package something when you just want to run it and get on with your day.
/usr/bin/env is required by POSIX, but bash's location already varies across distros and operating systems. NixOS's choices there are fundamentally correct.
Since shebangs have no native way to look up binaries from your PATH scripts should be including the full path to the binary from /nix in the shebang (and they should stop opening PRs asking people to switch to /usr/bin/env for them)
>but bash's location already varies across distros
It almost always exists in both /bin/bash and /usr/bin/bash via a symlink.
>NixOS's choices there are fundamentally correct
I suspect the choice has more to do with that they don't want to do the work needed to remove /usr/bin/env.
And one of its main uses in practice today is to perform lookup via PATH in shebangs, since it has to do that kind of lookup to be able to launch programs with modified environments as given in those examples anyhow. It obviously can't perform that common function if applications using it can't find it, so it's in an exceptional position relative to other utilities.
NixOS just makes the correct tradeoff here for `env` to be able to perform one of its main functions by putting it in a conventional location.
> Since shebangs have no native way to look up binaries from your PATH scripts should be including the full path to the binary from /nix in the shebang (and they should stop opening PRs asking people to switch to /usr/bin/env for them)
Nixpkgs already has facilities to handle this for scripts that are packaged via Nix. Those shebangs matter only when (a) some impurity is actually desired or (b) the scripts are used/managed out-of-band.
The issue also doesn't only affect NixOS.
> It almost always exists in both /bin/bash and /usr/bin/bash via a symlink.
What if I don't want to use the system bash (ever) because it's old? If someone isn't shipping their own bash or targeting a specific version that they know comes with a target platform very deliberately, why should they point to the system bash?
>NixOS just makes the correct tradeoff here for `env` to be able to perform one of its main functions by putting it in a conventional location.
At that point you might as well do the same for sh and bash as it would also save a lot of unnecessary headache. Shebangs are not a necessary part of a distro. You can always call the interpreter directly and pass in the script.
I personally find the idea of disrupting the normal FHS for purity to be a cool idea, but if you are going to ignore that goal and compromise to increase compatibility with existing scripts I feel you might as well compromise that purity more to support bash as that will solve the users of the OS even more problems.
>What if I don't want to use the system bash (ever) because it's old?
When you are sharing a bash script with others you typically aren't going to want to use bleeding edge features. I don't see that as a big problem. For your own scripts you can always use the full path to whatever version you want.
> No, it isn't. The required directories are /, /dev, /tmp. The reqired files are /dev/null, /dev/tty, and /dev/console.
To finish splitting the hair: the env utility is specified by POSIX (it also specifies sh, and not bash), but it doesn't specify the path of any standard utility.
> Since shebangs have no native way to look up binaries from your PATH scripts should be including the full path to the binary from /nix in the shebang
Weird hill. Shebangs are a "native" way to tell the ~system what interpreter to use, and optionally what arguments to pass to it. Can you clarify how this argument doesn't self-reduce to absurdity? Why should the distinction you're drawing apply to the "non-native" behavior of env and not to the non-native behavior of every other external interpreter and executable?
> (and they should stop opening PRs asking people to switch to /usr/bin/env for them)
Again--weird hill. I won't pretend the Nix community isn't a big source of these requests, but your sample may be skewed if you think Nix is the only source of these requests.
For example, a narrow GH search (("/usr/bin/env bash" AND "/bin/bash" AND nix) -org:NixOS -org:nix-community) focused just on bash only gives me 429 issues and 283 PRs that smell nix-motivated (and some are references to "*NIX"). A similar search for macOS (("/usr/bin/env bash" AND "/bin/bash" AND macOS AND NOT nix AND NOT nixos) -org:NixOS -org:nix-community) turns up 1.8k issues and 1k PRs.
> I suspect
No real need to speculate--https://github.com/NixOS/nixpkgs/commit/7281a851b3594 makes it somewhat clear that this is a convenience for end users that may want to use (or write) scripts ~can run on other NixOS and other distros.
(There are definitely people in the community who'd be happy to remove both /bin/sh and /usr/bin/env. Both of these are even nullable options, though I don't think I've heard of them being used outside of the envfs module in nixpkgs and the FHS module in https://github.com/balsoft/nixos-fhs-compat.)
> they don't want to do the work needed to remove /usr/bin/env.
Remove it from where? These are already extensively patched out in nixpkgs. If that's the work you're talking about, it gets done all the time.
>Can you clarify how this argument doesn't self-reduce to absurdity?
I think you misunderstood me. My comment about being native is that Linux does not look at your path when handling the shebang. Since POSIX doesn't standardize where env is there is no way to know how to launch env ahead of time. If there is no way to write a generic shebang you might as well just accept that you will need to change it.
>but your sample may be skewed if you think Nix is the only source of these requests.
Fair point. I am also biased from PRs also trying to insert flake.nix into projects. My issue is that nix is doing something nonstandard and it feels like projects are having to accommodate nix's oddities instead of nix being the one to accommodate what already exists.
>makes it somewhat clear that this is a convenience for end users that may want to use (or write) scriptsz
Thanks for sharing this. I always assumed they had it from the beginning.
>Remove it from where
Not all instances of it in build scripts are properly rewritten. Also there would be work in creating a migration plan to not breaking people who currently rely on its existence.
> I think you misunderstood me. My comment about being native is that Linux does not look at your path when handling the shebang.
I understood your comment. Maybe we're just doing a prescriptivist/descriptivist thing.
The shebang is a good example of a Unixy affordance with creative applications, and I asked for clarification because I (a descriptivist :) don't see why any specific functionality enabled by this affordance is more or less valid.
> Since POSIX doesn't standardize where env is there is no way to know how to launch env ahead of time.
In a fundamental sense, it's impossible to be certain that code written to run on one system will run on any ~other (including the one it was written on, since it may have mutated it in incompatible ways as soon as execution starts). We can try to trust POSIX, but most distros enable users to mutate the system in ways that even it can't protect us from.
> If there is no way to write a generic shebang you might as well just accept that you will need to change it.
I'm of (at least) two minds about this. It's obviously correct that there's no way to write a generic shebang that will work everywhere. But I think it's also obviously a poor use of human time and attention, at scale, for us to all individually waste time ~localizing every third-party script for every system we ever run it on (perhaps repeatedly, as the system changes). The impossibility of a 100% solution isn't a good reason to shun 90% solutions.
(I say this as someone who develops a tool, https://github.com/abathur/resholve, for ~localizing bash/shell scripts--shebang included. In some sense my ego could benefit from end users needing a tool for this, but the task is inherently fraught on stateful systems and is probably best addressed at the package-manager level.)
> Fair point. I am also biased from PRs also trying to insert flake.nix into projects.
Just as fair. They mean well (and generally just want to make the project easier to distribute or contribute to), but they can be a bit ~deaf to reasonable concerns about adding to the maintenance burden.
> My issue is that nix is doing something nonstandard and it feels like projects are having to accommodate nix's oddities instead of nix being the one to accommodate what already exists.
Also fair, though I hope you'll keep your eyes open for cases where people trying to package a project with Nix are shaking loose portability/reproducibility/underspecification problems that are already latent in the project and are worth fixing even if you ultimately reject the .nix file. (This won't be everything. There are certainly cases where Nix is the only one needing the patch and should do the work to keep up with it.)
Anecdotal, but it's reasonably common to run into projects with hardcoded paths that leave the build/test processes working cleanly on exactly one person's mutable system without anything anywhere saying what that system is or how they bootstrap it. I've seen this include ~snapshotted test outputs that will only pass on the authors system because it's affected by files or even dotfiles that may be in the project directory but not committed, or higher up in the directory tree on the system.
This kind of stuff is just as likely to trip up non-Nix contributors. It may also be a big hurdle to the broader OSS community being able to pick up the torch for them if they get burned out, fall ill, change careers, etc.
(Sometimes maintainers are standoffish about fixing these, especially if they distribute their own binaries or directly push artifacts out to package repositories and so on. They may not understand why we want to build from source or run their test suite or build scripts or build the manual. I'm sympathetic on some level, but I must admit I'm flummoxed when people seem actively incurious about reports that suggest they might have trouble building the project if they lost access to their device).
> Not all instances of it in build scripts are properly rewritten.
Any example? There are definitely asterisks (https://github.com/NixOS/nixpkgs/blob/a4d0fe7270cc03eeb1aba4...), and the default behavior here is one driver for people going out to ask for `/usr/bin/env` (because those can get autopatched). But we do still have the tools to patch them. It isn't the end of the world if you tell us to kick rocks.
> Also there would be work in creating a migration plan to not breaking people who currently rely on its existence.
Yes (though, perhaps ironically, the closest I have to a pitch for Nix is what an incredible lever nix/nixpkgs/NixOS are for experimenting with the feasibility of ideas like this at scale).
It was too long ago since I contributed to nixpgs or used nix for me to remember any specific examples. It may have just been with something I was personally packaging.
I end up just using patchelf since getting the alternatives working is harder. I would prefer if NixOS is going to give up on moving everything into /nix that it just makes symlinks in the standard paths so users don't need to find something to do it for them.
I have thought this, too. But if that includes libraries or even stuff that would go under /usr/share, that could cause breakage on NixOS updates for software that expects specific versions of things at those paths.
This is probably less of an issue for executable paths, but if people really expect to be able to ./configure && make on NixOS, NixOS needs to have a whole different release cycle. Ideally you'd probably still want atypical prefixes, if just like `/usr/1.0/...` or something so you could have multiple releases (and software compiled against them) live side-by-side.
I think that could work really well, but it would be a huge maintenance burden and there's nobody up for it right now. And it would still involve some of the pain we currently have with unusual filesystem structure.
I like this one the most. Sums up my experience after drinking the kool aid. I feel invincible now whenever I make changes to my machines or dev environments.
Nixos: an excellent place to spend thousands of hours trying to save hundreds of hours of time reinstalling linux and setting it up each time you buy a new computer.
Composing/merging multiple packages rather than layering them saves time and makes things consistent between "containers". Systemd service description contains 90% of what you may want from docker anyway. (filesystem isolation, security restrictions, networking, lifecycle management, multiple service instances)
NixOS: I'm selective about who I pitch NixOS to, but if I think someone I know would be a good fit with it, my pitch is basically a tl;dr version of Chris McDonough's excellent ramble here: https://youtube.com/watch?v=17-TRCpDizA
Computers nowadays are a writhing complex mass of components that change and crumble from beneath your feet when you're not looking. NixOS makes your computers predictable and manageable again. It gives you the power to set your preferences and solve your problems in a more durable way than ever. In doing so, NixOS also makes getting things right feel worthwhile when you might otherwise be inclined to just live with and adapt to brokenness. NixOS makes computing fun again, and puts practical configuration management, even on desktops, within reach for lazy home users.
Nix: Portable, predictable development environments that are fast, native, and don't ask you to fuck around with port forwards or bind mounts. Nix is insanely fast compared to Docker Desktop, and provides easy access to an extraordinarily massive collection of packages (80,000+!). If you develop on Mac and Linux and deploy to Linux, there's no better way to distribute your software or its dependencies internally than with Nix, period.
Currently using Fedora Silverblue. I am tempted to learn Nix and NixOS, but I have red several accounts that Nix is hard, documentation somewhat lacking, the ecosystem frustrating. Can anyone tell me if I should invest time to learn Nix, nonetheless?
I'll second this video recommendation! It's long, but it's basically a series of brief demos, so you can get a lot of the value out of it even if you start in the middle or skip around.
I've been forcing myself to get into NixOS. The idea is great. The Nix expression language isn't hard. I like the immutable root and generations (snapshots).
Setting up a desktop environment or Window Manager is quick and easy. Applications selection is great and you can install different versions in parallel.
The biggest problem for me is on the driver/hardware suppoet of my 2022 gaming laptop. Suspend, sleep, hibernate can be finicky. The graphics driver can also be hit or miss.
Documentation can be better especially for the NixOS exclusive behaviors. The Nix configurations needs more details as to what it exactly does and the packages it pulls. The Arch wiki and other Linux docs can cover the general stuff.
When I was in college, I discovered that reading in different genres (mathematics textbooks, philosophical papers) was a different skill than reading in general. I had to kind of get a feel for certain specialized genres and styles, and after I did, it gave me an ability to read them much faster than I could when I started.
As a Linux hobbyist, I learned that a huge part of feeling at home on the CLI was learning how to explore an environment at the command line, and the tools available for doing that: man, info, --help, tldr, bro, apropos, whatis, etc. Learning how to use completions and my own shell history to recall and mentally reinforce commands, even if I'd only ever used them once before was a big thing. Learning a new command takes me a hell of a lot less time now than it did when I was kid.
The Nix ecosystem is a little bit like that. The resources you can find on nixos.org are good, and you can get by with just them and some manpages, but it'll be slow at first. As you spend more time with Nix, you get a sense of what order to consult the official docs in and what unofficial resources are worth looking at. You now how to read Nix code and can quickly find examples or answer questions just by grepping through Nixpkgs. You gain enough background that it's easy for you to ask useful questions on Matrix, IRC, or Discourse. And the time it takes to learn something about the Nix universe that's totally new to you goes way down.
If you go into Nix with an eye out for resources and methods of learning like that, I think you'll get your bearings more quickly. If you make a reasonable effort to ask good questions and you're patient, you'll also get a lot of good help.
Parts of the Nix ecosystem are and will stay frustrating. But for me, it was totally worth it.
Can you build/test/run your organization's software from 5 days/months/years ago - across multiple platforms, systems, and ecosystems - reliably?
Can you develop, build, manage, and maintain your software without fear?
Do you want a system do the bookkeeping for proper software dependency management? Or do you want people to do it by hand?
Do you want a declarative system, or try to remember and keep track of all the changes you've ever made by hand?
You don't get these things for free, but if you value them, then Nix is the tool for you. Or at least learn about it so that you can learn from the decades of accumulated knowledge.
next 30 seconds: I can confidently compile and run multiple incompatible versions of software simultaneously. I can build projects from years ago. I can package large projects from different ecosystems (python 2/3, c/c++, go, Javascript, Octave, Rust) and be confident they will not interfere with each other. I can try bleeding edge software with no risk to it interfering with my system. It is faster and less hassle than juggling various Docker containers and VMs. It protects me from dependency hell. Using Nix to manage an operating system (ie: NixOS) then gives me those benefits for my entire machine. Then I get even more benefits when using Nix on any other (not even necessarily NixOS) machine by pushing around package closures and managing a simple binary cache.
But overall: it makes me more productive. It is my secret weapon to manage the complexity of software development. The benefit is not on day 1, but on day 100 and day 1000.