I switched my workstation over to NixOS ~6 weeks ago and it's been really good, I'm a total convert. The thing that really got me over the hump was entirely configuring it using Claude Code.
One unexpected benefit is that both my workstation and my backup laptop have the same setup, so I can run updates on the scratch box before doing my workstation. I decided to run the "latest" rather than 25.11 release, so it's nice to test before I apply (I hit a GDM issue a few weeks ago that left me at a black screen; but not a huge deal, just select the "previous" option in the grub screen).
I've got everything to parity with what I had on my previous Ubuntu workstation. I had anticipated issues with some software that isn't packaged (but NixOS packages a LOT), but that wasn't an issue. Claude was able to do all those things no problem.
The biggest tricky bit was with my vim setup; I've been using AstroVIM and trying to get away from managing my own vim setup. You can't, AFAICT, just apply astrovim in NixOS. So I described the vim setup I wanted to Claude Code, and I now have a ~700 line config that implements everything I wanted: LSP, TreeSitter, a small variety of other things. Unlike Astro/Lunar, where tweaks you want to make are buried in some set of files in this whole giant distro, it is all encoded in this one "neovim.nix" file.
I also set up home-manager and SOPS and so far that has been working just great! I now have home directory settings that are replicated across 2 machines.
I'm still really only using it on one machine, so we'll see how it gets more complicated if I start running it on some servers.
I'm on year 6 and still feel the same way, using NixOS for all my machines, and also for my homelab servers (building on the main machine and then deploying over SSH). Everything else feels primitive by comparison. Rolling back is incredible.
I have one github repo with a top-level flake containing system definitions for all of my machines. Much of my config is modularized, so it's easy to take custom stuff from one machine and use it on another.
It's nice to hear that AI tooling is making it more accessible for people.
I'm no AI booster by any stretch of the imagination, but it's not "run[ning] ... computer systems" in this case. Your NixOS setup is defined by declarative config files, and nix builds or updates a working system from them. AI in this case is just writing the config files, which you'd then (hopefully) read and at least vaguely understand before applying them.
It generates a config file. You can read it before applying it. While Nix may be nigh intractable to write for some people, it is quite a bit easier to read, and any shenanigans would immediately be noticed.
I had quite a rollercoaster going from Windows 10 to Arch to Windows and then settling on NixOS. Main reason being able to do clean package/program setup and centralize, version-control my configuration.
My main issue with Arch was that after installing and trying stuff it left OS dirty even after package removal. This might be because I had some things built and installed through AUR (e.g. latest mpv releases that sometimes broke). Eventually I went back to latest Windows 11 build wanting easy no-bs setup.
Of course, then MS decides to shove down half baked AI integration that somehow used half my RAM and randomly slowed my CPU. I am guessing it was busy indexing, searching or security-scanning something.
Got increasingly annoyed by Microslop and tried NixOS. Bumpy ride initially but after committing for few weeks I am finally settling on it be the last OS I need.
I also really like that Nix (both on NixOS or as a package manager for Linux/macOS) can temporarily fetch packages with `nix shell` removing entirely the need to install something I am just trying out or something I know I am not going to need on a regular basis.
Similarly the integration of flakes/devshells and direnv is great to create reproducible development environments. Everything I need and at the correct versions are automatically setup as soon as I `cd` into a project directory.
> My main issue with Arch was that after installing and trying stuff it left OS dirty even after package removal
Yeah, that's literally a problem with every single OS that is not NixOS (or, shoutout, Guix, or the other Nix-based variants).
That's also why I am sticking with NixOS. Been at least 5 years now- it's wonderful having a reliable LINUX system as my daily driver (or one of them).
And you can reboot into any old configuration! Even more insurance against fuckups!
> I am finally settling on it be the last OS I need
Same here. As soon as I got everything set up just how I like it in a declarative, reproducible fashion, I had this feeling of... "OK, this is great. I can't see a reason to ever leave this."
Aconfmgr is a good solution (practical trade-off for me). When it feel like "my OS must be dirty at this point", then I spend a couple minutes with this and I'm back to the clean state.
I don't do this more then twice a year, so if you insist on an always clean system, YMMV
> installed through AUR (e.g. latest mpv releases that sometimes broke)
On my home system I'd do this to switch to a new mpv release:
"gitty mpv"
(This is my alias to check out the latest mpv sources, from github, via git clone URL_HERE.)
Scripts repackage mpv into .tar.xz after this git clone step.
Then I do:
"clangy mpv"
clangy is my alias to compile via clang from llvm; and the
specific instructions would be found in my COOKBOOKS_DIRECTORY
aka recipes (similar to homebrew, but in .yml files), where
all information is gathered from mpv.yml then.
One setting there is:
prefix: f
This means "non-traditional prefix", aka "AppDir" prefix. AppDir
prefix is how GoboLinux installs software, e. g. in /Programs/Mpv/22.06.2026/
(I keep the dd.mm.yyyy notation, but this can be toggled; on my home
system I use /home/Programs/ though rather than /Programs/ for historic
reasons, and also as I want to backup my /home/ directory, including
all programs).
So the above would, via clang, compile mpv from source (if the git clone
worked), into the AppDir prefix. Then it would simply create symlinks
and so some more processing, so /usr/bin/mpv would point at /home/Programs/Mpv/Current/bin/mpv, and Current is a Symlink to the
current version in use. I can keep old entries of mpv under /home/Programs/Mpv/
so switching is trivial. And cleaning up is also trivial, I remove e. g.
an old mpv version there, then call one post-removal script (or I simply
pass the name of it, but I find it easier to work via the commandline in
two steps here). The benefit of the above is that, for instance compared to
your "latest mpv release sometimes broke", this would not affect me, the old
mpv versions would work still, and there can not be any outside installation
other than the versioned AppDir.
Right now my /home/Programs/ has 499 entries. I'll eventually have all programs
there, and work, then I'll switch to a completely custom LFS/BLFS. Right now my
base system is manjaro, which works very well as a base system, even though it
uses systemd. /lib/ is a symlink on manjaro by default towards /usr/lib/ and so forth. I find this works so much better than e. g. debian.
> Got increasingly annoyed by Microslop and tried NixOS. Bumpy ride initially but after committing for few weeks I am finally settling on it be the last OS I need.
Not disagreeing at all, but imo the issue you had with AUR is one that by design could be completely avoided. I am not saying this is your fault, mind you; just pointing out that this may be an assumption by both AUR as well as you, since your expectation is to trust the package manager. Here, my input would be the question whether a package manager would be necessary in the first place or not (I still have scripts to handle that, mind you, but the assumptions made via AUR may be wrong in many areas, including not offering versioned AppDirs by default. I don't understand why all package managers do not offer versioned AppDirs; it would solve so many issues).
I should add that some programs are harder to install from source, but mpv works very well; ffmpeg too, surprisingly enough. LLVM/clang is a bit harder to setup, and by far the worst offender is firefox. Mozilla should be ashamed of mozconfig for life.
God bless Hacker News, where "just start building your own package management system, like I did" is an earnest comment, including a sketched out implementation.
BTW, there is a NixOS.wsl for Win11 and Nix-Darwin for macOS and the Nix package manager runs on any Linux. You could run Fedora and configure somethings with Nix.
Nix excels at solving real world problems for developers. No more "Well, it worked on my machine". You setup a flake.nix in your code repo along with direnv and even that new junior dev can merely clone the repo and all the dependencies are installed by the flake.nix configuration file. Including the language and IDE configuration for the team. i.e. tabs vs spaces and whatnot. The same flake.nix can be applied to your CI / CD to help with reliable builds. You can also use it to create Kubernetes and other containers or a bare metal NixOS server. Keep all the configs in git and run them straight from the repo.
It's great for ensuring your devs don't break the freaking build by updating something with npm, etc. You should audit anything you install due to the severe threat of supply chain attacks. Recently impacting Node.js and Arch Linux AUR, etc.
Yes, LLMs can write quite a lot of Nix but they don't necessarily get down to the nitty gritty best practices. So you need to be careful with it. You should also audit your configuration for security issues.
I really love NixOS for my two devices, one surface laptop (lol), and my nvidia pc. It reduced my headaches with drivers so much.
Before updating my nvidia driver or something related to my surface I was scared to break something. With NixOS I can just go back to the old working config.
Another underappreciated feature about NixOS is, that you can create a VM out of a NixOS config to locally test a server update/deployment.
Yep, exactly the same experience as me. The fact that everything is declarative and revertible means that I'm much "braver" than I would be with virtually any other Linux.
An example I have given before, but there was a weird quirk with my ThinkPad with Linux, where with USB keyboards, if I hadn't been typing for more than a minute, it would have to "wake up" for about four seconds, so I'd lose the first couple words that I was typing.
Fixing this involved playing with a few boot parameters, which can be scary to play with on something like Ubuntu. The issue is annoying, but nothing I can't live with, so if I were on Ubuntu or something I probably would have just tried to live with it, but because it's NixOS, I realized that the worst case scenario is that I reboot and choose an older generation, so I did a few experiments with boot parameters and fixed it.
> Another underappreciated feature about NixOS is, that you can create a VM out of a NixOS config to locally test a server update/deployment.
And similarly, you can generate a bootable ISO of your NixOS config. It's really nice for both testing things out and also as a recovery mechanism. Rather than booting some generic ISO, connecting to the internet, installing whatever recovery tools and filesystem drivers I need, and then doing the recovery, I can boot an ISO that is identical to my main system, with all my favorite recovery tools pre-installed.
I've ditched M$, switched to NixOS last month and I feel like I don't hate computers again. Shouldn't have procrastinated this for so long. All other operating systems feel so silly to use now (at least when they aren't anxiety- and rage-inducing).
I love the slightly weird learning curve on NixOS where initially it seems incredibly complex writing this weird functional programming language for every change you want to apply to your system, then over time it clicks and you end up in a place where any operating system that doesn't define everything in a weird functional programming language seems incredibly complex. I read blog posts about doing things on other distros now and I'm left thinking that an 800 word set of instructions would be 25 lines of Nix expressions.
it's like reading instructions for using a GUI program (open this dialog, click this checkbox, fill in this value) vs copying and pasting a complex FFMpeg command
I love seeing all these posts from NixOS newcomers! It seems anecdotally like LLMs have really given it a boost recently, I guess by reducing the intimidation factor of the language and the unfamiliarity? Of all the positive and negative outcomes I have imagined from LLMs, NixOS becoming popular was not one of them, but I'll take it.
NixOS has been my daily driver since 2022/2023 and I have greatly improved the management of my 2 computers and few VMs since. Because of LLMs, I now understand the language much better, but even if I didn't want to write Nix directly, describing the config to AI usually produces good results.
The two main sticking points IMO are still:
- Development environments are still a pain. devenv.sh is great for web and backend, but not perfect for dependency (package) management and more complicated environments like mobile or embedded
- nixpkgs monorepo doesn't update fast enough IMO. As a consequence, I see a number of flake repositories popping up to more easily package and distribute software not yet on nixpkgs or that don't update often enough (https://github.com/numtide/llm-agents.nix is a good example). This is perhaps by design, but it takes some digging to find the reliable and trustworthy flake repos. I'm increasingly concerned with AUR-like trust issues
> Development environments are still a pain. devenv.sh is great for web and backend
Weird, development environments are one of my favorite things about nix. I don't use anything like devenv.sh, just add a `flake.nix` to the repo defining a devShell, and then add `use flake` to `.envrc` and let direnv activate it. Every major and most minor editors have support for direnv, and if they don't, you can just launch them from a shell in that directory. This makes the only system dependencies for a great dev environment nix and direnv.
> I'm increasingly concerned with AUR-like trust issues
Once you've done it a few times, most things are pretty easy to package yourself, and you can just check those derivations into your git repo for your machines and use them. Especially if you're using LLMs, it shouldn't be all that hard to package what you need in most cases. For stuff that's more complicated or difficult, it's more likely there will be some kind of de facto standard flake for it.
I decided to move to NixOS a few months ago. In terms of OS, it was one of the best decisions I've made so far. It's awesome to have the rollback experience, upgrade whenever you want and also being able to experiment without being afraid of breaking already working stuff.
Another great benefit, is that AI can read my whole OS (good and bad at the same time, I know). This makes the AI way more accurate on giving you a good solution instead of having to scan all of your OS and dig into /etc.
Personally, I really like NixOS. It's hard but definetely worth the try. Probably not for everyone, but worth it if you're a computer scientist or need to maintain hundreds of computers.
One of the best things about Nix, aside from LLMs being able to manage your config, is having a monorepo that contains the config across all machines (shared and machine-unique), like hosts/{nas,macbook}/{configuration.nix,home.nix,modules/}.
Now I have the same setup across my macbook, desktop, and NixOS servers.
Understandable with Apple dropping official support but kind of sad as they were selling Intel powered Macs until as recently as 2023 and with Tahoe still continuing to receive security updates until 2028.
How is NixOS on Intel Macs currently? Hopefully Linux can still breathe life into these computers in 10 years time.
I've been using t2linux[0] patched distros on an Intel MBP for a while now. While I applaud the efforts, it is not without sharp edges, and I do occasionally have to boot into macOS to do some things. I gave up on trying to use the onboard or bluetooth audio (onboard can cause it to crash in weird ways, and bluetooth can break depending on if wifi is in 2.4 pr 5ghz mode? I don't know, I use a USB DAC now and it's fantastic). Trying to use the webcam causes a hard crash. Sleep is weird (but that's a given for most linux things I think). The maintainers do a good job of getting all their little hacks included...but I'd probably be frustrated with it all if I didn't have 25+ years of experience with linux and be able to fix things myself. The MBP was a gift and my only machine at the moment so I won't complain much personally :).
It's great. It's complicated. I have a MacBook Pro Late 2013 – very old. NixOS runs totally great! Even the proprietary hardware just works, with the nixos-hardware channel. Battery life is awesome, 4 hours of office work.
There is a snag however: Drivers for the built-in Broadcom Wi-Fi card are unmaintained and bug-ridden. Replacements do not exist either. The driver doesn't work most of the time nowadays and I have to rely on a USB Wi-Fi adapter that is sooo slow.
Maybe more recent Wi-Fi chipsets in Intel Macs are better off. Or maybe you don't need Wi-Fi!
I post this on every post about Nix I encounter, but I sincerely hope that it gets static electricity typing one day. I have yet to try typenix (a fork of the typescript compiler applying the typescript type system to nix)
Adding TS types to Nix would make it so much easier to write Nix code. Which string do I need here? Oh the type system knows, the language server shows it inline - I don't have to look at the source. I've used NixOS since 2018 and written nixpkgs derivations and it would've saved me so much time.
I'm glad that TypeNix exists but it really should just be officially supported or even the default.
What makes Bazzite-like uncommon is the degree of hardware testing and kernel tuning required to get some of the more exotic hardware fully working and stable.
I am tempted to try making a "Nixzite" flake just to see how far it can get to feature parity with Bazzite, but again most of the story with Bazzite is the sizable community working on hardware tuning and kernel modifications. The catch with that flake would be a lot of waiting for the kernel to rebuild if I bring in the Bazzite patches, and that's just not a fun UX...
There are templates for deploying NixOS but almost all that I've encountered are heavily opinionated and thus only kinda work for specific people (usually the ones that designed them). Then when you want to customize them it's almost always easier to start from scratch.
I've used this set up for 3 or 4 years now and love it. I used to hit bottlenecks having to edit some nix files once or twice a month and forgetting the language but LLMs dramatically reduce that barrier.
The same reason you don't use arch linux on servers. Some distros are simply better suited for servers. We do have talosos for k8s and we (used) to have clearlinux.
rather than being theoretically better, it's simply the standard way of running servers. Nobody stops you from using nix or even arch on servers, but nearly all of installations, enterprise packaging and "officially" supported distros are debian/ubuntu/centos and has been like that for a really long time.
Nvidia for example won't give you any support unless you use specific kernel versions on ubuntu.
The majority of these commits are to keep packages up to date. Easy to get an incredibly high number of commits when nixpkgs is a monorepo containing the definition of 140000 packages
NixOS is a pretty cool idea in theory. In actual practice
I found it too complicated to manage. Immutability is kind
of cool too, but it creates an obstacle to solving even
trivial task in my daily life using Linux. And I don't want
to really use such a domain specific language like Nix, for
things that really should not need a programming language
per se. For instance, I like ruby, but I don't want configuration
stuff to be kept in .rb files; that's also one gripe I have
with homebrew, even if the idea to HAVE a recipe in a .rb
file, is not bad per se. I am just too used to e. g. yaml
files or any other simple format for literally everything.
All my RC files and ENV data and aliases for shells is kept
in .yml files; ruby then just autogenerates any target
format I need for different shells/terminals, and so on and
so forth. Also, NixOS is not very flexible. I prefer e. g.
/Programs/Ruby/4.0.5/ rather than a hashed directory name.
It's not a bad idea here either, and there would be many
workarounds for that (see GoboHide on GoboLinux, for instance),
but at the end of the day it felt as if I was fighting NixOS
too much than getting real work done. There is something to
be said about simplicity at all times, even if the ideas in
NixOS are still great. For instance, we could guarantee that
every snapshot would work, so people having the same hardware
could just re-use configuration and have things work, without
needing to know how to change the system precisely. That would
not be needed because NixOS could make a guarantee about ALL
possible stable snapshots in time. I don't think NixOS goes
that far, so far, but it would be a very logical extension.
Same with immutable packages / reproducible packages:
We could make such a guarantee if we extend NixOS. But until
all of that happens, I stick with simplicity and flexibility.
It just kind of works better, even if it is nowhere near as
sophisticated as NixOS.
I switched my workstation over to NixOS ~6 weeks ago and it's been really good, I'm a total convert. The thing that really got me over the hump was entirely configuring it using Claude Code.
One unexpected benefit is that both my workstation and my backup laptop have the same setup, so I can run updates on the scratch box before doing my workstation. I decided to run the "latest" rather than 25.11 release, so it's nice to test before I apply (I hit a GDM issue a few weeks ago that left me at a black screen; but not a huge deal, just select the "previous" option in the grub screen).
I've got everything to parity with what I had on my previous Ubuntu workstation. I had anticipated issues with some software that isn't packaged (but NixOS packages a LOT), but that wasn't an issue. Claude was able to do all those things no problem.
The biggest tricky bit was with my vim setup; I've been using AstroVIM and trying to get away from managing my own vim setup. You can't, AFAICT, just apply astrovim in NixOS. So I described the vim setup I wanted to Claude Code, and I now have a ~700 line config that implements everything I wanted: LSP, TreeSitter, a small variety of other things. Unlike Astro/Lunar, where tweaks you want to make are buried in some set of files in this whole giant distro, it is all encoded in this one "neovim.nix" file.
I also set up home-manager and SOPS and so far that has been working just great! I now have home directory settings that are replicated across 2 machines.
I'm still really only using it on one machine, so we'll see how it gets more complicated if I start running it on some servers.
I eventually gave up using mason and lsp servers and used nixvim
https://github.com/will-x86/nixos-dotfiles
( ./home/base/nixvim)
I'm on year 6 and still feel the same way, using NixOS for all my machines, and also for my homelab servers (building on the main machine and then deploying over SSH). Everything else feels primitive by comparison. Rolling back is incredible.
I have one github repo with a top-level flake containing system definitions for all of my machines. Much of my config is modularized, so it's easy to take custom stuff from one machine and use it on another.
It's nice to hear that AI tooling is making it more accessible for people.
> The thing that really got me over the hump was entirely configuring it using Claude Code.
I MOSTLY understood it before Claude Code, but WITH Claude Code it's almost a no-brainer for most people. All the upside with none of the downside.
> entirely configuring it using Claude Code
This scares me. I would not want AI to run my computer systems.
I'm no AI booster by any stretch of the imagination, but it's not "run[ning] ... computer systems" in this case. Your NixOS setup is defined by declarative config files, and nix builds or updates a working system from them. AI in this case is just writing the config files, which you'd then (hopefully) read and at least vaguely understand before applying them.
It generates a config file. You can read it before applying it. While Nix may be nigh intractable to write for some people, it is quite a bit easier to read, and any shenanigans would immediately be noticed.
that's quite interesting because I would love for AI to run my systems, given it is capable enough (and it is given right tools). Jarvis anyone?
Yep!
Just waiting for the dgx spark style system with proper bandwidth as nd a price point of max 1500 or winning the lottery.
But in 3 years I bet I will have Jarvis.
Told my wife already thatwe need a lab room
It writes into a configuration file that I git diff before applying.
I had quite a rollercoaster going from Windows 10 to Arch to Windows and then settling on NixOS. Main reason being able to do clean package/program setup and centralize, version-control my configuration.
My main issue with Arch was that after installing and trying stuff it left OS dirty even after package removal. This might be because I had some things built and installed through AUR (e.g. latest mpv releases that sometimes broke). Eventually I went back to latest Windows 11 build wanting easy no-bs setup.
Of course, then MS decides to shove down half baked AI integration that somehow used half my RAM and randomly slowed my CPU. I am guessing it was busy indexing, searching or security-scanning something.
Got increasingly annoyed by Microslop and tried NixOS. Bumpy ride initially but after committing for few weeks I am finally settling on it be the last OS I need.
I also really like that Nix (both on NixOS or as a package manager for Linux/macOS) can temporarily fetch packages with `nix shell` removing entirely the need to install something I am just trying out or something I know I am not going to need on a regular basis.
Similarly the integration of flakes/devshells and direnv is great to create reproducible development environments. Everything I need and at the correct versions are automatically setup as soon as I `cd` into a project directory.
> My main issue with Arch was that after installing and trying stuff it left OS dirty even after package removal
Yeah, that's literally a problem with every single OS that is not NixOS (or, shoutout, Guix, or the other Nix-based variants).
That's also why I am sticking with NixOS. Been at least 5 years now- it's wonderful having a reliable LINUX system as my daily driver (or one of them).
And you can reboot into any old configuration! Even more insurance against fuckups!
> I am finally settling on it be the last OS I need
Same here. As soon as I got everything set up just how I like it in a declarative, reproducible fashion, I had this feeling of... "OK, this is great. I can't see a reason to ever leave this."
https://github.com/CyberShadow/aconfmgr
Aconfmgr is a good solution (practical trade-off for me). When it feel like "my OS must be dirty at this point", then I spend a couple minutes with this and I'm back to the clean state.
I don't do this more then twice a year, so if you insist on an always clean system, YMMV
I'm borderline motivated putting Ubuntu onto my parents computers.
Win11 was frustrating ...
Chrome OS Flex has worked out nicely for my mother-in-law's potato
> installed through AUR (e.g. latest mpv releases that sometimes broke)
On my home system I'd do this to switch to a new mpv release:
"gitty mpv"
(This is my alias to check out the latest mpv sources, from github, via git clone URL_HERE.)
Scripts repackage mpv into .tar.xz after this git clone step.
Then I do:
"clangy mpv"
clangy is my alias to compile via clang from llvm; and the specific instructions would be found in my COOKBOOKS_DIRECTORY aka recipes (similar to homebrew, but in .yml files), where all information is gathered from mpv.yml then.
One setting there is:
This means "non-traditional prefix", aka "AppDir" prefix. AppDir prefix is how GoboLinux installs software, e. g. in /Programs/Mpv/22.06.2026/ (I keep the dd.mm.yyyy notation, but this can be toggled; on my home system I use /home/Programs/ though rather than /Programs/ for historic reasons, and also as I want to backup my /home/ directory, including all programs).So the above would, via clang, compile mpv from source (if the git clone worked), into the AppDir prefix. Then it would simply create symlinks and so some more processing, so /usr/bin/mpv would point at /home/Programs/Mpv/Current/bin/mpv, and Current is a Symlink to the current version in use. I can keep old entries of mpv under /home/Programs/Mpv/ so switching is trivial. And cleaning up is also trivial, I remove e. g. an old mpv version there, then call one post-removal script (or I simply pass the name of it, but I find it easier to work via the commandline in two steps here). The benefit of the above is that, for instance compared to your "latest mpv release sometimes broke", this would not affect me, the old mpv versions would work still, and there can not be any outside installation other than the versioned AppDir.
Right now my /home/Programs/ has 499 entries. I'll eventually have all programs there, and work, then I'll switch to a completely custom LFS/BLFS. Right now my base system is manjaro, which works very well as a base system, even though it uses systemd. /lib/ is a symlink on manjaro by default towards /usr/lib/ and so forth. I find this works so much better than e. g. debian.
> Got increasingly annoyed by Microslop and tried NixOS. Bumpy ride initially but after committing for few weeks I am finally settling on it be the last OS I need.
Not disagreeing at all, but imo the issue you had with AUR is one that by design could be completely avoided. I am not saying this is your fault, mind you; just pointing out that this may be an assumption by both AUR as well as you, since your expectation is to trust the package manager. Here, my input would be the question whether a package manager would be necessary in the first place or not (I still have scripts to handle that, mind you, but the assumptions made via AUR may be wrong in many areas, including not offering versioned AppDirs by default. I don't understand why all package managers do not offer versioned AppDirs; it would solve so many issues).
I should add that some programs are harder to install from source, but mpv works very well; ffmpeg too, surprisingly enough. LLVM/clang is a bit harder to setup, and by far the worst offender is firefox. Mozilla should be ashamed of mozconfig for life.
God bless Hacker News, where "just start building your own package management system, like I did" is an earnest comment, including a sketched out implementation.
(I'm admiring this, not mocking it)
BTW, there is a NixOS.wsl for Win11 and Nix-Darwin for macOS and the Nix package manager runs on any Linux. You could run Fedora and configure somethings with Nix.
Nix excels at solving real world problems for developers. No more "Well, it worked on my machine". You setup a flake.nix in your code repo along with direnv and even that new junior dev can merely clone the repo and all the dependencies are installed by the flake.nix configuration file. Including the language and IDE configuration for the team. i.e. tabs vs spaces and whatnot. The same flake.nix can be applied to your CI / CD to help with reliable builds. You can also use it to create Kubernetes and other containers or a bare metal NixOS server. Keep all the configs in git and run them straight from the repo.
It's great for ensuring your devs don't break the freaking build by updating something with npm, etc. You should audit anything you install due to the severe threat of supply chain attacks. Recently impacting Node.js and Arch Linux AUR, etc.
Yes, LLMs can write quite a lot of Nix but they don't necessarily get down to the nitty gritty best practices. So you need to be careful with it. You should also audit your configuration for security issues.
I really love NixOS for my two devices, one surface laptop (lol), and my nvidia pc. It reduced my headaches with drivers so much.
Before updating my nvidia driver or something related to my surface I was scared to break something. With NixOS I can just go back to the old working config.
Another underappreciated feature about NixOS is, that you can create a VM out of a NixOS config to locally test a server update/deployment.
Yep, exactly the same experience as me. The fact that everything is declarative and revertible means that I'm much "braver" than I would be with virtually any other Linux.
An example I have given before, but there was a weird quirk with my ThinkPad with Linux, where with USB keyboards, if I hadn't been typing for more than a minute, it would have to "wake up" for about four seconds, so I'd lose the first couple words that I was typing.
Fixing this involved playing with a few boot parameters, which can be scary to play with on something like Ubuntu. The issue is annoying, but nothing I can't live with, so if I were on Ubuntu or something I probably would have just tried to live with it, but because it's NixOS, I realized that the worst case scenario is that I reboot and choose an older generation, so I did a few experiments with boot parameters and fixed it.
> Another underappreciated feature about NixOS is, that you can create a VM out of a NixOS config to locally test a server update/deployment.
And similarly, you can generate a bootable ISO of your NixOS config. It's really nice for both testing things out and also as a recovery mechanism. Rather than booting some generic ISO, connecting to the internet, installing whatever recovery tools and filesystem drivers I need, and then doing the recovery, I can boot an ISO that is identical to my main system, with all my favorite recovery tools pre-installed.
Ohh I didnt know that, but it makes sense that you would be able to create an ISO, good tip!
I've ditched M$, switched to NixOS last month and I feel like I don't hate computers again. Shouldn't have procrastinated this for so long. All other operating systems feel so silly to use now (at least when they aren't anxiety- and rage-inducing).
After using NixOS for a bit and eventually learning to rely on it, life without it seems inconceivably complex
I love the slightly weird learning curve on NixOS where initially it seems incredibly complex writing this weird functional programming language for every change you want to apply to your system, then over time it clicks and you end up in a place where any operating system that doesn't define everything in a weird functional programming language seems incredibly complex. I read blog posts about doing things on other distros now and I'm left thinking that an 800 word set of instructions would be 25 lines of Nix expressions.
yes, exactly!
it's like reading instructions for using a GUI program (open this dialog, click this checkbox, fill in this value) vs copying and pasting a complex FFMpeg command
I love seeing all these posts from NixOS newcomers! It seems anecdotally like LLMs have really given it a boost recently, I guess by reducing the intimidation factor of the language and the unfamiliarity? Of all the positive and negative outcomes I have imagined from LLMs, NixOS becoming popular was not one of them, but I'll take it.
Absolutely.
The language is just nothing for a casual Linux user.
Arch? Easy. Gentoo love it. Ubuntu for all my servers.
But nix and nix os, nah.
NixOS has been my daily driver since 2022/2023 and I have greatly improved the management of my 2 computers and few VMs since. Because of LLMs, I now understand the language much better, but even if I didn't want to write Nix directly, describing the config to AI usually produces good results.
The two main sticking points IMO are still:
- Development environments are still a pain. devenv.sh is great for web and backend, but not perfect for dependency (package) management and more complicated environments like mobile or embedded
- nixpkgs monorepo doesn't update fast enough IMO. As a consequence, I see a number of flake repositories popping up to more easily package and distribute software not yet on nixpkgs or that don't update often enough (https://github.com/numtide/llm-agents.nix is a good example). This is perhaps by design, but it takes some digging to find the reliable and trustworthy flake repos. I'm increasingly concerned with AUR-like trust issues
> Development environments are still a pain. devenv.sh is great for web and backend
Weird, development environments are one of my favorite things about nix. I don't use anything like devenv.sh, just add a `flake.nix` to the repo defining a devShell, and then add `use flake` to `.envrc` and let direnv activate it. Every major and most minor editors have support for direnv, and if they don't, you can just launch them from a shell in that directory. This makes the only system dependencies for a great dev environment nix and direnv.
> I'm increasingly concerned with AUR-like trust issues
Once you've done it a few times, most things are pretty easy to package yourself, and you can just check those derivations into your git repo for your machines and use them. Especially if you're using LLMs, it shouldn't be all that hard to package what you need in most cases. For stuff that's more complicated or difficult, it's more likely there will be some kind of de facto standard flake for it.
Is devens something else than nix shell?
I decided to move to NixOS a few months ago. In terms of OS, it was one of the best decisions I've made so far. It's awesome to have the rollback experience, upgrade whenever you want and also being able to experiment without being afraid of breaking already working stuff.
Another great benefit, is that AI can read my whole OS (good and bad at the same time, I know). This makes the AI way more accurate on giving you a good solution instead of having to scan all of your OS and dig into /etc.
Personally, I really like NixOS. It's hard but definetely worth the try. Probably not for everyone, but worth it if you're a computer scientist or need to maintain hundreds of computers.
One of the best things about Nix, aside from LLMs being able to manage your config, is having a monorepo that contains the config across all machines (shared and machine-unique), like hosts/{nas,macbook}/{configuration.nix,home.nix,modules/}.
Now I have the same setup across my macbook, desktop, and NixOS servers.
> Deprecation of x86_64-darwin
Understandable with Apple dropping official support but kind of sad as they were selling Intel powered Macs until as recently as 2023 and with Tahoe still continuing to receive security updates until 2028.
How is NixOS on Intel Macs currently? Hopefully Linux can still breathe life into these computers in 10 years time.
I've been using t2linux[0] patched distros on an Intel MBP for a while now. While I applaud the efforts, it is not without sharp edges, and I do occasionally have to boot into macOS to do some things. I gave up on trying to use the onboard or bluetooth audio (onboard can cause it to crash in weird ways, and bluetooth can break depending on if wifi is in 2.4 pr 5ghz mode? I don't know, I use a USB DAC now and it's fantastic). Trying to use the webcam causes a hard crash. Sleep is weird (but that's a given for most linux things I think). The maintainers do a good job of getting all their little hacks included...but I'd probably be frustrated with it all if I didn't have 25+ years of experience with linux and be able to fix things myself. The MBP was a gift and my only machine at the moment so I won't complain much personally :).
[0] https://wiki.t2linux.org/
It's great. It's complicated. I have a MacBook Pro Late 2013 – very old. NixOS runs totally great! Even the proprietary hardware just works, with the nixos-hardware channel. Battery life is awesome, 4 hours of office work.
There is a snag however: Drivers for the built-in Broadcom Wi-Fi card are unmaintained and bug-ridden. Replacements do not exist either. The driver doesn't work most of the time nowadays and I have to rely on a USB Wi-Fi adapter that is sooo slow.
Maybe more recent Wi-Fi chipsets in Intel Macs are better off. Or maybe you don't need Wi-Fi!
I have NixOS installed on a 2009 MacBook Pro and it works well enough every time I pick it up.
I'm probably also going to install it on a 2019 iMac once macOS stops getting security updates but I haven't tried it yet.
I post this on every post about Nix I encounter, but I sincerely hope that it gets static electricity typing one day. I have yet to try typenix (a fork of the typescript compiler applying the typescript type system to nix)
https://github.com/ryanrasti/typenix
Adding TS types to Nix would make it so much easier to write Nix code. Which string do I need here? Oh the type system knows, the language server shows it inline - I don't have to look at the source. I've used NixOS since 2018 and written nixpkgs derivations and it would've saved me so much time.
I'm glad that TypeNix exists but it really should just be officially supported or even the default.
> static electricity typing
I assume that was an autocomplete typo?
I would love a Bazzite-style nixos distribution. Like batteries-included for gaming.
Is this kind of thing common in the NixOS space ? Like configs you can import that manage 99% of the os for you ?
What makes Bazzite-like uncommon is the degree of hardware testing and kernel tuning required to get some of the more exotic hardware fully working and stable.
Jovian exists for the Steam Deck and is probably the closest thing right now: https://jovian-experiments.github.io/Jovian-NixOS/
I am tempted to try making a "Nixzite" flake just to see how far it can get to feature parity with Bazzite, but again most of the story with Bazzite is the sizable community working on hardware tuning and kernel modifications. The catch with that flake would be a lot of waiting for the kernel to rebuild if I bring in the Bazzite patches, and that's just not a fun UX...
There are templates for deploying NixOS but almost all that I've encountered are heavily opinionated and thus only kinda work for specific people (usually the ones that designed them). Then when you want to customize them it's almost always easier to start from scratch.
It is not common at all
I'd love to try NixOS but I still have PTSD from trying to run/use Nix on MacOS, across two separate profiles on the same physical device too.
On macOS I settled for Nix + HomeManager rather than going fully nix-darwin
I wonder how common this set-up is, but it's what I settled on as well (my flake contains 8 other NixOS hosts with common home-manager config).
Sometimes I wish I could control more things using nix-darwin but then I remember I like mostly defaults on System Settings.
I've used this set up for 3 or 4 years now and love it. I used to hit bottlenecks having to edit some nix files once or twice a month and forgetting the language but LLMs dramatically reduce that barrier.
Why don’t more people use NixOS on servers?
Is it because of no LTS?
And is having a LTS somewhat the antithesis of what NixOS represents?
The same reason you don't use arch linux on servers. Some distros are simply better suited for servers. We do have talosos for k8s and we (used) to have clearlinux.
Reproducible builds though seem perfect for servers, no?
rather than being theoretically better, it's simply the standard way of running servers. Nobody stops you from using nix or even arch on servers, but nearly all of installations, enterprise packaging and "officially" supported distros are debian/ubuntu/centos and has been like that for a really long time.
Nvidia for example won't give you any support unless you use specific kernel versions on ubuntu.
Let's talk about the important things... how is the drama currently on the Nix community?
> The 26.05 release was made possible due to the efforts of 2842 contributors, who authored 59703 commits since the previous release.
Maybe they should think about increasing their release cycle, that sounds completely unmanageable.
After 10 years in my company I have around 1,500 commits in total, it would take me 390 years to author 60K.
The majority of these commits are to keep packages up to date. Easy to get an incredibly high number of commits when nixpkgs is a monorepo containing the definition of 140000 packages
Good to know. I am entirely against monorepos but in the very specific case of NixOS I get how it can actually make sense.
NixOS is a pretty cool idea in theory. In actual practice I found it too complicated to manage. Immutability is kind of cool too, but it creates an obstacle to solving even trivial task in my daily life using Linux. And I don't want to really use such a domain specific language like Nix, for things that really should not need a programming language per se. For instance, I like ruby, but I don't want configuration stuff to be kept in .rb files; that's also one gripe I have with homebrew, even if the idea to HAVE a recipe in a .rb file, is not bad per se. I am just too used to e. g. yaml files or any other simple format for literally everything. All my RC files and ENV data and aliases for shells is kept in .yml files; ruby then just autogenerates any target format I need for different shells/terminals, and so on and so forth. Also, NixOS is not very flexible. I prefer e. g. /Programs/Ruby/4.0.5/ rather than a hashed directory name. It's not a bad idea here either, and there would be many workarounds for that (see GoboHide on GoboLinux, for instance), but at the end of the day it felt as if I was fighting NixOS too much than getting real work done. There is something to be said about simplicity at all times, even if the ideas in NixOS are still great. For instance, we could guarantee that every snapshot would work, so people having the same hardware could just re-use configuration and have things work, without needing to know how to change the system precisely. That would not be needed because NixOS could make a guarantee about ALL possible stable snapshots in time. I don't think NixOS goes that far, so far, but it would be a very logical extension. Same with immutable packages / reproducible packages:
https://wiki.debian.org/ReproducibleBuilds
We could make such a guarantee if we extend NixOS. But until all of that happens, I stick with simplicity and flexibility. It just kind of works better, even if it is nowhere near as sophisticated as NixOS.