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.
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.
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.
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.
¹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.
#!/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
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).
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
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.
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.
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).
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.
But NixOS spoiled my entire mindset around Linux. Going back to anything else feels like a massive downgrade. We would be better off today if declarative operating systems became the standard back when they could.
In my experience few years ago, it was a pain to set it up on everything except macOS and iOS (which come with eduroam certificates preinstalled in their trust stores).
My biggest issue has been packaging binary distributed programs. These often want files in a particular directory somewhere, often want to find relative path libraries or plugins, want certain configuration options in etc...
None of that Just Works, there's a whole confusing method to try and monkey patch the software to work but its long list of not being able to find the information you want, not being able to do what you want, or simply limitations around how nix wants to structure things that make it really really frustrating.
If something like Nix were to be done again... I'd really recommend starting with something like a strongly typed flake like language with tooling a lot closer to that of cargo from rust from the get go. Errors should be easy, projects should be easily setup independently, etc. Where every project can simply be built as an independent thing. Sure there's downsides, but the upsides are that... you don't have the impossible task of managing one of the largest mono repos, if not the largest, on github. With all of the insane issues that entails. It wouldn't be that terrible to have a crates.io equivalent to publish, test, and share flakes.
Now I think I might've just created flakehub... but flakehub still relies on nix the tool and nix the language which are far from easy to work with.
Also for someone not knowing Rust it is also very intimidating and if you start to go into more complex things you are easily out of luck with the tutorials out there.
The monorepo is not that big of an issue. More often you are being bitten by badly maintained software that doesn't work with a 3 year old compiler or upstream is unwilling to move forward because of LTS support or something.
But then you discover there are like 4-5 different ways to manage packages and not much consensus in the community on what the correct way is. That was kinda discouraging
0. If you're new and on the fence about using flakes, go ahead. (If you know you don't want them, fine.)
1. Prefer declarative installation to imperative installation.
2. If a module exists, prefer using it to configure a package to just adding that package to a list of installed packages.
3. 'Native' packages are better than 'alien' packages.
3a. Packaged for Nix is better than managed externally. (I.e., prefer that programs live in the Nix store rather than Flatpak or Homebrew.)
3b. Prefer packages built from source to packages carved out of foreign binaries.
4. Prefer to just rely on Nixpkgs for things that are already in Nixpkgs; only bother with other sources of Nix code (likely distributed as 'flakes') if you know you need them.
5. Prefer smaller installation scopes to larger installation scopes— when installing a package, go with the first of these that will work: per-session (i.e., ephemeral dev env) -> per-user -> system-wide).
6. Prefer Nixlang to not-Nixlang (YAML, JSON, TOML, whatever).
7. If you're not sure, go for it.
If you follow these guidelines you'll make reasonable choices and likely have a decent time. The most important rule is #1, so once you know your OS, your task is to make sure you have at least one module system available to you. (On NixOS, that's NixOS and optionally Home Manager. On other Linux, that's Home Manager. On macOS, that's Home Manager and/or Nix-Darwin.)
After that, everything can find its natural place according to the constraints above. If you need to break or relax a rule, it'll be obvious.
Inevitably you'll end up with things installed in a handful of ways and places, but you'll know why each thing belongs where it is, and you can leave yourself a note with a '#' character anywhere that you think a reminder might be useful. :)
Anything that is best configured with a nixos module should probably be in your system configuration, but beyond that there are probably a lot more than 5 different ways and they have their advantages and disadvantages.
What I settled on was a per-user declarative setup (first with "nix-env -r", now with "nix profile"). Then I use nix shells to run software for one-offs. If I find I am running the same software from a nix shell a lot, I toss it in my declarative file.
Plenty of people hate this setup, and do something completely different (e.g. imperative managing of profiles, or using home-manager, or a dozen direnv setups). I don't necessarily think any of them are wrong, but they are not for me for various reasons.
> At this point NixOS has been around for 2 decades, but it still feels like it has not settled on good recommended workflows for incoming users.
Yes. This was a major pain point when I was getting started. The IRC community has been helpful in this regard. I also really don't like that nixpkgs serves as both a lib and a package set. Be one! I don't want "special" inputs in my config.
Users of what exactly?
Workflows for configuring a desktop to play Steam games is vastly different from workflows for managing a cattle fleet of enterprisey servers.
Rollbacks saved me from completely destroying my entire system. I managed to fill up my boot partition in a way that deployed successfully but left the whole system unbootable after reboot, and the only way I managed to save it without having to completely wipe and reinstall from scratch (which means losing all my data) was to load the SD card onto my laptop, fix the boot partition by hand to ensure the kernel from the previous generation was valid, and edit the bootloader config to delete the offending configuration (because accidentally trying to boot it would re-corrupt the boot partition).
I've also used rollbacks in other less catastrophic situations, such as when I broke wireless (since I build remotely on a much more powerful machine and deploy over SSH).
For complicated stuff I run containers such as docker or podman (you could use distrobox too), so I don't have a headache while trying to achieve it in NixOS (but I respect everyone who does this and makes this system grow).
that's not every encouraging :)
That said there are prolific and longstanding contributors who focus on non-NixOS and even non-Linux platforms, and corporate users are likely to be running Nix on macOS or Ubuntu (under WSL). It's not surprising that some users who don't use NixOS on laptops or desktops have still become Nixpkgs contributors or maintainers, imo.
I've never even really tried NixOS on the desktop TBH.
1. I use Nix primarily on the desktop (2 laptops, 2 workstations), though I also use it on one server. I don't think I could ever go back to any other Linux distro for my daily-driver. Things "just work" to a degree that they never have for me on e.g. Ubuntu.
2. I quite despise the Nix language; this is not to say that I think it's particularly bad (or good) as a language, just that nearly every single degree-of-freedom in language design that is largely about personal taste takes the opposite choice to what I would prefer
3. I find setting up development environments with it to be very hit-or-miss, to the point where I have in some cases fallen back on what I would do without nix, and used nix-ld to fill in the gaps.
The thing that hits close to home for me, is the inability to use software that doesn't support nixes opinions on how to do version management (for example a post of mine from years ago[^0]), software that likes mutable state for its configuration (Gnome for example) and yeah, trying new things that aren't packaged for nix means writing a nix derivation.
That said, I feel like nix does more good than harm for me so the paper cuts are bearable.
[0]: https://community.roonlabs.com/t/unable-to-get-roon-to-start...
I've painfully learned how to do everything I need. My only big complaint is updating systemd. I have yet to figure out the systemd update bug. Sometimes nixos-rebuild-switch takes my network offline when updating systemd. It's incredibly annoying to update a box and have it drop offline. My work around is to do a 'diff' and when systemd is updated, I reboot manually and only update the boot image.
No disto ever came close to giving me what NixOS gives:
- I can try to rebuild my system as many times as I want and it doesn't matter if it fails, as long as I get one to succeed I can switch to it;
- Once I get the system the way I want, I can reproduce the same setup with a single command across a number of different machines;
- I can reuse different parts of the config with different machines and update things incrementally, revision, etc, and every time I improve my shared config on one machine, the improvements are automatically transferred to the other machines upon gir-pull and rebuild.
I've now transfered most of my previous configuration to Nix, and not only that but I have tons of services I never bothered configuring on all machines enabled since it was all this trouble of moving configs back and forth.
I've got my share of issues with Nix, from trying to use submodules with Flakes (nixos-install does not work with it) to tons of headaches when trying to play with specializations - most of the time issues were caused by not understanding how the evaluation works or how to properly abstracting modules - but I cannot imagine myself going back to a regular Linux distribution ever again.
At this point I just use Nix home manager for my dotfiles/userspace programs on a normal distro and I feel like I get 90% of the benefit without any of the headaches.
I generally do know my way around Linux command line nowadays, but with Ubuntu and Arch (especially early in my career when I didn't know what I was doing), I would get into states that break the video driver, or break GRUB, or make the machine unstable, and the only thing I could do was reinstall the whole OS.
With NixOS, since it's all declarative, if I end up really breaking something, I can always reboot and choose a previous generation. It makes things a lot less scary for me, I can experiment with and play with different boot parameters and drivers and I know that I won't be stuck spending two hours reinstalling everything. It changes the entire way that I work.
For example, on my current laptop (Lenovo Thinkpad, AMD), I was having an issue with my USB ports idling out, so sometimes the first ~4 seconds of my typing wasn't registering since the USB port had to wake up. The solution involved adding a kernel parameter `usbcore.autosuspend=-1`.
Had this been something like Ubuntu, I have been burned enough trying to add kernel params that I might honestly have just lived with the annoyance because I didn't want to risk everything breaking, but because I knew that there was no actual risk with NixOS, I was able to fix it permanently, and I have the solution committed to Git if I ever have to do this on another computer.
If it works for you, sounds good!
I comment because I recently had opposite thoughts - that maybe I should migrate off nix home manager - to keep 90% of benefits (nixos) and avoid all the headaches (home manager quirks). Funny how opposite experience we have.
For me I love nixos because how when I configure something it just works, and how when I break something I can just undo that easily. And I like how my system don't get more cruft with time and stays lean.
With NixOS: I don't care. You can recover from a half deleted root file system.
To quote a friend: "A new car smell on every reboot."
If you you are cut from the internet or end up with a very slow connection you can end up totally blocked. As a minor configuration change can require you to download a lot of data.
I also found out there is not much you can do to protect you from this.
I found my way to Nix because I wanted to try SteamOS on nicer hardware than the Steam Deck. Bazzite is the recommendation in that space now, but at the time, there were a lot of equally unknown options. There's a community called Jovian that has replicated the SteamOS setup atop NixOS, using Valve's own sources. Using official sources and taking the chance to learn a new functional programming language seemed like as good a place to start as any.
When it works, it's great; however, +1 to all the gripes.
_Everything_ in Nix is set by writing to a text file and calling a CLI to rebuild. If you don't have ready access to a keyboard, you might not be able to so much as change the timezone. You can end up on obsolete versions of evergreen software like Chrome too, because Nix wants to own everything, and nothing changes until you rebuild.
I mean if you have VMs in the cloud, who cares. If you have a laptop or a small network that require to be fully operational even if connectivity is lost, think about it twice.
The bad part is the impenetrable errors and obscure configuration. Although, with the rise of LLMs I find it's not as bad. Getting a non-trivial flake.nix setup is much easier now. Could never remember the override system before, but can manage with Chat GPT haha.
Nix is an excellent build tool. I use it for all of my projects now. And when building is tricky, e.g. Elixir, I rely on Nix devshells to get my tools setup.
NixOS is an amazing server distro. My primary home server VM is running NixOS and it has been rock solid and easy to maintain. I plan to run NixOS exclusively as I add more machines.
But I haven’t had a good experience with NixOS on my development VM (as compared to Ubuntu or Debian). You end up spending more work than expected up front just to get something working. One recent frustrating experience was trying to get VS Code Server to run on NixOS so that I could connect to it over SSH. Ultimately I just gave up.
It did, and thanks to that rollback feature, my system was working in a few minutes.
I would say the biggest negative is that it seems the development of it is disjointed, as there are almost too many ways to do the same thing; some things are being deprecated before the documentation even keeps up with development.
--- personal notes: --- Also, some things are finicky and require some understanding to get to work (e.g. getting VSCode (on Windows) working with language analyzers and code sitting inside a WSL NixOS distro)
- I love Flakes but don't really love home-manager; I can understand home-manager being useful if your using Nix and not NixOS. - My NixOS rules pretty simple: 1) A per-project flake.nix + direnv file (or an env playground) 2) Configuring "etc/nixos/configuration.nix" for global tools like "wget, git, etc." (don't get me started with programs.<program_name>.enabled, see above for "too many ways to do the same thing")
programs.<program_name>.enabled implies that there is some system configuration needed in order for the program to function (or in home manager, the analog would be user configuration in your home directory).
Whereas environment.systemPackages simply puts bins on your path.
> The advantage over docker here is that (when using Flakes) Nix builds are completely reproducible. Docker containers may be isolated, but surprisingly they are not deterministic out of the box. With some work you can make docker deterministic, but thats what you need, its much easier to use Nix.
as the whole purpose of the Dockerfile is to create a reproducible environment.
For example, if you have a debian base container that you run `apt install nginx` in, what version you actually get depends on a lot of different things including what the current version of nginx is inside of the remote repositories you're installing from _when the docker build command is executed_, not when the Dockerfile is written.
So, if you do "docker build ." today, and then the same thing 6 months from now, you will probably not get the same thing. Thus, Dockerfiles are not reproducible without a lot of extra work.
Nix flakes are not like that - they tag _exact_ versions of every input in the flake.lock, so a build 6 months from now will give you the _exact same system_ as you have today, given the same input. This is the same as like an npm lock file or a fully-specified python requirements.txt (where you have each package with an ==<version>).
So, you definitely can make Dockerfiles reproducible, but again, the Dockerfile itself is not made to do that.
Hope that helps your understanding here!
Its even worse. Its not the current version when the command is executed, its _the current version taking the layer cache into account_, which is a classic docker gotcha in needing to do single line `apt-get update && apt-get install` to sidestep. The layer cache really makes it hard to reason about.
Then theres the million app-level changes that can creep in, eg copying local source is non-deterministic, apt-update, git clone, etc. Nix requires you to be fully explicit about the hash of the content you expect in each of those cases and so if you build it twice it is actually the same build.
A more trivial example of non-deterministic would be that you can write a Dockerfile that uses curl to fetch data from random.org; the functions nix provides for fetching from URLs require you to specify the sha-sum of the data you fetch.
Nix flakes make it hard for you to inject anything into your dependencies that hasn't been hashed to confirm its identity. It in many cases still isn't 100% deterministic (consider e.g. a multithreaded build system where orderings can influence the output), but it's a big improvement.
The idea with nix flakes is it has a lock file which should guarantee the same build. This is like package-lock.json or pdm.lock which contains dependency checksums for every package.
Docker works more like your standard package manager. If you ask for mysql 5, today you may get mysql 5.1, but next week you may get mysql 5.2. So it does not come with a guarantee.
The issue is that you have to lock down all your dependencies, including local data, repos, and registries. Most people, and even most companies, don’t have the resources to achieve that, so they simply don’t do it.
Further, Docker doesn’t provide any significant mechanisms to help ensure reproducibility in the face of these issues, so you can’t say that Docker supports reproducibility.
My first hurdle was configuring the network in configuration.nix. The installed template implies network settings go there, but that’s misleading. Worse, "nixos-rebuild switch" requires a working network, so a broken config leaves the system unable to fix itself – a catch-22.
Next, I tried "nix search wget", as suggested in the manual, but hit errors about missing experimental features. I had to enable both nix-command and flakes manually to get this to work:
nix --extra-experimental-features nix-command --extra-experimental-features flakes search nixpkgs wget
(edit: formatting)
I just ran into this on an airplane! I'm relatively new to nixos (~4 weeks in) and I had configured my laptop to use DNS over TLS and DNSSEC, which is normally not a problem. But to get through those login gateways for the wifi, you need to disable all of that so they can MitM your DNS requests. "Thats no problem, everything is already in my nix store so I should be able to comment out those lines and run a nixos-rebuild" I thought to myself, but alas I was wrong. I'm sure I could have worked through it with enough persistence but it was a short enough flight that I decided to just wait until I landed to continue my otherwise wonderful journey into the nix.
I can see the value in a completely declarative configuration for my OS.
But the hurdles to get something worthwhile out of that value prop are just too high with my (low) level of skill (in this area) coupled with the limited time I have to build new skills. There are other things I want to invest my time in, but I can totally see this being where someone wants to spend some of their time.
I've never found setting up a Linux distro the way I want it particularly hard and once in a while I like to just start from a blank slate to see what's new—so yeah, not for me.
Trying to hack on other people's junk with NixOS is just asking for pain. Just use Ubuntu LTS like everyone else. That's generally easy and painless.
To me that's a large part of the very definition of a useful general purpose OS is that it's flexible and enables you to do whatever you need to do today, without the developers having previously somehow planned and provided for exactly that thing.
It's like the systemd argument all over. The exact thing systemd aims to prevent is the exact thing that made the original unix so powerful and useful that 40 years after architecting it, it still worked because they didn't try to think of every possibility, they gave you a toolbox that let you do whatever you might need to do. Where systemd sees a shell script as "unmanaged chaos" I see "unconstrained utiliy", a useful toolbox including a saw that doesn't have it's own opinions about me what boards I can cut.
If "Trying to hack on other people's junk with NixOS is just asking for pain." that is basically the definition of "this is not a useful operating system that empowers me to get things done". It's useful maybe as a crafted firmware for a static device.
(Not saying that nixos inflexibility is driven by the same paternal "we'll give you the whitelist of actions Poettering thinks are valid" attitude as systemd. In nixos it's merely a natural consequence of indirection and layering. They aren't trying to remove any agency from the user/admin, it's just the simple indirection itself that makes pre-planned and standardized things easier at the expense of anything direct and unplanned becoming harder.
Like instead of having an OS that may or may not be driven by ansible, let's replace the OS with just ansible, and now there is no way to do anything any other way except by figuring out how to write a playbook to do it.)
NixOS gains most of its power from restrictions. These restrictions enable awesome things like starting a shell with all dependencies in seconds versus minutes using alternative technologies (used by great effect by replit). Nix works surprisingly well for most software, but anything with a ton of dynamic dependencies is going to cause issues. Even knowing what the dependencies might be statically can be hard. Sure, providing an OS with no restrictions and complete flexibility is an option, but then you'll just end up no better off.
Whatever the future of operating systems will be, it certainly will involve more restrictions and less flexibility.
Yeah, but being that Nix is essentially a giant wrapper for the system, that kind of goes without saying. The other side of the coin is that, using other people's Nix junk is extremely easy. Far easier than what any other distro could hope to achieve.
My favorite example is simple-nixos-mailserver. Try passing someone a dovecot, postfix, and openssh configurations/instructions in any other distro and see how long it takes before they mess up, or more likely, give up.
Whereas with simple-nixos-mailserver, you're guaranteed to get something to work, essentially right out of the box.
Stability is a great thing for busy professionals that want stuff to just work.
How many apps have you upgraded that have crashed and burned from the update? Me, a lot. both commercial and OSS. With OSS at least you get all the pieces so you can figure out how to put it back together again. With Commercial, you rollback, file a bug report and hope someone somewhere in the company will be incentivized enough to fix it for you.
The problem really stems from how tightly entangled packages are to the nixpkgs source tree. Nix offers the most foundationally modular system possible, and it organizes its packages in a monolithic source tree! This means that despite installed packages being totally isolated in the /nix/store/, the package source (what Nix calls a "derivation") is semantically tied to whatever specific dependency version was implemented in the contemporary nixpkgs source. If you want to provide users more than one version of a package inside the same source tree, you must put the version in the name, like SDL2 or python3.11.
I started this GitHub issue a long time ago: https://github.com/NixOS/nixpkgs/issues/93327. Somewhere buried inside may lie the answer to your question. Either way, I have mostly given up on wrapping my head around the current ecosystem of half-baked solutions to this mess; despite still actively using NixOS in ignorance.
This only works for versions of your package that do exist in nixpkgs but aren’t currently the default for your chosen channel, so it doesn’t help if your channel is out of date and you want to install a newer version that hasn’t been packaged yet. But then that’s the case in almost any Linux distro if you rely on installing your software from the distro’s native package repo, and much the same solutions exist in NixOS as in other distros. Although if you’re really determined, you can also start writing your own derivations to automate building the latest versions of your favourite applications before they’re available from nixpkgs…
¹ https://lazamar.co.uk/nix-versions/
² https://lazamar.github.io/download-specific-package-version-...
From their homepage:
> Declarative builds and deployments.
> Nix is a tool that takes a unique approach to package management and system configuration. Learn how to make reproducible, declarative and reliable systems.
So is it some kind of CI/CD system? A package manager? But people seem to be running it as an OS? Why would I want to declaratively build my OS? Why not just use one of the hundreds of distros already available with lots of packages to pick and choose?
The install nix link on the home page seems to indicate I can install it inside linux. Does that mean nix is not a distro itself? Oh but further below there is a disk image too. Huh...
Its all very confusing to me. And that triangular image every single nix related articles uses is no help.
He did find functional programming to be sort of mystic so I don't know if I trust his take on assesing the nix language itself.
TLDR; just stick with ubuntu or arch unless you feel like experimenting
I've got x86 servers running NixOS that are deployed using Colmena, but it seems to fall apart when I add cross compilation into the mix.
When I worked on my startup briefly, I built nixOS images with everything needed for raspberry pis; all I needed to do was use dd to burn the image to an SD Card.
For me, nix is a wonderful and perfect solution for building stable software.
1) I Don't Know The State: there's some weird little bit of state hanging around somewhere I don't know about that's messing with my end result. Once I learn about this state, correcting it is trivial.
I hate this kind of problem solving, it's not mentally stimulating, I don't learn a lot, looking up answers online is often not helpful. And when I fix it, I don't gain a lot beyond just the problem not happening anymore. (examples: secret config file i didn't know about, an application edited its own config, file permissions were wrong, symlink was wrong, cache is invalid, etc.)
2) I Don't Understand The Concept: the idea of what something is supposed to do or why hasn't clicked for me yet. Getting to that state will take some time as I wrap my head around it. Once I do, I have that knowledge forever and can build on it to understand even more concepts.
I _love_ this kind of problem solving. It's mentally stimulating, it builds on itself, increases mastery, problems are easily found / troubleshot online because people are dealing with similar issues and not their own machine's personal state.
NixOS has been almost entirely the second kind of problem solving for me. The first two weeks were basically a full time job of fussing with my config but once I got it, I got it forever. Writing my first derivation was confusing, but now it's easy and it'll always be easy.
I think this is why Nix has been able to "get away with" having the abysmal, fragmented documentation that it has for so long - it's so good at being a near-stateless, all-encompassing declarative configuration that even outdated blog posts, random people's personal configs on github, even the nixpkgs source code can be helpful enough to solve your problem (and that's often all you have to go on!!!)
The multitude of ways things can be configured spooked me a bit for desktop use though.
A good article nonetheless.
Mass storage on a big encrypted RaidZ array of spinning rust, no issues. Bootloader, /boot, Encrypted Root and Databases on Mirrored NVME Drives. And man is that a nailbiter on each update. Setup my drives during 22.11 following NixOS Root on ZFS instructions [1], which were amended following reports of systems becoming unbootable [2] and mostly removed later [3].
Besides initially being a broken setup [4] with an increasing amount of mounts each update stalling any system writes and causing updates to fail, it became a well running machine after that was fixed. Then during the 24.05 update and with no config change, the system became unbootable [5]. After a tough recovery [6] I never figured out how to do mirrored bootloaders again, switched to a single bootloader setup. To this day I have interactions I don't understand and am trying to fix [7], which sometimes causes updates to knock services offline due to the `nixos-rebuild switch` process stopping services, going to update the bootloader, failing due to missing mounts and exiting with services being offline, prompting manual intervention.
[1] https://github.com/openzfs/openzfs-docs/blob/1211e98faf1f37a...
[2] https://github.com/openzfs/openzfs-docs/commit/1211e98faf1f3...
[3] https://github.com/openzfs/openzfs-docs/commit/4fb5fb694f44c...
[4] https://github.com/NixOS/nixpkgs/issues/214871
[5] https://github.com/openzfs/openzfs-docs/issues/531
[6] https://github.com/openzfs/openzfs-docs/issues/531#issuecomm...
[7] https://discord.com/channels/568306982717751326/132854109967...
i tried looking into nix but felt very weird having python and flask as the same thing am i just heing irrational?
> But not always. Why? Because there are so many ways the context can vary as everyone is doing different things. Is that config you found:
This whole section reads like author gives ChatGPT code snippets and asks it to explain.
Nix snippets are not very copy-pastable because everyone creates different abstractions to reduce boilerplate. I have probably done "JSON -> list of packages" conversion 3 different ways in my codebase.
See what people are promising when they say "declarative" is a dream. You just tell the computer the final state you want, and the language does what it needs to do to get there.
The problem here, is that in order for that to work, the language has to know how to get where you want it to go, and give you vocabulary to tell it that. That "how to get there" and "vocabulary" has to be written in a (gasp!) general-purpose language.
So now, you come across a situation where you need the declarative language to do something it doesn't know how to do. So now you're forced into the position of helping create the declarative language. And as it turns out, creating a declarative language in a general-purpose language is a lot harder than just using a general-purpose language to tell the computer how to go where you need it to go in the first place, because you have to delve into an existing codebase which is inevitably giant.
I've begun to refer to this anti-pattern as "Configuration-Oriented Programming" (COP).
I'm being a little facetious here--I've not looked into Nix enough to have any educated opinions on it. But it sounds like my outsider impression that Nix is a COP might not have been too far off.
I originally had a very positive nix experience. I had to fix some docker build issue at work. This particular dockefile needed the buildx command. Except for whatever reason I just couldn't install the needed component for buildx to work. Somewhere during a messy Ubuntu 18.04 to 22.04 upgrade something broke and now I was getting a conflict (with nothing btw, it's just empty).
I used nix to install docker and the required component with no hassle and was able to get on with my work.
Inspired by this experience I wanted to evaluate nix for a more long-term usage. I setup my personal PC to dualboot windows and nixos. The trouble started basically immediately.
I couldn't get KDE plasma 6 to work with Wayland. It turns out that you need to also enable Wayland support in sddm. Why the official installer did not do this or why this was only documented on some random unrelated page in one of the two wikis I couldn't tell.
Ok, video working I immediately spotted another problem. I set up my disk encryption, login and kde wallet passwords to match in the hopes that on boot I will only have to enter it once (this is an option you can enable). Login screen worked, but kwallet just wouldn't log in automatically. I spent literal hours on this over the past year each time walking away frustrated. Is this a nix issue, Linux issue or kwallet issue? Who knows. Eventually I just set an empty password for kwallet. This still didn't solve my git ssh keys not loading automatically. I just gave up.
Most importantly, dev environments just do not want to work with VSCode. The recommended extension stopped working years ago, the other extension still works but there's no way to force a specific load order so randomly other extensions will just not see your nix env. I had to resort to installing rust globally just so I could get rust analyzer working. So much for dev environments. I don't even want to go over how much working with package managers when using nix for building sucks (particularly npm/pnpm/yarn).
If I had installed nix on a work laptop they would have fired me for wasting time. Next time I'm trying one of the immutable config driven distros. Hopefully that is going to work better.
System services have always been able to be configured by dropping files in /etc. Lots of software also specifically supports config dropins, so that merging configs from multiple sources is even easier. Even stuff like creating users and groups can be done on systemd distros by dropping in config files. Similarly configuring user software is mostly about dropping files in ~/.config etc.
Package managers vary. Alpine's apk is the best in that `/etc/apk/world` is the list of packages you want, and every run of `apk upgrade` will install and uninstall packages accordingly to match that list, but it doesn't have dropins. apt and zypper don't even have a config file, only an opaque database that you can only interact with using the commands. But you can maintain your own packages list and then script apt/zypper to diff against that list and install/uninstall accordingly. (zypper in particular does maintain a list of packages, except it's a list of packages that you *don't* install explicitly but are just auto-installed as dependencies of the ones that you did, which is funny to me.)
I get declarative config on all my devices (a mix of OpenSUSE, Debian, Ubuntu and postmarketOS, across servers, desktops, laptop, phone) with just an Ansible-like setup. For each device I have a `$hostname.roles` file that contains one role per line. Each role corresponds to a `role.$role` directory that contains any files that should be deployed as part of that role (both under homedir as well as at the system level) as well as a `packages` file that lists any packages that should be installed for that role. Then there's a small shell script that matches the hostname of the machine against this directory and ensures that all files exist, and that all the required packages are installed and no extras are installed. Also the entire directory is in version control so I have a log and reasoning recorded for every change.
The author mentions rebuilding a laptop to do another laptop's job by applying the other's Nix config. I have also used my script to rebuild a few devices after their disks died and I had to reinstall the OS from scratch, so it ticks that checkbox too. And of course I've added and removed roles occasionally to add/remove features from individual devices.
NixOS would give me a way to rollback the entire config, but I can also do that with this. In case I need to rollback to packages that no longer exist in the distro repository, I have btrfs snapshots to roll back to.
NixOS would give me a way to install multiple versions of packages, but this is something I've never needed. I primarily stick with distro software so it is always consistent, and if two distro softwares require different versions of the same dependency, distros already know how to solve that (make two coinstallable packages).
The one time I tried to build someone else's Nix project (and they even had a Dockerfile with nix in it to do the build so it would be completely independent of the host), it didn't build for me, so I'm not sure how reproducible it really is. But that might've just been a problem for that one project.
I'm sure Nix(OS) has benefits for other people, but for me the benefits that I would care about are handled entirely by dropping files in the right places, and I don't have to use a different OS or package manager or bespoke programming language to do that.
Using another common tool (salt/chef/puppet/...) or something home-rolled? (Just asking because I'm interested in new options in this space)
Also it means it has no dependencies on the target machine. You might say Ansible doesn't need anything on the target machine except ssh, but it does require the target machine to be reachable over ssh, which is not necessarily the case if I'm rebuilding a machine such that its network is not already configured. So in that case all I need to do is sneakernet my git repository over and then execute a shell script.