DE version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
73% Positive
Analyzed from 3120 words in the discussion.
Trending Topics
#nixos#nix#mpv#system#more#using#things#don#home#need
Discussion (48 Comments)Read Original on HackerNews
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.
https://github.com/will-x86/nixos-dotfiles
( ./home/base/nixvim)
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 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.
This scares me. I would not want AI to run my computer systems.
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
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.
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.
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
Win11 was frustrating ...
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.
(I'm admiring this, not mocking it)
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.
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
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.
Now I have the same setup across my macbook, desktop, and NixOS servers.
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.
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 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.
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.
[0] https://wiki.t2linux.org/
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'm probably also going to install it on a 2019 iMac once macOS stops getting security updates but I haven't tried it yet.
Is it because of no LTS?
And is having a LTS somewhat the antithesis of what NixOS represents?
Nvidia for example won't give you any support unless you use specific kernel versions on ubuntu.
https://github.com/ryanrasti/typenix
I assume that was an autocomplete typo?
Sometimes I wish I could control more things using nix-darwin but then I remember I like mostly defaults on System Settings.
Is this kind of thing common in the NixOS space ? Like configs you can import that manage 99% of the os for you ?
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...
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.
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.