I’ve been curious about NixOS for quite some time. Reading about it I couldn’t see how the config sharing capabilities, setup, or rollabck would be better than Arch and sharing the list of installed packages, using downgrade or chroot.
So I decided to run NixOS in a VM and I’m still confused. An advantage I can see for NixOS is its better use of cores and parallel processing for packages install.
It’s clear that I’m missing something so please help me understand what it is.
Just wait until you mess up something like DNS or delete every text editor and you’ll be grateful for rollbacks.
Can you elaborate? I messed up DNS when I started with Arch and it was easy to recover from that. For text editing, I’m using neovim and can go back with undotree. Of course, if I delete my file and remove it from the trash it’s too late. Can you recover deleting files with NixOS?
That’s not what rollbacks are for.
On NixOS, to change most configs, you need to rebuild.
To rebuild, you need internet.
If you mess up DNS, you need to rebuild to gain internet.
But you need internet to rebuild, so you can’t.
That’s when rollbacks are useful
Got it. So you can rollback without Internet access. I get that point and Arch can also do that with pacman -U. Again I feel like I’m just stupid and am missing something. Like I said I genuinely try to figure out what it is. NixOS would be the only distro I could consider switching to and that’s why I’m currently testing it.
One issue with rollbacks Arch has is that there’s basically only up to three valid configurations available at any time. These are your current system configuration (oldest state), upstream repositories (newest) and your local database copy (somewhere in-between, though all three states can be identical, e.g. straight after Syuing). By definition, you can’t convert your system configuration back to an older one because it’s the oldest one of the three already. What you can do is mix your current oldest configuration with packages from the cache, older or newer doesn’t actually matter. But you’re not getting back the old state really, you’re creating a new one that’s different from Arch’s repository.
A configuration on NixOS includes all exact package versions and their exact configurations. No exceptions.
If you actually need these guarantees is a different question. I used Arch for 15 years and never had significant issues. I switched to NixOS instantly after trying it on an old notebook and immediately recognized that the whole approach suits me so much better that I switched almost all machines over by now.
Very nice explanation. I also recognize this point for NixOS.After reading so many comments, they all confirm what I’ve read before and I may realize that my real problem is already having a stable system which means not being in need for some “advanced” recovery options. That being said, I’m still curious and will continue testing NixOS.
Not that I really have too much spare time but when I do I enjoy learning and tweaking NixOS. With its current development state, things are changing a lot so it can keep me busy for months. That’s probably what I was mostly looking for: another toy to play with. Will see if I actually switch to NixOS at some point. Thanks again for your feedback.
They do very different things even if the outcome is the same. You are not rollingback your system by downgrading each package. You are statefully changing your filesystem. Rollbacks in Nix and Guix are internet free, atomic and reproducible because they amount to changing the target of a single symlink
For me it’s the fact that I have one source of truth for my whole system config that I can stick in git
If I want to clean up software I don’t need anymore I just remove them from the package list and they’re gone next rebuild
Also means when I reinstall or setup a new system I just run the installer, do a git pull, rebuild and I’ve instantly got all my tools, configured just how I like them
Also, if I want to make a big change I can build my system in a VM first to make sure it works first (not that I do that because it also lets me revert to an earlier build from grub if I need to)
I’ve also got both my laptop and my PC on basically identical configurations from the same git repo with each of them having a smaller config file for hardware specific stuff
If I didn’t already have my relevant configurations tracked in git and my (quite simple) post-install script to copy the configs to relevant dirs, I guess I’d use Nix. I don’t see the appeal when I have the same functionality on a distro I am familiar with.
Which distro are you using and how are you tracking your configs in git? A bare git repo with a worktree set?
Arch. My home directory is a git directory that ignores all by default then I enable what I want to keep.
Are system services configured in the home directory in arch? 😮
Better in some ways, but it has the worst documentation of any distro I’ve seen so far. https://nixlang.wiki is trying to improve that
How to read NixOS documentation:
- Go to wiki, see if topic exists
- If it does, notice how it doesn’t cover your case
- Use the hints from the wiki to get your search engine redirect you to https://ryantm.github.io/nixpkgs/
- Notice it still doesn’t cover your use case
- Use search engine again, this time with the hints from aforementioned page, to arrive in the proper code in the nixpkgs repository
- Read annotated source code to see what actually happens
Yeah, this is how I found https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/setup-hooks/make-wrapper.sh yesterday because I wanted to install some shell scripts that needed to be adapted.
Don’t get me wrong, maintaining a distribution the way NixOS is a huge effort and I can’t praise the maintainers and developers enough. The ecosystem they’ve built is unlike I’ve seen anywhere, and the technical foundation is sound – in fact I’d wager more sound than what commercial distributions offer. The latter just have more grease. But I do understand the criticism about lacking documentation. But human labor is scarce, and I mean look at me posting this here instead of improving it.
There’s also no good guidance or best practices for packages in nixpkgs and stuff is permanently changing (which in my opinion is good). E.g. did you know that new derivations should be sorted by letters, not categories, and not go into
all-packages.nix? At least if your derivation doesn’t require fancy attributes (pardon me if that is not the correct term). Or thatstdenv.mkDerivation rec {…}is not best practice, but ratherstdenv.mkDerivation (finalAttrs: {…})? And why the latter even works?Writing good documentation for a system, especially one that’s permanently evolving, is not easy, and I prefer all efforts going to actually maintaining and evolving the system itself than trying to get the perfect documentation that’s outdated in a matter of time. And without trying to gatekeep it, NixOS is a distribution for advanced users. I recommend it to everyone who has a solid understanding of how a Linux system is composed because I think it’s important what NixOS abstracts away from you. And as an advanced user, reading commented code once in a while is fine in my opinion.
The problems with nix/nixos documentation are:
- documentation isn’t sexy so not many want to do it
- documentation is difficult to be written by beginners because… they’re beginners
- nix/nixos maintainers undervalue documentation efforts - I’ve tried to get in pull requests, but they just stall (not reviewed, nitpicked to death, simply not merged, etc.)
- it isn’t generated from source code
Also, the very top heavy decision making process harms the community. Some person with hundreds of commits can push through nearly any change (good or bad) relatively quickly, unless other frequent contributors are really really against it. However, fresher contributor with a great change is forced to go through a never-ending process and few stay to actually finalize it.
Pushing tomasterwas not seldom for a long time and IINM it isn’t possible anymore. But maintainers can simply (and do) create a PR, make a change and merge it.These difficulties just make me want to fork nixos. For documentation, at least there’s https://nixlang.wiki
Good points. If you go through the open pull requests on nixpkgs, there’s a lot of stuff that never got through and it’s not obvious as to why. I was happy to see a lot of stuff merged less than a week ago. But at this point, there’s a huge backlog.
As to forking NixOS, which in my opinion means forking Nixpkgs, Guix system seems like a good start. I decided for NixOS because of proprietary packages as I use Steam, and support for secure boot which while still young and only through lanzaboote works very well for what I use it.
Guix system seems like a good start
I’m glad they exist. It shows that the concepts can be successful using another language. To me, the major downside is exactly what you said: no proprietary stuff. Additionally, it’s LISP.
In a fork, I’d try to change the way decisions are made, which software is used, add linting and autoformatting to repositories, move away from github (maybe by the time I find the time to we’ll have federated sourceforges) and github actions, maybe use nickel or haskell instead of nix, generate documentation from sourcecode, try and use a distributed cache (tahoelafs, ipfs, storj or some other distributed/decentralised file storage), etc. Getting any of that done in the current repos seems like an uphill battle.Let us know when you do! It’s a huge undertaking and NixOS has a pretty big network effect. Doesn’t mean no one should tackle creating an alternative. I fully believe declarative distros are the future for any production environment and that the space is far from taken by current distributions.
documentation isn’t sexy so not many want to do it
Don’t think that’s the primary issue. Most of us can appreciate good documentation.
It’s more of a resource problem. We could either be writing docs or working on literally everything else. Docs are important but so are updates, fixes and new packages/modules/etc. Most of us contribute in our free time and would rather spend that little time on ensuring that the distribution works.
nix/nixos maintainers undervalue documentation efforts - I’ve tried to get in pull requests, but they just stall (not reviewed, nitpicked to death, simply not merged, etc.)
Not at all. It’s, again, a resource distribution problem. That happens to many, many PRs, regardless of what they actually do. We have a rather severe shortage of reviewer time.
Nitpicks can be annoying but the people do it because they actually do care; quite a lot.
it isn’t generated from source code
It… is?
https://nixos.org/manual/nixos/stable/options (warning: humongous page, may crash your browser)
very top heavy decision making process harms the community.
What kind of decisions are we talking about? The RFC process is the exact opposite of “top heavy”.
Some person with hundreds of commits can push through nearly any change (good or bad) relatively quickly, unless other frequent contributors are really really against it.
No. Someone recently got their commit access revoked for self-merging something that was really not good. We care about quality.
However, fresher contributor with a great change is forced to go through a never-ending process and few stay to actually finalize it.
Yup, that happens. We don’t have enough time to give newcomers a really good experience.
Though if I’m honest, a fresh contributor should rather get more of a feel for the processes and conventions for a bit before trying to implement a “great change” (as in: size and complexity) anyways. That massively reduces the need to go back and forth over obvious mistakes a more experienced contributor would simply not have made.
maintainers can simply (and do) create a PR, make a change and merge it.
And it’s frowned upon. Especially if that touches something someone else maintains and no reasonable response time was given.
Again, someone recently had their commit access removed for doing exactly that. We don’t like this either and this issue is slowly but surely getting better now.
These difficulties just make me want to fork nixos.
That won’t help anyone.
We have a rather severe shortage of reviewer time.
That’s probably true, but the number of reviewers is very limited as well. Most people in the nixos org have no merge rights. Someone who creates package ABC and has it merged, is not able to merge changes onto package ABC without the stamp of approval from one of the few people with merge rights --> a small, select group of people are saddled with the final decision.
The community could do with more people with merge rights or something like The Collective Code Construction Contract (C4).
Nitpicks can be annoying but the people do it because they actually do care; quite a lot.
Most of the nitpicks could be resolved by a linter and auto-formatter. It’s also quite annoying when a review is just a bunch of character modifications, renames, replacement of entire sections with no comment whatsoever. Or when knowledge is implied. “use
mkDerivation (final: ...)” or “usepathinstead of./.” like… OK, what does that even mean? Why isn’tmkDerivation {}or./.OK and if there is a new standard/convention, why isn’t it mentioned somewhere that’s hard to miss like the the PR template, or linter or build output? Having it on nix.dev as a suggestion, is not the way to do it.What’s even worse is when you get one review like the above, change it, then get another review that again changes something according to undocumented convention, you change it, and another reviewer comes along with yet another such review. I don’t contribute to
nixpkgsanymore, in part, for that reason.It… is?
The options and lib do it, but why not the rest? What about stdenv? What about fetchers? build-support?
very top heavy decision making process harms the community.
What kind of decisions are we talking about?
How easy or hard is it to get a repo in the nix-community org? Who is allowed to make large changes to nixpkgs e.g review process, CI/CD, package naming, etc? There have been discussions in the community forum about adding linters and
nix-fmtbut no big-wig ever gave it the go-ahead, so it never happened.How was the official wiki nixxed anyway? Was that an RFC?
The RFC process is the exact opposite of “top heavy”.
When RFCs can simply be closed as “won’t resolve” or whatever the euphemism is for “no, not on my watch” without community consensus, then I’m not sure what else to call it.
Though if I’m honest, a fresh contributor should rather get more of a feel for the processes and conventions for a bit before trying to implement a “great change” (as in: size and complexity) anyways
I agree. Large and complex changes from newbies are difficult to integrate. But there are QOL changes from newcomers I’ve seen that (again) were just stalled or nitpicked to death. There have also been packages requested by a few people, a PR from a newcomer attached and it just never crossing the finish line. A reviewer left a comment, the PR creator made a change and asked if it was fine now, only to hear crickets.
These difficulties just make me want to fork nixos.
That won’t help anyone.
I disagree. If the OG nix community won’t change (or won’t do it quickly enough), then that’s the beauty of opensource: the project can be forked.
A great example of the tar-like movement of the OG nix community (or the maintainers? dunno) is the wiki. A member finally had enough and just started another one (https://nixlang.wiki/), which IMO already looks and feels much better than unofficial yet officially linked to nixos.wiki. That wiki seems to have come from the official wiki being killed, but then a need for a wiki arising and a nix community member taking it upon themselves to create it as the (for lack of better term) nix top dogs for whatever reason didn’t recreate it.
I have sympathy for the long-time contributors (maintainers? although that seems to have another connotation in the nix community) to nix, nixpkgs, nixos, etc. There are a lot of moving parts, input, feedback, opinions, PRs, issues, and whatnot, but as a newcomer, there seems to be a resistance to change or at least an inability to take advantage of the good will and energy of the community.
The community could do with more people with merge rights or something like The Collective Code Construction Contract (C4).
That is nicely written but we have mostly already implemented that. There’s some critical things like
A new Contributor who makes a correct patch SHALL be invited to become a Maintainer.
which we will not implement as commit access to Nixpkgs is security-critical. Anyone with commit access can push malware to thousands of users. We’re doing good here not handing that out to anyone who contributes a patch.
Most of the nitpicks could be resolved by a linter and auto-formatter.
https://github.com/NixOS/rfcs/pull/166
It’s also quite annoying when a review is just a bunch of character modifications, renames, replacement of entire sections with no comment whatsoever. Or when knowledge is implied.
As a reviewer, you cannot know the reviewee’s experience level. Simply ask and/or Google if you don’t know something. We don’t explain every little thing in detail that we comment on every 5 PRs. Nobody has time for that.
Why isn’t
mkDerivation {}or./.OKI don’t know the context of the latter but the former is absolutely okay. It’s just a matter of taste really and reviewers are free to express theirs.
Having it on nix.dev as a suggestion, is not the way to do it.
Why? That’s official docs.
What’s even worse is when you get one review like the above, change it, then get another review that again changes something according to undocumented convention, you change it, and another reviewer comes along with yet another such review. I don’t contribute to
nixpkgsanymore, in part, for that reason.That happens sometimes. I’m guilty of that too to a degree. If all you receive are such nitpicks, it’s a good sign that the other aspects of your PR are good to go.
Also note that this isn’t uniform among committers. Most don’t care about nits very much unless you’re doing something clearly out of the ordinary.
Two of the most notorious committers who did this have gotten their wrists slapped recently btw.
why not the rest? What about stdenv? What about fetchers? build-support?
I don’t know how you imagine that to work? There is no generic way to document bespoke code (LLMs don’t count).
How easy or hard is it to get a repo in the nix-community org?
I don’t have much experience with that but the one time I did that I simply walked up to one of the nix-community admins at NixCon and asked them to. I imagine it works roughly the same without being in-person.
Who is allowed to make large changes to nixpkgs e.g review process, CI/CD, package naming, etc?
Anyone.
Small obvious improvements with little to no downsides or room for opinion can just be done and everyone will thank you.
For “larger” improvements with more room for controversy, you must go through the RFC process. See for instance https://github.com/NixOS/rfcs/pull/140
How was the official wiki nixxed anyway? Was that an RFC?
I don’t believe there ever was an official wiki? If so, that must have been ages ago.
The inofficial one is still up FWIW https://nixos.wiki/.
Edit: Looked it up and there was an official wiki at some point it was scrapped because it’s better to have the documentation in the Nixpkgs tree together with the code. In a sense, it still exists in the form of the official manual.
When RFCs can simply be closed as “won’t resolve” or whatever the euphemism is for “no, not on my watch” without community consensus, then I’m not sure what else to call it.
Not sure which one you’re referring to.
There have also been packages requested by a few people, a PR from a newcomer attached and it just never crossing the finish line. A reviewer left a comment, the PR creator made a change and asked if it was fine now, only to hear crickets.
Most of the issues you see can be traced back to limited reviewer capacity.
If the OG nix community won’t change (or won’t do it quickly enough), then that’s the beauty of opensource: the project can be forked.
Forking a project is a click of a button but that still won’t solve anything. All problems mentioned here are problems of the community around the project which we sadly haven’t found a way to clone yet. You’d have a project that is dead in the water because maintaining Nixpkgs is an insane amount of work that requires at least a community as large as the one around Nixpkgs.
tar-like movement of the OG nix community (or the maintainers? dunno)
Note that you’re talking about an entirely different set of people here than the rest of the post.
A member finally had enough and just started another one (https://nixlang.wiki/), which IMO already looks and feels much better than unofficial yet officially linked to nixos.wiki
The main difference is that it runs different (IMHO better) wiki software; wikijs instead of a weird mediawiki fork.
It’s great that they set it up separately but I’d fully expect it to become the regular nixos.wiki at some point with most of the content copied over. I don’t think anyone wants to keep maintaining the old one’s technical aspects now that this exists.
That wiki seems to have come from the official wiki being killed, but then a need for a wiki arising and a nix community member taking it upon themselves to create it
No, it’s because nobody is really maintaining the technical aspect of the current unofficial wiki. The reason they went ahed and set up a new wiki is that it’s easier to start from scratch on a new domain than migrating the old wiki in-place; both from a technical and organisational PoV.
as the (for lack of better term) nix top dogs for whatever reason didn’t recreate it.
There is no such thing. I don’t even know who set the wiki up. It’s probably just some person who did it out of passion, just like https://nixlang.wiki/ now.
You seem to be assuming some sort of authority structure where there really is none. For better or for worse, there is no person or group of people who call the shots. That’s not how we work.
Most of the NixOS infra for instance was held together mostly by one person in their free time because nobody else stepped up. They’re in the process of transferring that role to a couple others who did eventually step up as we speak.
It’s similar with a lot of things in the Nix community. The wiki is a good example. The person who set up the new one didn’t want to bother figuring out who in the world maintains the old one and how they could get the new one in place, so they created an entirely new one instead.
there seems to be a resistance to change or at least an inability to take advantage of the good will and energy of the community.
There will always be resistance to change. Not all change is good afterall. In moderation, conservatism is a good thing (actual conservatism that is, not the BS kind in current politics).
I think what you’re feeling is mostly correct but it’s mostly due to lack of time and energy, not because we don’t want to change.
The rate of change also isn’t uniform. Compared to the infra or Nix itself, Nixpkgs changes quite a lot IMHO.
I recognize the username and you’re a long-time contributor IINM. Your responses resemble those of other long-time contributors. I thank you for your contributions, I really do, but it seems that you have been involved for long enough to have learned how to live with certain things and now consider them normal.
My opinions are my own and most likely do not represent those of the majority of newcomers (at least I hope they don’t otherwise you wouldn’t have many), but my experience contributing to nix repos has led to me deciding I won’t try and contribute anymore. You can’t make everyone happy so I might just be a statistic of course.
Good day
I think if you have no answer, it could be that NixOS doesn’t solve any problem for you. In effect, it’s not better. Don’t buy into social media hype. It’s just a tool like any other.
You’re spot on and that’s what this discussion helped me figure out: I have no problem. I knew that but I also thought that NixOS would bring something new to improve my Linux usage. So far I still see such improvements for servers or deployment on several machines but not for a single user with standard needs (and this statement may be wrong and due to my limited experience with NixOS).
But NixOS approach is quite different from others and I feel like I may discover something of interest to me once I learn more about it. Also, just for the sake of learning and discovering, I will continue experimenting with it for a while.
In short, Nix reduces the setup time, both for your system and for your projects. If you find yourself spending a while setting stuff up (for example, after a reinstall; or maybe you want to run your project on another PC and need to install the right dependencies), Nix will help. Otherwise, if your desktop is vanilla Fedora or whatever and you don’t do much programming (or you don’t have any dependency management problems), Nix probably isn’t for you.
I’m currently working on rebuilding a Debian web server that’s been around for 10 years and accrued configuration over that time in NixOS. It’s nice to have one single easy to understand file that fully defines the server and can be used to rebuild it if needed.
I can see that from a server maintenance point of view. After having read so many great things about NixOS, I may have exaggerated my expectation and I may be the problem for being a user with too limited needs to get the full benefits of NixOS.
For me this single config file doesn’t save that much additional files and most of them would be files you configure only once during installation. Nonetheless I can see how “easier” it would be to save one file instead of 3 to reproduce your system and I can only imagine how much better it is from a server point of view.
The appeal of it, to me, is the same as why Docker containers are really good. You write your definition, save it to git, for example, and if you ever need to setup your computer from scratch, if you restore that config, it’ll setup your computer exactly like it was before. But even besides that, being able to roll back if something goes wrong, is a big plus
That’s what I keep reading and why I would like to give it a try. For now I’m still confused how this is easier/more efficient than sharing your list of packages, restoring a backup, or using downgrade in Arch. I’m really interested because I like to try new stuff, especially if they bring something of interest.
I really have hard time to see the difference for now after my first setup in a VM but also because imaging my full Arch system on a new machine 2 years ago only took me an hour and less than 10 command lines.
Again, I’m genuinely trying to understand what I’m missing. From my reading NixOS seems to be the only distro I could switch to.
Because your Nix config also configures your software, not just installs it. Admittedly, with base NixOS that’s more true with server software than desktop. But with the addition of home manager you can also configure many desktop apps in your Nix config.
You’ll understand when you’re older, son
Or maybe I’m already too old for so much tech.
NixOS puts your full system configuration in a portable set of files. You can easily reproduce the same configuration on another machine. I also like that instead of accumulating a growing list of packages that I don’t remember why I installed I have package lists specified in files with comments, and split into modules that I can enable or disable.
IMO NixOS works best when you also use Home Manager to apply the same benefits to your user app configurations and such. (OTOH you can use Home Manager to get those benefits without NixOS. But I like that I get consistency between the OS-level and user-level configurations, and that both use the same set of packages.) I use Home Manager to manage my list of installed packages, my dot files, Gnome settings, Firefox
about:configsettings, and so on.You might be installing packages imperatively with
nix profile installor withnix env -i. If that’s the case you’re not going to see the full benefits of a declarative system in my opinion. I prefer to install packages by editing my Home Manager configuration and runninghome-manager switch.I like that NixOS + Home Manager automates stuff that I used to do by hand. A couple of the things that I do or have done are to,
- test an experimental window manager, Niri
- use Neovide (a GUI frontend for Neovim) with a custom patch to tweak font rendering
Now I have that kind of stuff automated:
- Since there was no packaging for Niri when I started trying it I wrote my own in my NixOS config with a NixOS module to set up a systemd unit to run it. Because Nix packages are effectively build scripts, whenever I update Nix automatically pulls the latest version of Niri and compiles it without me having to think about it anymore.
- I use the Neovide package from nixpkgs with an override to compile with my custom patch. Like with Niri my configuration automatically gets the latest Neovide version and builds it with my patch when I update, and I don’t have to think about it anymore. I use this overlay to do that:
modifications = final: prev: { neovide = final.neovide.overrideAttrs (oldAttrs: { patches = (oldAttrs.patches or [ ]) ++ [ ./neovide-font-customization.patch ]; }); };You can see that I compile some things from source. That’s fine on my desktop, but takes a while on my travel laptop. But I don’t need to compile on my laptop because I can use Nix’s binary cache feature. I push my NixOS and Home Manager configurations to Github, and I have Garnix build everything that I push. Garnix stores everything it builds in a binary cache. So when I pull my latest configuration version on my laptop it downloads binaries from that cache.
So, it’s like this. Your operating system is an environment. It has it’s paths, it’s got it’s file system. In many ways said system can have plenty of conflicts and issues regarding dependencies, runtime and permissions, even cruft that it will accrue over the years even.
This is where nix comes in. Nix creates sterile, reproducible environments. With flakes, the reproducibility is 1:1. It can also manage several environments, all isolated from each other.
Not only that, but technically speaking, nix can build anything, as it’s a build system of build systems. You don’t have to rely on nixpkgs or NixOS. You still get the environmental magic, along with whatever nix evaluations you put into it, so you could make your own nixpkgs (or recipes, really).
Personaly I want to go deeper, so I was thinking of how I could beat make my own package set by getting all the SRPM’s of say RockyLinux to create rockypkgs, which is just the Rocky Linux selection of packages and patches built into nix environments.
Maybe you could then also have ubupkgs, fedpkgs, rhelpkgs… mix and match packages lol Yeah, it really is that insane.
Imho Nix has not reached it’s potential yet because of some stuff that needs to be fixed, but restructuring and refactoring is underway. Nix as a command will become more streamlined and central for ease of use, and nixpkgs needs a bit of recajiggering to get the package layering just right - or so I’ve heard (find us, in the Matrix chats).
What is good about NixOS (and GuixOS) is that they apply to package management the same principles that Git applies to managing source code. The Nix store is basically an append-only database (you might even call it a “blockchain”) of inter-dependent packages.
So from an individual computer user’s point of view, it is much safer to install and roll-back software with Nix than with an ordinary package manager that might allow you to accidentally delete package dependencies and break your system. With Nix, you can install packages that actually do break your system, but because of the append-only nature, you can actually roll-back the install automatically right from the Grub boot menu, no need to re-install anything.
Another advantage of NixOS, though this is more from a system operator’s point of view, is that you can guarantee reproducible builds. If the package you have installed has the same hash on all of your computers, that is a simple, human-verifiable proof that all of those systems are running the exact same build of the software. You can probably see that this is very useful for people running servers, like compute clusters, or doing things like A-B testing.
(don’t know if arch supports this natively now but) declarative package managment is why j started using it… having ansible/terraform basically be a part of the os is great for me because a reinstall of the current running system just means i copy my configuration.nix and i’m back to where i was but fresh…
another thing is build isolation (you can have clashing dependencies without issues because each package specifically links to the dependencies it needs)… it does kind of bloat the disk a bit, but it also shares dependencies of the same version across packages so it’s not like flatpack (if i understand that correctly)
for me personally I like to be able to install software temporarily using
nix-shellcommand it’s awesome. the installed program will be gone once you leave the nix-shell. It’s just awesome for me.Don’t forget to run
nix-collect-garbagetho. The program is actually still installed, the symlimk to $PATH is just deleted after exiting the nix-shellThat’s indeed pretty neat.
I agree, but you don’t need nixos if that’s all you want since you can get nix-shell on most linux distros
