One Week of NixOS
jae.moe
jae.moe
Main reason for leaving was that Nix package maintainers have to heavily patch all software. Packaging for nix is more like porting software to another operating system. Just check the amount of ad-hoc patches in nix-packages repo, and note that they have automated tools for patching the most common problems, so the problem is even worse. Now how about quality of these patches... I was able to merge some pretty large patches to nix-packages from an anonymous and sketchy-looking github account, and they weren't scrutinized much, because the original author of the derivations abandoned them.
Moreover, Nix breaks the chain of trust for the language packages. For example, Erlang and Elixir packages are signed cryptographically. Most erlang libraries come with a rebar.lock file containing hashes of the dependencies, so reproducible builds are already ensured. Unfortunately, package hashes are incompatible with Nix derivation SHA's, because they include some additional envelope data. What did Nix people do to work around this problem? They patched out the checks for rebar.lock files from the 3rd party Erlang build system. I would not dare to run a distro that contains patches like this in any kind of production environment.
Additionally, /nix directory is readable by all users, so you cannot use Nix to manage secrets, and there was no universally approved way of doing so (or at least it was the case at the time I was using it).
As for personal use... You cannot install opam packages without dealing with incompatiblities, you cannot easily install games from Gog without dealing with incompatibilities, and to be honest, do you really need such degree of reproducibility for your very own dev machine?
The issue of integrating with other language ecosystems is indeed very problematic (and it's a very hard problem), especially with regards to the chain of trust (by the way, it's not completely broken, you can still read the original package hash in the derivation, and evaluate this derivation to get the Nix derivation hash), and with regards to the fact that including all of the packages of every ecosystem in `nixpkgs` is not doable.
There is also the (related) problem that evaluating a configuration implies evaluating `nixpkgs` itself, which requires a good amount of available memory, and this can only get worse as `nixpkgs` grows.
Someone could certainly submit a PR to the nixpkgs repo that purports to do that but really modifies the generated Nix expressions to refer to different sources, but this would be discovered by anyone who re-runs the package update process.
Another annoying thing is that NixPkgs has developed some technical debt, with some packages being perennially broken. Guix is smaller, but much cleaner in this regard. Julia can't be used in Nix, and many Bioconductor packages are broken.
However, I feel like the existence of FHSUserenvs needs to be better advertised and documented. These give you the ability to easily install unpatched software that assumes a regular (FHS) Unix filesystem layout (/bin, /lib...).
Still, I think the benefits of using Nix and NixOS surpass the drawbacks right now. I use Nix in dozens of machines. It is, along with Arch, my favorite distribution. Both sit at two local maxima of the design space. Declarative-functional and imperative with a minimal layer of tooling.
I just miss using the same tooling as everyone else in my team without issues or having to constnatly spawn up a new nixenv everytime I change folders. Maybe using FHSuserenvs will help?
I've never really been able to grasp the language, I don't care what anyone says, the documentation is terrible. Every time I try build a package it always takes me days to workout how to do it.
Really feeling that while, yeah, it's nice to have everything in one configuration file, it's good, but when something breaks, I have really no idea how to fix it.
The fact that Nix ditches FHS is so what's appealing about it unfortunately there's a huge body of work that assumes it.
Most of the patches though are making libraries or binaries fully referenced from nix store rather than from the PATH or some other implicit state.
It's not. As far as I can tell, it's used heavily in some corporate environments once you're faced with solving the development environment dependency hell and you need something that actually solves your problem. (This is my story too.)
> ...and now I manage my personal machines with a simple Ansible playbook
Where Nix is used you typically don't have "personal machines". And having a separate guy just doing setups of developer environments is a huge overhead.
With ansible, I feel like everything is poorly solved and you need to weigh decisions about when to use various hashicorp products. Worse still if you use their plugins instead of just script substitutions you get stupid behavior like not being able to fix your configuration because it is broken, or turning off the supposed advantage of these plugins such that they are almost as good as sed again.
But I do agree we need to deal with the language-based packaging situation much better. It's a long-standing project of mine to fix that.
Speaking of half-assed kludges, NixOS itself is a held together by duct tape of scripts patching shebangs and whatnot.
The deployed system is very easy to reason about, which I greatly appreciate with my laptop and production environments.
(In addition to trying to support the language-based ecosystems better, I also want to reduce the things we do in bash. I think those are complimentary goals, too.)
Oh ffs really? Yeah, that's the kind of hijinks that leave you scratching your head. Thanks for the head's up.
I'll admit (although it annoys me) that I couldn't follow what was going on there. Nix x Erlang's gnarly build system seems like complexity junkie crack to me, but then I'm getting older.
It's actually fine, thanks for a remark.
...a different hash.
You see, I naively think that a checksums should not be overwritten when they doesn't match.
Yes, really. This PR partially reverted this behavior (or rather made it less intrusive): https://github.com/NixOS/nixpkgs/pull/54115/files , but from there you can easily track "rebar3 hermecity patch", which had introduced it.
If you're curious about Nix, I highly recommend you give it a try. nixpkgs have great quantities of packages that matches Arch/AUR, and every single one of them goes through mandatory reviews ensuring quality. On top of that, the Nix tooling makes it easy to create your own packages and reuse existing package definitions. So for example, if you want to use a fork of a software available in Nix and maybe even add some custom patches, all you need to do is write a few lines in your config. Switching to Nix was a really refreshing experience and the amount of documentation and the code in the nixpkgs repository was very helpful for me to get started.
Most software actually doesn't assume the FHS. (Autoconf, Meson, and CMake all don't, for example.)
Any widely used distros do this. Plus, the statement that you have to patch all packages is false. In many cases, all you have to do is set the right build flags and environment variables, which is handled by standard helpers in nixpkgs.
I'd also like to add that nixpkgs has the most extensive testing for packages compared to any other distros I've seen.
> Packaging for nix is more like porting software to another operating system.
Dramatic, but again, simply not the case.
> note that they have automated tools for patching the most common problems, so the problem is even worse.
This is a good thing. Manual patching for the most common problems isn't sustainable, especially if you maintain a large number of packages. Just ask packages maintainers of any major distros.
> I was able to merge some pretty large patches to nix-packages from an anonymous and sketchy-looking github account, and they weren't scrutinized much
All packages in nixpkgs has a mandatory review process as you should very well know. As scary as you make it sound, I'm pretty sure at least one committer have taken a look at your code to see if there was anything malicious in it.
> Moreover, Nix breaks the chain of trust for the language packages.
After a quick look, it seems like you can still use the unmodified erlang package manager? The patched version you've mentioned seems to be there for facilitating creation of Nix packages and it looks like the main intent was to remove the ability to download packages from the internet. If this is the case, it wouldn't be a security problem at all because the dependencies would have to be prefetched and their hashes precomputed.
> /nix directory is readable by all users, so you cannot use Nix to manage secrets
Why not store secrets in a private location, just like you would on any other distros??? What is it that other distros have that Nix is missing? I'm not seeing your point here.
With that being said, note that this feature is being worked on, and systemd very recently introduced a new feature for secrets management [1].
> You cannot install opam packages without dealing with incompatiblities, you cannot easily install games from Gog without dealing with incompatibilities
Matbe take a look at buildFHSEnv.
> do you really need such degree of reproducibility for your very own dev machine?
Yes, it saves me from having to do a clean install of my system every few months. I haven't done a clean install at all the last few years since I started using NixOS.
[1]: https://github.com/NixOS/rfcs/pull/59#issuecomment-624723733
I've yet to encounter another distro that deliberately breaks 3rd party software the way Nix did it to rebar3 (before it was reverted).
> Plus, the statement that you have to patch all packages is false.
IIRC `patchShebangs' script runs for any package using stdenv.
> I'd also like to add that nixpkgs has the most extensive testing for packages compared to any other distros I've seen.
Which distros? Can you share a comparison in number of tests/coverage?
> Dramatic, but again, simply not the case.
As other commenters mentioned, software written for GNU\Linux often assumes FHS. NixOS breaks FHS, and has to patch soft to work around that.
> This is a good thing.
How so?
> This is a good thing. Manual patching for the most common problems isn't sustainable, especially if you maintain a large number of packages. Just ask packages maintainers of any major distros.
Other major distros don't break FHS, therefore they don't need to patch trivial things like shebangs.
> All packages in nixpkgs has a mandatory review process as you should very well know. As scary as you make it sound, I'm pretty sure at least one committer have taken a look at your code to see if there was anything malicious in it.
It depends on your threat model. Mine is stricter.
> If this is the case, it wouldn't be a security problem at all because the dependencies would have to be prefetched and their hashes precomputed.
Once again, it breaks the cryptographic chain of custody set by the upstream. In my threat model that's not acceptable. I tend to trust the upstream more than the distro.
> Why not store secrets in a private location, just like you would on any other distros???
Secret provisioning is by far the most difficult DevOps problem, and it can go catastrophically wrong for all too many reasons. Nix not only doesn't help, but also introduces additional footguns with world-readable configuration files.
> What is it that other distros have that Nix is missing?
Other distros have FHS. FHS accounts for secret management, among other things.
> Yes, it saves me from having to do a clean install of my system every few months.
Ok, though I never had to do a clean install of GNU\Linux either on my dev machine.
Except that your anecdote is completely misleading given that the patched version was intended for creating Nix packages. You could've just used the unmodified version instead.
Furthermore, upstream developers complain about how distros are breaking their software all[1] the[2] time[3]. Again not a Nix specific problem. Nix even alleviates some of the problems because you can use different versions of the same software, meaning that different packages don't have to share dependencies as aggressively as other distros do.
> Which distros? Can you share a comparison in number of tests/coverage?
Arch, Debian, CentOS, and Homebrew, though the last one isn't strictly a Linux distro. I can't possibly count the numbers given that the sheer number of packages available, so it's based on experiences at looking at package definitions. I tend to check package definitions across distros a lot to write packages fir Nix.
> It depends on your threat model. Mine is stricter.
If you have a problem with software projects accepting outside contributions even if they go through review, you have a problem with using free and open source software in general. It makes me wonder how you even manage to use the Linux kernel.
> Once again, it breaks the cryptographic chain of custody set by the upstream. In my threat model that's not acceptable.
Then use the unmodified rebar3 for your project instead. But anyways, if your threat model involves not trusting SHA256, you likely have a problem with your said cryptographic chain of custody too.
> Nix not only doesn't help, but also introduces additional footguns with world-readable configuration files.
> FHS accounts for secret management, among other things.
That's an outright lie. NixOS doesn't prevent you from storing secrets in a file and applying your usual UNIX permissions. FHS has absolutely nothing to do with it.
[1]: https://github.com/pypa/pip/issues/5599 [2]: https://web.archive.org/web/20181021091049/https://github.co... [3]: https://twitter.com/videolan/status/1153963312981389312
The package was called rebar3, not rebar3-nix or something. If the fork was called differently then no one would complain. Also this fork was based on hacks, like patching rebar3's internal files and messing with caches. If you don't see anything wrong about this, then this way of thinking just proves what I said in the parent.
But forking rebar3 wasn't needed at all, because rebar3 _already_ had all the features needed for Nix. Namely, it has get-deps command producing fixed output derivation, and it supports _checkouts directory, needed for hermetic build.
> Then use the unmodified rebar3 for your project instead. But anyways, if your threat model involves not trusting SHA256, you likely have a problem with your said cryptographic chain of custody too.
There's no reason to use SHA256, if you just replace it with a different SHA256 whenever it doesn't match with the upstream.
> Nix even alleviates some of the problems because you can use different versions of the same software, meaning that different packages don't have to share dependencies as aggressively as other distros do.
Docker exists. Although it's not perfect by any means, it doesn't require reinventing the entire world. I extrapolated my experience with Erlang to the rest of NixOS reinventions, which in theory could be wrong, but it was convincing enough for me.
> That's an outright lie. NixOS doesn't prevent you from storing secrets in a file and applying your usual UNIX permissions. FHS has absolutely nothing to do with it.
I was not talking about "storing secrets in a file", but rather about the whole live cycle of the secrets, including transferring them between parties, storing, provisioning, rotation, etc (imagine you have to solve a problem of changing some secret on 100 machines securely and reproducibly via blue/green deployment). As far as I know, Nix doesn't provide facilities for solving this problem at scale. I would be happy to be proven wrong.
> FHS has absolutely nothing to do with it.
It absolutely does. Some pieces of software look for secrets in /etc/ (Kafka, for example). When etc (or its analogue in /nix) is world-readable hilarity ensues.
First of all, the fork obviously isn't there for general consumption. You made it sound like unsuspecting users would use it and have unverified code downloaded on their machines, which is borderline false when it doesn't have the ability to download code from online sources. This attempt to mislead is what I'm having problems with.
Second, it would've been nice if you've raised an issue on GitHub and helped improve Nix instead of complaining and spreading borderline falsehoods on HN. Erlang isn't exactly a widely used language, so design choices would be made by the few who actually uses it. It would always help to have more productive input by actual users.
> Also this fork was based on hacks, like patching rebar3's internal files and messing with caches. If you don't see anything wrong about this, then this way of thinking just proves what I said in the parent.
Ranting about how "it's a hack!" based on cherry-picked implementation details isn't convincing at all. The intent here is to have a copy of rebar3 that builds packages from local sources only, for consumption by package maintainers. That's not by any means unreasonable.
> But forking rebar3 wasn't needed at all, because rebar3 _already_ had all the features needed for Nix.
Tell me a single major distro where it's okay to essentially redistribute packages from language-specific package managers without making huge adjustments in the way packaging is handled. I know of none. For countless software, distros just give up on packaging altogether because the effort required to make that adjustment can easily get out of hand. This is the major reason many Maven packages aren't packaged on Debian.
To make matters worse, many packages from languages-specific package managers won't even compile on major traditional FHS compliant distros. Changes to upstream packaging aren't unwarranted, however much you'd prefer to believe otherwise.
> There's no reason to use SHA256, if you just replace it with a different SHA256 whenever it doesn't match with the upstream.
The SHA256 would be verified by package maintainers, reviewers, and the hydra CI instance.
> Docker exists.
If you're against the concept of distro-provided packages, why didn't you say so upfront instead of making baseless accusations about what a horrible security disaster Nix is?
Also let me remind you that almost all Docker container images rely heavily on distro-provided packages. What are you going to do now?
> As far as I know, Nix doesn't provide facilities for solving this problem at scale.
Neither do other distros, though Nix is a close to having a built-in solution as I've just shown you.
> When etc (or its analogue in /nix) is world-readable hilarity ensues.
Why are you repeating this when I just told you it's not true? /etc in Nix is not world-readable, plain and simple. This works perfectly fine on my NixOS system:
$ echo secret | sudo tee -a /etc/secret > /dev/null && sudo chmod 600 /etc/secret
$ cat /etc/secret
cat: /etc/secret: Permission denied
$ sudo cat /etc/secret
secretI didn't know that when I installed a package called "rebar3" and spend some time trying to understand what's wrong with my build. Oh, my bad, should've known better that "rebar3" was for internal consumption, and I need to install "rebar3-open" instead.
> Second, it would've been nice if you've raised an issue on GitHub and helped improve Nix instead of complaining and spreading borderline falsehoods on HN.
Thanks for suggestion. I did exactly that, and I fixed this entire mess. In fact, the current NixOS Erlang infra is partially based on that work.
> Ranting about how "it's a hack!" based on cherry-picked implementation details isn't convincing at all.
I professionally work with Erlang, and I know what is hack and what is not.
> Tell me a single major distro where it's okay to essentially redistribute packages from language-specific package managers without making huge adjustments in the way packaging is handled. I know of none. For countless software, distros just give up on packaging altogether because the effort required to make that adjustment can easily get out of hand.
Language-specific packaging should be left to language-specific package managers, they have more domain knowledge. Nix doesn't solve this dilemma in any better way.
> Also let me remind you that almost all Docker container images rely heavily on distro-provided packages. What are you going to do now?
Keep on using it? Take systems software from the distro-provided packages, add my own stuff on top. Building RPM is a nobrainer. I was considering Nix as an alternative to our deploy process, but realized that it would introduce more problems than solve.
> /etc in Nix is not world-readable, plain and simple.
Please take a closer look at what you're quoting. You missed a very important part:
> (or its analogue in /nix)
You see, if I want to utilize Nix to full extend and use its main "reproducibility" feature, I need to put all my configuration in a derivation. Configuration includes secrets. Derivations are world-readable.
> Neither do other distros
Distros maybe don't, but "bug-ridden kludge that is Ansible" (according to Nix user) does.
If that was your problem, you should've said so instead of spinning it up into an entirely different security problem that plainly did not exist.
> Thanks for suggestion. I did exactly that
Except you didn't stop spreading falsehoods. You've spent more lines using your brand new HN account spreading lies about an open source project people have dedicated their free time into.
> professionally work with Erlang, and I know what is hack and what is not.
Fixating on hyper specific implementation details taken out of context without considering the design, intent, and usage is not what I call professionalism in the software industry.
> Language-specific packaging should be left to language-specific package managers, they have more domain knowledge.
Domain knowledge that fails to build or run portably even on widely used FHS-compliant Linux distros.
> Nix doesn't solve this dilemma in any better way.
I've already explained about the problems distro package maintainer faces and how Nix alleviates some of the problems which you then responded with a totally unrelated "Docker exists" nonsense.
> Take systems software from the distro-provided packages, add my own stuff on top.
So packaging problems won't exist if we just stick with Docker, but you would use distro packages to create a Docker image? How would that even work?
> Building RPM is a nobrainer.
Go tell that to RedHat maintainers.
> Please take a closer look at what you're quoting. You missed a very important part: > > (or its analogue in /nix)
/etc in NixOS is not /nix. It's /etc. Very important indeed.
> You see, if I want to utilize Nix to full extend and use its main "reproducibility" feature, I need to put all my configuration in a derivation. Configuration includes secrets. Derivations are world-readable.
You see, Please. Stop. Repeating. Lies.
You don't put secrets in a world-readable location, period. The typical Nix way of handling secrets is that you store in them in a secure path and point the configuration to that path.
> Distros maybe don't, but "bug-ridden kludge that is Ansible" (according to Nix user) does.
You can use numerous solutions that can work together with Nix. How about NixOps, which, among other things, handles secrets management? Or what about, say, Ansible? After all, any solution that would be able to send the Nix configuration, place secrets in a secure filesystem path, and run commands to build the Nix configuration would suffice.
It was merely an answer to your remark about "this fork wasn't meant for external consumption". Please don't try to substitute the argument.
> Except you didn't stop spreading falsehoods. You've spent more lines lying with your brand new account on HN.
I spent much more time researching this project and trying to figure out the least ugly way to fix its problems. This time was effectively wasted. I just wrote my post so someone who faces issues similar to mine will investigate the matter more carefully.
> Fixating on hyper specific implementation details taken out of context without considering the design, intent, and usage is not what I call professionalism in the software industry.
Ad hominem, moving on.
> So packaging problems won't exist if we just stick with Docker, but you would use distro packages to create a Docker image? How would that even work?
I am not going on to explain how to work with docker, it's a mainstream technology that has plenty of documentation and examples.
> You see, Please. Stop. Repeating. Lies.
https://github.com/NixOS/nix/issues/8
Please don't go ad hominem and don't accuse me of lying. This issue is submitted by Nix devs themselves.
> The typical Nix way of handling secrets is that you store in them in a secure path and point the configuration to that path.
And this is precisely the hack I was talking about. Because of this approach you cannot manage secrets with nix at scale (just to clarify: when I say "nix" I always mean the package manager). This is an issue submitted by core designers.
I think we ran out of productive arguments in this conversation.
Right now, I do manage my Erlang dependencies with Nix only and without using rebar/mix (particularly since I do want full release upgrades with hot code reloading), but manually managing those dependencies certainly doesn't scale well for all projects, especially if they already use rebar/mix.
I also haven't looked into newer projects like nix-elixir[2], but as another commenter here mentioned, there are typically tools available to convert between the language-specific package managers, but they all come with their own set of issues and tradeoffs (eg. duplicating dependency information or importing from other derivations at evaluation time) so they might not be suitable for your project.
The situation with secrets is a long lasting issue[3] with several attempts of solving, but so far the best practice is to just to either leave secrets out of the Nix store or just make sure the entire Nix store is not accessible.
Since I also use NixOS for a few days, I can imagine why it could be frustrating if things don't work out of the box like on other distros. Having had my own adventures patching things like no tomorrow, I know sometimes the effort to do this could be quite time consuming, especially the GOG games[4] you mention.
So I'd say if you frequently use software that is problematic on NixOS and don't want to go through the hoops of patching or making workarounds like eg. Docker or FHS user environments[5], I'd probably stay off NixOS.
Personally however I think it is worth going through a few hoops, since to me it shifts the frustration of "my system broke during an update" to "just want to get X to work NOW" and among other nice benefits (eg. bisecting whole systems, rollbacks and/or using specific packages before they broke) I'd rather prefer a working and reproducible system.
[1]: https://github.com/NixOS/nixpkgs/issues/53834
[2]: https://github.com/hauleth/nix-elixir
[3]: https://github.com/NixOS/nix/issues/8
[4]: https://github.com/openlab-aux/vuizvui/tree/0aa8064087b895d2...
[5]: https://nixos.org/manual/nixpkgs/stable/#sec-fhs-environment...
I never need to worry about a mess anywhere outside of `/home`. Ever.
Ever make a symlink to fix a broken package and forget about it?
Ever make a change to a config file and forget about it?
Ever update your system and find out something is broken, just to spend time repairing the problem?
All these things tend to add up over months and years. After a while, I usually end up reinstalling my distro to start fresh.
Never again.
I used to have diskless machines on my network set up the non-nix way: system directories full of tftp and pxe stuff; root directories constructed by an OS's installation procedure, and then customized somehow to work with an nfsroot. Later on, I wanted to make some changes but had no idea how. I hadn't taken enough notes of where everything came from and what it was doing. The files were still working, but without having documented their intent, I had to scrap it all. But documenting intent is laborious and fragile; you have to include enough detail that future you (or someone else) can follow your logic, and worse: keep all that in sync with the reality.
Since then I have fully committed to the Nix way. Now, the contents of my tftproot are built according to a declaration in my configuration.nix: the root directory in my TFTP configuration specifies a dependency on a PXE package, with some configuration applied. Not only don't I have to look through the built directories and try to remember what everything is, I never think about the built directories. The insight of declarative configuration is: if you fully document your intent, the system can take care of realizing it.
When I want to change a program I have written, I edit the source code (where all the intent is) and recompile it. NixOS is that for systems. I will no sooner go back to mutation-based system management than start changing my programs by taking a hex editor to the binary.
And it gets better over time, more projects are supporting Nix, and there's exciting things being worked on, like IPFS support for the store, and Flakes to get proper reproducibility.
What I ended up doing since about a year or so is just make my whole root partition something I can generate with Debian debootstrap + chroot. I have a +- 250 LOC bash script which I just invoke on a free partition, and it just completely reinstalls Debian in there as if it were a Docker container.
I then rerun this about once every month, reboot, switch to the new partition (and fall back to the old one in case things went wrong, which almost never happens) and I couldn’t be happier with it. Happy middle ground.
Steam just works, though? I've been running nixpkgs.steam for a while, and it has consistently been the best Steam-on-Linux experience I've had. Precisely because what Steam sees is tightly controlled, and there's no place for accidental DLL/.so hell, and ambient changes to your OS making it into Steam/games breaking its assumptions.
(and for everything else you have steam-run/buildFHSUserEnv)
The same games run fine on a Debian 10 host, all of the libraries the link to are bit-identical to the ones in the LXD container, and I've even tried running the exact same kernel.
I'm lost here, as I feel like I've made everything match (at least in the LXD container): the kernel is bit-identical, the games are bit-identical, the libraries they link to are bit-identical. There must be something I'm missing.
Having said this, ostensibly I really like NixOS and I have actually used it as my main desktop for about a year back in 2015.
[1] https://nixos.org/manual/nixpkgs/stable/#sec-fhs-environment... [2] https://github.com/mozilla/nixpkgs-mozilla/blob/master/pkgs/...
I think nix isn't as useful for developers using it to setup their workstation compared to for operations setting up deployment environments. -- I like that I can just run "nix --install myPackages" and have the exact, up-to-date versions of software installed... but, it's not often that I need to run this. (The up-to-date versions thing is nice). -- Maybe this will be more compelling for stuff like GitHub Codespaces, and other ephemeral machines?
(EDIT: and nix-shell is cool and very pure, but looks to me like people are just fine using images of development environments/toolschains with VMs or Docker. etc.).
NixOS itself does feel very different to other OSs. I think people discount how much trouble they run into on other OSs. Partly because other OSs have larger communities, and advice will often apply across multiple OSs. With NixOS, there's a higher requirement for understanding of what's going on; and it's not obvious that the benefit from doing this is worth it.
And there’s a bunch of utilities I use rarely so I don’t even keep them installed, since I know I can just `nix run nixpkgs.hello -c hello` if I ever want to run them.
And then for a work project I set up a custom derivation that I can use when I need to run the occasional scripts that require the custom ruby and python environment, so I can just run e.g. `nix run nixpkgs.my.env -c pod install`. This way I’m not even polluting my global environment with this stuff the way the work scripts expect. And I’m currently working on formalizing this into Nix derivations in the work repo directly (in an attempt to convince my coworkers that we should all use Nix).
Say for the use-case of "I have a macOS laptop, and I use Arch Linux on a different computer". I can't genuinely recommend nixpkgs as better than just running "brew install..." and "pacman -S" (and whatever AUR tool is in vogue). -- Yes, once you know what you're doing and have a configuration, nixpkgs is nicer. But it's not as if the good-enough alternatives are too hard.
When there are more hurdles to getting the bleeding edge (like on Amazon Linux or whatever), I appreciate how much easier it is to just "install nix, install my packages". But even then, installing a recent version of tmux or fish or whatever is a quick search and a few commands away. (Which isn't that much if you only have to do it once every few months; and/or note how to do it in some script or markdown notes).
Trust me, if your development setup is non-trivial (bunch of services maybe in different languages maybe written by different teams) it absolutely is, and is one of the areas where you can get the biggest productivity wins by using nix.
At some point I managed something that could be launched from nix-shell, only to lose it soon after in FS failure.
Both are declarative by default and easy to reproduce.
Hopefully we’ll see them converge in the future.
> I think nix isn't as useful for developers using it to setup their workstation [...] I like that I can just run "nix --install myPackages" and have the exact, up-to-date versions of software installed... but, it's not often that I need to run this.
This might be idiomatic to me (i.e., the devices I use; how; my level of anxiety; etc.) but I have (historically) found OS reinstalls and system moves disruptive.
Over time, the work, documents, downloads, config changes, cruft, old apps and such on a system all congeal into a big blob of system state. To move with confidence, I ended up with a few choices: 1) have the old system runnable as a reference so that I can jump but have it as a reference every time I encounter something that's missing or misconfigured, 2) manually inventory everything on the system to triage what needs to be carried forward and what is crap, 3) copy everything on the system and pretend I'll take the time to do number #2 later (ha! in reality I'll just accumulate multiple nested copies stretching back decades!)
Adopting Nix enabled me to declare my personal essentials, and per-project essentials. This got me close enough to confident I can quickly prepare a fresh device that it motivated me to close most of the remaining gaps on macOS. Instead of feeling like it'd take me days+ to get back to full productivity on a clean device, I know I just need an hour or two.
This confidence liberates me from lot of gnawing everyday anxieties about (i.e., infinite permutations of how inconvenient it would be to lose my system at [already stressful moment where I'm under pressure to deliver something]).
> looks to me like people are just fine using images of development environments/toolschains with VMs or Docker. etc.
I used to be in the VM (virtualbox + vagrant/chef/shell) camp. I was net-happier with that than single-system state and things like virtualenv, but on a laptop I'm not very keen on the extra resource use and performance penalty, and over time I still found one shift or another (virtualbox/vagrant updates, chef cookbook updates, VM image updates, or a VM image that stops publishing) created a fairly regular drumbeat of unexpected, low-leverage debug time.
You can use the package manager to package, build and install software and to take advantage of their large package repo and features like nix-shell without using the OS. What the OS gives you is a full system and all of its services managed exclusively with the paradigms of the package manager.
I do run NixOS on all four of my machines and I got in OS-first package manager second. At first, like the author, I also frequently needed escape hatches like other machines or VMs, but I think if you get into the package manager first you're probably less likely to get stuck. Depending on what you want to do you get a lot of the good stuff with much less commitment that way.
A few months ago I tried migrating my development environment from Ansible to Nix. My playbooks are basically in alphabetical order and so that meant starting with Alacritty. I immediately hit two issues:
- A conflict between the version of fontconfig the package was compiled with and the version of fontconfig installed on my system.
- Nix's OpenGL problem. [0]
They're easy enough to work around but I wonder how big the list would've gotten if I hadn't stopped there.
Could you explain a bit more what you mean? I had prior experience making Debian packages (on Debian and Ubuntu), Arch packages, and a bit of Homebrew on macOS. When I started writing Nix derivations two years ago, I found that it much easier than making Debian packages. Arch packages were easier than both, because the build scripts are just shell scripts, but I found it easier to make correct packages with Nix.
I have most experience with Rust/cargo and packaging Rust applications is really easy with buildRustPackage. As a bonus, you can also easily pull in necessary native libraries.
On the other hand, things like Python packages are pretty tricky.
One of the problems is that the Python ecosystem does not have a strong tradition of semantic versioning. For that reason, a lot of Python packages have (perhaps overly) strict bounds. That works fine for something like pip, which can pick any version of a Python package and can typically find a way to resolve all dependencies. But it's harder with Nix, because nixpkgs only ships one version of Python packages (for good reasons).
Another issue with Python packages that I encountered several times is that some Python packages directly modify their own paths (e.g. until recently Huggingface datasets), which breaks with the read-only Nix store.
I think it depends on if your use case allows for a gradual transition and on your tolerance for migration pain wether or not Nix is worth the trouble right now.
Even if packaging is more difficult with Nix, I appreciate that packages do end up containing a much more precise and flexible description of what they depend on.
Note that these issues aren’t insurmountable, but it doesn’t seem like the Nix community cares very much about them (and of course it’s open source software so there is no obligation for them to care, etc but that doesn’t magically make it a good tool for these use cases either).
I have personally worked with Nix on a Fedora system, but only for things that run inside the terminal.
EDIT: I removed some content here because it didn't think it applied since you clarified in another comment you were trying to use existing packages.
I would generally advise people to start getting into Nix by using it to define your development environments on your existing (linux or macos) daily OS.
I strongly feel like it needs to take the idea to a new level, ditch the messy language and completely refactor it. Don't get me wrong, NixOS is 17 years old and it still feels like alpha version.
1. Draw some ovals
2. Draw the rest of the effing owl
Yes, you only have to write your Nix expression code in a couple of files; of course, the issue is "how to write that Nix expression code correctly".
> Looking at any of the 60,000 packages in Nixpkgs should give one an idea of what to write.
This is exactly the fallacy I addressed in my comment--Nixpkgs is a really brutal reference for a variety of reasons. Let's say you're building a Python project--first of all, good luck finding a good reference package in nixpkgs if you don't already know where the Python packages are. Secondly, the general scheme seems to be "import nothing, write some function that takes dependencies as arguments", which means you'll have no import statements pointing you to the source files for the dependencies. Further, because nixpkgs doesn't believe in docstrings or static types, you'll have nothing that helps you infer the shape of the thing you're searching for or otherwise provide you with reliable grep criteria. You'll need to grep for the call site for your function to determine what gets passed in, and that thing might be the result of calling some other function with its own args, so you end up recursing through this process for the whole dependency tree. It's needlessly tedious, and this example is just the tip of the painful iceberg.
Actually, you can. In any place a SHA256 hash is required, you can put *lib.fakeSha256" (which is an all-zeros hash) and the build will fail and Nix will tell you what the correct hash is.
[0] https://github.com/lf-/nix-doc
That's what Guix is for. https://guix.gnu.org/
> There, we are installing per-user packages because yes, NixOS supports that, any user can have its own packages that others users can’t access.
Other users can access those packages if they want to. Those packages won't show up in other users' $PATH, so other users will not be affected by them, but they could see what's in /nix/store if they wanted to. This matters when you're thinking of putting private data (such as an encryption key) in a package: it's vital that you don't do that on a multi-user system.
Edit: Correction published!
But it's too complex.
I guess that's the result of them trying to do everything an OS does using their new arcane Nix language. I don't know how else this could be accomplished though -- but I hope there is another way.
I find it weird often I would find files written in the Nix language in minified/unreadable way fashion in parts of the system.
It's a sympton of the complexity of everything that for every weird error that I would find I would search the internet and not find a person with the same problem. It's always something slightly different and then the solutions proposed to that person would made no sense to me at all or they would introduce much more complexity.
If you come from a Haskell background its nice, otherwise it's "arcane".
Try Guix-SD.
The problem absolutely is complexity, and there is a lot of stuff you need to grok to be able to use nix productively in anger and sadly that includes a lot of stuff that really ought to be much more straightforward.
Also, IMO you don't do anyone a favor by recommending they try Guix-SD over NixOS unless you also make it pretty clear that Guix is quite fringe even compared to Nix. For example Nix can and is being used for Real Work by well known companies. It as a steep learning curve but also, for certain tasks, an enormous payoff that justifies this effort.
Real Companies are using Guix for Real Work too.
Perhaps Guix is "fringe" by some definitions, but you made it sound like some barely-usable hobby project.
To me, as a former Nix contributor, it largely boils down to a matter of taste. But there are distinct advantages (and disadvantages) to both.
Nix is used by a couple of well known companies such as Pinterest and Target, I have used (and continue to use) nix myself professionally and I know several other places that use it. But even with nix, there needs to be a really good justification to use it in preference to some more standard solution. For example, if all you are working on is python webapp with fairly simple dependencies, I'd probably recommend sticking to poetry and maybe a docker container for your DB. If you need to deal with e.g. machine learning or video processing, or something else that involves a lot of gnarly C/C++/Fortran dependencies or if you've got non-trivial DB migrations or other dependencies which you can very conveniently deal with as a (correctly cached and therefore instantaneous) build artefacts with nix, nix can start to make sense, especially if you need to customize any aspect of the build. At the point where you have a bunch of different services written in several different languages, and your dev env needs to run a dozen plus different services together plus some DB(s) and other infrastructure, you can literally achieve two orders of magnitude improvements in key metrics compared to "industry best practice" cruft like docker or (barf) minikube (e.g. how long it takes to spin up all those services correctly, CI speed, deployment times or how long it takes to spin up a new developer, how much extra tooling infra you need to shepherd and so on). Even then you will still need at least two people with a good familiarity of nix and invest in some basic training for the rest of the company and you might periodically run into annoying speed bumps.
In summary, as a rule of thumb, I'd say even something as non-mainstream as nix only make sense if you think it'll buy you a 10x or greater improvement for something you really care about. I'm not deeply familiar with Guix, but my superficial impression is that it's a much more ideologically pure and not particularly inspired transliteration of nix to scheme that keeps a lot of the obvious flaws in nix (e.g. not using principle of least power; stuff like sha256, github urls and revs should reside in toml or similar and not be munged into the turing complete and non-machine editable nix/scheme code). It still has a significantly lower user base and the greater ideological purity means more stuff won't work compared to nix or mainstream solutions. This all matters less for personal use, where I agree it is indeed a matter of taste. But to me the aforementioned means there would need to be some massive benefit of Guix over nix to make it worth considering in a professional setting. Is there, in your opinion?
Whether or not these institutions qualify as Real Companies is up to you. Other than that I occasionally see focused patches and bug reports from people using their work credentials, but nothing on the scale of Pinterest and Target of course.
We did recently get a bugfix for 'guix system container' from Google, but I suspect that was more the result of an evaluation than anything else:
https://issues.guix.gnu.org/43540
As for benefits in a professional setting, there are a few design (and implementation) differences that I think gives Guix an edge. One is grafts: Guix can deliver security updates for core packages really fast, whereas Nix needs to rebuild every dependent package. The grafting mechanism can also be used to perform other transformations, e.g. to locally enable CPU optimizations for low-level libraries without having to rebuild the world.
On the topic of security, Guix has a strong focus on bootstrapping, meaning that e.g. the Rust and Java compilers are built purely from source code, whereas Nixpkgs use opaque binaries provided by upstream projects. This property (as well as excellent cross-compilation support) is why Bitcoin chose Guix to build their installers:
https://bitcoinmagazine.com/articles/guix-makes-bitcoin-core...
Another important design difference is gratuitous use of so-called "search paths". I noticed one common criticism in this thread is that packages often needs patching to work in NixOS. In Guix, such cases are very rare. Take a look at the patches carried by Guix, conveniently stored in a single directory:
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages...
By and large, these are just security- or bug (often test suite) fixes. I won't go into detail on how search paths work, but if you try Guix on any distro (maybe except Guix System) you'll quickly understand.
It's funny that you mention "non-machine editable Scheme code". In the Lisp world, code is data, which powers among other things the "updaters" in Guix: 'guix refresh -u foo' will update the "version" and "sha256" fields of "foo" in your git checkout.
Finally, a huge selling point for me personally, is general scriptability. I recently added code to build Chromium extensions with Guix. It was about 150 lines of code, and packaging extensions is pretty much like packaging anything else:
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/build/ch...
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages...
There are many other things of less importance that makes me stick to Guix, such as running the test suites of most packages, largely preventing compatibility and other run-time problems that occasionally show up in Nixpkgs (and even popular distros like Arch).
Now, the end user experience of Guix System is not great due to lack of proprietary firmware, as well as GNOME and KDE maintainers, but as a professional tool Guix is really solid in my (supremely biased) opinion.
I agree wrt desirability of grafts as an escape hatch (I think there's been some undocumented crappy version of this in nix for ages, no idea what keeps it in limbo). I also agree that bootstrapping is better in principle.
The search path (in nix?) thing, I don't fully get -- can you expand what you mean? Concerning not needing to patch upstream -- the world is full of setup.py scripts and other cruft that tries to download random stuff from the internet or write and read hardcoded system paths -- how do you deal with that?
> It's funny that you mention "non-machine editable Scheme code". In the Lisp world, code is data
One of the ego-salving lies lispers like to tell themselves ;) If it were so they'd enjoy world class refactoring, whereas in reality they can't even auto-indent code without manually futzing around with symbol properties in emacs. I haven't fully traced how guix update works, but looking at edit-expression it doesn't look very code-is-data to me (the replacement function operates at character not ast/sexp level; read is only called for side-effect as a hack twice).
At build time obviously Guix has all the same problems with packages that attempts network access (to download test data or whatever). I found it easier/more intuitive to provide such additional resources with Guix, but then it's been four years since I used Nix!
On the topic of search paths, IIRC Nix uses a combination of wrappers and "setup hooks" to configure things like C_INCLUDE_PATH or PYTHONPATH. In Guix, such search paths are "first class" and gets automatically configured when the relevant packages are installed to a profile.
That means no hook or wrapper is necessary, and it works with arbitrary profiles as well as "guix pack", etc -- and it is also possible to compose profiles (an emerging pattern among Guix users is to have different profiles for different uses -- a step towards privilege separation).
You'll find almost no hard coded references to "~/.guix-profile" or "/run/current-system" in Guix.
Wrt the updater code, apparently you have studied it more than I have! I think my point still stands though -- that approach would not work if not for the fact that sexps are well-structured.
I haven't often run into wrapper issues, but when you do it's a pain. So thanks for the pointer, I should probably look at how guix does it.
In Guix search paths are properties of the packages that consume them: for the GStreamer example in that PR all the plugins provide the search path attribute, whereas in Guix it is only set once, on the 'gstreamer' package.
The Guix approach has a limitation though, in that users must manually install gstreamer for the plugins to become visible in the profile. It's one of the oldest high-severity bugs in Guix: https://issues.guix.gnu.org/22138
I was just talking from my perspective. And I found Guile much easier than Nix.
The complexity difference of NixOS compared to, let's say, Arch felt like Git to Subversion. It makes totally sense to me that a fundamentally different model of package management would require some rethinking, but it didn't make sense to me to create such a strange language for it (like Guix has proven).
However, from my own production experience with nix I find that language related overheads and frictions are just completely in the noise compared to grokking e.g. the many different flavors of overriding stuff or working out good workflows for pinning and bumping nixpkgs and individual dependencies, providing suitable overlays and integrating native language tooling (poetry, yarn, cargo etc.) with nix etc. etc. Now the language itself does have some psychological effect on wider adoption, but effectively scheme is equally obscure to almost any target audience and, IMO, an inferior design for this problem space, that presents a larger rather than smaller hurdle for most people. I guess the debugging experience at least must be better?
Don't get me wrong, I'd prefer 99% of shitty DSLs (cmake, make, pom, jinja, moustache, chef and so on and so forth) had just used even a mediocre internal lisp/scheme DSL. However, I'd say Nix is a bit of an outlier: it's IMO a remarkably elegant design that really pulls its own weight. Most of my complaints (poor debugging experience and error messages) are quality of implemenation rather than language design as such – I am not quite sure to what extent this applies to lack of static typing.
In any case one of the main usability defects of nix is shared by guix: 90% of cases should be declarative toml or similar, not some weirdo turing complete language. It's great to have a powerful language for the bits that actually need it, but a lot off stuff really shouldn't. In particular mixing metadata (description, hashes, version numbers, urls etc.) with build descriptions is just a dumb and painful way to do things and completely screws up tooling. There are tools to help with that (e.g. niv), but this should just be fixed at the source.
You still have to learn all the thousands of obscure schemas each thing expects and supports.
Could be written in JavaScript and you would still not know what is going on and would have to waste months in documentation and support forums.
Or maybe the documentation is just very incomplete, I don't know.
I’ve started using it with nix-darwin on macOS and replacing various dot files tools and loosely coupled files and installed dependencies using Homebrew with clear and declarative Nix scripts has really changed how I manage my development environment.
I even went as far as coding up colour scheme configurations to synchronise colours between Kitty, Tmux, and Neovim, and added some configs to compile Neovim from source to get to some of its newer features, and I don’t think I would’ve done any of that (or rather, kept any of that around) without Nix.
> I even went as far as coding up colour scheme configurations to synchronise colours between Kitty, Tmux, and Neovim, and added some configs to compile Neovim from source to get to some of its newer features, and I don’t think I would’ve done any of that (or rather, kept any of that around) without Nix.
This sounds interesting! Are your dotfiles public?
I choose to replace Nix channels with in-code tarballs of the nixpkgs repository. Sometimes that does confuse darwin-rebuild but it could also be because I’ve set it up slightly incorrectly.
My Nix files are indeed open source! There’s a colour utility and a file that uses them to create theming files. https://github.com/kitten/nix-system/blob/master/config/colo...
Usually, the nuclear option to installing something on NixOS that just isn't playing along (e.g. Steam and its games) is to use buildFHSUserEnv[0] which sandboxes the directory structure you're used to on other Linux systems. Of course, this means you'll be writing a bit of Nix code – if you're lucky, steam-run[1] makes software run instead, and you could probably hackily add missing libraries[2] otherwise needed, to steam-run (just remember that this is a nuclear option and not recommended because you're moving away from NixOS purity, but it does exist).
Also, I suggest posting this to the NixOS links section[3] if you want more Nix users' eyes on this.
[0]: https://nixos.org/manual/nixpkgs/stable/#sec-fhs-environment...
[1]: https://nixos.wiki/wiki/Steam#steam-run
[2]: https://nixos.wiki/wiki/Steam#Adding_missing_dependencies
I think this idea is not specific to Nix, and I wish it was used a lot more in configuration languages. For example, it was something I really missed when using Ansible. The lack of this feature means that writing the inventory is much harder than it needs to be, and I've seen horrible hacks that try to get around this.
Did you know know we have FHS compat environments: buildFHSUserEnv?
This is our fallback solution for huge closed-source things like steam + its game games that we agree it doesn't make sense to repackage individually with patchelf.
I'm saying we agree and if we didn't have `buildFHSUserEnv` it would be a dealbreaker for many more than you. Please give it a shot, and us a second chance!
Rewriting the library paths for a given binary also works but is cumbersome.
Ideally there would be a few extra tools in Nix to say "adopt this binary" in a similar way we can install things into our environment permanently, and to transform a binary to look for dependencies in the right places.
From what I understand it’s inspired by NixOS, but instead of the DSL for configuring packages Guix uses Guile.
- Having less development effort than Nix involved in packaging; some packages end up broken/out of date as a result
- Its more "pure" packaging ethos (no bundled dependencies, all dependencies must themselves be packages for Guix, etc). I like this in theory but practically it makes packaging some applications (Go/Node ones especially) effectively impossible. Debian seems to have the same issue: https://lwn.net/SubscriberLink/835599/b4de94c924ae4463/
- The build farm often doesn't have substitutes available for certain packages, which tend to be precisely the ones that take ages to build on older hardware. Cue multi-hour IceCat builds
- There's not much documentation available on packaging beyond the trivial cases. Packaging many applications is pretty simple, but for the ones that aren't it's a bit of a guessing game and trying to read through definitions of other involved packages
All that aside... these are complaints that I have as a dedicated Guix user, and I've thoroughly enjoyed my time using Guix System. It's the first distro I've ever used that I haven't felt has gotten "polluted" after over a year of tinkering with it - I've installed (and uninstalled) multiple DEs, and I know I can trust the package manager to actually remove every single thing that was installed as part of that.
And it's really nice to use a distro whose entire configuration system and package definitions are written in a single language (Guile) - I've written a few simple package definitions myself and I think the fact that it's all written in the same language has made it easier to dive deeper into how the system works after having written a few packages.
Generally I love guix. As a tool its very ergonomic to use, the documentation is excellent, and the mailing lists are active and informative. As for specifics:
* The CLI is way better than nix's and each command is fully documented and flags are intuitive. `guix install foo` is a lot more intuitive than `nix-env -iA foo`. Nix is in the middle of overhauling its CLI but until that task is complete I personally believe there's no contest.
* Guix has a lot more first party functionality when it comes to importing packages for some languages. If someone's project is in python, ruby, haskell, or ocaml it only takes `guix import fooRepo package` to create a package that isn't yet in guix's package repository. Also this functionality is easily discoverable thanks to guix's excellent documentation. I wish this extended to nodejs projects but that's likely never going to happen.
* There are a number of built-in ways to share guix packages with people who aren't using guix with the command `guix pack`. This has come in handy for me in a number of situations like creating singularity containers for coworkers or trying out stuff they're working on in an isolated environment.
* Speaking of containers, `guix environment` lets me run software in ad-hoc containers.
Now, all of this is great but the desktop experience still leaves much to be desired. The desktop experience has all of the problems running NixOS has except the added trouble of Guix's immaturity. Gnome is only 3.34 while most distros have already migrated to 3.38. Guix has been a pain to run on my laptop, so much so that I've resigned to only use it as a package manager and DevOps tool.
The difference comes in the maintained software distribution, nixpkgs, being less strict in its package inclusion criteria than its guix equivalent.
Instead, it seemed that I had to manually update the nix config. Then, I had to learn the syntax of the language. Then when I figured out the basic, I added Firefox, but it required me to add some parameters (I don't remember the specifics) but I couldn't find any explanation about what those should be for the Firefox package.
I don't understand why they don't have tooling (or didn't at the time) to update your nix config for you.
If they want to convert people over to their way of doing things they have to lower the barriers to entry substantially.
You probably tried to add firefox to your local one - which should be good enough. I wouldn’t really want a program to auto-update the global configurarion.nix
I find for my laptop I get 90% utility that way in including user systemd services.
I love all the NixOS blog posts but I hate that they are always so surface level. NixOS feedback or writeups never go beyond this shallow level.
I'll make a follow-up in more time (some months) and go in more details!
Probably should've used the word "dislike" instead of hate. Apologize.
As someone whose been using Nix for almost a year (not NixOS as long) I struggle that there is zero advanced write ups.
Could be because it's the same experience which is good news.
But there's a series of advanced concepts that deserve more love: custom Nix cache, distributed building, remote deployments , NixOps, writing eloquent derivations, secret management (please!), how to sanely use vim_configurable etc...
I spent a long time documenting the Maven (Java) documentation and recently had it approved.
So far I think it's brilliant. I didn't even know about the functional aspect but once I "got it" it makes me not wish to go back to a mutable system. I say this is a long time gentoo user. It won't replace my gentoo system any time soon, but it certainly has potential.
A simple example of this is when I want to run a Python script from the internet, I can execute
nix-shell --run "python3 foo.py" -p "python3.withPackages (ps: with ps; [ numpy ])"
nix-shell --run "ghci" -p "haskellPackages.ghcWithPackages (ps: with ps; [ QuickCheck ])"
These problems have already been solved to varying degrees in other places, but Nix lets you unify them (think of the huge amounts of libraries downloaded by cargo, cabal, node and so on scattered amongst projects and your home folder, Nix stores everything in /nix/store/) into a single framework.
I'd like to also say that the Nixpkgs repository[4] is super easy to contribute to, just open a PR on GitHub as opposed to sending patches via mailing lists, which is checked via the CI. I'm not sure if there's something analogous on other package repositories but there's also a bot[5] that opens thousands of PRs updating and testing packages automatically.
[0] https://github.com/Shopify/comma
[1] https://github.com/Lassulus/nix-autobahn
[2] https://github.com/nix-community/nixos-generators
[3] https://matthewbauer.us/blog/beginners-guide-to-cross.html
#!/usr/bin/env nix-shell
#!nix-shell -i /bin/sh -p ffmpeg_4 lsdvd python3
They are very different, but lead to some of the same benefits. Silverblue largely follows the same system layout as traditional distributions (FHS, with packages in a global namespace). But compared to traditional distributions, it replaces the package manager with snapshots in a git-like store (OSTree). The system is immutable and provides atomic updates/rollbacks, like NixOS. They offer an mechanism on top of OSTree (rpm-ostree) to layer traditional RPMs from Yum/DNF repositories. To keep the base system lean and immutable, they encourage installing desktop applications through Flatpak and doing development through traditional, mutable containers through podman/toolbox.
Silverblue is a bit strange in that it is in two worlds: on the one hand it touts the benefits of immutable systems, on the other hand it acknowledges that in their own setup, development is only really comfortable by also providing mutable systems through containers.
NixOS is far less compromising than Silverblue. It chooses one model, functional package management, and that's the way of the highway (no FHS, immutable store, all packages live in their own directories in /nix/store). There are some small escape hatches like buildFHSUserEnv, but no major compromise as Silverblue has. Nix shares some benefits like atomic updates/rollbacks and an immutable system. But provides many others that Silverblue's model cannot easily provide (or has as the answer 'spin up another container'), such as permitting several different versions of packages in parallel, virtual environments (but for any package), etc.
I think both approaches are very promising and not one is necessarily better than the other. Nix/NixOS' approach is more consistent and more powerful. However, Silverblue's pragmatic use and strong integration of containers, makes it much more familiar for most people. Also, much more software works out-of-the-box as a result.
Conceptually its a great idea, but I'm a bit worried about the possibility of all-mighty failures caused by adding the extra layer of abstraction and complexity. Its a bit like messing around with the buzz-word-of-the-day Kubernetes compared to just getting the job done with a good old fashioned VM.
Given solutions like Salt are around that can manage reproducible builds anyway (in conjunction with PXE installs), I see limited applications for NixOS.
Also, sometimes its nice to have the warm fuzzy feeling of using a software vendor's supported package build on a supported OS (e.g I'd rather run a package from the official Postgres repo then mess around getting Postgres working on NixOS).
> possibility of all-mighty failures caused by adding the extra layer of abstraction and complexity
In the end, I think all distributions ends up with similar layers of abstractions and complexity, mostly regarding packaging, but sometimes also other components.
What I've found when using NixOS compared to Arch, is that if I screw up my Arch installation I either need to sacrifice my time to try to fix the screw up (which sometimes adds spending time just learning/reading about some concept I don't know about) or I need to recover from backups, so I can get back to work.
With NixOS screw ups, I simply choose the previous version on boot and I'm "recovered". Leads to me getting back to what I was doing faster, but missing the opportunity to learn my own personal stack better. But not every moment needs to be "understand everything 100%", which in Arch-land, tends to happen, otherwise you continue to screw up.
Although I'm still on the fence of upgrading to NixOS because the OS as an concept + it's own language is still not easy to learn, especially for more advanced usage, it's getting closer each day to just dump Arch and start using NixOS full time. Mostly because the reproducible nature of the OS.
One of the advantages is that packages just works on the contrary of the AUR where I had lots of problems for lots of packages that wouldn't just not build or work.
last major issue I had was when everything moved from /bin to /usr/bin.
One recent example was me trying out KDE Plasma. Usually I use AwesomeVM but the HN thread about the new Plasma version made me try it out in Arch. After the install and trying to use it for a while, I wanted to go back.
Uninstalling the package(s) is not enough, as it already has been overwriting bunch of stuff and changed configs that are not being rolled back after uninstalling.
Still to this day KRunner launches (via some d-bus command or something like that) when I do my Super+R shortcut, which usually runs the AwesomeVM launcher, not KRunner. Haven't figured out how to get rid of it yet, but got other stuff to do right now, so simply living with it for now.
With NixOS, I'd just reboot and select the previous version where KDE Plasma was never installed.
Another fun related feature: NixOS really only requires /nix and /boot to boot. So, some of us just nuke everything except /nix, /boot, and /home on boot:
The problem was: in the AUR, lots of packages didn't built or launch, and even in the official repos, some packages were missing libraries or just not having the right versions.
I was tired of tinkering to get everything to work as I wanted.
I used Arch for a while before NixOS. Another problem I encountered with the AUR is that, since the AUR is not built as a single consistent system with Arch itself, often packages from AUR would start failing because some library was upgraded in Arch and the newer version was ABI-incompatible with the version that the AUR package was compiled with.
Why is partitioning not part of a config file, but done at installation?
The config file has this line:
imports = [ ./hardware-configuration.nix ];
fileSystems."/" =
{ device = "/dev/disk/by-uuid/14b5b22f-6cd2-4da5-a9a5-6ee74b76509d";
fsType = "ext4";
};
fileSystems."/boot" =
{ device = "/dev/disk/by-uuid/7D69-81E5";
fsType = "vfat";
};
For the initial installation you actually have to set up the partitions and mounts inside the root filesystem manually similar to what you have to do to install Arch.
Then you run the install command. The install command sets up the system with a default (or customized) configuration and also generates the hardware-configuration.nix file so that it matches the root filesystem you have set up before running the install command.
All help is welcomed :).
The configuration.nix system configuration can be moved between systems, but imports a generated hardware-configuration.nix that really should not be moved between systems.
If you don't want user and system specific configuration to intermix by having user-specific software in your system configuration and you want to manage you the dotfiles in your home directory in the style of Nix there is another popular project called home-manager which enables that, but that's totally optional.
Having used NixOS for more than a week, I have the same but opposite feeling. If you don't mind the hyperbole, NixOS is a solution, Salt and similar as a substitute is duct tape. :)
Therefore Chef (they other tools are equivalent in my view) is IMHO not a good enough tool to manage dev environments.
I agree, but your and my definition of “good enough” is not the same as everyone else’s. These tools wouldn’t be as heavily used if folks didn’t feel they solved a problem they had.
Update: trying to install the same package in different versions at the same time is also a pain.
I perceive nix as a tool that removes a layer of abstraction and complexity - the FHS. Having an app working is easy. Having multiple apps share the same FHS is complex because of conflicting requirements. Without FHS, there is no shared dependency resource thus no conflicts. Multiple applications are just as easy as a single application.
I see NixOS as an easy way to re-install easily my system when I get a new machine or just to sync easily packages between my laptop and desktop (so they almost have the same things installed on them).
As for servers, I don't really see the point of nix as usually, pre-made and preinstalled images are already deployed. I think I'll still stick with Debian and all the usual software such as Docker for this usage.
As a result, working with docker images often needs special privileges which leads to complex situations involving docker-in-docker etc., which just shouldn't be necessary.
But it's also reached for as a solution for a whole heap of other things which are much better done in other ways.
I have not found this at all tbh.
And I've actually found the discoverability of the tricks used in nixpkgs to be pretty amazing. Sure the manual could always do with being more thorough (indeed it's always getting better), but again, in comparison, the quantity of stuff understandable from just reading the contents of nixpkgs and knowing basically one language is huge.
I compare it to a lot of the other systems I work with where just to decipher relatively simple setups people have created I have to understand cryptic combinations of terraform, Dockerfiles, bash, helm, github workflows, concourse pipelines, puppet/chef/ansible/..., travis.yml, Brewfiles... each of which being weirdly arbitrarily restricted and inevitably needing to call in yet another tool to fill in the gaps in their capabilities.