The older I get, the more I realize that so much of the divide in the tech field is simply between the two camps of "the tools are the interesting part" vs "getting things done with the tools is the interesting part".
Your veiled implication that Nix and NixOS aren't about "getting things done" is, I think, more than a little unfair. I'm using multiple programming languages at work. Each one of them has its own dependency manager that does basically the same job as the other ones. In Python it's Poetry, in Ruby it's Bundler, in JavaScript it's npm/yarn, in PHP it's Composer, etc. A lot of projects require extra setup steps outside of the dependency manager. It's not a good experience that lets you get up and running quickly. And my situation with scripting languages isn't the worst case: God help you if you have dependencies between projects in AOT compiled languages that use different dependency managers.
Of course, the standard answer is to spin up a ton of Docker containers. Docker works, but it looks to me like a local optimum rather than a truly painless solution. It sucks as a build system, and Dockerfiles not being reproducible is the default outcome that needs significant extra care to avoid (how many times have you seen apt update or some equivalent in one)? Besides, why should I have to worry about a whole another OS inside my main OS, with potentially different tooling and conventions, when what I really want is just specific versions of a couple of tools?
I think we've gotten used to development environments being a shitty experience to the point where it seems part and parcel of programming, but when you take step back, it's apparent that the situation causes a lot of frustration and wastes a lot of time. To me, Nix's combination of package manager and reproducible build system looks like one of the most credible ways out. NixOS' declarative configuration and rollbacks are nice side benefits too, for server admins and newbies respectively. Nix just needs a lot more polish. I'm not about to introduce a tool where the most common workflow is still considered experimental. For now, I'll keep using Docker, but I watch Nix with interest and can't wait until its UX matures.
EDIT: Removed claim that Bazel and Buck's creation was motivated by multi-language support. Looks like the main motivations were speed and reproducibility.
One of the workflow I’m trying to practice is the idea of workspace. It can be done with virtual machines or containers on linux. As you can guess, it’s about one project per system. I don’t mind the redundancy as it brings me peace of mind when configuring the system or managing dependency.
Nix's core idea is wonderful, but I wish it could be redone from scratch. Why can't we just layer some Flatpaks that have source code in them or something?
But the whole thing seems like it's designed to express more powerful things than you can easily map to an app store style install/uninstall button, rather than solving the problem with the least powerful tools that give the user the highest level interface possible, and leave as much as possible for the computer to figure out.
I use Nix and agree with most of what you said, except the main value proposition of docker-on-dev-machine is not convenience, but approximation of production
The more I use nix, the more I understand it's both. Nix is genuinely so fucking great, but the ecosystem and docs and language are a mess. It needs to be cleaned up, and things _are_ getting better.
The core philosophy of Nix is so damn solid though, and that's the real innovation here. As long as its philosophy manage to stick around, then it's ok.
I think that's a bit reductive, but I get the intent. A lot of people see systemic problems in their development and turn to tools to reduce the cognitive load, busywork, or just otherwise automate a solution. For example "we always argue over formatting" -> use an automated formatter. That makes total sense as long as managing/interacting with the tool is less work, not just different work.
With Nix I still think it's a net positive, but the "different kind of work" side of the equation is pretty large. That's why we're building Flox [1]. The imperative user interface of a package manager (flox install, flox search, etc) that builds out a declaratively-configured, reproducible, cross-platform developer environment. I really think it nails the user experience by keeping that "different work" side of the equation small, and (I hope) just gets out of your way.
I just started using Flox last weekend and so far it has been quite nice experience. There are two things I don't like, though:
1) The Homebrew package is a cask that installs also Nix. While I like Flox, I don't want my systems to be married to it. Yes, I know about install option with "generic Nix", but I'm using Homebrew with Brewfile both in macOS and Linux, and I would like the Homebrew package to be just Flox.
2) Documentation is OK for getting started, but not for anything more than that. There are nice manifest.toml examples for many use cases in floxenvs[1] but you need to find those first. Also I'm not sure how I feel about inline shell scripts in toml. While it works, separate files would be easier to handle, at least for me.
Quickly skimmed through the Flox site and it looks like it’s based on Nix. The problem with the competitor https://www.jetify.com/devbox and most likely in Flox is that Nix makes trivial environment setup really easy but when you need something more complex it falls apart because the Nix packages are often unmaintained and simply broken.
How many of them actually work though? If you end up having to go fix upstream packages then having a tool manage your environment is not useful since you still have to understand the domain.
With Nix I usually ended up in a situation where I had to both figure out how to configure my environment _and_ fix the upstream Nix packages. At that point it’s just easier to stick to Homebrew and some custom shell scripts.
I tend to agree. I also think both sides need to learn to better appreciate the other.
Without people getting shit done with the tools we’ve built, there would be no demand for better tools and no need to write them.
Without better tools, the things we can get done are limited. Better tooling is an exponent to our productivity. The things we can accomplish today would have been nearly unimaginable nearly thirty years ago.
> Better tooling is an exponent to our productivity
Nix & NixOS have made me much more productive. Maintaining a desktop is effortless. If something breaks, I can simply reboot to a previous installation. I can also try software without installing, and develop parallel projects relying on dependencies that would be mutually incompatible in a regular imperative package manager.
But I recognize that if you need to do something slightly unusual, documentation is incomplete and scattered. For simple things, my contrarian view is that Nix is not hard at all. The subset of Nix I use can be learned in a couple of hours. I think the trick is to avoid getting sucked into packaging complex software with messy build systems. If the stack you use is well packaged in NixPkgs, it's a joy to use. If it's not, it's better to stay away.
I first heard of Nix a few years ago from someone who fell firmly into the camp of "the tools are the interesting part." Despite my reservations, perhaps because I didn't want my opinion of the person to lead me away from something useful, I started to mess with it. After about 30 minutes I decided it was not for me and have not touched it since.
I do keep an eye on Nix-related stories to get a sense of whether or not I should change that stance. So far, nothing has led me to change it.
It would be good to have some interesting tasks to do?
I think the tools should do also much of the work. I actually prefer batch systems that are a simple execution of a program against a dump which are just process all the data and generate data with the new states than a networked online system that breaks all the time and due to DNS
Micro services keep me awake but a simple CSV processing I can fix in my own time.
I love NixOS, it's my daily driver on my personal laptop, but it definitely has given me more than its fair share of headaches.
If everything you're going to do is in Nixpkgs, great! Nix will mostly "Just Work" and you'll get all the nice declarative goodness that you want. Since Nixpkgs is constantly getting updated, this isn't that weird of a thing.
The thing that's been most annoying to me is when I try and run generic Linux programs, only to be unceremoniously told "You can't run generic Linux programs in NixOS because we break dynamic linking". Suddenly something that would take about ten seconds on Ubuntu involves me, at the very least, making a Flake that has an FHS environment, or me making a package so that no one else has to deal with this crap [1]. I didn't really want to know how to make my own Nix package, and I don't really want to be stuck maintaining one now, but this is just part of Nix.
This means that it's still not something I could easily recommend to someone non-technical like my parents, unlike Ubuntu. You have to be willing and able to occasionally hack up some code if you want your system to be consistently useful.
To be clear, there's a lot of stuff I really like, I don't plan on removing it from my laptop, and for something like a server (where the audience is sort of technical by design), I really have no desire to ever use anything but NixOS, but it's a little less impressive for desktop.
You can run generic Linux stuff if you install nix-ld¹, the only tricky bit is having to customize the set of libraries given to nix-ld for your use-case. It includes various common libraries by default, but depending on what you want to run you may have to add to it.
Interesting, I didn't realize that that was an option.
I've been getting by with buildFHSenv and Flakes, which, despite my complaints, really isn't that annoying. My goal at this point is to eventually compile all my flakes and take on Lutris.
I will say that once I found out about Flakes it bothered me a lot less. I find them a lot easier to test and it's nice to be able to easily define a custom little environment for them and then just do `nix run` afterwards.
It's been especially useful to be able to specify exact versions of wine and winetricks installs on a per-game basis.
Just use Nix/Home Manager on Ubuntu or something instead of NixOS. You get, by far, most of the reproducibility and none of the NixOS issues. NixOS feels more like a great server environment, but not that good of a DE.
I don't think I agree with that. You don't get the system snapshotting, and you can't make your root filesystem tmpfs if you just use Ubuntu + Home Manager.
Yeah, that's exactly what I did for a while, but really once you get the hang of nix it's kind of unnecessary. I keep this bit of nix to hand for anything that I need to run
#!/usr/bin/env nix-shell
{ pkgs ? import <nixpkgs> { } }:
(
let base = pkgs.appimageTools.defaultFhsEnvArgs; in
pkgs.buildFHSUserEnv (base // {
name = "FHS";
targetPkgs = pkgs: (with pkgs; [
/* add additional packages here e.g */
pcre
tzdata
]);
runScript = "bash";
extraOutputsToInstall = [ "dev" ];
})
).env
Running `nix-shell` will drop you into a bash shell that looks just like a normal linux distribution with a lot of common libraries (thanks to `pkgs.appimageTools.defaultFhsEnvArgs`) and after trying to run your application you can shove whatever you need in the extra packages when it complains about a dependency being missing.
Obviously it's a bit more work than other distros, but once nix gets it's claws into you, you'll find it hard to go back to old ways.
I'm technical enough to where making a Flake doesn't really bother me, and it's really not as hard as I was making it out if you're already familiar with functional programming, I'm just saying it's an annoyance.
That said, I might need to play with Distrobox, it looks like it's in nixpkgs.
I've been on the fence about Nix. I've wanted to love it (and do love the concept), but between the Waiting-for-Godot situation for flakes, the weird language, and the occasional political infighting I've seen pop up about the community, I still haven't switched.
I'm no language expert, but I genuinely don't understand why it wouldn't have been better to build some equivalent DSL in Haskell to do this given the similar lazy nature of the language. DSL for most things, then open the hood and do actual Haskell for crazier use cases. I get that Nix started before Haskell became less academic and slightly more usable in the mainstream and has built up momentum, but the lack of tooling for understanding what is going wrong when incrementally building up a config is very confusing.
I'd be curious if anyone has go to or from NixOS compared to declarative distros compared to the atomic distros like ublue [0] and has any thoughts. I'm a bit split about what to move to next (though my >5 year Tumbleweed install on most of my machines is holding up no problem).
I switched away from Nix OS and eventually landed on GNU Guix, which I have stayed on for about 4 years now. One of the main reasons I switched away from Nix was because of the language, and how underdocumented it all felt. GNU Guix was a breath of fresh air, using a language with decades of academic backing outside of the context of Guix (SICP was awesome for getting into it) and the whole system is very well documented, with a nearly Arch-wiki quality manual built into the OS in the info pages.
4 years can be a very long time in a project, especially when the "network effect" hit around that time, where the active user count (and contributions) grown significantly.
Also, the language is quite simple, it's just foreign and you felt more at home with Scheme, so you might not have given Nix as much of a chance. This is the classic "simple vs easy" from the Hickey talk.
Documentation is no perfect, but has become quite a bit better over the years, and many of the problems that still linger are simply architectural ones of the nixpkgs repo, irrespective of language and wouldn't be solved in any other language/DSL in itself.
I'm using Universal Blue now (Aurora, i.e. KDE flavour) and I'm very happy with it. With its large amount of pre-installed packages and drivers (including proprietary ones), I still didn't need to install any custom package (rpm-ostree) or otherwise modify the OS config (except for turning off SELinux in /etc/sysconfig/selinux). It's the most pragmatic distro I've used so far.
SaveDesktop[0] (saves flatpak apps and DE configs) and mise-en-place[1] (declarative shell environment manager) are making my installation backupable and quite reproducible (not to NixOS standards though).
For software that's not in flatpak, docker or mise, toolbox[2] and distrobox[3] are available for the rescue. Both work really well (toolbox seems better for CLIs, distrobox for GUIs), but all atomicity/declarativity is lost.
> I'm no language expert, but I genuinely don't understand why it wouldn't have been better to build some equivalent DSL in Haskell to do this given the similar lazy nature of the language.
My impression is that you can't really build nix as a DSL in haskell, because the core insight of nix is to introduce the "derivation" function into a pure programming language, whose behaviour is pure (the output is determined by only the inputs), but whose implementation is very much not (it builds packages from a specification).
There may well be a work-around for that (it's been a while since i haskelled), but it's likely to end up with a result that's less clean than it would ideally be.
Personally I find the nix language to be a pretty good match for the tasks it is used for (though some basic static typing would be nice).
From the outside, i can see why it looks odd, but from the inside, there's not much of a desire to switch to something better, because the language isn't the thing that gives people trouble after the initial learning period (which would exist with any host language).
My impression is that you can't really build nix as a DSL in haskell, because the core insight of nix is to introduce the "derivation" function into a pure programming language, whose behaviour is pure (the output is determined by only the inputs), but whose implementation is very much not (it builds packages from a specification).
Evaluation is completely pure (at least with flakes, which disallows querying environment variables, etc.). Evaluation of derivations will result in .drv files in the store, but that does not add impurity to the language itself. Building the .drv is a separate step (instantiation).
You could totally write something that generates .drv files in a different language and use Nix for instantiation (building). If I am not mistaken, this is how Guix started - they evaluated derivations defined in scheme to .drv files and then let the Nix daemon build them.
Aside from that, as a Nix user, I am happy that Haskell is not the language. Nix is a very small, simple language that is easy to wrap your head around and does not lead to a lot of abstractionitis. A want to say this in a way without painting a caricature, but the Haskell community has a tendency to pile on a lot of abstractions and I would hate to see a Nix with monad transformers, lenses, or whatever is popular these days.
I don’t understand—the language itself is completely contained and separate from the derivation. Evaluation could be done in any language and the derivation will remain the output. You can absolutely have a better language generate derivations, surely? Hell, you could use Python typescript or go if you wanted to. They’d even be completely compatible with the unholy mess of cursed bash that is stdenv.
What you can’t port over to another language as neatly are the modules. Good riddance, id say. Undebuggable spaghetti from hell.
> from the inside, there's not much of a desire to switch to something better, because the language isn't the thing that gives people trouble after the initial learning period (which would exist with any host language).
Unfortunately I have wasted enough of my life to call myself “on the inside” and IMHO the language itself is close to the number one threat to wider adoption of nix.
This sounds like a great idea! How do I do it? (The unstable stuff and using modern techniques? How do I even know what's modern?)
I currently have a spare laptop lying around. I popped in the latest NixOS ISO and just gave it a spin. Some things I noticed:
- The installer only allows to install on ext4 unless you manually partition the disk? I thought it was 2025, not 2005.
- Is there no way to search for packages without a browser?
- I found boot.grub.* and boot.systemd-boot.* - what if I want to use refind? What about Limine?
- How do I know if any given program goes into programs.programname.enable = true or into environment.systemPackages = with pkgs; [ programname ]?
- Why is the ISO furnishing me with a configuration.nix when everyone says to use flakes instead of that? How do I switch?
I'd preferably be able to answer those questions without reading a 300 page handbook. I've been using a lot of Linux distros over the last 30 years and the above questions have usually bean answerable on a headless system with the supplied documentation. I understand that Nix is a paradigm shift compared to "classic" distros, but that only puts the onus more in Nix to be discoverable.
I spent quite a while trying to understand what Nix was actually trying to accomplish and how one would actually go about using it. Granted I was trying to do it on a Chromebook, but the idea stands: I should be able to get at least the nix environment set up and the silly gnu hello world built and running, right?
Turns out nah. The ergonomics are just that of a hiltless double bladed sword.
I'm glad I'm not the only one, but i also was aware of pushcx trying years ago and still failing [1] and he's a smart dude unlike me. I didn't feel so dumb.
Yes, the ergonomics are poor. I endure them for the results, but the ergonomics should be better.
Guix has better ergonomics, but it's own set of downsides.
I expect the underlying idea of holistic declarative systems is sound, and we're awaiting a polished alternative. Maybe it'll reuse nixpkgs under the hood
, but replace the name, the tooling, and the language exposed to the user.
Nix for me has been a great source of stability. I used to run ubuntu and was never happy. Packages randomly broke, the UI lagged a lot, I always had to dig to get things working. One day when I head a uni deadline an automated updated destroyed my wifi funcionality. I had some experience with nix from work so in anger I installed NixOS. Wifi worked and I finished my uni assignment. Haven't installed anything else on my computers since, and that was 6 years ago. Sure things can be a pain. But NixOS has never broken in unexpected ways. I know if I update things may go wrong. But I can always go back and try again a newer version a few weeks later.
The biggest drawback is really that "random executable from the internet" does not work out of the box. And sometimes you have to spend a lot of time to package something yourself. But all in all It has saved me time and a lot of pain. I dare even say I no longer have a toxic relationship with my OS.
For those pesky random executables there's a couple of escape hatches -- buildFHSenv and nix-ld. This is also predicated on good provenance of the executables in question. One should probably not even ldd sketchy binaries:
Even proper packaging is far easier compared to other package managers. Typical distros push users away from packaging their own software, so users end up relying on ad-hoc solutions instead. Nix instead makes packaging easier by having proper tools to abstract away the nitty gritty details.
For random binaries, autoPatchelfHook works miracles.
NixOS literally just broke webcam drivers on alder lake and wake from sleep. That was a huge pain to deal with when updating for the rsync vulnerabilities. And a bunch of other issues.
Thank goodness for perfect rollbacks. I'll take rsync vulnerabilities over a super broken system and try again in a few weeks.
I use NixOS as my daily driver. I concur. I wouldn't recommend it for most people (even for me, when I decided to give it a try). I'd probably just go Arch if I were to do it over again.
The concept behind Nix/NixOS is amazing, but it needs to be polished. Flakes are the future, but they are languishing in this experimental status. Even simple things like installing packages from stable and unstable channels are too hard to figure out. The documentation is terse and the community answers are often not enlightening.
A big complaint of mine is that the builds should be reproducible, but I find I sometimes need to run `nixos-rebuild switch` several times to get a successful build. The error messages mysteriously resolve themselves. For me, this doesn't pass the bar for being considered reproducible.
Don't get me started on using an NVIDIA graphics card also. Granted, part of my difficulties is that I was running Wayland, which doesn't have the best NVIDIA support, but I felt like I was just doing an exhaustive search through the potential config settings to see what worked. Ultimately, I found just the right combination of settings to get everything working buttery smooth. I ripped out the NVIDIA card and put an AMD card in.
Installing packages from different channels is still far easier than on any other distro. Try getting a Debian 10 package to work on Debian 13. You can't. GUI programs are hard because how GUIs work on Linux. You cannot make them easily pure, they always rely on the booted system through drivers and a bunch of impure things all over the place.
If the software you are using has race conditions in its build system then there is only so much you can do to fix that. You could for example run nothing in parallel with only one core but then everything would be painfully slow. Also the occasional network hickup breaks things. Lately also io_uring in combination with nodejs has been a great source for kernel bugs. You can only bang the software so much from the outside.
Nvidia is bad because Nvidia is bad but at least switching between different driver versions and variants is possible without leaving a trace of old things behind on your system like on literally any other distro.
After spending some time on NixOS I basically decided to hold off until flakes become official and the docs are written with them in mind. In the mean time I just run Arch with Nix home-manager and I'm happy.
I've developed enough good habits over the years that I don't get breakages, and home-manager allows me to easily sync my dotfiles across machines..
If you’re afraid of the experimental status, there are plethora of pinning solutions other than flakes which work with NixOS today and will continue working until roughly the end of time
What makes you reluctant from using flakes? I initially thought I'd never have a need for flakes but after spending an hour on YouTube and Googling, I converted to flakes.
My experience has been in complete agreement with yours: I love the theory, but the practice is so, so painful.
And yes, I also had to settle for your NVIDIA fix. I suspect I would have had a marginally better time on Arch as there are more people beating their heads against it and documenting how they made it work. NixOS documentation is piss-poor in comparison.
Most people don't realize that you can read the arch wiki and put the same settings into the nixos options. Where is the point in replicating that all again?
I use NixOS, one of the annoying things to me is the documentation and error reports.
I swapped my installation to a Flake managed install a few months ago, and parts of my Nix files that were perfectly fine before started throwing out errors (specifically HomeManager), which no amount of Googling the error message that gone thrown got me any closer to a solution.
I looked at documentation recently to try and enable PGO/LTO and Zen 3 optimizations (don't mind compiling everything) and I think I saw at least 10 ways and none worked (gcc errors, etc).
This is why I haven't switched my NixOS to flakes yet. The community discussions always act as though flakes should be the default that everyone should use now, but I figure that the developers know what they're doing and haven't made them the blessed path yet for a reason. So far so good—my system is far more stable than it was under Debian and I've yet to run into anything that didn't have an easy answer.
I have a suspicion that because the Nix community is disproportionately likely to contain early adopters, the general mood in the forums is less risk-averse than I am with my primary stacks.
> I figure that the developers know what they're doing and haven't made them the blessed path yet for a reason.
My take is: flakes don’t align with centralised nixpkgs and ultimately don’t solve any problems that can’t be solved without flakes.
They’re just an interface for a decentralised module system. You can use them, they’re feature-complete, and they don’t align with nixpkgs: it doesn’t make sense for individual packages to have their own flakes, nixpkgs can already be loaded as a flake.
FlakeHub tries to popularise flakes, but I don’t know if there is a flake discovery problem to solve.
Ekala Project is designing a poly-repo alternative to nixpkgs (ekapkgs) and they don’t embrace flakes.
So... Flakes have reached full maturity: a decentralised package format that has stalled its adoption status within the main Nix toolchain.
I'm glad I'm not the only one who's grinding their gears with flakes.
I decided to migrate to flakes because a lot of the documentation for things I wanted to do with NixOS required flakes. It took me at least a few hours to understand what the purpose of them was though.
Worth noting that ChatGPT et al. Are equally useless for debugging Nix. Frustrating that it’s so far behind. Error messages are often cryptic and misleading.
> ZFS on Linux [...] The recommended way to do this is to use LUKS, not native ZFS encryption.
FWIW I've been using native zfs encryption on nixos and it works great. It lacks neat features like being TPM-backed or having multiple keys, but if all you need is password-based encryption then I think native ZFS encryption is better since you'll be able to do encrypted zfs send/recv, you'll have granular control over which datasets are encrypted (or encrypted with different passwords), you'd get cross-platform support for the encryption (for example, my FreeBSD home server can receive and decrypt my laptop backups), and you aren't adding another layer of complexity.
I think the main reason ZFS's native encryption isn't recommended is that there's known bugs in its implementation, especially around key rotation and send/recv.
> I think the main reason ZFS's native encryption isn't recommended is that there's known bugs in its implementation, especially around key rotation and send/recv.
Is that still the case? I thought the send/recv bugs at least were squashed a couple years ago?
I’ve also been using ZFS native encryption on my machine. I wouldn’t describe it as flawless- but that’s mainly due to how nixos-unstable works.
There have been several times where the latest “stable” ZFS doesn’t support any of the newest kernels, and the “latest working” kernel goes EOL, and so nixos completely drops it.
And my options every time seem to be
-roll all the way back to latest “LTS” kernel. This sometimes breaks things.
-skip ahead to a beta release of ZFS (this isn’t always an option, and do I really want an unstable file system?)
-just don’t update for like a month and wait for new ZFS to release, supporting a newer kernel.
And there really isn’t a good option here. Theoretically there’s another option where I maybe keep using the EOL kernel version, and update the rest of my system normally, but I haven’t figured out how to configure that. So I just pick whichever option breaks the least amount of things each time. It’s definitely more of a ZFS issue than something NixOS-specific, but it’s annoying when I’m suddenly greeted with “That kernel version is EOL now.” And the update fails. And there is no easy way to ignore that and accept the risk of a slightly-outdated kernel.
Readit News
Of course, the standard answer is to spin up a ton of Docker containers. Docker works, but it looks to me like a local optimum rather than a truly painless solution. It sucks as a build system, and Dockerfiles not being reproducible is the default outcome that needs significant extra care to avoid (how many times have you seen apt update or some equivalent in one)? Besides, why should I have to worry about a whole another OS inside my main OS, with potentially different tooling and conventions, when what I really want is just specific versions of a couple of tools?
I think we've gotten used to development environments being a shitty experience to the point where it seems part and parcel of programming, but when you take step back, it's apparent that the situation causes a lot of frustration and wastes a lot of time. To me, Nix's combination of package manager and reproducible build system looks like one of the most credible ways out. NixOS' declarative configuration and rollbacks are nice side benefits too, for server admins and newbies respectively. Nix just needs a lot more polish. I'm not about to introduce a tool where the most common workflow is still considered experimental. For now, I'll keep using Docker, but I watch Nix with interest and can't wait until its UX matures.
EDIT: Removed claim that Bazel and Buck's creation was motivated by multi-language support. Looks like the main motivations were speed and reproducibility.
I have staunchly refused to allow this at my current employ, and I’ve been there long enough where I can steer this.
This isn’t acceptable and all it does is help introduce inconsistency and regressions.
I realize I am fortunate in that I can effect change at my job in this arena.
But the whole thing seems like it's designed to express more powerful things than you can easily map to an app store style install/uninstall button, rather than solving the problem with the least powerful tools that give the user the highest level interface possible, and leave as much as possible for the computer to figure out.
Deleted Comment
The core philosophy of Nix is so damn solid though, and that's the real innovation here. As long as its philosophy manage to stick around, then it's ok.
I've given it a try and it's quite incredible how easy certain things are.
The problem is the Nix language and the developer experience are really rough.
There's a chance that Nix could figure this out or a competitor with Nix-like ideas could become mainstream. That's my hope anyway.
It would be a shame if the ideas behind Nix got dismissed because of the current issues with Nix.
Just learn, use, promote best practices and stop forking the ecosystem _even_ further...
There, I got that off my chest.
With Nix I still think it's a net positive, but the "different kind of work" side of the equation is pretty large. That's why we're building Flox [1]. The imperative user interface of a package manager (flox install, flox search, etc) that builds out a declaratively-configured, reproducible, cross-platform developer environment. I really think it nails the user experience by keeping that "different work" side of the equation small, and (I hope) just gets out of your way.
[1]: https://flox.dev
1) The Homebrew package is a cask that installs also Nix. While I like Flox, I don't want my systems to be married to it. Yes, I know about install option with "generic Nix", but I'm using Homebrew with Brewfile both in macOS and Linux, and I would like the Homebrew package to be just Flox.
2) Documentation is OK for getting started, but not for anything more than that. There are nice manifest.toml examples for many use cases in floxenvs[1] but you need to find those first. Also I'm not sure how I feel about inline shell scripts in toml. While it works, separate files would be easier to handle, at least for me.
[1]: https://github.com/flox/floxenvs
The model of having packages on Github with pull requests scales very well.
Therefore, you could argue that people are getting things done with Nix.
This is a meaningless point. Different distros split packages differently.
With Nix I usually ended up in a situation where I had to both figure out how to configure my environment _and_ fix the upstream Nix packages. At that point it’s just easier to stick to Homebrew and some custom shell scripts.
Without people getting shit done with the tools we’ve built, there would be no demand for better tools and no need to write them.
Without better tools, the things we can get done are limited. Better tooling is an exponent to our productivity. The things we can accomplish today would have been nearly unimaginable nearly thirty years ago.
Nix & NixOS have made me much more productive. Maintaining a desktop is effortless. If something breaks, I can simply reboot to a previous installation. I can also try software without installing, and develop parallel projects relying on dependencies that would be mutually incompatible in a regular imperative package manager.
But I recognize that if you need to do something slightly unusual, documentation is incomplete and scattered. For simple things, my contrarian view is that Nix is not hard at all. The subset of Nix I use can be learned in a couple of hours. I think the trick is to avoid getting sucked into packaging complex software with messy build systems. If the stack you use is well packaged in NixPkgs, it's a joy to use. If it's not, it's better to stay away.
Like what? Witing an entire operating like Linux or Windows NT from scratch?
I do keep an eye on Nix-related stories to get a sense of whether or not I should change that stance. So far, nothing has led me to change it.
How do you feel about Kubernetes?
It would be good to have some interesting tasks to do?
I think the tools should do also much of the work. I actually prefer batch systems that are a simple execution of a program against a dump which are just process all the data and generate data with the new states than a networked online system that breaks all the time and due to DNS
Micro services keep me awake but a simple CSV processing I can fix in my own time.
Deleted Comment
If everything you're going to do is in Nixpkgs, great! Nix will mostly "Just Work" and you'll get all the nice declarative goodness that you want. Since Nixpkgs is constantly getting updated, this isn't that weird of a thing.
The thing that's been most annoying to me is when I try and run generic Linux programs, only to be unceremoniously told "You can't run generic Linux programs in NixOS because we break dynamic linking". Suddenly something that would take about ten seconds on Ubuntu involves me, at the very least, making a Flake that has an FHS environment, or me making a package so that no one else has to deal with this crap [1]. I didn't really want to know how to make my own Nix package, and I don't really want to be stuck maintaining one now, but this is just part of Nix.
This means that it's still not something I could easily recommend to someone non-technical like my parents, unlike Ubuntu. You have to be willing and able to occasionally hack up some code if you want your system to be consistently useful.
To be clear, there's a lot of stuff I really like, I don't plan on removing it from my laptop, and for something like a server (where the audience is sort of technical by design), I really have no desire to ever use anything but NixOS, but it's a little less impressive for desktop.
[1] https://github.com/NixOS/nixpkgs/pull/366367
¹https://search.nixos.org/options?channel=unstable&show=progr...
I've been getting by with buildFHSenv and Flakes, which, despite my complaints, really isn't that annoying. My goal at this point is to eventually compile all my flakes and take on Lutris.
It's been especially useful to be able to specify exact versions of wine and winetricks installs on a per-game basis.
Obviously it's a bit more work than other distros, but once nix gets it's claws into you, you'll find it hard to go back to old ways.
I'm technical enough to where making a Flake doesn't really bother me, and it's really not as hard as I was making it out if you're already familiar with functional programming, I'm just saying it's an annoyance.
That said, I might need to play with Distrobox, it looks like it's in nixpkgs.
I'm no language expert, but I genuinely don't understand why it wouldn't have been better to build some equivalent DSL in Haskell to do this given the similar lazy nature of the language. DSL for most things, then open the hood and do actual Haskell for crazier use cases. I get that Nix started before Haskell became less academic and slightly more usable in the mainstream and has built up momentum, but the lack of tooling for understanding what is going wrong when incrementally building up a config is very confusing.
I'd be curious if anyone has go to or from NixOS compared to declarative distros compared to the atomic distros like ublue [0] and has any thoughts. I'm a bit split about what to move to next (though my >5 year Tumbleweed install on most of my machines is holding up no problem).
[0] https://universal-blue.org/
Also, the language is quite simple, it's just foreign and you felt more at home with Scheme, so you might not have given Nix as much of a chance. This is the classic "simple vs easy" from the Hickey talk.
Documentation is no perfect, but has become quite a bit better over the years, and many of the problems that still linger are simply architectural ones of the nixpkgs repo, irrespective of language and wouldn't be solved in any other language/DSL in itself.
SaveDesktop[0] (saves flatpak apps and DE configs) and mise-en-place[1] (declarative shell environment manager) are making my installation backupable and quite reproducible (not to NixOS standards though).
For software that's not in flatpak, docker or mise, toolbox[2] and distrobox[3] are available for the rescue. Both work really well (toolbox seems better for CLIs, distrobox for GUIs), but all atomicity/declarativity is lost.
[0] https://github.com/vikdevelop/SaveDesktop
[1] https://mise.jdx.dev/
[2] https://github.com/containers/toolbox
[3] https://github.com/89luca89/distrobox
My impression is that you can't really build nix as a DSL in haskell, because the core insight of nix is to introduce the "derivation" function into a pure programming language, whose behaviour is pure (the output is determined by only the inputs), but whose implementation is very much not (it builds packages from a specification).
There may well be a work-around for that (it's been a while since i haskelled), but it's likely to end up with a result that's less clean than it would ideally be.
Personally I find the nix language to be a pretty good match for the tasks it is used for (though some basic static typing would be nice).
From the outside, i can see why it looks odd, but from the inside, there's not much of a desire to switch to something better, because the language isn't the thing that gives people trouble after the initial learning period (which would exist with any host language).
Evaluation is completely pure (at least with flakes, which disallows querying environment variables, etc.). Evaluation of derivations will result in .drv files in the store, but that does not add impurity to the language itself. Building the .drv is a separate step (instantiation).
You could totally write something that generates .drv files in a different language and use Nix for instantiation (building). If I am not mistaken, this is how Guix started - they evaluated derivations defined in scheme to .drv files and then let the Nix daemon build them.
Aside from that, as a Nix user, I am happy that Haskell is not the language. Nix is a very small, simple language that is easy to wrap your head around and does not lead to a lot of abstractionitis. A want to say this in a way without painting a caricature, but the Haskell community has a tendency to pile on a lot of abstractions and I would hate to see a Nix with monad transformers, lenses, or whatever is popular these days.
What you can’t port over to another language as neatly are the modules. Good riddance, id say. Undebuggable spaghetti from hell.
> from the inside, there's not much of a desire to switch to something better, because the language isn't the thing that gives people trouble after the initial learning period (which would exist with any host language).
Unfortunately I have wasted enough of my life to call myself “on the inside” and IMHO the language itself is close to the number one threat to wider adoption of nix.
This post is fair.
Nix is very flexible, and it hasn't yet stabilised on a firm set of recommendations for a happy path.
Going on a whim:
* Use nixos-unstable. It's defacto stable, and gets much more attention than nixos-stable.
* Use flakes.
* Don't use multiple versions of nixpkgs. In the rare case a package is failing to build, then raise an issue, or wait, or rollback.
* On NixOS, don't use user profiles. They won't interop in the way OP hopes.
* Only use nixpkgs. If you absolutely must use another flake, only use popular ones from https://github.com/nix-community.
But until the community give opinionated suggestions, users will stray towards bad practices.
(Also, no need to mix pipewire and jack. Pipewire can emulate jack.)
I currently have a spare laptop lying around. I popped in the latest NixOS ISO and just gave it a spin. Some things I noticed:
- The installer only allows to install on ext4 unless you manually partition the disk? I thought it was 2025, not 2005.
- Is there no way to search for packages without a browser?
- I found boot.grub.* and boot.systemd-boot.* - what if I want to use refind? What about Limine?
- How do I know if any given program goes into programs.programname.enable = true or into environment.systemPackages = with pkgs; [ programname ]?
- Why is the ISO furnishing me with a configuration.nix when everyone says to use flakes instead of that? How do I switch?
I'd preferably be able to answer those questions without reading a 300 page handbook. I've been using a lot of Linux distros over the last 30 years and the above questions have usually bean answerable on a headless system with the supplied documentation. I understand that Nix is a paradigm shift compared to "classic" distros, but that only puts the onus more in Nix to be discoverable.
I spent quite a while trying to understand what Nix was actually trying to accomplish and how one would actually go about using it. Granted I was trying to do it on a Chromebook, but the idea stands: I should be able to get at least the nix environment set up and the silly gnu hello world built and running, right?
Turns out nah. The ergonomics are just that of a hiltless double bladed sword.
I'm glad I'm not the only one, but i also was aware of pushcx trying years ago and still failing [1] and he's a smart dude unlike me. I didn't feel so dumb.
[1] https://push.cx/nixos
Guix has better ergonomics, but it's own set of downsides.
I expect the underlying idea of holistic declarative systems is sound, and we're awaiting a polished alternative. Maybe it'll reuse nixpkgs under the hood , but replace the name, the tooling, and the language exposed to the user.
https://netboot.xyz/ is probably the easiest way if your cloud provider supports it.
The biggest drawback is really that "random executable from the internet" does not work out of the box. And sometimes you have to spend a lot of time to package something yourself. But all in all It has saved me time and a lot of pain. I dare even say I no longer have a toxic relationship with my OS.
https://jmmv.dev/2023/07/ldd-untrusted-binaries.html
For random binaries, autoPatchelfHook works miracles.
That world was fun but I don't want to go back to that place.
Thank goodness for perfect rollbacks. I'll take rsync vulnerabilities over a super broken system and try again in a few weeks.
The concept behind Nix/NixOS is amazing, but it needs to be polished. Flakes are the future, but they are languishing in this experimental status. Even simple things like installing packages from stable and unstable channels are too hard to figure out. The documentation is terse and the community answers are often not enlightening.
A big complaint of mine is that the builds should be reproducible, but I find I sometimes need to run `nixos-rebuild switch` several times to get a successful build. The error messages mysteriously resolve themselves. For me, this doesn't pass the bar for being considered reproducible.
Don't get me started on using an NVIDIA graphics card also. Granted, part of my difficulties is that I was running Wayland, which doesn't have the best NVIDIA support, but I felt like I was just doing an exhaustive search through the potential config settings to see what worked. Ultimately, I found just the right combination of settings to get everything working buttery smooth. I ripped out the NVIDIA card and put an AMD card in.
If the software you are using has race conditions in its build system then there is only so much you can do to fix that. You could for example run nothing in parallel with only one core but then everything would be painfully slow. Also the occasional network hickup breaks things. Lately also io_uring in combination with nodejs has been a great source for kernel bugs. You can only bang the software so much from the outside.
Nvidia is bad because Nvidia is bad but at least switching between different driver versions and variants is possible without leaving a trace of old things behind on your system like on literally any other distro.
I've developed enough good habits over the years that I don't get breakages, and home-manager allows me to easily sync my dotfiles across machines..
And yes, I also had to settle for your NVIDIA fix. I suspect I would have had a marginally better time on Arch as there are more people beating their heads against it and documenting how they made it work. NixOS documentation is piss-poor in comparison.
I swapped my installation to a Flake managed install a few months ago, and parts of my Nix files that were perfectly fine before started throwing out errors (specifically HomeManager), which no amount of Googling the error message that gone thrown got me any closer to a solution.
I looked at documentation recently to try and enable PGO/LTO and Zen 3 optimizations (don't mind compiling everything) and I think I saw at least 10 ways and none worked (gcc errors, etc).
I have a suspicion that because the Nix community is disproportionately likely to contain early adopters, the general mood in the forums is less risk-averse than I am with my primary stacks.
My take is: flakes don’t align with centralised nixpkgs and ultimately don’t solve any problems that can’t be solved without flakes.
They’re just an interface for a decentralised module system. You can use them, they’re feature-complete, and they don’t align with nixpkgs: it doesn’t make sense for individual packages to have their own flakes, nixpkgs can already be loaded as a flake.
FlakeHub tries to popularise flakes, but I don’t know if there is a flake discovery problem to solve.
Ekala Project is designing a poly-repo alternative to nixpkgs (ekapkgs) and they don’t embrace flakes.
So... Flakes have reached full maturity: a decentralised package format that has stalled its adoption status within the main Nix toolchain.
I decided to migrate to flakes because a lot of the documentation for things I wanted to do with NixOS required flakes. It took me at least a few hours to understand what the purpose of them was though.
I just wish the documentation would be improved really, as an example https://nixos.wiki/wiki/Build_flags#Building_the_whole_syste... no longer works (gcc complains).
Deleted Comment
FWIW I've been using native zfs encryption on nixos and it works great. It lacks neat features like being TPM-backed or having multiple keys, but if all you need is password-based encryption then I think native ZFS encryption is better since you'll be able to do encrypted zfs send/recv, you'll have granular control over which datasets are encrypted (or encrypted with different passwords), you'd get cross-platform support for the encryption (for example, my FreeBSD home server can receive and decrypt my laptop backups), and you aren't adding another layer of complexity.
Is that still the case? I thought the send/recv bugs at least were squashed a couple years ago?
There have been several times where the latest “stable” ZFS doesn’t support any of the newest kernels, and the “latest working” kernel goes EOL, and so nixos completely drops it.
And my options every time seem to be
-roll all the way back to latest “LTS” kernel. This sometimes breaks things.
-skip ahead to a beta release of ZFS (this isn’t always an option, and do I really want an unstable file system?)
-just don’t update for like a month and wait for new ZFS to release, supporting a newer kernel.
And there really isn’t a good option here. Theoretically there’s another option where I maybe keep using the EOL kernel version, and update the rest of my system normally, but I haven’t figured out how to configure that. So I just pick whichever option breaks the least amount of things each time. It’s definitely more of a ZFS issue than something NixOS-specific, but it’s annoying when I’m suddenly greeted with “That kernel version is EOL now.” And the update fails. And there is no easy way to ignore that and accept the risk of a slightly-outdated kernel.