I started my Nix journey a little over a year ago, and I regret not having switched sooner. A package-manager that also ships an operating system that can be customized from the bootloader up, using a purely functional programming language is the perfect configuration management tool!
It does have some rough edges, and I did lose some hair figuring things out early on, but it has been getting better with each passing day. Pretty much the entirety of my setup at home is now built by Nix and runs NixOS, including my Macbook Air (runs NixOS on ZFS), and two Mac-Minis that PXE-boot a custom NixOS served by a Raspberry Pi 4 running a custom NixOS configuration that also acts as a firewall connecting wirlessly to my ISP's router. The Mac-Minis also double as build machines which makes for a pretty smooth experience when I'm building anything on my work laptop (a 2020 Macbook Pro running Big Sur) that I dock with my CinemaDisplay, which is wired thru an unmanaged switch to the rest.
So far I haven't missed any packages that I could not find in nixpkgs, or customize just the way I wanted to. The community is pretty responsive and quick to merge any pull requests for fixes/upgrades. I would whole-heartedly recommend switching to Nix/NixOS/Nixpkgs.
Same. I've been meaning to take the time to learn and switch to NixOS for several years now, and finally had some time to do it this past spring.
I haven't been this happy and giddy with a new piece of technology since I completely eliminated Windows for Ubuntu back in 2009.
There was a learning curve that took several months, but now that I've got everything I had on Ubuntu running smoothly on NixOS, I could never go back. And this for my daily driver, not a server or anything.
My favorite part is how it enables rapid experimentation with different build configurations, without any concern about borking the current working build.
If the new build breaks something, a single command rolls it back to the prior working build.
If the new build crashes the system, just reboot and choose the prior working build in GRUB. When you're logged back in, call the rollback command to point the system back to the working build.
This makes learning and testing both Nix itself and your particular system build faster, easier, stress-free, and just downright fun, which is invaluable.
Declarative, deterministic, immutable OS builds is a significant step out of the tarpit of software complexity.
I switched to NixOS half a year ago. The reason? I fell in love with literate programming (I use [1]); being able to write (and read) your whole OS configuration is the dream!
There are few bad sides to NixOS though.
The community consists mostly of programmers, which means I am missing some creative tools (mockups, mindmaps, ..). In the future I will be able to provide/build them myself, but it is not a smooth transition from my previous arch setup.
Also the whole documentation sucks: There are three (!) official manuals + the home-manager manual + Nix pills + YT + random blogs where I have to piece everything together.
Still I find NixOS superior to every other OS (windows, linux) I have tried so far. I just feel free and am not afraid to fuck up anything [2], as I can just go to a previous generation when it doesn't boot.
Lastly, I can save my whole config in git and am free to try new tools -- If I don't like them, I just remove their line in my config. No more chasing after random install folders! (Except in home..)
I really like the idea of NixOS, but there not being a single clear guide of how to set everything up (and the messy documentation) is the biggest thing holding me back. I also really don't like wasting so much time on tinkering with my system the way I used to do.
But I'm seeing so much Nix news these past few weeks, I guess it'll be better in a few years!
I think you can get going with little to no knowledge. Setup the system, choose a few cool options and packages, and go rebuild. Simple as that.
The difficulty comes from the advanced topics. Modularizing your setup, writing your own packages, generally going off the beaten path.
I did not do any of that (yet). I will in the future, but I am fine with my low-level setup. One machine, one user. A bit later I moved to Nix Flakes (which is just an additional wrapper file around the previously written config) and added a few overlays.
My trick: I downloaded every single public "NixOS" dotfile repository I could find, and then just used "ripgrep" to find anything I was interested in.
Another cool trick I read is setting up a VM to test a small config and get a feeling for it, and then decide if yo want to proceed.
NixOS' saving grace when it comes to the learning curve is that experimentation is extraordinarily safe, thanks to the declarative config and rollback functionality. If you don't know what you're doing, you can pretty painlessly get away with just fucking around.
Not just that. The ability to enter a sandboxed shell environment, play around with as many packages as you can get your hands on, and then exit back to my clean machine is my absolute favorite feature!!!
SO many times in the past, I'd be concerned about installing new things because they'd break my otherwise pristine developer environment. Yes, rvm/nvm/virtualenv and others help, but they fail to hold a candle to the nix-shell!
>I really like the idea of NixOS, but there not being a single clear guide of how to set everything up (and the messy documentation) is the biggest thing holding me back.
Yeah this part is messy, and why I always disclaim that I had a learning curve of several months to make the transition. However, my system setup is a little more complex than the standard install - mirrored ZFS root drives on dual m.2 drives, with mirrored boot partitions. That wasn't in the docs, needed a blog post to explain it [1].
>I also really don't like wasting so much time on tinkering with my system the way I used to do.
I've found that once you get everything configured to your liking, you spend similar or less time tinkering than on other OS's, just because the entire system config is captured in a single config file now. There's some up-front learning and work required, but after that it's smooth sailing.
Anyone looking into transitioning to NixOS should take a leisurely weekend and just read through all three of those first. Being at least familiar with all of what's there will make getting up and running a lot smoother.
>The community consists mostly of programmers, which means I am missing some creative tools (mockups, mindmaps, ..). In the future I will be able to provide/build them myself, but it is not a smooth transition from my previous arch setup.
Any time you need a package that's not in nixpkgs, feel free to submit a packaging request for it:
Especially if you explain that it's a popular tool in the creative community, that kind of thing is useful for the Nix packaging team to be made aware of. Even if someone doesn't package it right away, there's a good chance it will make it into the next 6-month release cycle.
That sounds like a nice way to do it, too. I heard about it before, but don't know R, so I didn't really consider it.
The reason I chose lmt is that it correctly keeps the markdown language syntax of the code blocks. That means I can put my literate config into my Zettelkasten [1] or [2] and watch it pretty-print in the browser.
There are also literate [3] and org-babel [4], but I don't think they are future proof. .lit is a random format and .org basically requires Emacs+orgmode.
For lmt/markdown: I believe yes, to the extend the editor allows for it. It is seemingly just like regular mardkown code blocks. I get the correct syntax high-light in the ``` code blocks. I don't have lint/LSP setup yet (currently moving to Neovim), so I can't say anything about that.
Literate/.lit: I don't know, I guess not.
Emacs/orgmode: Yes, this also does syntax highlight. And you can edit the code-block in a separate window as if it was a "real" source code file. I've been using this for almost two years now. Personal opinion: I don't think the benefits of Emacs outweight the cons.
"not afraid to fuck up anything" likely refers more to the ability to rollback the system to any (non-deleted) previous revision of the system configuration, directly from the bootloader, which means you can easily recover even from a broken kernel.
This applies regardless of whether you are packaging/updating something in the package set yourself, or using something that someone else packaged.
No, you can get the installer directly from the NVidia website, but only for selected platforms. If you're on a different platform, you'll have to wait until somebody ported (read: hacked) the release (or do it yourself).
Hate to make a boring me-too comment, but I feel the same: I've been using it a bit over a year, and I wish I had started even sooner. Now I've got two laptops and a NUC, plus two odroid-hc4's, all on NixOS. All the system configuration that used to be half-broken ansible and a pile of scripts (plus all the one-off hacks that weren't even captured anywhere) is now nice pure nix configuration. I've nix-ified builds for a bunch of personal projects too.
Yeah, it took a few months to learn, and there are still lots of rough edges, but going back to a non-Nix linux distro would feel like going back to windows. I agree with the sibling comment that it makes me feel happy and giddy, like no other technology I've learned recently.
> So far I haven't missed any packages that I could not find in nixpkgs, or customize just the way I wanted to.
And it's honestly not that hard to package things that aren't yet Nixified. Any C project is easy - I've learned more about cmake from mkDerivation that anywhere else.
And overlays make it easy to make tweaks to a build without straight-up forking. Beautiful!
> I've learned more about cmake from mkDerivation that anywhere else.
This is something I find really fascinating about Nix (or more precisely nixpkgs) that gets overlooked a lot: it is essentially a giant database that documents how different build tools work, how different projects are built, and so on, in an exhaustive and consistent manner.
That can be an extremely valuable resource to have in your back pocket, even if you're not actually using Nix!
I always think it's worth mentioning explicitly that NixOS makes it not just possible to put everything including the root file system on ZFS, it makes it completely easy.
It's not unique at that though. FreeBSD has had this for a decade. And Ubuntu is adding it now as an installer option.
PS: I do like the idea of NixOS and its USPs which are indeed unique :)
For me what's stopping me is the learning curve. I don't mind learning per se but if I put the time in it I'd like it to be for something that's useful in more places. Like ansible.
What's interesting about NixOS' seamless NixOS support is that ZFS can't be included in the Linux kernel, and so that kind of integration takes more work with Linux distributions, so relatively few distros have it down pat.
BSDs don't face that kind of integration challenge, since they can just ship ZFS support directly in their kernels. They have recently faced an integration challenge of their own, though: rebasing their ZFS implementations on OpenZFS (f.k.a. ZFS on Linux).
Anyway ZFS is great and I hope OpenZFS' multiplatform support gets so good it can become popular on Linux, *BSD, and macOS all at the same time. :D
Can you elaborate a bit more on why ZFS is great? I am currently thinking about doing "one final install" for my system, and am undecided between BTRFS and ZFS.
I noticed that most "hip" people use ZFS, but based on my meager research it seems actually recommended and designed for "big" data-center setups.
Why is ZFS good for small PC setups?
---
If am being honest I just want something that works reliably, is easy to extend and doesn't require maintenance. Maybe ext4 is good enough?
If you have a single disk, BTRFS is probably as good as ZFS for you.
ZFS is mature and featureful, and it's easy to performance tune specific subdirectories using 'datasets' (on BTRFS you can do some of the same stuff with 'subvolumes'). It has good utilities for backup, including over the network. It always supports up to date, efficient compression (these days, zstd). It's good at pooling, so you don't need LVM if you want to be flexible about 'partitioning'.
One genuine advantage it has over BTRFS other than stable softraid support is that it's cross-platform among Unices, including (in incipient form) even macOS. So experience you gain in administering it would be transferable that way. (OTOH, Windows has a pretty mature BTRFS driver, but ZFS on Windows is even more recent (and difficult) an effort than ZFS on Mac).
Truthfully, ext4, BTRFS, and ZFS are all fast and stable, and once you set them up your filesystem, you'll probably hardly think about it. (If you go with ext4, I'd set it up on LVM to make it easier to extend or 'repartition' in case you wanna structure things differently or add another distro or whatever.)
Linux's heritage and continued use as a server OS makes it rich with fast, reliable, flexible, feature-complete filesystems. All three of your options here are better than what's on offer on any Windows or Mac desktop, so you kinda can't go wrong, so don't overthink it. Just pick something you feel like learning or whose documentation strikes you as agreeable and interesting. Whatever you choose will serve you fine until your disk dies or you get bored. :)
> I don't mind learning per se but if I put the time in it I'd like it to be for something that's useful in more places. Like ansible.
Depending on whether you mean "used by more people" or "applicable to more problems"... if the latter, tools like morph or NixOps might be of interest to you, which essentially extend Nix to "across multiple remote machines", which means that de facto you end up with an orchestration tool like Ansible or Puppet.
>It's not unique at that though. FreeBSD has had this for a decade. And Ubuntu is adding it now as an installer option.
Right, but FreeBSD isn't Linux, if you want both ZFS and the Linux ecosystem, then I would argue NixOS is the best at that right now.
I tried Ubuntu and ZFS recently in a VM just to see how it worked. The installer handles a simple, standard ZFS config just fine. But if you want to do anything more complex, then you're doing manual configuration, at which point it's better to just use NixOS, where all the manual config is done in the main NixOS config file.
#MeToo. I am using two OSX machines and two remote Linux machines for my day-2-day private/work related stuff.
Nix+home-manager allows me to have all productivity tools consistently available across all platforms with minimal effort [1].
Dotfiles/shell config lives in a separate folder [2] and is not managed in nix.
Tangent: Secrets are are encrypted with git-crypt (https://github.com/AGWA/git-crypt) and live in the same repo [3]. I generate GPG keys for every new host I am working on and check in the public keys to the repo as well, then "approve" them from an authorized host using `git-crypt add-gpg-user ... && git push` [4]. This gives strong encryption without managing passwords by hand. [Copy of private key is kept in bitwarden as backup].
Getting the hang of Nix took me a while. I wrote-up my journey to get the latest-gratest emacs installed here [5]. But now I am over the bump, and it's adding value to my workfows. E.g. I switched some projects from docker to nix-shell for lightweight virtual-envs, e.g. [6].
I don't want a 'journey' to use my OS. I don't want to learn a whole new language and set of overengineered abstractions to solve what I see as, at most, 5% more of application installation problems that are already 75% solved by package managers[0]. If the Nix community wants more people using Nix, they'll have to make it more attractive for those of us who do not want to waste so much time needlessly learning new stuff to do the same things we're already doing.
[0] which are already an overengineered and under-delivering solution in my opinion.
> I don't want a 'journey' to use my OS. I don't want to learn a whole new language and set of overengineered abstractions to solve what I see as, at most, 5% more of application installation problems that are already 75% solved by package managers[0]. If the Nix community wants more people using Nix, they'll have to make it more attractive for those of us who do not want to waste so much time needlessly learning new stuff to do the same things we're already doing.
This is fair, but keep in mind that package managing is only a small part that what Nix solves, and it is a much superior solution than anything else that I know (Docker for example is not really reproducible because you can't trace all dependencies; this seems like a philosophic issue but I saw some containers breaking because some dependency inside the container was updated without nobody knowing).
If we take NixOS, it also solves the issue with configuration, and with some auxiliary tools it also solves issues with deployment. You have alternatives for both of the issues too, but the fact that NixOS is much more integrated than any tooling (like Ansible, Puppet, etc) means you have much more flexibility. Also, don't forget atomic upgrades and fallback.
Eventually, instead of "wasting time", NixOS starts to save time by becoming the most reliable OS you ever used: you will never waste time anymore reinstalling your system from scratch, or if your hardware broke, you will never waste days trying to get your system to the same way it was. Also, because nixpkgs is enormous, you also tend to save time by not looking at "oh, this program seems cool, how can I install it on my computer since I never heard of this XYZ language?", and them installing the package manager from the language in 5 different ways because you have no clue. And even when you need to package the program yourself, nixpkgs has many abstractions that makes it much easier.
So instead of wasting time, Nix and NixOS is an investment. You may choose to invest your time right now to save later or not. Either way is fine.
Just to finish the topic, I fully concur yo you that we as a community needs to have better documentation.
That's absolutely fair, I don't think either the parent or the NixOS devs implied in any way that it should be the right fit for everyone or 100% of the Linux distro market share is the end goal.
For me, the benefits outweigh the quirks of the language. As my alternatives to manage multiple machines consist of: wonky Bash scripts, similar tooling but bolted-on on top of the distro and with no built-in rollbacks (Ansible, Puppet, etc.), or trying to get everything right manually, Nix does not seem like the worst out of this bunch.
What I'm hearing is "I really don't like the way traditional systems are designed and I don't want to have to learn anything new!"
Nix is different, unapologetically so, that's the issue. And if it had to be more orthodox to win over a few more itinerant users that would make the whole thing pointless.
I'm not asking it to be more 'orthodox', I'm asking to not have to spend months scouring poor documentation to learn a new language and toolchain to gain the very few benefits Nix provides over the existing systems. If Nix is so inherently complicated it cannot deliver that, then why would I want it?
Ultimately I want less complication in my life, not more, and Nix very much does not provide that from what I can see.
Traditional systems have complexity too. Its just not up front.
I like to compare it to fossil fuels and global warming. Traditional systems get one started quick, but eventually build a large fragile system that gets harder to fix/rebuild the longer it goes on.
Nix is different, it forces you to do your work upfront. But once setup, you pretty much can (and to my attestation do) forget it is in place. You do have to learn setting a anything a and everything. But you only do it once. If the house burns down, you don't need to remember what you had. You don't need to remember what to setup in what order. You don't have to find out you forgot something in the middle of something else. In other words, the onus is no longer on you.
That last sentence is incredibly liberating. I stopped worrying having black screens after updates and pretty much stopped having rescue disc, because rescue functionality comes built in the system. It sounds cultish, and it kinda is, but as I said in previous comment on Nix, it is the worst system management tool, except all the others.
Oh, I use Nix because it does provide less complication in my life. It's just necessary to wrap your head around a few core principles first, which can be a little mind-bending when you start out (no fixed /usr locations? huh?)
It is like saying I don’t want spending months to learn git to gain the very few benefits of a version control system. I much prefer to share my code with my coworkers via usb-sticks. Yeah this is less complicated in the short term.
I honestly don't want to learn git precisely because there are version control systems that accomplish the things I need in a much simpler way. I only bother using git at all because some FOSS projects I've worked with use it. Hell, my impression is that most people who use git don't bother really learning it, they just keep a recipe book of how to branch, commit, etc. and then rely on stack overflow to un-fuck the repo after they accidentally blow it up.
I could not agree more. Most people, IMO, are workflow junkies! It doesn't matter how good/bad/ugly the tool is; if it works, it stays forever! And git is a perfect example of a tool that is complex, but survives because it became the gold-standard for FOSS.
Having said that, wouldn't you agree that same recipe-book approach is also true for traditional system configuration/administration?
Yes and for the same reason: people don't want to deal with systems that are overly complex for their needs, and OS configuration (especially in Linux) tends to have a ludicrous amount of needless complexity.
But the thing about Nix is that it just adds even more complexity. As was mentioned elsethread, in order to be effective with Nix you need to understand all the complexities of Nix and Linux. And the thing about Linux is that we have a ton of adequate recipe books out there already.
Complexity exists and is going to get worse with time. The root cause is the prevalent software development paradigm: millions of developers/teams working simultaneously on different parts of the software stack, with an imperfect understanding of an ever-evolving system. "Needless" therefore is a matter of perspective. Reasonable defaults and recipes are a proposed way of dealing with said complexity, but what is reasonable is again based on imperfect understanding, and is therefore only going to work under specific conditions that are not written in code.
Nix offers a way to easily customize and override said "reasonable defaults" across packages written in different programming languages and compiled using a variety of build toolchains. Doing so requires using a common language for expressing defaults and overriding them. IMO, that is not adding complexity, but taming it to make it reasonably easy for individual developers and teams, small and large.
I'd argue that the traditional stack relies on way too many tools, each designed for a limited purpose, and making a LOT of assumptions about the target system. This IMO is far more complex than learning one language and framework.
> But the thing about Nix is that it just adds even more complexity
It absolutely doesn't. I'm someone who is fairly fluent with Nix, and in comparison the complexities of running a non-trivial docker-compose setup gives me nightmares. Luckily I basically never have to worry about that though.
Nix operates at the cusp of some of the most complex and obscure parts of the technology stack: operating systems, compiler toolchains, and package managers. These inherently complex components require a fair bit of commitment to fully comprehend in order to be used well. You can get a lot of mileage skimming through some tutorials to become productive, but to really utilize it to its full potential requires a fair bit of investment. You don't have to be an automotive expert to drive a car, but if you're looking to race, it behooves oneself to invest the time it takes to gain the expertise.
Nix takes a very different approach to system configuration than the traditional ways. Because it treats the entirety of the operating system (bootloader, kernel, user-land, services, account management, etc.) as a single composable unit, it is forced to break some old rules that date back to the oldest days of Unix and are (now) considered to be written in stone. The deviation from the Unix Filesystem Hierarchy is, IMO, required to make systems more composable and maintainable, and is inherently a good thing in the long run. Portable development environments eliminate "works-on-my-laptop" scenarios and ensure everyone on the team is always in sync with each other and CI/CD. Reproducible builds that can be rolled back after a botched deployment are a huge win. And delivering all of these features in a single tool requires breaking some of the old rules, and that is always met with resistance due to the inertia of "it works fine for me".
To be honest, there is no reason why you should give up what works well for you. Having said that, for those that are looking beyond the traditional tools like shell-scripts, Ansible, Chef, Puppet, and others, Nix offers all that is needed to easily build and maintain composable software stacks. Docker comes close to delivering some of the same features as Nix, but comparing the two is a bit like comparing system configuration using shell scripts to Chef/Ansible.
Yes; one does have to learn a new language and its idiosyncrasies. But that is also true of things like Rust. As a seasoned C programmer, I am able to write "good" C code. But that is not a statement about C's ability to scale to larger teams. Rust requires developers to give up their old ways of thinking and "give in" to the Rust-way. The longer you fight the borrow-checker, the more painful it gets. But once you give in, you are able to write code that is safer for use within large teams, thus delivering more momentum in the long run. It is not that it can't be built with C; it requires a communal way of thinking about software complexity that is forged by experience and tempered by camaraderie, and tools like Rust and Nix are excellent supplements.
I do agree with you that the documentation leaves a lot to be desired. I've always considered the FreeBSD Handbook to be the gold-standard for technical documentation and Nix has its work cut out to reach that stage of maturity. But I have full confidence in the Nix community's ability to deliver.
> it is forced to break some old rules that date back to the oldest days of Unix and are (now) considered to be written in stone.
On the other hand, one of Nix's greatest strengths is that in many respects, its innovations are conservative. It brings software building and distribution forward in terms of reproducibility and isolation (like containers do) but (unlike containers) also retains the traditional package management virtues of granularity, efficiency, and sharing common resources (dependencies) when possible.
> I don't want a 'journey' to use my OS. I don't want to learn a whole new language and set of overengineered abstractions to [do development work]
This is pragmatic.
Nix somewhat reminds me of the kinds of mindsets that enjoy learning Vim/Emacs, or learning how to use 40%-sized keyboards like the Planck. -- I think it takes curiosity to be interested in that kindof stuff.
I agree. I love the idea of Nix. At least what I think is the idea - basically Bazel as a package manager. But the actual implementation is inaccessible.
If someone could make a user-friendly implementation of the Nix concept I think it would be very popular.
While there are definitely a lot of remaining documentation and usability issues with Nix as it stands today, the core model is far from 'overengineered' - if anything, it's orders of magnitude less complex than the organically-grown cobbled-together pile of tools and conventions that 'traditional' distros are made out of.
Nix having a well-defined, complete, specified-upfront, coherent model doesn't make it 'overengineered'; it just means that the tools were designed from the start to help you manage the complexity of system management, rather than just kind of leaving it implicit and letting the end user and/or packager deal with the fallout later through an ever-growing collection of workarounds and patches and scripts.
It's completely valid to decide that NixOS is not (yet) for you due to the learning curve that still exists; I frequently warn people away from NixOS (when they are not prepared to deal with that) for this precise reason. But please don't conflate that with 'bad design'.
> [package managers] are already an overengineered and under-delivering solution in my opinion.
This is kinda nuts to me. Every time I use a system that doesn't offer proper package management, it makes me wish I had a decent package manager. What do you think is better than a modern package manager for solving the same problems?
This super interesting to me as I am currently PXE booting Ubuntu which is a pain every two years when I switch the new LTS release. Do you have some pointers or configs to your setup?
There’s a small amount of homelab stuff I need to spend the time porting to nixos. Grafana is in there, for example, but pihole is not. I currently run a weird mix of VMs because of this, and I’d like to make that more homogenous.
I literally just gave NixOS a go day before yesterday. The two things I noticed if you want to use NixOS as just a basic desktop setup was..
1. It is simple and fast to install. People make NixOS feels like black magic. NixOS is easier to install than Arch linux. Just do 3 things. Partition your disk, create the nix configuration file and finally run the command "nixos-install" command. Let me explain with a lil more explanation:
a. Partition your disk with parted or cfdisk and mount it (mentioned in docs https://nixos.org/manual/nixos/stable/).
b. Generate configuration file which has the biggest myth around it. My god, this is dead simple and could install it in 5-10mins after doing it just ONCE (This obviously excludes time needed to reading up about NixOS to be familiar with it, but trust me it is not hard for a first time installer). You literally run the command "sudo nixos-generate-config" and it generates a config file in .nix format and YOU DONT HAVE TO START FROM SCRATCH AT ALL. And you don't need to know nix programming language. It has all the settings needed in the config file and all you have to do is uncomment the necessary stuff. The sound, grub, wifi etc.
c. Then run the command "nixos-install".
THAT IS IT. You can even mention the packages you need to install in config file. You have a functional OS for desktop which can take leverage Nix package manager. AND YES! This includes wifi, grub, sound and everything basic. They all are already in the nix config file you generated. Uncomment the necessary settings and boom!
2. The second point was supposed to be that it is a point release and thus have old packages and hence not a rolling release. This was based on the package search that firefox and some other packages are one version behind even on unstable repo 2 days ago. But just as I typed this, I double checked and Firefox 93 is in stable repo (21.05) and so are some of my other packages. I went back to Arch and was gonna ditch nixos due to this. So this is huge. I probably gonna install NixOS on my laptop now. DO correct me if I am wrong on this please. Because this is the only thing that is stopping me from using NixOS.
> It is simple and fast to install. People make NixOS feels like black magic. NixOS is easier to install than Arch linux. Just do 3 things. Partition your disk, create the nix configuration file and finally run the command "nixos-install" command.
Step 2 is doing a lot of work here. It's pretty 'draw the rest of the fucking owl'.
Using NixOS as a personal desktop for doing development can take a lot of work. You can expect it to take more work than just making the same setup in Arch linux, or whatever.
My experience with Nix is that it's 95% wonderful, 5% very painful. -- Navigating the painful parts of Nix requires understanding what's going on with the Linux parts, with the Nix parts, and with the parts of whatever you're trying to do. (Whereas with other OSs, you can generally get by with copy-pasting from StackOverflow).
Especially given that Nix requires use of a pure functional language, and that there are few tools developers are willing to put effort in to learn, Nix really stands out as unfamiliar.
> My experience with Nix is that it's 95% wonderful, 5% very painful.
This is very true. Having used NixOS as my main OS for 5 or 6 years now, the encouraging thing is that the '95%', the 'happy path' is growing all the time. It'll never be 100%, but more and more people will find that Nix's 95% covers 100% of their own use cases. (This is especially true as Flatpak matures and gains popularity, making it more and more useful as an escape hatch for running oddball software that Nixpkgs contributors haven't had a chance to wrangle yet.)
> Step 2 is doing a lot of work here. It's pretty 'draw the rest of the fucking owl'.
Not really. Most distros aren't fully set up from the moment you complete a base install. Similarly, all you need for a base install of NixOS is to enable (1) a desktop environment, (2) a text editor, (3) a web browser, and (4) probably NetworkManager. In practice, this is a matter of uncommenting three or four lines from the template that nixos-generate-config gives you. Then after the install, you go about making everything comfy, just like with any other distro.
A few packages are effectively rolling even in the stable distribution, because they have a high volume of security fixes and it's a high-impact application. We just don't have the resources to backport all the fixes. This isn't completely unlike debian's treatment of e.g. firefox which keeps even its `oldstable` distribution up to date with "latest" ESR (correct me if I'm wrong).
There are still debates in the community over what the stable distribution is "for", so you may occasionally see some inconsistencies in what gets bumped and what doesn't.
For a daily driver, I'd just use nixos-unstable instead of a specific release to get access to all the up to date packages. It's actually not as unstable as the name might imply. PRs are merged into the master branch of nixpkgs and are only merged into the unstable branch once the updated package is successfully built so it tends to be perfectly OK for daily use.
A lot of updates do get backported to stable branches and you can do it yourself pretty easily if you need an update, so running stable for servers makes sense. But for a desktop I prefer the rolling release, always updated model.
I do not like backported packages. So is unstable directly upstream stable version of packages exactly like Arch? Cos that is what I want.
Cos in Linux distro context, debian or nixos unstable repo just means it is not yet tested for the specific distro. But in fact the packages itself would be latest stable versions from upstreams.
Nix's official package repository, Nixpkgs, is the most up-to-date repository out there[1]. Especially so for the unstable channel. So I assume it would fit your needs well.
But with Nix, you can be more flexible and mix packages from stable and unstable channels very easily. In my case, the kernel and desktop environment comes from the stable channel while the rest comes from unstable.
Unstable (most often than not) is almost an exact copy of the latest branch, which means it has most of it's packages updated to latest version. Given the nature and abstractions of NixOS, unstable ends up being way more stable than most distros, you also get rollbacks for free.
But unstable repo is always a second tier citizen in most distros. This means less eyes on them. This is where Arch excels. Arch just provides packages "as is" or how it was intended by the upstream and the packages are first class citizens. So they get as much as attention as it is gonna get.
The usage of "unstable" itself is from an era where even stable versions broke a lot. This is not the case anymore. And stable repos breaking more than unstable repos in some distros atleast proves it.
Among contributors (and maybe even among the whole community), unstable is probably more popular on NixOS than the stable releases, so if anything it has more eyeballs.
The distinction also matters less on NixOS anyway, since you can (generally) freely mix and match packages from different releases.
Lots of Nix packages are totally unmodified, but many also have to be patched in able to cope with the read-only package store.
On the other hand, NixOS is, like Arch, a distro without any defaults aside from systemd. So Nixpkgs doesn't include patches that try to reshape upstream packages for the sake of some particular vision of the ideal desktop experience or whatever.
Unstable in NixOS is nothing like the horrors that wait in Fedora Rawhide and Debian Sid.
NixOS benefits from the fact that it has unit tests and that all packages are built in a consistent way across all packages.
Archlinux is a bit more stable then NixOS unstable, but not significantly so. But more importantly if you do somehow manage to update to a broken build, it's take less than a second to roll back to exactly where you were before hand.
Is unstable directly upstream stable version of packages exactly like Arch? Cos that is what I want.
Cos in Linux distro context, debian or nixos unstable repo just means it is not yet tested for the specific distro. But in fact the packages itself would be latest stable versions from upstreams.
I did read my reading but it is really blurry and hard to find information on how often the packages gets updated.
I also would like plain upstream versions of software without a distro doing any changes. And with NixOS and Nix, this is perfectly capable of fixing even the remote issues of instability that usually happens with Arch Linux.
Pretty much yes, I also switched from Arch and this works great for me.
I only had issues a couple times with broken packages, then you can either not update at all or remove those packages. It should also be possible to keep the older version of those packages in the nix config but I did not look into it.
Yeah, there are a few ways to do this. See the section on 'Pinning an unstable service' for an example of how to pull in just one package or service from another release:
With flakes I am using the master branch. You cannot get more bleeding edge and there is absolutely no danger. If something does break, I just boot the previous system. So awesome!
I recently made the switch to Guix, which is a distro heavily inspired by NixOS. It even has a Nix service[1] which is easily enabled to get the best of both worlds. Highly recommended!
However, it was designed to be more hackable and easy to inspect, which is facilitated by the fact that it's integrated in a general-purpose language.
As an example, that allows the `guix system` to verify properties before you deploy a system: that the config does not refer to non-existing file systems, that the initrd doesn't lack modules needed to mount the root file system, that there are no references to undefined system services, etc.
Another big difference is that the relation between services in Guix is explicit, as can be seen above. Conversely, a NixOS service can modify anything in the whole system config, which can make it harder for users to understand how the final config came to be.
Side effect (NixOS users will understand): someone writing a Guix service doesn't have to worry about `mkIf` and other contrived constructs, they won't even have to care about fixed points and infinite recursion. :-)
Been using Nix at Transloadit to replace our ubuntu + custom compiled based stack and while there has been a learning curve with friction, it has been so worth it. I sleep better knowing all state follows from our declarative nix files, can be changed and reverted with confidence, and we’ve cut down our build and deploy times 100X because we only ever compile something once now thanks to shared build cache between our devs and CI <3
How does Nix approach managing dot files and other application specific files? When I restore from backup, getting the right packages, flatpaks, services running is only a matter of a simple ansible playbook. Biggest annoyance comes from getting all the apps to feel/act the same as they did before. I've resolved this by having known good rc and other files in an Ansible repo and restoring that way. This works very well, but would be keen in knowing if there are better approaches.
With Home-Manager (HM) you can "bake" your dot files into the config [1]. That means they are stored in your "generation" and then get symlinked to the right directory.
Either you write the dotfile directly in your config (Nix syntax) or you write the file like normal, and then tell HM to store it. I like the second version better, as I find it more natural.
The problem with the "baking" approach is that it is very annoying to do a small change to a config: you have to rebuild the system every time.
Currently, Nix way of handling dotfiles is "home-manager". Personally, I'm not convinced to translate all my random dotfiles to the format acceptable by home-manager because I wouldn't be able to use them in a non-nixos distro or a future home-manager replacement itself.
1. home-manager is perfectly usable on any linux distro, that's in fact how the eventual transition to nixos started for me -- by porting my home config (on ubuntu, at the time) to home-manager. in fact I still keep my os-config and home-config repos separate, so my home config should still on non-nixos if the need arises
2. you don't need to "translate" any existing config files, it's perfectly fine to use them as-is.
I see. So there's a solution for dot files, if a bit too involved. Currently for a low effort approach when backing up something that I know requires a bit of reparse, I use ansible templates, which basically replaces 1 string with another in a file. So far this always worked.
What about application files? I.e. backing-up/restoring firefox. In it's simplest form it's copying ~/.mozilla which I appreciate is no different than copying a dot file. Does nix have a way to restore app artifacts?
Imo Home Manager isn't really about dotfiles. It's a NixOS-like module system for configuration unprivileged programs and services. You could use it, for example, to install and configure systemd user services for Emacs to run as a daemon, and for gpg-agent to run and work as your SSH agent. It lets you bundle specific versions of programs (with patches or configuration changes) in a declarative, reproducible way on non-NixOS Linux distributions, and if you incorporate it into your dotfiles it lets them become more reliable and comprehensive in that way. It also includes features for directly managing dotfiles, but if you're happy with your current dotfiles management system, you can leverage Home Manager to portably configure services without using it for directly managing all your dotfiles.
> Does nix have a way to restore app artifacts?
Not really. The Nix store is read-only, so if your dotfiles are in the Nix store, running applications can't write to them. There's a lot of stuff in ~/.mozilla that Firefox expects to write to during operation. There are aspects of Firefox that you can configure in Nixpkgs, including bundling extensions and setting defaults, but ~/.mozilla is not like ~/.vimrc, so it's not suitable to generation by Nix in the same way.
BTW, there is a Firefox module in Home Manager for those who want a customizable Firefox. Like, I set my custom `about:config` flags there and every time I reinstall my system I am sure that I didn't forget that random config to enable hardware acceleration again. You can also manage extensions with it, but for this part I prefer to use Firefox Sync itself.
At least for me, this is even better than backup/restore. Generally I don't want to preserve cache or cookies between installations, I just want my config there.
> At least for me, this is even better than backup/restore. Generally I don't want to preserve cache or cookies between installations, I just want my config there.
Yeah, I agree. NixOS even includes a module for easily hosting your own Firefox Sync server, too! So I guess in terms of use cases the solution is actually more or less complete.
After hearing "NixOS has many, many packages, you won't be missing much" for a long time and seeing the package search prompt on the NixOS front page, I decided to try it
What are obscure programs few people need or use?
Thinking back about my studies in computational linguistics, Praat and Wavesurfer popped into my mind.
If I were to look at replacing a Linux distro in-place, would it make sense to try doing most of the configuration in a VM?
That is, if I did replicate the more important pieces of my current environment, could I then install NixOS and replicate that state to bare metal with minimum downtime?
How does KDE play with Nix? I recall KDE shits all over the place with all the different cfg files it has. I had trouble trying to store them in my git repo.
Would be awesome to use Nix to bring some sanity to KDE config
I have two experiences with trying KDE, one time with Arch and one time with NixOS. Both times I ended up (trying to) get rid of it again. The Arch experience left me with bunch of trash files and software still installed, my dbus setup is still not the same since then. But with NixOS I simply rolled back to the previous build and everything was fine.
The environment itself worked fine on both OSes, but if you're not sure if you'll like it, trying it on NixOS is way safer than anything else.
Mixed. Some things - like the theme switcher - break constantly because KDE has no awareness of NixOS and its configuration management approach, and indeed its configuration setup seems to change all the time.
The base setup works fine though, I've only had some core functionality break once, and that was after an upgrade to a new NixOS version - the progress display integration thingem for the file manager was broken.
>I want to use NixOS so bad ... But I want to believe
It's an operating system, not a disney movie. Not sure what sort of redemption arc you are waiting for. If you are curious, try it. If not, then don't. What's all this business about believing ?
It is still very good for some things like as a desktop OS, has very good Steam/Proton ecosystem, etc.
Using Arch as a server can be a headache. Just today I updated a Arch VM running postresql. Postgresql needs to previous version present to do the upgrade. I had actually skipped a version (11 to 13) so Arch no longer had version 11 in the repos and old packages had broken dependencies.
I ended up just installing the Nix package manager on the system. I started a shell with Postgres 11 & 12 both present to do one upgrade. Then I used another shell with 12 & 13 to do the final upgrade. It took like 10 minutes vs the hour I had spent trying to rollback packages on Arch.
This is definitely something Nix is very good at, but it's not a problem with Arch. Staying up to date with upstream is basically the point of the distro, so if you're going to postpone an update for a year you should be using something else.
The cost of Arch's KISS philosophy is a system that is uniquely brittle among Linux distros in a number of ways, and Arch users are totally unwilling to admit this except in the form of blaming users for having bad experiences.
I was about to ask the same thing. I think I have more than 10 years and haven't noticed any significant change in Arch, it requires no additional work.
From personal experience, using NixOS saves me a lot of time compared to Debian based distros. The initial setup is painful, but after that you are in complete control. Don't need to update? Don't!
I had desktop sessions running flawlessly for months without any interruptions. Never seen that before on other distros, really.
Whereas I just left Debian-based distros because I'm hitting that exact problem with backported patches not arriving in any reasonable length of time in many packages. There seems to be a real manpower problem over at Debian in terms of maintainers.
I definitely feel like I'm hearing this about debian and it manifests worry, because I sense if we don't consolidate so many parallel oss volunteer based projects soon, we could lose a lot of valuable work to rot and collapse. but who would even undertake that survey and proposal process.
I do wish our line of work would formalize into an international guilds so apprentices help learn to maintain this stuff on their way to becoming "journeymen", somehow.
I started my Nix journey a little over a year ago, and I regret not having switched sooner. A package-manager that also ships an operating system that can be customized from the bootloader up, using a purely functional programming language is the perfect configuration management tool!
It does have some rough edges, and I did lose some hair figuring things out early on, but it has been getting better with each passing day. Pretty much the entirety of my setup at home is now built by Nix and runs NixOS, including my Macbook Air (runs NixOS on ZFS), and two Mac-Minis that PXE-boot a custom NixOS served by a Raspberry Pi 4 running a custom NixOS configuration that also acts as a firewall connecting wirlessly to my ISP's router. The Mac-Minis also double as build machines which makes for a pretty smooth experience when I'm building anything on my work laptop (a 2020 Macbook Pro running Big Sur) that I dock with my CinemaDisplay, which is wired thru an unmanaged switch to the rest.
So far I haven't missed any packages that I could not find in nixpkgs, or customize just the way I wanted to. The community is pretty responsive and quick to merge any pull requests for fixes/upgrades. I would whole-heartedly recommend switching to Nix/NixOS/Nixpkgs.