The first issue you describe is that you already have alternative Nix-like solutions in particular domains (R packages), and Nix let you continue using them. Is this not desirable though? You have the choice of letting Nix handle this, or carving out a Nix-less niche to continue using existing / more cross-compatible solutions.
The second issue is that support for games is weak in NixOS. But is this surprising? You're running games via emulation on a niche OS, where neither the game or the emulation tools you're using officially support NixOS. I'd say the fact NixOS can run these games at all is very impressive. Other alt-OSes, like Haiku, would not be able to do so.
The third issue is that you seem to need to edit /etc/hosts to be able to connect to captive portals on public WiFi. Do you? I'm on Linux, and I don't.
It honestly seems like Nix requires more tinkering than you were willing to do to get it set up, and that's an absolutely valid decision to make - it's the reason I don't use Arch, for example - but I feel like your article frames this as an issue with Nix, which seems a little disingenuous.
Developer environments are my favorite usage of nix. To me, they deliver on the promise but, there’s a big caveat, dealing with languages that need native libraries is a real pain. The mentioned buildFHSUserEnv is basically a last resort. There are better solutions but they require a great deal more fiddling. I find that my start up time for getting a developer environment going is very long, sometimes 10x longer than just installing it in Ubuntu on a fresh vm. I find it is worthwhile to go through this process as I then don’t have to worry about being able to recreate it or switch between very incompatible projects. Luckily for me, the ecosystem that I frequently have to deal with this with is python and poetry2nix works pretty well (with some rough edges). mach-nix made this even easier but it is abandoned in favor of dream2nix which isn’t ready.
The learning curve for nix is intense. It is incredibly unfamiliar and useful information is widely spread (the main documentation was too dense for me to comprehend when I started). Read the post, it seems to me that the author never got over the learning hump into it actually being useful. I think that is a perfectly rational choice, it isn’t the right thing for everyone. The one thing that kept me going through the first year of the learning process was one of the things that the author didn’t find important, being able to boot to a previous configuration. I don’t have to worry about updates that break something or making a bad configuration change. If I update my system and something breaks, at worst, I can simply reboot to revert to the previous configuration until I’m ready to troubleshoot the issue.
Nix also does itself a disservice but not promoting flakes as the nix way. Using channels makes reproducibility much worse.
1. This is a bit off, Nix does not exactly let me continue using existing tools. NixOS' dependency system means that the R dependency management system I was using (renv) would not work on its own. renv would try to compile R libraries but would fail because it could not find dependencies
I accept that Nix provides a way to handle this problem through buildFHSUserEnv, but the point I raised in the post was that buildFHSUserEnv feels hacky and unparadigmatic. I conceded, through additional NixOS configuration, that I couldn't use NixOS' store or use the NixOS recommended way of installing R libraries
2. Yep, not surprising at all, definitely to be expected. The point I wanted to make in the post was that NixOS makes it harder to tell whether it is a Linux or game-specific issue or if it is because of NixOS
Also, even though it wasn't surprising in the least, it was still a major annoyance/frustration
3. Not all captive portals, most just used a 302 HTTP redirect which works without trouble, but some were weirder -- although I'm beginning to think that this was because I didn't have `networking.useDHCP = true` enabled, as I wrote in another comment
With the whole "your system is read-only" bit, I'll add that Nix can make trial and error editing of config files quite tedious. Editing and reapplying the configuration is fast, but not as fast as editing a file and `systemctl restart`ing the service in question.
On development environments I've also had similar problems. My workplace uses a combination of Python and C++. While Python has an established package management system, C++ is still in the early days. The traditional is just use what your OS provides, but the production OS is different from the development OS, the former being much more "stable" (and therefore with older package versions) than the latter. This has caused plenty of headaches with features not being available, and is holding us back from using newer C++ features, or even adding dependencies easily.
Being keen on Nix, I've been testing out using it locally for dependencies.
With C++ it mostly works. Some annoyances have been packages not providing CMake or pkglib config files. Some packages don't quite have all the possible features enabled, and it's not trivial to enable them (I struggled with arrow and liborc).
Then comes Python, which introduces the same nightmares which the author experienced. Python packages that use system shared libraries are troublesome. The buildUserFHS solution seems like the right approach when mixing and matching, but it introduces a few more problems (the details of which elude me right now).
An additional problem is portability. Theoretically one could use `nix bundle` to ship whole applications, but a shared library is a different matter. We've got a Python module written in C++ module, I'm not sure a module built by Nix would be compatible with the host's Python, given the libstdc++ differences and so on.
This struggle is topped with the fact I'm the one going against the grain, trying to sort out the issues I hit, for my own purposes only. I do hope I manage to prove to myself that it's a tenable approach, and eventually can propose it to the wider team. But for now I know it's a dream.
The nightmares come from pypi packages and their assumptions that e.g. the particular version of `libfoo.so` that happens to be in your `/usr/lib` at the time of installation is the one you need it to link against, which is a very crass assumption in 2023. Nix doesn't hide you from this. But it's quite straightforward to write your own nix packages based on upstream python packages which should work fine alongside other nix packages.
By and large, nix does not play particularly well with other package managers, because the nix view is that it's absurd having 7 different package managers fighting for control of the same system.
No, I think it's a very sensible assumption. As far as I can see, virtually every GNU/Linux OS has shared libraries in /use/lib, and it even has crude support for versioning.
When these assumptions break with Nix, I'll grumble about it, but I won't blame it on the original package. Nix's approach is a break from the norm, so really it has the responsibility of maintaining compatibility.
> But it's quite straightforward to write your own nix packages based on upstream python packages
Things break down when you have to stick to specific versions of packages, at which point creating/overriding nixpkgs quickly becomes untenable. My idea is to use Nix to complement the existing standard standard Python tools everyone uses.
And addresses that by becoming the 8th different package manager fighting for control of the same system, a la https://xkcd.com/927/
The vast majority of the issues I have faced have been down to nixpkgs. Of course, nixpkgs is an incredible project, but it lacks direction, uses bad practices everywhere, and pretty much all of the flaws you’d expect on a vast monorepo with a somewhat laissez-faire management approach.
Oh, one other problem I had, I guess, was when MS removed a link to a Teams binary that was baked into nixpkgs, which meant I couldn’t rebuild my system without losing teams, until I fixed it with a custom derivation. I could also have fixed it by pinning the nixpkgs it came from to one with a working teams URL, but that seemed like too big of sledgehammer for a single application.
One of the key assumptions made by nixpkgs, and by many hermeticity-focused projects, is that URLs stay alive and unmodified. They don’t promise that something will always build. They promise that it will build perfectly, exactly as you specified, or not at all. There’s a nice security element to that I guess.
Nonetheless, NixOS is the best distro I’ve ever used. I certainly spent much more time fighting Arch, etc than I do NixOS - and I’ve never come across a problem I can’t work around with some nix code.
So my position, I guess, is that NixOS is the second best distribution for me. The best is the one that builds on NixOS and has learned some mistakes, thrown away some technical debt, etc.
This shouldn't be the case since the main upstream substituter, cache.nixos.org, should have the derivation cached or at least the latest remote source/binary. MS Teams is an exception since it's licensed as "unfree" which likely prevent caching. I think there's a way to mark the remote src of the package as redistributible (if MS allows that) even if the final package/derivation is not destributible.
Since external sources are content addressed, you can always manually add the source file via the `nix store add-file` or `nix store prefetch-file`.
And if something did break? Rollback from the boot screen and you should be back in business (until you figure out how to pull in an overlay).
Unless I misunderstood the predicament with which you were left.
However, everything was just a hassle to get working. Any program that's not in the package repos takes a day or two of fiddling to install. I just lost patience with it and have been on Ubuntu for the past few years.
Granted, it's not ideal that this kind of hint is needed for such an important workflow. Oh well. All the rest still makes it easily worth it for me.
If I remember correctly, it would work in 80% of cases and fail on the last 20% (usually if some library is missing or if it has some strange binary installation procedure).
The 20% made it not worth it for me to use as a desktop environment. I still see the value in it for server configurations, though.
While the language is declarative your configuration is scattered, debuggers are absent, and you're ultimately interacting with a a layer on top of what the original package was designed to do.
This makes it hard to figure the system out, how to debug, and occasionally support is missing.
This is fundamentally necessary, because the "original package" (for some value of "package") doesn't care about anything else on the system apart from getting itself running using whatever arbitrary configuration scheme / fs layout / daemon management happens to please the upstream author.
I think it's worth being more precise here.
With a NixOS system, the configuration and services can all be declared from a single starting point. (Which is a benefit you'd get from NixOS, or maybe Ansible).
With NixOS' modules, the options used to configure services can be set from any nix file, which may be annoying (but IME is more likely to be a help than a hindrance).
The actual configuration files used by running services will be in some not-obvious-to-find directory.
> ...you're ultimately interacting with a a layer on top of what the original package was designed to do. This makes it hard to figure the system out, how to debug, and occasionally support...
Yeah; when something doesn't go well with Nix / NixOS, you may need to understand any/all of what the Nix code is doing, what the package/service you're describing is trying to do, and how it runs in Linux.
That said I’ve had a very positive experience packaging NodeJS apps with Nix, the /nix/store lends itself very nicely to the mess that is node_modules as each NPM package can be stored once in the store and NodeJS can read the dependencies directly from /nix/store if using something like Yarn PNP, I wrote a Yarn plugin to make this a bit easier https://github.com/madjam002/yarnpnp2nix Using Nix as a development shell along with direnv makes for a very nice developer experience.
The thing is though, you can get these benefits even without using NixOS, you can install Nix on various Linux distros and personally I use it on macOS.
NixOS is great for servers where reproducibility and consistency is important, personally I was never a fan of tools like Ansible that are a bit of a hack.
Ironically I think the best way to learn Nix is to go backwards: Build a server on NixOS, then learn how to package your app in Nix for deployment, then use NixOS as a developer machine. Server configurations are (usually) much simpler, making the language and distro easier to learn.
I have .envrc ignored in my global gitignore, and then I write 'use flake $HOME/my-nix-config#node' to .envrc. direnv then grabs that and does the rest. I no longer need to commit anything Nix related to git, so my coworkers are none the wiser.
Ultimately this article shows that, once again, the problem with Nix is the documentation.
What you might not be as familiar with is that these authentication sites often block you from visiting any domain at all, and then to access the authentication site on their own domain you must explicitly link their domain to an IP address through the /etc/hosts file.³
3. I'm assuming on Mac and Windows this is taken care of for you somehow and it is a non-problem.
I saw an entry like the below and thought a DNS configuration might have been the problem -- in retrospect, it could have been another issue, perhaps I set `networking.useDHCP = false` in my NixOS config, but I honestly cannot remember
https://askubuntu.com/questions/961557/ubuntu-17-no-redirect...
I'll update my post with a note about this
To edit it, you must edit your system Nix configuration in /etc/nixos/configuration.nix and then rebuild your system, which —get this — requires a network connection to complete! So somehow, to connect to the Internet, you must be able to connect to the Internet.
For what it's worth, the following worked for me, though there appear to be other ways as well:
cd /etc/nixos # Or wherever you store your configuration.
nixos-rebuild build
sudo nix-env -p /nix/var/nix/profiles/system/ --set ./result
sudo ./result/bin/switch-to-configuration switch
Thanks for the link, I'll also post two that I saw when I was trying to work this out: - https://discourse.nixos.org/t/rebuild-nixos-offline/3679/4 - https://superuser.com/questions/1688845/nixos-how-to-fix-net...
Of course, IMHO, servers is where nixos really shines.
For me it was quite the opposite, regular Linux distributions annoyed me because after having them set up, some stupid mistake (either from my side, or from upstream, unsure about this) caused my whole bootloader to break, rendering my system unrecoverable (maybe not for every, but for me it was/is).
When i learned about NixOS, allowing you to essentially set up your whole system declaratively, it was so compelling to me, that i just went with it. Yea i don't really like / know the language very well, but it's a lot better of an experience than any prior Linux experience i made.
Upgrade the whole system? Dangerous. Upgraded and it kinda works, but you'd like to roll-back? Though luck.
NixOS is definitely not for everybody - perhaps Developer workstation is the most tricky to get right. But for production server use, the repeatability is great.
Nix ofc is agnostic of NixOS, is is generally my preferred way of getting packages.
I also happen to love when software makes too-wide assumptions and break. That is generally software poorly written and to avoid.
These side-effects and mutations cross-product with each other so much that computers have become failure dumpsters.
I think the biggest 'risk' is there's a long tail of stuff a developer might want to do. The more niche some task is, the more likely it is that the program you're trying to use makes assumptions about things in Linux being where things in Linux usually are.
But. I think 'developer workstation' is the use case most likely to benefit from NixOS desktop use. -- For servers, I think 'running containers' is an almost ubiquitous way of deploying applications.
Meanwhile, the advantage of reproducible builds and rapid rollback are so huge for me that I use it anyway.
May the source gods have mercy on me. :-/
The configuration is done with Scheme. I haven't tried it.
At some point last year I came to the conclusion that the immutability/repeatability of NixOS just isn't worth the drawbacks for a development machine. I swapped to openSUSE Tumbleweed and haven't looked back. It never gets in the way - I install what I want, manage my dotfiles in chezmoi, and rarely need to fight the OS to do what I need it to do.
I think NixOS has some interesting applications at scale. If I had to manage a fleet of 100+ machines and ensure they are all identical, and I can easily roll back changes, NixOS would be a prime candidate.
Similarly, I still think Nix the package manager is pretty great for individual project dependency management. There isn't really anything like it as far as I know.
In the end, I realized I was just still using ArchWiki for help and also that my Arch installation on my desktop was still fine after 5 years. I ended up switching back and felt much more at home. Personally, I would consider nix again if the language and scripts had less learning curve (I couldn't get vim code completion to work, ctags doesn't support nix either). Otherwise, I'd love to see a similar distribution in concept that used a more standard language that might be more accessible.
It’ll be funny if dependency management turns out to be a categorically harder problem than consciousness.