I stress it is only a personal feeling I’m going to express
I use NixOs on a daily basis. As metaphor: I feel like a peasant, that had worked the earth hard with his hands his whole life, that now has discovered some engineers that have assembled a rototiller, who kindly share the plans and the working production ready models. I won’t criticize the painting, the noise of the motor, and the user manual. These are areas of improvement.
I don’t think one single second about coming back to former ways of doing.
Because it’s a paragidm shift. The sort of things you don’t want to come back from once you get it.
NixOs is not just a new Linux distro.
I’ve just started experimenting with NixOS, and so I’m particularly interested in criticisms of NixOS that might make me want to abandon it now before I get too invested. Here are my thoughts on this person’s arguments:
Small community.
I’m only using NixOS in my capacity as a hobbyist running my own personal server infrastructure. I don’t care about hiring people or paying for support in this context.
Documentation
Yeah, it could be better. Documentation usually could be. On the other hand I do understand functional programming, so I don’t care if the Nix configuration language is hard for someone coming from an OOP background. I think those people should become comfortable with functional programming. I did have a little bit of trouble figuring out exactly what things were possible with nix configuration syntax, which, again, better documentation of the language would fix.
Configuration management.
System state and configuration described in a special file configuration.nix. It’s like an entry point to endless amount of functions and dependencies for your OS.
Yes this is the entire point. I like the idea that I can describe everything relevant about the state of my system in one file. Writing custom systemd services is something anyone using a modern linux with systemd might have to do, this is not unique to NixOS.
Kernel upgrade.
I just realized that the version of the kernel on my test NixOS system is 5.4, which is older than I would like. https://nixos.wiki/wiki/Linux_kernel tells you how you can upgrade to the latest kernel, which I just did without trouble.
Cloud support
This sounds like some issues specific to AWS (which I don’t use for my personal infrastructure), and with a version of NixOS a couple years old. Not sure if this is relevant to anyone today, but it’s not relevant to me.
Cache
Problems start happening when you spinning up your personal cache, which is used, for example to store your proprietary build artifacts. You always need to keep eye on the community channel version you’re using as a base for your builds. And yes, your own cache size will also grow very fast!
I haven’t done this yet, so I’m not sure how problematic it is in practice.
Security.
People are thinking, that NixOS deterministic approach of dealing with software is very secure. Maybe yes, it is really not possible to hijack the build results once the derivation bin build. But… You always need to pay for it…
During the upgrade from 18.03 to 18.09 Nix community decided to change Docker tools they’ve been use to calculate derivations checksums where you were dealing with Docker images.
As a result we rewrote all Docker based derivation declarations and more over to rebuild them all. It was really painful and unmanaged migration.
I don’t understand from this description what the problem was. It makes sense that when you do an OS update, you’ll have different versions of some of the binaries and need to rebuild things that depend on a hash generated from those binaries. I’m not sure how Docker images are coming into play here, or if this is relevant to what I would do with my linux systems.
Windows support
I’m not sure what it would mean for a linux distribution to “support windows”.
System requirements
I’ve been running the Nix tools on my laptop. Haven’t noticed them taking up too much space so far, and if they do I understand there’s a pruning mechanism.
Anyway I don’t find these points super-convincing, especially not for my own usecase (which is admittedly different from the use case of someone supporting production infrastructure at their day job).
I’ve just started experimenting with NixOS, and so I’m particularly interested in criticisms of NixOS that might make me want to abandon it now before I get too invested.
For some quick background, I’m a casual hobbyist Nix user & fan, I first tried installing NixOS maybe ~5 years ago, but shelved it after some heavy & deep experimentation; discovered home-manager since and swear by it now; installed NixOS again recently on a secondary personal laptop that I bought for Linux (my main one is Windows) and now consider it a keepers for purposes of tinkering and Linux-based hobby development.
I will try to reply to your first sentence, though it’s not easy for me to put many thoughts in a concise reply. My main takaway is probably such, that it will break in different ways than your now-“HN-standard” Ansible/Chef/… setup. Mind me, not necessarily in more or less ways, but different ones. And given that it’s still absolutely an emerging technology, those ways will be comparably less well-known, and the community is smaller (esp. compared to current golden standard ArchWiki or askubuntu.com), so at times you might/will be a trailblazer in solving some issue. Also sometimes re-blazing some trail that someone else quite probably blazed before, but most people are still tinkering in their garages and there’s not that many bloggers & other public knowledge-sharers yet, and that one person you need might not be on IRC just now or they are but didn’t notice your question.
In other words, it’s an emerging/bleeding-edge technology with all that it typically entails. As to investment, if we knew for sure which investment is the good one we’d be all millionaires ;) Personally, if you like tinkering and playing, my subjective belief is that it’s a better moment to start playing with Nix than ever before. I would be hesitant to recommend that to anyone seriously those ~5 years ago, other than an interesting talking point, but over last months I’m definitely advertising home-manager left and right to anyone who has enough intellectual curiosity and hacker spirit. Going NixOS is still brave IMO, “jumping in deep water”, but if you like it and manage to stay afloat, you might find you’re reaping some benefits, and ahead of the pack splashing merrily in the shallow waters. Personally, if you’re really into deep water, I’d hertily recommend trying to go towards Nix Flakes ASAP. That’s a somewhat higher risk bet, but I seem to find they’re fixing a lot of issues I had with “classic” Nix originally.
I think one thing that’s kinda still open question with Nix, which to me personally (bear in mind, hobbyist user) is the only major point of risk where Nix might have trouble, is with managing secrets. I know some people are trying to approach this from various angles, but I haven’t yet seen an approachable (to me) writeup explaining if someone really found a sensible and practical way to do that. I’m not sure if some solution/workaround will emerge, or will it require a major breaking change/evolution in Nix. I personally think there’s some chance this might be a risk to Nix’s solid mainstream position sooner or later. (And alternatively, some unexpected future technology might possibly unexpectedly outpace Nix to its own success.) But personally, I see Nix (esp. recently) on a trajectory to mainstream.
I sometimes contemplate the security of nixpkgs and I think anyone that uses nixos for production should as well. Currently there is no authenticity in the commit process, and I don’t think there is a list of people with commit access to the repository yet.
The reason why is because there is an opinion about gnupg being bad (it is), thus the additional requirement of signing commits would present a barrier of entry. This is at the expense of the integrity of the repository. Currently one compromised user (2FA is required for commiters) or a mismanaged webhook would be enough to compromise a package build (I don’t actually think the nixos folks would add a webhook this way). I do think gnupg gives value in the process here to ensure simple user compromises can be avoided. If not the drive-by commiters then the repository maintainers should.
Even if a nixpkgs maintainer isn’t compromised someone with the maintainer tag on a package has no requirement for 2FA and there is no way to validate who created the commit.
gnupg is terrible to use, but as long as there isn’t any proper substitution I think it’s a bad idea to have no signatures.
Edit: link updated to point to the topic rather than a specific post. Thanks @Foxboron for pointing out the incorrect link.
Even if a nixpkgs maintainer isn’t compromised someone with the maintainer tag on a package has no requirement for 2FA and there is no way to validate who created the commit.
That’s true, but package maintainers cannot merge commits in nixpkgs, only people in the nixpkgs-committers group can. So, at the very least their changes are reviewed before they are merged.
But you have no way to prove who merge the pull-request though, except for the unauthenticated metadata in the commit. I also assume that the “malicious commit” problem mentioned in the issue would escape the member of nixpkgs-committers because of the inherent trust in package maintainers.
And from the thread:
With nixpkgs, you can literally rebuild the entire tree in your own ci. You could re-create any package, and build and cache that. You can maintain your own package cache. The arguments for nixpkgs are nearly always better in the end.
The same argument can be made for any binary distribution which has a fairly straight forward way to bootstrap. I don’t think that applies to nixos(?). I don’t think it’s a strong argument for nixos that the reply to “you might not want to trust nixpks” is “rebuild everything”. It escapes the underlying problem because you are still building with the same sources.
You can’t recreate the package either. nixpkgs doesn’t guarantee bit-for-bit determinism even if the metadata for the derivative is identical.
Because objectively using nix and Nixos over Ubuntu or redhat can be argued in a way that will convincingly illustrate nix/Nixos is superior.
Okay, I laughed a little bit. I don’t know if this is a poorly worded argument. But no community based distribution is superior to any decade old enterprise distribution with people working on it. And the counter argument is easy; Where are the nixos security advisories?
(I know people are working on nixpkgs security, but the blind zealotism like this is a bit sad. It hurts progress.)
But you have no way to prove who merge the pull-request though, except for the unauthenticated metadata in the commit.
Not a fully satisfying answer, but you can in the GitHub interface. GitHub links merges or rebases to PRs. Of course, relying on a proprietary interface is suboptimal.
I agree that commit signing would be better (if you have devised a good way of establishing trust). But most people dislike GnuPG, for good reasons. If there was only a simple replacement that also supports hardware tokens.
I also assume that the “malicious commit” problem mentioned in the issue would escape the member of nixpkgs-committers because of the inherent trust in package maintainers.
Even though package maintainers build up trust, I have never blindly merged a PR because it is from a maintainer. I check every PR that I merge carefully. Given the feedback that I get on my PRs, I have the impression that other nixpkgs-committers do this as well. There can, of course, be exceptions.
(I know people are working on nixpkgs security, but the blind zealotism like this is a bit sad. It hurts progress.)
Agreed, but you also cherry-picked some of the more zealous comments ;). There are also a lot of active contributors who acknowledge current issues and suggest remedies, such as:
Making the nixpkgs-committers list public.
Improving branch protection policies.
Making hierarchies of package subset with fixed maintainers.
Anyway, security is a process and I hope that the NixOS/nixpkgs community can address some of your concerns in the future. I think a first good step would be to describe the current trust model somewhere, so that users can decide (based on their threat model) whether the trust model is sufficient for them or not.
Not a fully satisfying answer, but you can in the GitHub interface. GitHub links merges or rebases to PRs. Of course, relying on a proprietary interface is suboptimal.
That’s not really anything. Git shows the author based on the author or Co-authored-by so it is in no way a form of associating a code change to some author.
If there was only a simple replacement that also supports hardware tokens.
I would really love a solution here indeed. I still think GnuPG should be used until something is implemented. But I reckon I’m maybe in the minority in this regard.
I check every PR that I merge carefully. Given the feedback that I get on my PRs, I have the impression that other nixpkgs-committers do this as well. There can, of course, be exceptions.
I think being aware of the potential issues helps keeping people aware of the responsibilities they have when hitting that merge button. But I think defining a threat model where you consider a compromised commiter and/or malicious pull-request from an established packager are useful to work with.
Agreed, but you also cherry-picked some of the more zealous comments ;).
Oh, you linked directly to that reply so I thought there was some intention behind that. I did read through the thread afterwards and there is a good discussion there as you pointed out!
Anyway, security is a process and I hope that the NixOS/nixpkgs community can address some of your concerns in the future. I think a first good step would be to describe the current trust model somewhere, so that users can decide (based on their threat model) whether the trust model is sufficient for them or not.
I do hope so! But until then I do think it should be a something to be aware off if you consider running it in production. For hobbyist use most stuff is fine really.
That’s not really anything. Git shows the author based on the author or Co-authored-by so it is in no way a form of associating a code change to some author.
That’s not what I meant. Go to a merged PR, e.g. this ‘rebase merge’:
Below the horizontal line, there is a reference to the corresponding PR (presumably, GitHub’s database links commits to PRs). Click the PR number, which takes you to the PR, which is linked to the GitHub account that merged the PR.
Oh, you linked directly to that reply so I thought there was some intention behind that.
My bad, sorry! I will update the link, in case anyone else follows it.
Below the horizontal line, there is a reference to the corresponding PR (presumably, GitHub’s database links commits to PRs). Click the PR number, which takes you to the PR, which is linked to the GitHub account that merged the PR.
Right, but this doesn’t really prove anything.
Nothing is signed so you only know that someone with access to the github account jtojnar hit the merge button where the presumed author of the commit is erictapen.
And not to discredit any of the authors, but there isn’t a whole lot to establish identity here. If nixpkgs where to move off github the strict connection between the commits and the accounts are broken. With signing keys there would at least be some private key that would be compromised to forge these identities.
The information in github proves which accounts did each thing. GnuPG proves that a certain key was available to whatever process created the commit. Neither proves that the named human was involved or that the source committed was as they intended.
If you’re trying to manage the security of a project you’ve got to come up with a threat model and decide that some external things are trusted, otherwise you can’t get anywhere.
The information in github proves which accounts did each thing. GnuPG proves that a certain key was available to whatever process created the commit. Neither proves that the named human was involved or that the source committed was as they intended.
One is strictly tied to a proprietary vendor though. In the shower I tried figuring out what would happen if Github would disappear tomorrow. Arguably NixOS would have a few problems, but reestablishing the maintainer usernames to some presumed identity would be a hard one.
This is why a private Web of Trust (for example Debian and Arch) is useful. The identity of the packagers are separate from the service used.
If you’re trying to manage the security of a project you’ve got to come up with a threat model and decide that some external things are trusted, otherwise you can’t get anywhere.
The problem here is that there is nothing to anchor the trust in though. Formally stating a trust model (which has been mentioned) would help a lot though.
It wouldn’t be that hard, you’d use email and some side-channel communications to establish a web of trust.
And sure, you could do that earlier, but then you have to pay a big co-ordination cost persuading people and maintainers will have to use gnupg, which is a barrier to entry. Github isn’t going anywhere soon, and even if it did you could move to gitlab or whatever, so why pay that cost before you have to?
But you have no way to prove who merge the pull-request though, except for the unauthenticated metadata in the commit.
Even though I may not know jtojnar’s real identity, I know that jtojnar is someone I can trust, since they have a long history of valuable contributions to the project. So, it proves to me (if I trust GitHub) that a pull request is merged by an identity that I trust. So, does it prove who merged the pull beyond “unauthenticated metadata in the commit”, as you originally stated.
With signing keys there would at least be some private key that would be compromised to forge these identities.
You don’t have to convince me that proper commit signing is preferable ;), I fully agree.
Ah, the intention wasn’t to move the goalpost. My bad :) It felt more like clarifying the problem I had with the pull-request flow. But yes I agree with the explanation.
For thr commit signing case the entire gnupg UX is that after you type “git commit” you must type your password. For me a little GUI box pops up and asks for my passord every niw and then while using git.
I’m interested in your suggestions for how this could be improved.
The git integration is easy. gnupg is not easy. There is a lot more to commit signing then just git commit. Properly secure the keys, subkeys and gnupg key administration is the hard part.
I don’t know why a commit signing user would even need to know the word “subkeys”? It’s true they will need to initially generate a key somehow and set a password on it. While the seahorse GUI is quite good, for someone not planning to use gnupg generally the easiestwould probably be to have docs on what command to paste to generate a new key. It will ask to set a pssword and then you can forget about it again.
Like – the first couple points (re: the small community, poor documentation, & the need to learn their specialized language) is essentially why I rejected Nix as a personal workstation distro – but practically everything in industry is like this, so if you’re being paid for every hour you spend learning a specialized config language (like, you know, a DevOps professional), why not take advantage of build reproducibility? Like, you’re getting paid to fix a common problem with deployments while simultaneously adding an overhyped technology to your resume.
Where I work, until we moved from our own data center to the cloud a couple years ago, we spent dozens of man-hours a week vetting source code for standard third-party tools & patching them so that they’d build against the last toolchain somebody in the org had completely vetted. We had a six-month three-man project to move everything from glibc to musl. When we brought in a library written in fortran, we had to port it from fortran 90 to fortran 77 because the f77 source code was vetted but gfortran was not – which meant that somebody on staff needed to learn fortran. It was a nightmare – and one we put off by switching to docker images (at, IMO, a great cost). NixOS seems like it addresses some of these issues under certain circumstances – and that’s extremely valuable if you have the kind of security-anal folks in charge of your package set who think reading the entire LLVM codebase to vet for a “reflections on trusting trust” situation is a good idea on company time.
(The bit later about windows support, though… What does that even mean?)
The bit later about windows support, though… What does that even mean?
My guess is that it’s a comment on Nix, the package manager, which you can install on non-NixOS machines. Charitably, the comment is about WSL, not Windows proper, though I think I managed to install Nix on my WSL Ubuntu last year.
Alternatively, it’s an anticipatory comparison to the later mention of Docker, which runs on Windows proper.
Charitably, the comment is about WSL, not Windows proper, though I think I managed to install Nix on my WSL Ubuntu last year.
Indeed, single-user installs work fine under WSL2. Multi-user is more work, since WSL distributions do not systemd, you have to ensure that the nix daemon gets started.
This is an old article – we’re using NixOS on all our systems at work, and it all started on AWS in 2019. NixOS was resizing the volume and there were no issue with AWS integration. The only annoyance is that the AMIs created by the NixOs team are created sometime early after the cut and never updated. So as one approaches the next release, and wants to upgrade the system, there will be a lot of fetching. Also, sometimes the AMI will be late to arrive :)
And, God, do not try to run Nix in Docker! It’s really, not, REALLY bad idea!
Oh, yes, totally bad idea. Docker is for isolating the dependencies of a system and packaging them together. Nix is a packaging system that ensures you have all the dependencies you declared ready when you want to run your tool. Why using the same tools (or, why zip the tar.gz archive?). I just think the author of the article belongs to the class of people that mixes up Docker with VMs…
NixOS is not a silver bullet and it’s a lot of time & money to invest in it, with a risk of breakage which will be very tricky to troubleshoot for a newcomer.
With that said, accusing others of lying (like in the quote below) is just so…immature. You don’t have to like what I enjoy, but accusing me of lying just because you don’t understand what I like?
It is declared and provided to you by the system design, that you’ll get the same version of any software package from the derivation. Lie!
I don’t even care about reproducible builds, but NixOS is hands-down the most pleasant user experience. The only reason that I wouldn’t want to use it is pretty hard to find some binaries. Recently I wanted to use the objdump, readelf, and strings binaries. Apparently, they are in the binutils-unwrapped package… Also, compiling stuff that uses OpenGL is a bit of a pain, and I had a hard time installing vmware horizon.
nix-locate can be useful for this. It’s in the nix-index package. e.g.
❯ nix-locate 'bin/objdump'
(xcodebuild6.out) 0 s /nix/store/1jd5kk0c36v6mnj8wpj2v70rzbk2g3zv-Toolchains/XcodeDefault.xctoolchain/bin/objdump
(xcbuild.out) 0 s /nix/store/hsrmw5ahmcca987wp4q27216c9nja7y9-Toolchains/XcodeDefault.xctoolchain/bin/objdump
llvmPackages.bintools.out 0 s /nix/store/82fx3jrjb5721w3d4d1gm3xf1h2ah5lp-llvm-binutils-7.1.0/bin/objdump
goimports.out 0 s /nix/store/g0j5vygszxrv7xxzz5n3r4vfh28qsp0m-gotools-unstable-2019-11-14/bin/objdump
(glibc.debug) 312,040 x /nix/store/8zbl35kgg8v7gircl3pvy9027vslll1q-bootstrap-tools/bin/objdump
gcc-arm-embedded.out 1,323,576 x /nix/store/g2gvj8c6axb1jn37w2kyyy7gznqb8vwl-gcc-arm-embedded-8-2019-q3-update/arm-none-eabi/bin/objdump
gcc-arm-embedded-6.out 1,333,480 x /nix/store/qznwwp5jhi3bqn7jzmmi38rsj2754pcr-gcc-arm-embedded-6-2017-q2-update/arm-none-eabi/bin/objdump
gcc-arm-embedded-7.out 1,388,088 x /nix/store/rqgzbpxia6xz33dknabc6dqcgpdlgyvk-gcc-arm-embedded-7-2018-q2-update/arm-none-eabi/bin/objdump
dev86.out 22,488 x /nix/store/r92yf0bfl45rbcvi3nlci17736z3v8pl-dev86-0.16.21/bin/objdump86
binutils-unwrapped.out 0 s /nix/store/w2dbyz9m2dnk2x3hrf48y9hbmmn7hxg6-binutils-2.31.1/aarch64-unknown-linux-gnu/bin/objdump
binutils-unwrapped.out 374,120 x /nix/store/w2dbyz9m2dnk2x3hrf48y9hbmmn7hxg6-binutils-2.31.1/bin/objdump
(binutils_nogold.out) 0 s /nix/store/szbm7zdz8x22r0d6z3y989f3flpqlbv6-binutils-2.31.1/aarch64-unknown-linux-gnu/bin/objdump
(binutils_nogold.out) 374,120 x /nix/store/szbm7zdz8x22r0d6z3y989f3flpqlbv6-binutils-2.31.1/bin/objdump
Usually it’ll give you one-line with the answer you want, but a ‘bin/objdump’ appears in many packages, so you have to pick out the most relevant-looking one here.
We use K8s at work (dev (but really it’s a royal pain for dev) and qa/integration - and will be used for prod at some point). I spent some time playing with the Hashicorp stack over the holidays and since @cadey s recent posts about it I’ve been lookiing into Nix more lately.
I am more than a little intrigued by the idea of Nix and NixOS (and I guess NixOPs too) but the learning curve for it has been frustrating in that there are lots of example blog posts, but they all seem to be missing the bigger picture of how it all fits together (eg when I look at the Repos associated with the posts, there are a plethora of .nix files but no sense of how/when things get called/resolved).
I had little trouble getting the Hashicorp stuff running (upto and including waypoint) and was pretty nice to work with but the infrastructure and overhead needed seems too much for a single box side project.
I would love to experiment with Nix for said side projects, but my VPS provider of choice would not make it easy to use without manual intervention and so I spent yesterday filling in some notes on a process supervisor/deployment framework that I’ve been thinking about for a while (often saying to myself it’s not needed if I have X) that will run on a Plain Old Linux Box but still allow for automation around builds and deploys.
We use K8s at work (dev (but really it’s a royal pain for dev) and qa/integration - and will be used for prod at some point). I spent some time playing with the Hashicorp stack over the holidays and since @cadey s recent posts about it I’ve been lookiing into Nix more lately.
I think taking up Nix and immediately trying to use it in such a context is a lot to take in and will most likely end in frustration. Although NixOS is a Linux distribution, it is not like any other distribution and switching to NixOS pretty much amounts to learning an alien Unix system. Sure, the regular Unix commands are there, but otherwise the system is not like any other Linux distribution. If you want to user Nix in more complex setups, there is no way around learning the language (easy if you are familiar with FP, otherwise harder) and how nixpkgs works. Sooner or later, you will have to write your own derivations, and that will be painful if you do not know the language and nixpkgs functions and conventions.
A good place to start is using Nix as an extra package manager on a local Linux or Mac workstation/laptop. This not only gives you access to many packages (more than most other package sets), but also gives you ad-hoc development shells (with nix-shell). To make it less ad-hoc you can create per-project default.nix files or shell.nix files. Basically using Nix as a way to manage virtual environments, but then for any package. These don’t require you buy into Nix immediately, and you can just use it on the side. If you don’t like it, no harm done. Blow away ~/.nix-profile and uninstall Nix.
A good way of playing with declarative configuration, without immediately switching to NixOS, is to use Home Manager. It allows you to declaratively configure your home environment (basically dot files + packages). It gives you some of the benefits of NixOS, without immediately jumping into a foreign environment. If you like Home Manager, you’ll like NixOS and it’s a good point to jump ship.
I like the idea of NixOS, but I still haven’t found a concise guide on how to build my own nix expressions, and without that it’s a huge pain in the arse to get many projects working.
Nix has its own way of doing things, but they’re unfamiliar to me and slow me down a lot. Often, I want to try out some software and I don’t care if I can install it reproducibly - I’ll worry about that only if it turns out the software is useful and I anticipate I’ll need to share the process.
I still haven’t found a concise guide on how to build my own nix expressions, and without that it’s a huge pain in the arse to get many projects working.
I think I had the same issue. What I ended up doing is defining a single shell.nix which I use for all projects. That way, I don’t need to remember how the thing works and can just symlink it for each new project.
Often, I want to try out some software and I don’t care if I can install it reproducibly
Just to clarify, if the thing is fairly popular, than nix-env -i cool-up generally just works – nixpkgs is large.
The pain starts only if the software is not packaged, in which case you’d need to write your own nix expression, or to patch elf. There’s also a mysterious buildFHSUserEnv which I think can make binaries from the internet to just work, but, alas, I haven’t found a concise guide on how to use it )
In some of those cases buildFHSUserEnv can be helpful, it can be used to build lightweight sandboxes with an FHS environment. E.g., I have used it in the past to set up Java and Python environments that I don’t care to properly package. It’s also used within nixpkgs for a handful of packages that are difficult to package otherwise.
I highly recommend using mobile Firefox with the Ublock Origin browser extension (it’s an ad blocker). These are ads, and I did not encounter the problem.
I moved my VPS and NAS to NixOS, and it’s been a good experience, but I don’t think I’d want to have to run a production system on it. I can get by because I have peers who know their way around it better than I do, and I think it’d have been a pain to get even the hobby projects up and running from scratch without that support. Given that, I can sympathize a little with the author’s complaints, but the article is a couple years old at this point, and Nix has been making some great strides in usability lately.
I stress it is only a personal feeling I’m going to express
I use NixOs on a daily basis. As metaphor: I feel like a peasant, that had worked the earth hard with his hands his whole life, that now has discovered some engineers that have assembled a rototiller, who kindly share the plans and the working production ready models. I won’t criticize the painting, the noise of the motor, and the user manual. These are areas of improvement.
I don’t think one single second about coming back to former ways of doing.
Because it’s a paragidm shift. The sort of things you don’t want to come back from once you get it. NixOs is not just a new Linux distro.
[Comment removed by author]
I’ve just started experimenting with NixOS, and so I’m particularly interested in criticisms of NixOS that might make me want to abandon it now before I get too invested. Here are my thoughts on this person’s arguments:
I’m only using NixOS in my capacity as a hobbyist running my own personal server infrastructure. I don’t care about hiring people or paying for support in this context.
Yeah, it could be better. Documentation usually could be. On the other hand I do understand functional programming, so I don’t care if the Nix configuration language is hard for someone coming from an OOP background. I think those people should become comfortable with functional programming. I did have a little bit of trouble figuring out exactly what things were possible with nix configuration syntax, which, again, better documentation of the language would fix.
Yes this is the entire point. I like the idea that I can describe everything relevant about the state of my system in one file. Writing custom systemd services is something anyone using a modern linux with systemd might have to do, this is not unique to NixOS.
I just realized that the version of the kernel on my test NixOS system is 5.4, which is older than I would like. https://nixos.wiki/wiki/Linux_kernel tells you how you can upgrade to the latest kernel, which I just did without trouble.
This sounds like some issues specific to AWS (which I don’t use for my personal infrastructure), and with a version of NixOS a couple years old. Not sure if this is relevant to anyone today, but it’s not relevant to me.
I haven’t done this yet, so I’m not sure how problematic it is in practice.
I don’t understand from this description what the problem was. It makes sense that when you do an OS update, you’ll have different versions of some of the binaries and need to rebuild things that depend on a hash generated from those binaries. I’m not sure how Docker images are coming into play here, or if this is relevant to what I would do with my linux systems.
I’m not sure what it would mean for a linux distribution to “support windows”.
I’ve been running the Nix tools on my laptop. Haven’t noticed them taking up too much space so far, and if they do I understand there’s a pruning mechanism.
Anyway I don’t find these points super-convincing, especially not for my own usecase (which is admittedly different from the use case of someone supporting production infrastructure at their day job).
For some quick background, I’m a casual hobbyist Nix user & fan, I first tried installing NixOS maybe ~5 years ago, but shelved it after some heavy & deep experimentation; discovered home-manager since and swear by it now; installed NixOS again recently on a secondary personal laptop that I bought for Linux (my main one is Windows) and now consider it a keepers for purposes of tinkering and Linux-based hobby development.
I will try to reply to your first sentence, though it’s not easy for me to put many thoughts in a concise reply. My main takaway is probably such, that it will break in different ways than your now-“HN-standard” Ansible/Chef/… setup. Mind me, not necessarily in more or less ways, but different ones. And given that it’s still absolutely an emerging technology, those ways will be comparably less well-known, and the community is smaller (esp. compared to current golden standard ArchWiki or askubuntu.com), so at times you might/will be a trailblazer in solving some issue. Also sometimes re-blazing some trail that someone else quite probably blazed before, but most people are still tinkering in their garages and there’s not that many bloggers & other public knowledge-sharers yet, and that one person you need might not be on IRC just now or they are but didn’t notice your question.
In other words, it’s an emerging/bleeding-edge technology with all that it typically entails. As to investment, if we knew for sure which investment is the good one we’d be all millionaires ;) Personally, if you like tinkering and playing, my subjective belief is that it’s a better moment to start playing with Nix than ever before. I would be hesitant to recommend that to anyone seriously those ~5 years ago, other than an interesting talking point, but over last months I’m definitely advertising home-manager left and right to anyone who has enough intellectual curiosity and hacker spirit. Going NixOS is still brave IMO, “jumping in deep water”, but if you like it and manage to stay afloat, you might find you’re reaping some benefits, and ahead of the pack splashing merrily in the shallow waters. Personally, if you’re really into deep water, I’d hertily recommend trying to go towards Nix Flakes ASAP. That’s a somewhat higher risk bet, but I seem to find they’re fixing a lot of issues I had with “classic” Nix originally.
I think one thing that’s kinda still open question with Nix, which to me personally (bear in mind, hobbyist user) is the only major point of risk where Nix might have trouble, is with managing secrets. I know some people are trying to approach this from various angles, but I haven’t yet seen an approachable (to me) writeup explaining if someone really found a sensible and practical way to do that. I’m not sure if some solution/workaround will emerge, or will it require a major breaking change/evolution in Nix. I personally think there’s some chance this might be a risk to Nix’s solid mainstream position sooner or later. (And alternatively, some unexpected future technology might possibly unexpectedly outpace Nix to its own success.) But personally, I see Nix (esp. recently) on a trajectory to mainstream.
Said a (pseudo-)random stranger on teh internets.
I sometimes contemplate the security of
nixpkgsand I think anyone that uses nixos for production should as well. Currently there is no authenticity in the commit process, and I don’t think there is a list of people with commit access to the repository yet.Relevant issue: https://github.com/NixOS/nixpkgs/issues/20836
The reason why is because there is an opinion about gnupg being bad (it is), thus the additional requirement of signing commits would present a barrier of entry. This is at the expense of the integrity of the repository. Currently one compromised user (2FA is required for commiters) or a mismanaged webhook would be enough to compromise a package build (I don’t actually think the nixos folks would add a webhook this way). I do think gnupg gives value in the process here to ensure simple user compromises can be avoided. If not the drive-by commiters then the repository maintainers should.
Even if a
nixpkgsmaintainer isn’t compromised someone with the maintainer tag on a package has no requirement for 2FA and there is no way to validate who created the commit.gnupg is terrible to use, but as long as there isn’t any proper substitution I think it’s a bad idea to have no signatures.
There was recently a thread on NixOS discourse about the nixpkgs trust model:
https://discourse.nixos.org/t/trust-model-for-nixpkgs/9450
Edit: link updated to point to the topic rather than a specific post. Thanks @Foxboron for pointing out the incorrect link.
That’s true, but package maintainers cannot merge commits in nixpkgs, only people in the nixpkgs-committers group can. So, at the very least their changes are reviewed before they are merged.
But you have no way to prove who merge the pull-request though, except for the unauthenticated metadata in the commit. I also assume that the “malicious commit” problem mentioned in the issue would escape the member of
nixpkgs-committersbecause of the inherent trust in package maintainers.And from the thread:
The same argument can be made for any binary distribution which has a fairly straight forward way to bootstrap. I don’t think that applies to nixos(?). I don’t think it’s a strong argument for nixos that the reply to “you might not want to trust nixpks” is “rebuild everything”. It escapes the underlying problem because you are still building with the same sources.
You can’t recreate the package either. nixpkgs doesn’t guarantee bit-for-bit determinism even if the metadata for the derivative is identical.
Okay, I laughed a little bit. I don’t know if this is a poorly worded argument. But no community based distribution is superior to any decade old enterprise distribution with people working on it. And the counter argument is easy; Where are the nixos security advisories?
(I know people are working on nixpkgs security, but the blind zealotism like this is a bit sad. It hurts progress.)
Not a fully satisfying answer, but you can in the GitHub interface. GitHub links merges or rebases to PRs. Of course, relying on a proprietary interface is suboptimal.
I agree that commit signing would be better (if you have devised a good way of establishing trust). But most people dislike GnuPG, for good reasons. If there was only a simple replacement that also supports hardware tokens.
Even though package maintainers build up trust, I have never blindly merged a PR because it is from a maintainer. I check every PR that I merge carefully. Given the feedback that I get on my PRs, I have the impression that other nixpkgs-committers do this as well. There can, of course, be exceptions.
Agreed, but you also cherry-picked some of the more zealous comments ;). There are also a lot of active contributors who acknowledge current issues and suggest remedies, such as:
Anyway, security is a process and I hope that the NixOS/nixpkgs community can address some of your concerns in the future. I think a first good step would be to describe the current trust model somewhere, so that users can decide (based on their threat model) whether the trust model is sufficient for them or not.
That’s not really anything. Git shows the author based on the author or
Co-authored-byso it is in no way a form of associating a code change to some author.I would really love a solution here indeed. I still think GnuPG should be used until something is implemented. But I reckon I’m maybe in the minority in this regard.
I think being aware of the potential issues helps keeping people aware of the responsibilities they have when hitting that merge button. But I think defining a threat model where you consider a compromised commiter and/or malicious pull-request from an established packager are useful to work with.
Oh, you linked directly to that reply so I thought there was some intention behind that. I did read through the thread afterwards and there is a good discussion there as you pointed out!
I do hope so! But until then I do think it should be a something to be aware off if you consider running it in production. For hobbyist use most stuff is fine really.
That’s not what I meant. Go to a merged PR, e.g. this ‘rebase merge’:
https://github.com/NixOS/nixpkgs/commit/b193bc75adad98359d2a48d90bb7dfec1cf264c8
Below the horizontal line, there is a reference to the corresponding PR (presumably, GitHub’s database links commits to PRs). Click the PR number, which takes you to the PR, which is linked to the GitHub account that merged the PR.
My bad, sorry! I will update the link, in case anyone else follows it.
Right, but this doesn’t really prove anything.
Nothing is signed so you only know that someone with access to the github account
jtojnarhit the merge button where the presumed author of the commit iserictapen.And not to discredit any of the authors, but there isn’t a whole lot to establish identity here. If nixpkgs where to move off github the strict connection between the commits and the accounts are broken. With signing keys there would at least be some private key that would be compromised to forge these identities.
The information in github proves which accounts did each thing. GnuPG proves that a certain key was available to whatever process created the commit. Neither proves that the named human was involved or that the source committed was as they intended.
If you’re trying to manage the security of a project you’ve got to come up with a threat model and decide that some external things are trusted, otherwise you can’t get anywhere.
One is strictly tied to a proprietary vendor though. In the shower I tried figuring out what would happen if Github would disappear tomorrow. Arguably NixOS would have a few problems, but reestablishing the maintainer usernames to some presumed identity would be a hard one.
This is why a private Web of Trust (for example Debian and Arch) is useful. The identity of the packagers are separate from the service used.
The problem here is that there is nothing to anchor the trust in though. Formally stating a trust model (which has been mentioned) would help a lot though.
It wouldn’t be that hard, you’d use email and some side-channel communications to establish a web of trust.
And sure, you could do that earlier, but then you have to pay a big co-ordination cost persuading people and maintainers will have to use gnupg, which is a barrier to entry. Github isn’t going anywhere soon, and even if it did you could move to gitlab or whatever, so why pay that cost before you have to?
You are moving the goalposts a little. You said:
Even though I may not know
jtojnar’s real identity, I know thatjtojnaris someone I can trust, since they have a long history of valuable contributions to the project. So, it proves to me (if I trust GitHub) that a pull request is merged by an identity that I trust. So, does it prove who merged the pull beyond “unauthenticated metadata in the commit”, as you originally stated.You don’t have to convince me that proper commit signing is preferable ;), I fully agree.
Ah, the intention wasn’t to move the goalpost. My bad :) It felt more like clarifying the problem I had with the pull-request flow. But yes I agree with the explanation.
For thr commit signing case the entire gnupg UX is that after you type “git commit” you must type your password. For me a little GUI box pops up and asks for my passord every niw and then while using git.
I’m interested in your suggestions for how this could be improved.
The git integration is easy. gnupg is not easy. There is a lot more to commit signing then just
git commit. Properly secure the keys, subkeys and gnupg key administration is the hard part.I don’t know why a commit signing user would even need to know the word “subkeys”? It’s true they will need to initially generate a key somehow and set a password on it. While the seahorse GUI is quite good, for someone not planning to use gnupg generally the easiestwould probably be to have docs on what command to paste to generate a new key. It will ask to set a pssword and then you can forget about it again.
This is a mysterious rant.
Like – the first couple points (re: the small community, poor documentation, & the need to learn their specialized language) is essentially why I rejected Nix as a personal workstation distro – but practically everything in industry is like this, so if you’re being paid for every hour you spend learning a specialized config language (like, you know, a DevOps professional), why not take advantage of build reproducibility? Like, you’re getting paid to fix a common problem with deployments while simultaneously adding an overhyped technology to your resume.
Where I work, until we moved from our own data center to the cloud a couple years ago, we spent dozens of man-hours a week vetting source code for standard third-party tools & patching them so that they’d build against the last toolchain somebody in the org had completely vetted. We had a six-month three-man project to move everything from glibc to musl. When we brought in a library written in fortran, we had to port it from fortran 90 to fortran 77 because the f77 source code was vetted but gfortran was not – which meant that somebody on staff needed to learn fortran. It was a nightmare – and one we put off by switching to docker images (at, IMO, a great cost). NixOS seems like it addresses some of these issues under certain circumstances – and that’s extremely valuable if you have the kind of security-anal folks in charge of your package set who think reading the entire LLVM codebase to vet for a “reflections on trusting trust” situation is a good idea on company time.
(The bit later about windows support, though… What does that even mean?)
My guess is that it’s a comment on Nix, the package manager, which you can install on non-NixOS machines. Charitably, the comment is about WSL, not Windows proper, though I think I managed to install Nix on my WSL Ubuntu last year.
Alternatively, it’s an anticipatory comparison to the later mention of Docker, which runs on Windows proper.
Indeed, single-user installs work fine under WSL2. Multi-user is more work, since WSL distributions do not systemd, you have to ensure that the nix daemon gets started.
This is an old article – we’re using NixOS on all our systems at work, and it all started on AWS in 2019. NixOS was resizing the volume and there were no issue with AWS integration. The only annoyance is that the AMIs created by the NixOs team are created sometime early after the cut and never updated. So as one approaches the next release, and wants to upgrade the system, there will be a lot of fetching. Also, sometimes the AMI will be late to arrive :)
Oh, yes, totally bad idea. Docker is for isolating the dependencies of a system and packaging them together. Nix is a packaging system that ensures you have all the dependencies you declared ready when you want to run your tool. Why using the same tools (or, why zip the tar.gz archive?). I just think the author of the article belongs to the class of people that mixes up Docker with VMs…
NixOS is not a silver bullet and it’s a lot of time & money to invest in it, with a risk of breakage which will be very tricky to troubleshoot for a newcomer.
With that said, accusing others of lying (like in the quote below) is just so…immature. You don’t have to like what I enjoy, but accusing me of lying just because you don’t understand what I like?
I don’t even care about reproducible builds, but NixOS is hands-down the most pleasant user experience. The only reason that I wouldn’t want to use it is pretty hard to find some binaries. Recently I wanted to use the objdump, readelf, and strings binaries. Apparently, they are in the binutils-unwrapped package… Also, compiling stuff that uses OpenGL is a bit of a pain, and I had a hard time installing vmware horizon.
nix-locatecan be useful for this. It’s in thenix-indexpackage. e.g.Usually it’ll give you one-line with the answer you want, but a ‘bin/objdump’ appears in many packages, so you have to pick out the most relevant-looking one here.
I’ve started using nix-index to find binaries. After the first run nix-locate finds all binaries with the matching substring.
We use K8s at work (dev (but really it’s a royal pain for dev) and qa/integration - and will be used for prod at some point). I spent some time playing with the Hashicorp stack over the holidays and since @cadey s recent posts about it I’ve been lookiing into Nix more lately.
I am more than a little intrigued by the idea of Nix and NixOS (and I guess NixOPs too) but the learning curve for it has been frustrating in that there are lots of example blog posts, but they all seem to be missing the bigger picture of how it all fits together (eg when I look at the Repos associated with the posts, there are a plethora of .nix files but no sense of how/when things get called/resolved).
I had little trouble getting the Hashicorp stuff running (upto and including waypoint) and was pretty nice to work with but the infrastructure and overhead needed seems too much for a single box side project.
I would love to experiment with Nix for said side projects, but my VPS provider of choice would not make it easy to use without manual intervention and so I spent yesterday filling in some notes on a process supervisor/deployment framework that I’ve been thinking about for a while (often saying to myself it’s not needed if I have X) that will run on a Plain Old Linux Box but still allow for automation around builds and deploys.
I think taking up Nix and immediately trying to use it in such a context is a lot to take in and will most likely end in frustration. Although NixOS is a Linux distribution, it is not like any other distribution and switching to NixOS pretty much amounts to learning an alien Unix system. Sure, the regular Unix commands are there, but otherwise the system is not like any other Linux distribution. If you want to user Nix in more complex setups, there is no way around learning the language (easy if you are familiar with FP, otherwise harder) and how nixpkgs works. Sooner or later, you will have to write your own derivations, and that will be painful if you do not know the language and nixpkgs functions and conventions.
A good place to start is using Nix as an extra package manager on a local Linux or Mac workstation/laptop. This not only gives you access to many packages (more than most other package sets), but also gives you ad-hoc development shells (with
nix-shell). To make it less ad-hoc you can create per-projectdefault.nixfiles orshell.nixfiles. Basically using Nix as a way to manage virtual environments, but then for any package. These don’t require you buy into Nix immediately, and you can just use it on the side. If you don’t like it, no harm done. Blow away~/.nix-profileand uninstall Nix.A good way of playing with declarative configuration, without immediately switching to NixOS, is to use Home Manager. It allows you to declaratively configure your home environment (basically dot files + packages). It gives you some of the benefits of NixOS, without immediately jumping into a foreign environment. If you like Home Manager, you’ll like NixOS and it’s a good point to jump ship.
I like the idea of NixOS, but I still haven’t found a concise guide on how to build my own nix expressions, and without that it’s a huge pain in the arse to get many projects working.
Nix has its own way of doing things, but they’re unfamiliar to me and slow me down a lot. Often, I want to try out some software and I don’t care if I can install it reproducibly - I’ll worry about that only if it turns out the software is useful and I anticipate I’ll need to share the process.
I think I had the same issue. What I ended up doing is defining a single shell.nix which I use for all projects. That way, I don’t need to remember how the thing works and can just symlink it for each new project.
Just to clarify, if the thing is fairly popular, than
nix-env -i cool-upgenerally just works – nixpkgs is large.The pain starts only if the software is not packaged, in which case you’d need to write your own nix expression, or to patch elf. There’s also a mysterious
buildFHSUserEnvwhich I think can make binaries from the internet to just work, but, alas, I haven’t found a concise guide on how to use it )In some of those cases
buildFHSUserEnvcan be helpful, it can be used to build lightweight sandboxes with an FHS environment. E.g., I have used it in the past to set up Java and Python environments that I don’t care to properly package. It’s also used within nixpkgs for a handful of packages that are difficult to package otherwise.The bottom banner ad and un-dismissible newsletter signup banner makes this article a difficult read on mobile
I highly recommend using mobile Firefox with the Ublock Origin browser extension (it’s an ad blocker). These are ads, and I did not encounter the problem.
It put me off the whole thing.
[Comment removed by moderator pushcx: This added nothing to the conversation.]
I moved my VPS and NAS to NixOS, and it’s been a good experience, but I don’t think I’d want to have to run a production system on it. I can get by because I have peers who know their way around it better than I do, and I think it’d have been a pain to get even the hobby projects up and running from scratch without that support. Given that, I can sympathize a little with the author’s complaints, but the article is a couple years old at this point, and Nix has been making some great strides in usability lately.
[Comment removed by author]