A lot of odd Nix hate in here, or at least extreme dislike.
NixOS is so very usable. There are a lot of foot-guns but that's true of Linux systems.
It takes some time to get comfortable with all the different ways to configure stuff. There's a new language, a new build system, a new Linux distribution.
I've spent very little time relative to say, figuring out dpkg or systemd, or learning Bash or C or Perl, or learning the Linux FHS.
NixOS makes running deterministic systems driven from a single configuration incredibly easy.
Nix the language and tools allow you to build software deterministically and create environments where that software is available (e.g. on $PATH).
Nix Flakes is an experimental feature aimed at bringing reproducible and hermetic configurations of dependencies into the fold (i.e. lock files, ala Gem or Cargo or Go Modules).
Nix-the-tool's interactive "package manager" should be deprecated, as it's a huge pitfall for most developers. But it works and is frankly a good first step for folks coming from Apt or Homebrew.
Learning to write modules is probably the steepest learning curve, but compared to learning how to build RPMs or Dpkg or Brew recipes, it's really not bad at all. I actually find it easier and I've been at this for less than a year. Sure, if you're trying to get something working no one has figured out yet you may be in for a pickle, but that feels like it's always been true. The difference is a lot of software breaks and bends the rules and boundaries constructed to keep things and people sane. Nix does not allow that, generally, which is a very good thing. Fixing other people's garbage is the bane of any package system maintainer, it's no different here.
Crazy thing about NixOS is that it's so good, all the bad parts can be excused. I like to go on forums and complain about how the Nix configuration language is horrible, and there's not much documentation on how to get general things done.
But that said, I'm still running NixOS on my servers. And no way that I'd ever go back to old fashioned provisioning scripts like Ansible.
Just yesterday I had a problem upgrading a machine that's been running for 3 years without updates, and it wouldn't upgrade to the latest version of NixOS because of some certificate issue I couldn't figure out. Tried a couple things, nothing worked, gave up and destroyed the box. Installed the latest version of NixOS on it, pulled my configuration from git and it's back online exactly how I want it.
It runs 5 websites in docker containers with a reverse proxy that automatically gets its SSL certificates from Let's Encrypt, some other services, and a tmux session with irssi. Everything neatly managed by systemd through unit files, everything set up from one simple nixos configuration.
If I'm complaining about NixOS, it's because the best server operating system in existence right now has flaws. Not because I'd ever go back to a traditional linux distribution.
> Crazy thing about NixOS is that it's so good, all the bad parts can be excused. I like to go on forums and complain about how the Nix configuration language is horrible, and there's not much documentation on how to get general things done.
I don't think it is fair to say that Nix as a programming language is horrible, IMO, as a DSL it is pretty good and fits the domain well.
It is a strange language at first and it takes some time to learn all its quirks. Also, it lacks better tooling, things like LSP for example (there is one but it is slow and limited last time I tried). But just claiming the language is "horrible" is really unfair.
I think it's fair. It is, by far, the biggest hurdle to adoption and contributions.
I'm a SWE and I don't grok it yet.
Granted, I haven't spent a ton of time on it. But if you have to spend a ton of time on it, it has in some sense failed.
It's harder to learn than literally any other language I can think of that isn't designed specifically to be esoteric. Most languages, after you have picked up a few, you can just glance at and you've got the basics. Nix is its own beast entirely.
Edit: I do acknowledge that there is some difficult to manage inherent complexity. And, like many others, I love what Nix is trying to be. But I do think improving the language would be a big step.
I mean, I am very used to pure functional programming and I still find Nix quite challenging. For a lot of reasons. The abstractions are all weird, there are so many pieces that are confusingly put together, etc. Lots of stuff.
Even the PL itself is really weird and unfamiliar. And not super well documented. I remember spending a while not too long ago trying to figure out how to interpolate a string. And then you have goofy stuff like with, etc.
Exactly. Before learning Nix I used Elixir and Clojure, so I was pretty much at home using a functional language (even if Clojure/Elixir are not exactly pure functional, but they come close with their immutable data structures).
The other thing that trips some people is that Nix has lazy evaluation. Even Elixir or Clojure uses eager evaluation, so this concept is even more uncommon the functional programming. However, this concept bite me just a few times, so it is not like you have frequent issues with it.
In my experience, the biggest problems for learning Nix (the language) are the lack of type annotations and the tendency to separate function calls from function arguments. The first time you look in `my-package.nix` you find... a dict of function arguments? I think? What the heck? What function takes these arguments? What function arguments are valid?
So you end up grepping the whole source tree for `"./my-package.nix"` just to see what functions are using it, and you find this construct:
someFunction ./my-package.nix
Which in other languages would be the slightly bizarre
So you're pretty sure these are arguments to someFunction, but it's weird that the call to `someFunction` wasn't in the same file, because it makes it hard to know what's going on.
All of this this wouldn't be so unclear if the syntax wasn't visually similar yet semantically different from most languages. The map syntax in particular looks exactly like a block in curly brace imperative languages:
{
foo = "blah";
bar = foo + "blahblah";
}
----
Fortunately, there's work to separate Nix (the tool) from Nix (the language), so that any configuration language can be used to produce derivations. Nickel has been one of the drivers of this push:
This is exactly what I meant with "there is one but it is slow and limited last time I tried", but it does seem that they made good progress (the last time I tried it was some months ago).
Yeah, I'm just waiting for Jeff Geerling to get onboard with Nix. Then things will get interesting (he's a big Ansible buff and probably the biggest RasPi Youtuber).
I disagree. I don't use Nix, but I've been in situations before where an upgrade either couldn't complete, or catastrophically broke something. Those situations are horrible and can take hours or days to resolve.
Having the option to say "fuck it" and just reinstall everything, without worrying about manually installing exact software versions and reconfiguring everything sounds amazing.
I think the important thing that did not come across very well is that "wipe and reinstall" with nix is so incredibly painless that doing it is even an option. The same would be very very painful with other distributions. A clean reinstall of your whole system with nixos takes maybe 30 minutes. Compare with the average "my Ubuntu upgrade failed" debugging session...
Yes, and speaking of… the fact that “generations” are a central feature which allows seamless rollbacks to previous system states means that if your upgrade fails you’re hardly ever more than a few minutes away from a functional system again.
Wait, isn't a point of NixOS is that your updates are guaranteed to be smooth? I haven't used it, but your story now worries me. I don't want to be back at "just reinstall the OS" days, even if configuration is portable.
> And it wouldn't upgrade to the latest version of NixOS because of some certificate issue
This sounds like Lets Encrypt changing it's protocol. Nix itself doesn't give a shit about such things, but maybe some sort of script was supposed to double-check the cert on boot (just speculating). While NixOS can be reproduciable, whatever software Let's Encrypt runs is obviously outside the host's control, so perhaps "leap-frogging" to the latest NixOS somehow helped.
This is incidentally a good example at why I am pretty against microservices (not saying Let's Encrypt is a bad or a microservice, but it is the analogue of one in this parable).
I couldn't figure out what it was, but it was definitely a problem with NixOS itself, possibly with expired root certificates or something like that. The upgrade command couldn't connect to the nixos servers. I know there was at least one root certificate that expired in the past 3 years, so maybe I just caught a bad interval for not upgrading.
On NixOS installing any package is the same as reinstalling the operating system. Reinstalling the operating system just took a minute longer because it had to do more downloading. (edit: in theory, I actually bet that the certificates sneakily leak mutable state into the system with the expiry process, i.e. I bet that if I reinstalled the same version of NixOS with the same configuration, I'd get an install that would actually be able to talk to the nixos package servers)
But you're right to be worried a little bit, and this is exactly why many people criticize NixOS. In theory it's the most perfect operating system, but in practice it's so complicated that when something's bugged it's really hard to figure out how to recover, and the documentation is not up to the task of educating you on what to do when things are wrong.
Also this situation was a bit special because it couldn't talk to the NixOS servers for upgrading (I presume due to an expired root certificate, but I couldn't figure it out), if it was any other problem, I could simply roll back the upgrade process (which would be instantaneous because it doesn't actually remove the old packages when you upgrade).
With a cloud server it's obviously less of an issue, but even with a desktop for Nix its less of an issue than any other distro.
Each time you update your configuration it's essentially reinstalling. When you boot you have the option to boot the previous version (which includes previous app versions and etc).
Reinstalling NixOS and updating it are extremely similar actions except for full reinstalls having data loss (formatting) and taking longer (cache is empty).
When you use Docker you probably don’t configure your websites using Nix so there is no deterministic build happening here? In Ansible it’s just a few lines of code to start a Docker container. I’m not sure how Nix really helps here.
In Nix it's also just a few lines to start a Docker container. I might be considered a heretic by the Nix community, but I don't believe in the advantages of Nix for software development / application configuration. Docker is the end all solution to that problem in my opinion.
I haven’t used full-on NixOS yet, but I’ve used the Nix package manager quite a lot, and literally all of my forays have been miserable for a variety of different reasons.
To be clear, I love what Nix aspires to be, but it doesn’t deliver on its promises IMO.
As a package author, the Nix language has lots of rough edges, it’s absurdly tedious to figure out how to call various functions (what type of argument does it expect?) because it’s untyped and nixpkgs is poorly documented. There are too many other issues here to unpack.
As a consumer of packages, it’s often unclear what I need to do to install anything but the simplest packages. E.g., installing vs code with some plugins (note that this differs between NixOS and other systems). Further, the CLI interfaces are confusing from a UX perspective IMO, and it’s often unclear what I actually need to use Nix well (homemanager? flakes?) the guidance is confusing and contradictory.
So I don’t hate Nix, but I do have a lot of constructive criticism.
>So I don’t hate Nix, but I do have a lot of constructive criticism.
Why not write a blog post? Probably some of those issues are known but no one works on them, so a reminder isn't bad. And for those that aren't, maybe someone picks it up and tries to fix it.
Also considering posting your ideas to the Nix forums or possibly github issues, lots of activity there and you’ll probably get some good feedback before publishing.
The UI for Nix has been under significant rework over the last ~3 years, but the new UI isn't ready for primetime yet, so none of it is made prominent now. It's getting there though.
There’s no official support for non-free but the GUIX community has created a number of channels for non-free packages. I believe this is the main one:
Yes, but you won't likely find help for NonGNU software in the offical GNU Guix channels, IIRC they have a banner on their libera.chat that says you shouldnt be asking for help with non-free software here.
I have no opinion about NixOS but every time I read someone touting its merits I feel like I live in a parallel universe. NixOS seems to solve problems I never had at extreme costs to its general usability.
I don’t care that I can rebuilt a computer identical to mine in minutes. I don’t change computer often enough for it to matter and the tweaking I do is minimal because frankly tweaking configuration is not fun and feel like a gigantic waste of time. Same things for reproducible builds, I like them as a developer for the things I work on because they make things easier to manage and debug. I couldn’t care less as a user. I just want things to work.
I guess it could make sense for servers as an alternative to provisioning tools but then it seems to me like it’s competing with docker and kubernetes and I have never seen a convincing argument about why it would be better.
I think that’s why you see a lot of things you view as dislike. Plainly speaking I think most people don’t see the point.
The "market" for Nix is honestly OCD people that care about the software production process --- "god willing" our fastidiousness will eventually pay off as everyone else slowly boils in "accidental complexity", and our decisions finally make sense to others. In the meantime, it's hard to convey the benefits.
For now, I argue there is surprisingly little business case to care about developer efficiency --- VCs want you to blow cash, and increased developer outsourcing with remote work is covering the stupid complexity costs the cloud imposed. Mainly, businesses are demand constrained. That there is tons of embarrassing supply chain issues rights now is to me in accordance with this. America has gotten really good at advertising and customer acquisition, but we've lost skills at actually doing the basics, as it is really easy to service whatever demand you can scrounge up.
So far now, you either really want a clean workbench, even at the cost of dealing with the complexity that cleanup exposes, or you don't. That says whether Nix is or isn't for you.
> it seems to me like it’s competing with docker and kubernetes and I have never seen a convincing argument about why it would be better.
This seems to indicate a huge mismatch between what you think Nix/OS is compared to what it actually is. NixOS is for creating/maintaining systems, Docker is for running applications and Kubernetes is for running applications but across multiple servers, neither of those tools are like the other really.
I would argue Docker and Kubernetes are a bunch of crap popularized by people lulled into blowing all their money to cloud providers and compelled out of envy to imitate big tech -style deployments, even though it means taking on extra problems you absolutely don't need to deal with.
Also, Docker and Kubernetes are...just more layers. There is no cleaning up what came before. The Nix ecosystem is about drilling all the way down and cleaning up the prior tech debt. It's a fundamentally different approach.
Again, misunderstandings seems to run rampant in this thread...
No, Docker doesn't maintain systems, it handles applications. No one runs systems inside of Docker. People run applications with Docker, and Docker itself runs on systems.
And no, Nix doesn't "do this differently and better", as what Docker does and Nix does is wildly different. Nix is for machines, not applications. Sure, a subset of features from Nix can be used like Docker, but that doesn't mean Nix and Docker is the same, no matter what you think of markets or whatever.
I think what the parent is alluding to is: What is the practical point of using Nix when similar outcomes can be reached with more mainstream solutions? In other words, suppose I want to deploy a web app that depends on Nginx, PHP, and PostgreSQL.
I could:
(a) Run all as docker-compose type solution
(b) Run all as scripted Nix solution
(c) Install packages manually on general purpose OS
Lets ignore "c" for the moment as the goal is to avoid that exact scenario. Given the prevalence and widespread support for "a" why should sysadmins choose "b"?
I don't understand how you can use docker-compose, docker, Kubernetes or anything else to achieve the same thing as NixOS. NixOS gives you a fully reproducible personal computing system, from boot config, window manager, partitioning to applications, home directories and everything in between.
What mainstream options are available for doing this? Guix could be one option, but it's not mainstream so I'm not sure what tools you are referring to.
Guess I'm missing the whole subject of this thread then. The submission is about NixOS, which is for full systems (like in personal computers), something you cannot build with either Docker nor Kubernetes, the technologies that WastingMyTime89 said seems to compete with NixOS.
Eh you can do the same thing (or close enough) with a bash install script on a "stock" linux system and then a docker set up with the applications that that you want. Or with ansible. it really depends on the end goal. Not everyone needs every single bit to be the same. Or you can just image a drive. It depends on the end goal and often multiple solutions will get you there.
These are the nasty solutions I have to deal with at work all the time and my entire job consists of handling things when the "quick" bash cloud init script that someone wrote and various people have made additions to over the years goes wrong.
Bash scripts fail at this task because they are generally not convergent. Ansible makes a basic effort at being convergent, but most of the scripts I've seen are extremely naive about the ways in which a configuration can diverge.
And why would someone want that? Sure it sounds theoretically nice, especially if I was still working in IT. But learning another system with a poor ui has a large cost for a theoretical benefit.
Nix is (a) and (c), depending on how you want to use it. What differentiates it from docker-compose or `dnf install` isn't just the fact that you can ship something in containers or install some packages but also the various properties those containers or packages inherit from the build system.
Yes but no. Docker is mainly used for its ability to build and reuse standardised containers. It’s very much a distribution mechanism (I mean that’s why it’s called docker). From other comments I get the feeling that NixOS could be used to build reproducible containers in a way that remind me of building tools like Bazel but it’s not entirely clear to me why you would chose to do that nor if it’s actually a goal of the product.
> I guess it could make sense for servers as an alternative to provisioning tools but then it seems to me like it’s competing with docker and kubernetes
It’s not competing, it’s complementing. Think of it as a fully deterministic “docker build”.
Yes but « docker build » already exists and can already be made deterministic so it’s indeed somewhat competing. Would anything be easier by using Nix?
Right now it seems to me like a large ordeal with little to no benefits and my interaction with the Nix community hasn’t been very convincing. A lot of Nix users seem to believe determinism and reproducibility of everything to be enough of a justification in itself. I don’t think it’s worth the pain.
The biggest limitation of using Docker for building images is that it does not allow for composition. You can't simply say you want to combine a Python and Rust image for example.
With dockerTools from nix (https://nix.dev/tutorials/building-and-running-docker-images), this kind of composition is easy. You also end up with significantly smaller image sizes - containing only exactly the dependencies needed for the image to work, which is also good from a security perspective - since it decreases the attack surface.
> « docker build » already exists and can already be made deterministic
Truly deterministic Dockerfiles are a rare thing to find among the ecosystem.
And we haven't even got into docker's poor support for unprivileged container building which leads to weird solutions using dind when you need to build an image from inside a container..
Two examples to get a taste of the tradeoffs and utility it provides would be postgrest and IHL.
I think it’s sexy. But like you I haven’t had the time to really dive into it and understand it. The promise is simplification, both operational and in terms of the runtime.
> A lot of odd Nix hate in here, or at least extreme dislike.
I hate this expression. I'm a nix user. But if you can't understand why people dislike it... you're the one that's odd and out of touch.
If you want people to adopt nix the worst way to convince them is to call their behavior odd when it isn't.
The reason why adoption of nix is so low is trivial. High initial learning curve and it's so different from everything else that's out there. The only reason why I got over that learning curve is because my company uses it. If it wasn't for my job I would not have have the will power to climb over that learning curve.
Like seriously can you not see that someone is not willing to spend months learning nixos when they can get a pretty much from point A to point B using a turn key solution like ubuntu?
Nix is great. But you need to climb over the initial hump. That is all.
What we dislike is everything talking about the costs, and not the benefits. Fine if it's not for you --- I personally care more about institution and upstream adoption than getting more random end users at this point --- but people passing off these one-sided cost-and-no-consideration-of-benefits analyses as engineering decisions is a bit grating.
To me Nix is hard, but Nix is worth it. I acknowledge these people's pain, now would they acknowledge my pleasure (ideally without writing it off as that of a cult inductee! :)).
> What we dislike is everything talking about the costs, and not the benefits.
Exactly. I tried to push really hard our company to use Nix/NixOS (and maybe in our case nix-darwin too, since the majority of engineering uses macOS), but it never went anywhere (I did convert a few of my colleagues to use NixOS though).
But why? Well, onboarding is a pain in my company. We have some Ansible scripts that always break in some innovative ways, so it takes a whole day to setup a new machine for a bunch of engineers. Sure, partly of the fault is the fact that our Ansible scripts are really hacky (in some steps they still call some Bash scripts instead of using Ansible DSL for example), but Ansible is simply lacking in some places to have a really pleasant experience.
If we could use NixOS though, this would be a very different matter. I use NixOS in the same company, had the same configuration for pretty much 1 year, and also survived a broken laptop and setup my whole setup in like 30 minutes (most of time spend downloading packages actually). I even separated part of my NixOS configuration in another repository so other engineers using NixOS can also make use of it.
Yeah, it took a long time to get where I am currently, but nowadays I just stopped worrying about managing system, system update breakages, and anything like this. I can just use my system, fully up-to-date, and I know if something breaks, I can revert. It is beautiful.
Yeah I ended up working at a place that was already using NixOS -- as in developer laptops come with NixOS, and that was definitely a huge plus. Much nicer when the war is already won, and there is no class of macOS or Windows-using devs to appease!
> But if you can't understand why people dislike it... you're the one that's odd and out of touch.
Oh I know by now why people dislike it. I've worked for years with it with engineers of all stripes. It's always big heads and bad attitudes and never Nix itself.
And Ubuntu isn't a turnkey solution to what people use Nix for lol.
> A lot of odd Nix hate in here, or at least extreme dislike.
I don't have any doubts about the likes of Nix or even other attempts at improving the reproducibility of building and installing packages being technically superior to what we have now in some ways.
But at the same time, you can't forget about people and in some ways the industry taking the path of least resistance whenever possible.
You want to introduce a good but somewhat complicated way to manage packages? People will simply use "apt" while its UI/UX/DX is easy to get a hang of.
People get sick of differences between environments and how hard it is to deal with everything from resource constraints, port binding, configuration management, persistent data handling etc. in *nix? Many of them will turn to shipping VMs, tools like Vagrant or more recently - Docker.
Thus, it stands to reason that for any tool to become popular amongst the "common folk", not just brave early adopters or very technically able people, the tool needs to be easy to use.
I guess that's also why i'd say that more people use Linux distros (GNU or otherwise) as opposed to something like the *BSD OSes, even if those also have some notable benefits in regards to stability, networking performance, in-tree development etc.
Nix is common among consultancies because the more switching between projects you do, the more it pays off. If you like every 6 months (or merely every job change!) fuck with APT, your bashrc, etc. with a little stack overflowing during onboarding, whatever. It's too rare to be worth optimizing; I get it. If you switch projects every 2 weeks, the calculus changes greatly.
I do work at one of them now, but I got into Nix as a student hobbyist, when I was also rotating through homework assignments and personal projects quickly.
> Nix is common among consultancies because the more switching between projects you do, the more it pays off.
I feel like this is perhaps situational? I am yet to see Nix be used once in about 5 years of development in many projects in Eastern Europe, both governmental in private sector.
Though maybe the industry here is lagging behind trends - only in the past 3 years or so Docker has started gaining a foothold and even large corporations are just figuring out how to run their own Kubernetes clusters and Docker Swarm is still in use in some places, or even just Docker Compose.
Then again, some of these projects don't even have systemd services in place to ensure that they can be controlled easily, so who knows... Manually launching Tomcat or GlassFish instances never inspires confidence.
> I feel like this is perhaps situational? I am yet to see Nix be used once in about 5 years of development in many projects in Eastern Europe, both governmental in private sector.
Hah!
Nix is super European, and from my American vantage point the more west you go, the fewer Nix users there are! I first learned of the whole Eastern Europe consulting phenomenon via the Nix community too.
Yeah, good points. Nix has been as-yet very pointedly a developer-centric ecosystem. And not just that, but developer-centric for people who favor functional programming in general.
There's some work especially in the last few years to make it all more approachable, but that's the background. Wait a couple more years and you will see more projects like Nix GUI here start to mature and then it will get very interesting beyond people who have backgrounds in, e.g. distributed computing and Haskell.
Nix(OS) purely with Flakes i.e. without channels is so f good that I'm not using it just as my daily driver on a PC and to package software and create development environments...
I also replaced Buildroot with it for building embedded images for SBCs. Lifechanging experience.
I have went pretty deep in nix recently and imo the "Fixing other people's garbage is the bane of any package system maintainer, it's no different here" + high learning curve + lack of xattrs and permissions support in nix store makes it a bad OS. The amount of custom code to fix "issues" and "issues" that are only fixed because the maintainer thinks he knows better than the dev is too big to be maintainable. Still a good package manager for eg macOS if you dont need that.
> Fixing other people's garbage is the bane of any package system maintainer, it's no different here.
I honestly think it's hard for "Nix to Nix" simply because by trying to make everything reproducible, it is dealing with more of upstream's garbage, and "reifying" the hoops that people jump through doing sysadmin things in code looks scary.
I really want more upstream developers to use Nix, so they might loose their myopia, and start thinking of the the FOSS ecosystem as a whole, and not just their own packages within it. Nix is the best way to get the bird's eye view, I am sure. Just try not to gag at what you see!
[1] Though I still maintain that contributing to Nixpkgs is much easier than contributing to e.g. Debian or Fedora.
Yeah, exactly. Nixpkgs is basically the largest and most up to date repo in the Linux world now. Most of that’s coming just from the small existing core community. That has to say something for the efficiency of it.
Reproducibility is not the only issue they're facing. I think the mentality extends to more than just fixing linker issues, e.g. this https://github.com/NixOS/nixpkgs/issues/9656
At the end of the day, I much prefer trusting upstream than having to trust packagers to do everything right.
Having your screen locker which is written in C be setuid root is a really bad, really insecure idea. That it's supposedly being done for security reasons is replacing a minor, difficult to exploit security issue with something that's essentially guaranteed to be vulnerable.
Upstream is clearly wrong here - whether that means slock should be patched to be sane, or that slock should just not be packaged at all, I couldn't say.
The thread raises some valid points on both sides, but the slock issue is secondary to the real issue. Adding misc patches:
- Makes different systems behave differently - this makes bugs harder to track and confuses users
- Moves the trust from the software developer to both the software developer and packagers (who may not have the same expertise that the developer has)
For ex. #1: When you use software like slock, you presumably trust slock to do its job well. If you don't trust him enough in his choice to add setuid, then why would you trust him enough to use the screen locker?
I understand adding patches that are strictly packaging related if upstream is uncooperative (mostly I guess because nix is small), but changing behavior is another ballgame.
There's always been the tacit assumption that using a package manager implies trust in the way that packaging is handled by that manager. Often people who handle packaging dozens or hundreds of packages over years actually ARE much more aware of the security implications of decisions made by developers of individual pieces of software.
Fair, but at the same time, "setuid" is a war where everyone looses, IMO :).
Since the issue was first closed, there are some solutions for NixOS that I hope for discoverable. For Nixpkgs alone, I really don't think see any solution that is both secure and ergonomic -- setuid is bad.
Setuid has been replaced by capabilities, but nix faces the same struggles it has for setuid (only supports it through a wrapper, and that was after a "wontfix" according to the bug tracker).
More than that though, the mentality that you can just patch away critical features (like setuid) without telling the user is imo unhealthy for an OS.
NixOS is so very usable. There are a lot of foot-guns but that's true of Linux systems.
It takes some time to get comfortable with all the different ways to configure stuff. There's a new language, a new build system, a new Linux distribution.
I've spent very little time relative to say, figuring out dpkg or systemd, or learning Bash or C or Perl, or learning the Linux FHS.
NixOS makes running deterministic systems driven from a single configuration incredibly easy.
Nix the language and tools allow you to build software deterministically and create environments where that software is available (e.g. on $PATH).
Nix Flakes is an experimental feature aimed at bringing reproducible and hermetic configurations of dependencies into the fold (i.e. lock files, ala Gem or Cargo or Go Modules).
Nix-the-tool's interactive "package manager" should be deprecated, as it's a huge pitfall for most developers. But it works and is frankly a good first step for folks coming from Apt or Homebrew.
Learning to write modules is probably the steepest learning curve, but compared to learning how to build RPMs or Dpkg or Brew recipes, it's really not bad at all. I actually find it easier and I've been at this for less than a year. Sure, if you're trying to get something working no one has figured out yet you may be in for a pickle, but that feels like it's always been true. The difference is a lot of software breaks and bends the rules and boundaries constructed to keep things and people sane. Nix does not allow that, generally, which is a very good thing. Fixing other people's garbage is the bane of any package system maintainer, it's no different here.