Rendered at 23:15:57 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
linsomniac 7 hours ago [-]
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.
mplanchard 7 hours ago [-]
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.
zihotki 5 hours ago [-]
I'm building a homelab as well and fully second the ode. It feels incredible to do the setup via llm, like they are the perfect fit.
rhco 4 hours ago [-]
You could take this one step further using Syncthing to sync important data between the workstation and laptop.
That's how my devices are configured, and it's amazing - if I need to travel for work, I just pick up my laptop and go. NixOS makes sure the system itself is identical (apps, most of the code configs, etc), then any app-spcific config is handled by Syncthing. It was really magical the first few times I used my laptop on the road!
Also, if you aren't already across it, you should look into remote builds/deployments. Basically, the regular nixos-rebuild command supports deploying over SSH. It's nice because you can do the heavy work (nix evaluation, building non-cached packages, etc) on your grunty workstation, then have them pushed across to the laptop via SSH. Then, when you want to apply that build to your PC, it'll be super fast (since everything is already evaluated & built!).
linsomniac 4 hours ago [-]
Really solid advice.
Going to have to try that remote rebuild, because right now my 10yo T420 takes around an hour to rebuild gitbutler-cli (not yet packaged in NixOS), so that'd be real nice.
I know syncthing has a solid reputation, but I'm a bit reluctant to try it on my home directory (it's super mission critical). Does that interact well with home-manager+SOPS?
Mostly, when I'm away from my workstation, I just connect in from my personal macbook via the "wezterm tmux" feature, since most of what I do is either web or terminal. The need for a "pick up and go" copy is nice but not really necessary. Though in the event my main workstation fails, I should check to see how long an rsync from the restic backup would take. If it takes the better part of a day, that might be compelling to use syncthing, especially as my workstation is a 6+yo laptop.
linsomniac 3 hours ago [-]
Answer about syncthing: I probably would set it up on only a portion of my home directory, not the whole thing, so it wouldn't impact home-manager/SOPS. However, Claude pointed out this potential issue: the bulk of my "projects" directory (my most active directory) is git repos, and (a) those are likely to conflict on both ends (a git pull on both ends), and (b) much of that syncing git can handle (except, of course, uncommitted changes).
willx86 7 hours ago [-]
I eventually gave up using mason and lsp servers and used nixvim
That is really interesting, thanks for the pointer. I came across it a while ago when I was researching how to manually set up AstroVIM on NixOS and doing manually was a bit of a stretch for me at the time.
My setup right now is a fairly straightforward nix file listing the plugins and associated packages I want, and then an embedded long-ass lua config file, and I think the nixvim would just make that part of it declarative. I think I'll make a branch on my nixos repo and just have Claude try it. No reason not to.
willx86 2 hours ago [-]
I converted with claude
Use my repo for lsp.nix as neovims new v10 has a new way of configuring lsp's as lspconfig is depreciated, so I used the new lsp configuration method but went doc hunting to find out I need lspconfig for proper completions! ( I'll give it a push now to ensure it's my latest version)
pmarreck 6 hours ago [-]
> 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.
linsomniac 3 hours ago [-]
Agreed, that's where I was as well. I had been dabbling in manual NixOS configs for ~2 years. I mostly felt like I understood it. But as you say, all upside.
shevy-java 7 hours ago [-]
> entirely configuring it using Claude Code
This scares me. I would not want AI to run my computer systems.
mplanchard 7 hours ago [-]
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.
pmarreck 7 hours ago [-]
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.
Diti 2 hours ago [-]
Let’s be honest, most people do not review the full output of Claude Code because of slop fatigue.
linsomniac 3 hours ago [-]
I'm a 35-year professional sys admin, so you'd think I'd have really strong opinions about how exactly it sets the system up. Or maybe I have enough experience that I can just eyeball what it's doing and feel comfortable? I'm not sure.
Kind of reminds me of the movie Ronin where the young guy is asking the seasoned CIA guy what gun he likes. "It doesn't matter, it's just a tool, I put it in my toolbox."
Yiin 7 hours ago [-]
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?
spacington 7 hours ago [-]
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
exe34 6 hours ago [-]
It writes into a configuration file that I git diff before applying.
tomalaci 7 hours ago [-]
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.
wrxd 7 hours ago [-]
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.
synoptik 56 minutes ago [-]
Project README.md Install instructions: List of software to install and what those packages are called on different distributions: Just kidding, it just works.
pmarreck 7 hours ago [-]
> 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
spacington 7 hours ago [-]
I'm borderline motivated putting Ubuntu onto my parents computers.
Win11 was frustrating ...
beastman82 6 hours ago [-]
Chrome OS Flex has worked out nicely for my mother-in-law's potato
shevy-java 7 hours ago [-]
> 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.
paisawalla 6 hours ago [-]
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)
mplanchard 7 hours ago [-]
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.
spacington 7 hours ago [-]
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.
chem83 7 hours ago [-]
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
mplanchard 7 hours ago [-]
> 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.
spacington 7 hours ago [-]
Is devens something else than nix shell?
rekoros 7 hours ago [-]
After using NixOS for a bit and eventually learning to rely on it, life without it seems inconceivably complex
jon-wood 7 hours ago [-]
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.
data-ottawa 1 hours ago [-]
When I started self hosting last year it seemed insane that hosting a service required separately managing the imperative firewall state, vpn, container runner, systemd, and reverse proxy.
Nixos is nice because it just works. When I do a rebuild switch it will take down my affected services gracefully, apply the updates, update my firewall, and start the container all automatically and declaratively.
Plus the owning account and file permissions are explicit so it’s impossible to forget you ran chmod/crown on some script and now your service is over-permissioned.
It’s not magic but it feels like magic because it works so easily and reliably.
rekoros 7 hours ago [-]
yes, exactly!
1-more 6 hours ago [-]
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
AyanamiKaine 7 hours ago [-]
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.
tombert 7 hours ago [-]
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.
tryfinally 7 hours ago [-]
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).
craftkiller 5 hours ago [-]
> 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.
AyanamiKaine 5 hours ago [-]
Ohh I didnt know that, but it makes sense that you would be able to create an ISO, good tip!
yesbabyyes 4 hours ago [-]
You can similarly create a docker image from a nix config. It's quite beautiful, nix is impressive.
hombre_fatal 7 hours ago [-]
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.
evilmonkey19 7 hours ago [-]
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.
bouk 4 hours ago [-]
We use NixOS for all of our robots and servers at https://www.monumental.co, hard to imagine how we would do constant updates of our robot fleet without it.
If you're working on cloud systems it's easy enough to just throw away VMs all the time but you can't really do that with physical hardware that's on a construction site for months on end, where you only have a shared 5G connection. NixOS makes this all manageable!
unforgivenpasta 7 hours ago [-]
> 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.
temp0826 7 hours ago [-]
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!
wrxd 7 hours ago [-]
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.
Nerdrotic 5 hours ago [-]
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.
allset_ 4 hours ago [-]
> Removed 17532 outdated packages, in an effort to keep the package set maintainable and secure.
Thanks for this! I appreciate the acknowledgement that more software in nixpkgs is not necessarily better.
markatkinson 7 hours ago [-]
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.
wrxd 7 hours ago [-]
On macOS I settled for Nix + HomeManager rather than going fully nix-darwin
frantathefranta 7 hours ago [-]
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.
bjtitus 7 hours ago [-]
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.
LelouBil 7 hours ago [-]
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.
reinitctxoffset 44 minutes ago [-]
I'm fairly close to releasing something called nix-compile, which is a type inferring Hindley-Milner compiler that unifies across nixlang and bash. It finds a lot of bugs. Because it has a very complete view of your project, it can do cute stuff like precise go to definition across modules, annotate code with types in the comments, it's cool.
christophilus 7 hours ago [-]
> static electricity typing
I assume that was an autocomplete typo?
LelouBil 7 hours ago [-]
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 ?
jdiaz5513 6 hours ago [-]
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...
frantathefranta 7 hours ago [-]
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.
synoptik 35 minutes ago [-]
NixOS is very much a toolkit for building operating systems. You in modules that set up parts of the system with overridable defaults, and you focus on the parts that matter. Sometimes that is the disk layout, other times it is the dot files, yet other times it is the services.
Adding a new domain to my NixOS webserver is a single line of code.
Cyph0n 4 hours ago [-]
Jovian is as close as you’ll get. Works like a charm and gives you a SteamOS-like experience on desktop.
mrhottakes 7 hours ago [-]
It is not common at all
tiffanyh 7 hours ago [-]
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?
himata4113 7 hours ago [-]
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.
tiffanyh 6 hours ago [-]
Reproducible builds though seem perfect for servers, no?
himata4113 6 hours ago [-]
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.
yomismoaqui 7 hours ago [-]
Let's talk about the important things... how is the drama currently on the Nix community?
iLoveOncall 7 hours ago [-]
> 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.
wrxd 7 hours ago [-]
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
iLoveOncall 7 hours ago [-]
Good to know. I am entirely against monorepos but in the very specific case of NixOS I get how it can actually make sense.
shevy-java 7 hours ago [-]
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.
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 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.
That's how my devices are configured, and it's amazing - if I need to travel for work, I just pick up my laptop and go. NixOS makes sure the system itself is identical (apps, most of the code configs, etc), then any app-spcific config is handled by Syncthing. It was really magical the first few times I used my laptop on the road!
Also, if you aren't already across it, you should look into remote builds/deployments. Basically, the regular nixos-rebuild command supports deploying over SSH. It's nice because you can do the heavy work (nix evaluation, building non-cached packages, etc) on your grunty workstation, then have them pushed across to the laptop via SSH. Then, when you want to apply that build to your PC, it'll be super fast (since everything is already evaluated & built!).
Going to have to try that remote rebuild, because right now my 10yo T420 takes around an hour to rebuild gitbutler-cli (not yet packaged in NixOS), so that'd be real nice.
I know syncthing has a solid reputation, but I'm a bit reluctant to try it on my home directory (it's super mission critical). Does that interact well with home-manager+SOPS?
Mostly, when I'm away from my workstation, I just connect in from my personal macbook via the "wezterm tmux" feature, since most of what I do is either web or terminal. The need for a "pick up and go" copy is nice but not really necessary. Though in the event my main workstation fails, I should check to see how long an rsync from the restic backup would take. If it takes the better part of a day, that might be compelling to use syncthing, especially as my workstation is a 6+yo laptop.
https://github.com/will-x86/nixos-dotfiles
( ./home/base/nixvim)
My setup right now is a fairly straightforward nix file listing the plugins and associated packages I want, and then an embedded long-ass lua config file, and I think the nixvim would just make that part of it declarative. I think I'll make a branch on my nixos repo and just have Claude try it. No reason not to.
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.
Kind of reminds me of the movie Ronin where the young guy is asking the seasoned CIA guy what gun he likes. "It doesn't matter, it's just a tool, I put it in my toolbox."
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.
Nixos is nice because it just works. When I do a rebuild switch it will take down my affected services gracefully, apply the updates, update my firewall, and start the container all automatically and declaratively.
Plus the owning account and file permissions are explicit so it’s impossible to forget you ran chmod/crown on some script and now your service is over-permissioned.
It’s not magic but it feels like magic because it works so easily and reliably.
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.
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.
Now I have the same setup across my macbook, desktop, and NixOS servers.
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.
If you're working on cloud systems it's easy enough to just throw away VMs all the time but you can't really do that with physical hardware that's on a construction site for months on end, where you only have a shared 5G connection. NixOS makes this all manageable!
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.
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.
Thanks for this! I appreciate the acknowledgement that more software in nixpkgs is not necessarily better.
Sometimes I wish I could control more things using nix-darwin but then I remember I like mostly defaults on System Settings.
https://github.com/ryanrasti/typenix
I'm glad that TypeNix exists but it really should just be officially supported or even the default.
I assume that was an autocomplete typo?
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...
Adding a new domain to my NixOS webserver is a single line of code.
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.
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.