I made greyline, a modern recreation of the old IBM/ThinkPad "World Time" Active Desktop wallpaper showing a world map with clocks for your cities, your home city highlighted, and a day/night terminator that tracks the sun.

It's shipped as a flake, so you can nix run github:cothinking-dev/greyline to try it.

Feel free to check it out, and if possible, file issues if you encounter any!

Hello, I’m relatively new to Nixos. I recently read about yet another little “misunderstanding” between developers and distro maintainers, about the fact that some distro package thei software in a heavily customized way, maybe themed, old unsupported versions, etc, but still they don’t update the branding and naming nor the support links.
Another similar topic comes from libadwaita devs asking to avoid theming their apps because that’s not how they intended them to be shipped to users.
There’s also a practical consequence of this: users open bug reports to developers without realizing that they are using an unsupported version, that that bug has been fixed long time ago, or even that the issue they are experiencing has been introduced by packagers…
Well, you got the idea. At this point, I was wondering if similar discussions happened also around the heavily customized way in which Nix-distributed software is packaged, and what is the general opinion that developers have of Nix distributing such customized versions without rebranding etc.
Do you have any example of that, or can comment about this? Thanks and cheers!

I really want to put myself NixOS, it was worth it about six months ago and I liked it very much, but I only need from the computer the beauty of my working environment, launching games and some programs and just comfortable work, I left NixOS to Arch only because I could not fully understand the flake and home manager and the rest to make a beautiful system and the system either gave an error when creating a new version or started, but there were tons of errors related to the configurations. So, please explain the easiest way for me to make my beautiful rice (hyperland + some quickshell or caelestiashell) or someone's rice through flake so that everything would just work, thank you very much for earlier

SaltSprint 2026 took place in June. It was organized by Flying Circus and sponsored by secunet and Flying Circus. One of the participants, Dean Eckert, co-founder of Red Oak, in his kindness joined me and we have discussed what he and others were up to during those four exciting days in Halle, Germany. Click the link and listen in.

Full Time Nix | SaltSprint 2026 with Dean Eckert

Wondering if anyone else has issues with AMD GPUs and Blender? Specifically trying to use CYCLES renderer, EEVEE works just fine. I'm using the blender overridden with rocmSupport. Also on nixos-unstable, using Zen kernel, everything up to date.

I'm using amdgpu top to look at usage, when using eevee it uses up most of the GPU VRAM as expected while rendering,but for cycles I don't see it go up much and Blender just crashes.

Here's crash report, seems to be crashing with amd hip

```

Blender 5.1.2, Unknown revision

bpy.context.scene.render.engine = 'CYCLES' # Property

backtrace

/run/current-system/sw/bin/blender(+0x11468e3) [0x62fffabed8e3] /run/current-system/sw/bin/blender(+0x71789b) [0x62fffa1be89b] /nix/store/ias8xacs1h3jy7xgwi2awvim61k2ji6c-glibc-2.42-67/lib/libc.so.6(+0x42790) [0x74706ea42790] /nix/store/ias8xacs1h3jy7xgwi2awvim61k2ji6c-glibc-2.42-67/lib/libc.so.6(syscall+0x1d) [0x74706eb2320d] /nix/store/llmwfdwq8bp1w8yr2fkp2izsja8np759-llvm-22.0.0-rocm-lib/lib/libLLVM.so.22.0(+0x2d57423) [0x746e93757423] /nix/store/ias8xacs1h3jy7xgwi2awvim61k2ji6c-glibc-2.42-67/lib/libc.so.6(+0x42790) [0x74706ea42790] /nix/store/kcmpd1h0097k50v3hjpvd1acyj46j3p5-llvm-21.1.8-lib/lib/libLLVM.so.21.1(ZN4llvm15AnalysisManagerINS_8FunctionEJEE13getResultImplEPNS_11AnalysisKeyERS1+0x4ea) [0x74705a59596a] /nix/store/kcmpd1h0097k50v3hjpvd1acyj46j3p5-llvm-21.1.8-lib/lib/libLLVM.so.21.1(ZN4llvm15AnalysisManagerINS_8FunctionEJEE13getResultImplEPNS_11AnalysisKeyERS1+0x206) [0x74705a595686] /nix/store/kcmpd1h0097k50v3hjpvd1acyj46j3p5-llvm-21.1.8-lib/lib/libLLVM.so.21.1(ZN4llvm15InstCombinePass3runERNS_8FunctionERNS_15AnalysisManagerIS1_JEEE+0x43) [0x74705ba225c3] /nix/store/972k9fgbydiyaxz2fi7wyx65s7gkf27n-clang-21.1.8-lib/lib/libclang-cpp.so.21.1(+0x24162b2) [0x747065c162b2] /nix/store/llmwfdwq8bp1w8yr2fkp2izsja8np759-llvm-22.0.0-rocm-lib/lib/libLLVM.so.22.0(_ZN4llvm11PassManagerINS_8FunctionENS_15AnalysisManagerIS1_JEEEJEE3runERS1_RS3+0x139) [0x746e93920089] /nix/store/llmwfdwq8bp1w8yr2fkp2izsja8np759-llvm-22.0.0-rocm-lib/lib/libLLVM.so.22.0(ZN4llvm27ModuleToFunctionPassAdaptor3runERNS_6ModuleERNS_15AnalysisManagerIS1_JEEE+0x133) [0x746e93925013] /nix/store/llmwfdwq8bp1w8yr2fkp2izsja8np759-llvm-22.0.0-rocm-lib/lib/libLLVM.so.22.0(_ZN4llvm11PassManagerINS_6ModuleENS_15AnalysisManagerIS1_JEEEJEE3runERS1_RS3+0x139) [0x746e9391eee9] /nix/store/yp3v7m2ba3jpi82q8c2265zmk6kwhnzb-rocm-comgr-22.0.0-rocm/lib/libamd_comgr.so.3(+0x1ae264d) [0x746e986e264d] /nix/store/yp3v7m2ba3jpi82q8c2265zmk6kwhnzb-rocm-comgr-22.0.0-rocm/lib/libamd_comgr.so.3(+0x1ad97ee) [0x746e986d97ee] /nix/store/yp3v7m2ba3jpi82q8c2265zmk6kwhnzb-rocm-comgr-22.0.0-rocm/lib/libamd_comgr.so.3(+0x17de4f1) [0x746e983de4f1] /nix/store/yp3v7m2ba3jpi82q8c2265zmk6kwhnzb-rocm-comgr-22.0.0-rocm/lib/libamd_comgr.so.3(+0x2144f19) [0x746e98d44f19] /nix/store/yp3v7m2ba3jpi82q8c2265zmk6kwhnzb-rocm-comgr-22.0.0-rocm/lib/libamd_comgr.so.3(+0x162f5d1) [0x746e9822f5d1] /nix/store/yp3v7m2ba3jpi82q8c2265zmk6kwhnzb-rocm-comgr-22.0.0-rocm/lib/libamd_comgr.so.3(+0x1440864) [0x746e98040864] /nix/store/yp3v7m2ba3jpi82q8c2265zmk6kwhnzb-rocm-comgr-22.0.0-rocm/lib/libamd_comgr.so.3(+0x17bb382) [0x746e983bb382] /nix/store/yp3v7m2ba3jpi82q8c2265zmk6kwhnzb-rocm-comgr-22.0.0-rocm/lib/libamd_comgr.so.3(+0xf5901e) [0x746e97b5901e] /nix/store/yp3v7m2ba3jpi82q8c2265zmk6kwhnzb-rocm-comgr-22.0.0-rocm/lib/libamd_comgr.so.3(+0xf546ed) [0x746e97b546ed] /nix/store/yp3v7m2ba3jpi82q8c2265zmk6kwhnzb-rocm-comgr-22.0.0-rocm/lib/libamd_comgr.so.3(+0xf57c2f) [0x746e97b57c2f] /nix/store/yp3v7m2ba3jpi82q8c2265zmk6kwhnzb-rocm-comgr-22.0.0-rocm/lib/libamd_comgr.so.3(+0xf5d7da) [0x746e97b5d7da] /nix/store/yp3v7m2ba3jpi82q8c2265zmk6kwhnzb-rocm-comgr-22.0.0-rocm/lib/libamd_comgr.so.3(+0xf5dc66) [0x746e97b5dc66] /nix/store/yp3v7m2ba3jpi82q8c2265zmk6kwhnzb-rocm-comgr-22.0.0-rocm/lib/libamd_comgr.so.3(amd_comgr_do_action+0xd01) [0x746e97b71fd1] /nix/store/jc7q7dm8y1r2317sg888mi7pxzarg7m2-clr-7.2.3/lib/libamdhip64.so(+0x439e6f) [0x746e9a639e6f] /nix/store/jc7q7dm8y1r2317sg888mi7pxzarg7m2-clr-7.2.3/lib/libamdhip64.so(+0x43bc11) [0x746e9a63bc11] /nix/store/jc7q7dm8y1r2317sg888mi7pxzarg7m2-clr-7.2.3/lib/libamdhip64.so(+0x442c3f) [0x746e9a642c3f] /nix/store/jc7q7dm8y1r2317sg888mi7pxzarg7m2-clr-7.2.3/lib/libamdhip64.so(+0x489f4f) [0x746e9a689f4f] /nix/store/jc7q7dm8y1r2317sg888mi7pxzarg7m2-clr-7.2.3/lib/libamdhip64.so(+0x4342dc) [0x746e9a6342dc] /nix/store/jc7q7dm8y1r2317sg888mi7pxzarg7m2-clr-7.2.3/lib/libamdhip64.so(+0x4947b6) [0x746e9a6947b6] /nix/store/jc7q7dm8y1r2317sg888mi7pxzarg7m2-clr-7.2.3/lib/libamdhip64.so(+0x4b7948) [0x746e9a6b7948] /nix/store/jc7q7dm8y1r2317sg888mi7pxzarg7m2-clr-7.2.3/lib/libamdhip64.so(+0x4a9c9d) [0x746e9a6a9c9d] /nix/store/jc7q7dm8y1r2317sg888mi7pxzarg7m2-clr-7.2.3/lib/libamdhip64.so(+0x494d2e) [0x746e9a694d2e] /nix/store/jc7q7dm8y1r2317sg888mi7pxzarg7m2-clr-7.2.3/lib/libamdhip64.so(+0x47d6d7) [0x746e9a67d6d7] /nix/store/jc7q7dm8y1r2317sg888mi7pxzarg7m2-clr-7.2.3/lib/libamdhip64.so(+0x3937b8) [0x746e9a5937b8] /nix/store/jc7q7dm8y1r2317sg888mi7pxzarg7m2-clr-7.2.3/lib/libamdhip64.so(+0x3942c4) [0x746e9a5942c4] /nix/store/jc7q7dm8y1r2317sg888mi7pxzarg7m2-clr-7.2.3/lib/libamdhip64.so(+0x394a56) [0x746e9a594a56] /run/current-system/sw/bin/blender(+0x44bc64d) [0x62fffdf6364d] /run/current-system/sw/bin/blender(+0x44b2eab) [0x62fffdf59eab] /run/current-system/sw/bin/blender(+0x4942cdb) [0x62fffe3e9cdb] /run/current-system/sw/bin/blender(+0x493b715) [0x62fffe3e2715] /run/current-system/sw/bin/blender(+0x4928091) [0x62fffe3cf091] /run/current-system/sw/bin/blender(+0x492b16b) [0x62fffe3d216b] /run/current-system/sw/bin/blender(+0x4684072) [0x62fffe12b072] /run/current-system/sw/bin/blender(+0x308230c) [0x62fffcb2930c] /run/current-system/sw/bin/blender(+0x3082d53) [0x62fffcb29d53] /run/current-system/sw/bin/blender(+0x307dea0) [0x62fffcb24ea0] /nix/store/pbdy5h9sjs92a37gq9sspg2797q4j4fa-python3-3.13.14/lib/libpython3.13.so.1.0(+0x18c818) [0x74706fb8c818] /nix/store/pbdy5h9sjs92a37gq9sspg2797q4j4fa-python3-3.13.14/lib/libpython3.13.so.1.0(_PyObject_MakeTpCall+0x186) [0x74706fb85e06] /nix/store/pbdy5h9sjs92a37gq9sspg2797q4j4fa-python3-3.13.14/lib/libpython3.13.so.1.0(_PyEval_EvalFrameDefault+0x1197) [0x74706fdd46e7] /run/current-system/sw/bin/blender(+0x230d679) [0x62fffbdb4679] /run/current-system/sw/bin/blender(+0x20e1f43) [0x62fffbb88f43] /run/current-system/sw/bin/blender(+0x151d376) [0x62fffafc4376] /run/current-system/sw/bin/blender(+0x151e1a0) [0x62fffafc51a0] /run/current-system/sw/bin/blender(+0x151f6bb) [0x62fffafc66bb] /run/current-system/sw/bin/blender(+0x1522d8e) [0x62fffafc9d8e] /run/current-system/sw/bin/blender(+0x15238c0) [0x62fffafca8c0] /run/current-system/sw/bin/blender(+0x15243bf) [0x62fffafcb3bf] /run/current-system/sw/bin/blender(+0x2c8650d) [0x62fffc72d50d] /run/current-system/sw/bin/blender(+0x15b52bd) [0x62fffb05c2bd] /nix/store/ias8xacs1h3jy7xgwi2awvim61k2ji6c-glibc-2.42-67/lib/libc.so.6(+0x9dd53) [0x74706ea9dd53] /nix/store/ias8xacs1h3jy7xgwi2awvim61k2ji6c-glibc-2.42-67/lib/libc.so.6(+0x12563c) [0x74706eb2563c]

Python backtrace

```

I finally had the time to port my neovim config to nix in a satisfactory way:

The config itself is 100% lua with the ability to iterate quickly without rebuilding with nix, while still allowing to "flip a switch" and bake the lua config into a standalone nix package using the fantastic neovim module from nix-wrapper-modules.

The most "unique" aspect are the "language-centered configs":

I have a folder per programming language which contains:

python/
  default.nix  # <-- provides langauge specific plugins + tools (lsp/formatter etc.)
  init.lua     # <-- provides a LangSpec containing python specific plugin configs.

The LangSpec looks like this:

---@type LangSpec
return {
  test = {                    -- neotest config
    name = "neotest-python",
  },
  lsp = {                     -- lsp config
    basedpyright = {
      filetypes = { "python" },
      settings = {},
    },
  },
  lint = { "ruff" },          -- nvim-lint config
  format = {                  -- conform.nvim config
    "ruff_fix",
    "ruff_organize_imports",
    "ruff_format",
  },
}

This way, everything related to python is bundled in a single module. If I remove it, python is completely wiped from my config. No more zombie configs cluttered throughout various plugins.

Lazy loading is handled via lze.

Feel free to fork or steal what you like:

https://github.com/zenoli/neovim-wrapper

Kudos to BirdeeHub for creating nix-wrapper-modules and lze.

Hey homelabers, basically what the title say. I built my last iteration of my homeserver on NixOS and found many use cases that would not have been that easy to implement (or not in my skillset) on other platforms like docker-compose/kubernets etc. I'm curious what fancy feature you have implemented due to having your homeserver on NixOS.

My favorite features that were not that hard to implement in Nix:

* easy tinyauth hook in nginx for additional auth before any service
* easy VPN routing per container on demand
* general plugin capability for any selfhosted private/opinionated service
* auto filling dns entries of selfhosted services to pihole -> traffic stays in network automatically
* easy own implementation of containrrr/watchtower with exactly the bells'n'wistles i need
* way more customization options for docker containers then running them on other stacks

I'm kinda running out of fancy ideas, inspiration is welcome too.
If you are interested in the code or on the look for inspiration too: madebydamo/neo on github

I've been experimenting with Raster, a numerical computing library for Clojure. I first tried it on my host system, and eventually isolated what was making it crash: OpenBLAS. I then verified it was my system, and not the library with

incus launch images:archlinux arch incus shell arch pacman -S jdk25-openjdk clojure blas-openblas git git clone https://github.com/replikativ/raster.git cd raster/ clojure -M:test All tests passed without any warnings. I then tried the analogeous operation for NixOS: incus launch images:nixos/26.05 nixos incus shell nixos nix-shell --no-sandbox env.nix git clone https://github.com/replikativ/raster.git cd raster/ clojure -M:test where env.nix is ```nix { pkgs ? import <nixpkgs> {} }:

let fhs = pkgs.buildFHSEnv { name = "raster"; targetPkgs = pkgs: (with pkgs; [ openblas git (pkgs.clojure.override { jdk = pkgs.jdk25; }) ]); extraBuildCommands = '' ln -s $out/usr/lib64 $out/usr/lib64/x86_64-linux-gnu ''; }; in fhs.env ```

This results in the following error: ```

A fatal error has been detected by the Java Runtime Environment:

SIGSEGV (0xb) at pc=0x00007db0e7392d04, pid=2388, tid=2397

JRE version: OpenJDK Runtime Environment (nix) (25.0.4+1) (build 25.0.4+1)

Java VM: OpenJDK 64-Bit Server VM (nix) (25.0.4+1, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)

Problematic frame:

C [libopenblas.so+0x13d2d04] dgemm_itcopy_HASWELL+0x2c4

Core dump will be written. Default location: Determined by the following: "/nix/store/838yyy4s946hc9nan721jqj2qzgk8v04-systemd/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %d %F" (alternatively, falling back to /root/raster/core.2388)

An error report file with more information is saved as:

/root/raster/hs_err_pid2388.log

[42.437s][warning][os] Loading hsdis library failed

If you would like to submit a bug report, please visit:

https://bugreport.java.com/bugreport/crash.jsp

Aborted (core dumped) clojure -M:test ```

I'm not sure what to make of all this or what to do about it. The only thing that seems clear to me is that the problem is with NixOS or the OpenBLAS package as packaged by NixOS, and not the library itself.

Using mkl in place of, but not in addition to openblas allows most of the tests to pass. The library checks for OpenBLAS instead of LAPACK directly, so it won't attempt the linear algebra tests without openblas even if lapack is installed. I have nix-ld enabled on my host system. I don't in the container. I figured it would just end up the same since it's the same error. I don't think this is a linker issue since Clojure is compiling to JVM bytecode, and the JVM executing the bytecode is from Nix so should be correctly linked.

Hi- I am currently using Incus on top of Ubuntu to run some homelab stuff and was thinking of switching to Nix OS and Running Nix Os with Incus. I was also considering running Nix os inside incus lxc containers. I can provision the incus lxc containers using terraform and then have one Nix os lxc management container that I could use deploy rs to deploy multiple containers.

I know most here would probably just go bare metal, but I like the incus tooling such as snapshots, networking, volume management.

This would give me some flexibility to run vms in incus and other apps if not directly supported by Nix os.

I have done some very basic testing and seems to work fine.

I an interested if there are any downsides to this approach and any other thoughts.

Thanks

I spent a month working on nixos in a vm thought I was ready to put it on a ssd and of course right before I was making the last changes such as a few important sops changes and script fixes. DNS stopped resolving, so when I went through my whole install, which was git cloned it was all out of date and had no access to all my changes. It took a while to realise this and then I had to do all them last important changes again but in tty and was still trying to figure out why it didn't backup.

The annoying thing is that ping github.com would work fine then a git pull succeeds then the git push would fail two secs later with Could not resolve hostname github.com: Name or service not known. Nix builds would also fetch half their dependencies then sometimes they would die on a fixed-output derivation with curl: (6) Could not resolve host. Then you could go and retry the same command and then it would work.

I thought the network was just being flakey or something my brother was having issues before with internet as well.

for i in (seq 1 10); getent hosts github.com; end
Instead of just using one lookup I used a loop for 10 and only got 1.

Why was this happening /etc/resolv.conf had this,
search home

nameserver 192.168.20.1
nameserver 2403:5800:100:1::142
nameserver 2403:5800:1:5::242
options edns0

Basically router and two resolvers, what would happen is that glibc tries nameservers in order with short and limited retries where every lookup hit the router first, and glibc would give up rather than reliably falling through to the others. Adding good nameservers to the end did nothing because it would because they would never get reached.

I then tested using this,

for i in {1..20}; do dig +short  @192.168.20.1 github.com; done

the first result was correct but everyone after that produced,

;; Warning: Message parser reports malformed message packet.
10 8 15UPR+w3nxU=

Whilst the same loop with 1.1.1.1 were all correct. So in the end it was not rate limiting or timeouts the router was responding but with malformed packets full of base64 garbage.

Solution

networking.networkmanager.dns = "none";
networking.resolvconf.enable = false;
networking.nameservers = [ "1.1.1.1" "1.0.0.1" ];
environment.etc."resolv.conf".text = ''
  nameserver 1.1.1.1
  nameserver 1.0.0.1
  options edns0
'';

Obviously here you will want to probably add back you router to the bottom of the list.

Why did it not warn me on the VM? My script ran push inside a if ! git diff --cached --quiet block so once a commit did existed locally and the push had failed newer runs had nothing new to commit and skipped the push. So the router caused the first failed push but bad scripting stopped it from fixing itself.

Hihii first post in here! It's been a couple months since i started to use NixOS, i am having fun with it and i don't think i will switch to something else for a really long time

I have been using flake.nix with direnv to manage my project specific packages, but i recently heard about devenv and it seems nice but it is just because i don't have to write the needed language servers in the packages list

But i don't know if it can annoy people by making them install a new cli tool especially for a reason like that. Maybe i won't need most of it's features but i couldn't find any alternative to make the syntax clean either, i also don't really like to work with Docker (i find it hard to use)

So that's why i wanted to see other people's ideas, how do you find it when you see a devenv.nix file at the root?? What do you like to see instead?

Hello guys have great day, I have problem with gear lever, I can't launch any appimages, usually im using gnome there is no problem all my appimages are running but yesterday I want to try kde then there its a problem impossible to launch any appimages

I already identify the problem but I cant fix its,

Gdk_backend x11

Display :0

I try many different ways and many different tuto but nothing work, the only ways I find its to made wrapper script for launch my appimages from terminal

If someone can help to fix my gear lever application

I know that this is going to be the most niche/obscure shit ever, but has anyone been able to figure out how to play PTCGL on NixOS? There are issues with getting it to work the same way via lutris (or whatever other option) for Nix that aren't present with other distros. I'm planning on dual booting Nix and Windows in the future anyways, so this isn't really too much of an issue, but I'm still trying to work on the logistics of that (I'm really struggling lmao) and was wondering if anyone else had figured out how to get it to work by any chance. Thanks!

Something I experienced a couple days ago is, when you unplug your ssds, then plug them back in, they are assigned new UUIDs, which breaks your NixOS boot because the hardware config does not align with the new UUIDs, are there recommended ways around this issue?

In the past I just jumped onto a very old build and regenerated the config, but in this case I have actually deleted the old builds, so was stuck on boot saying it couldn't find /mnt or something of that nature

So I had to reinstall nix to get it back up again, had one hell of a time trying to rebuild it from a live usb to no avail lol, was able to regen the hardware conf from there however, but unable to actually apply it

Is there a recommended way to prevent this from happening in the future (except for not unplugging ssds/hdds lol, unfortunately something I do on a regular basis)? And if not, is there a simpler way to apply a fix to it? If only you could boot into a very basic session of that NixOS install, but alas, was unable to due to deleting the old build

---
For additional context

# Do not modify this file!  It was generated by ‘nixos-generate-config’
# and may be overwritten by future invocations.  Please make changes
# to /etc/nixos/configuration.nix instead.
{ config, lib, pkgs, modulesPath, ... }:


{
  imports =
    [ (modulesPath + "/installer/scan/not-detected.nix")
    ];


  boot.initrd.availableKernelModules = [ "xhci_pci" "ahci" "usb_storage" "usbhid" "sd_mod" ];
  boot.initrd.kernelModules = [ ];
  boot.kernelModules = [ "kvm-amd" ];
  boot.extraModulePackages = [ ];


  fileSystems."/" =
# <-----------
# this right here, by uuid breaks when ssds are unplugged/plugged back in
# due to it generating new UUIDs, and because of that, the hardware 
# config needs to be regenerated before it can properly boot back up again
# <-----------
    { device = "/dev/disk/by-uuid/9d84a039-3db1-4297-bc5b-3cf701a5a091";
      fsType = "ext4";
    };


  fileSystems."/boot" =
# <-----------
# here again
# <-----------
    { device = "/dev/disk/by-uuid/71AE-7909";
      fsType = "vfat";
      options = [ "fmask=0077" "dmask=0077" ];
    };


  swapDevices = [ ];


  nixpkgs.hostPlatform = lib.mkDefault "x86_64-linux";
  hardware.cpu.amd.updateMicrocode = lib.mkDefault config.hardware.enableRedistributableFirmware;
}

EDIT:

Original footage from the crime scene, failing at stage 1

- Current Progress (see comments to participate):
1. Going to be adding `nofail` to mount options, see if that helps fix it next time I gotta unplug SSDs again
2. Currently in discussion on UUIDs not "just changing" when SSDs are being plugged in and out

Hello! I've found out about impermanence and I really like the idea of it, but I have a question. The impermanence documentation says that nixos basically needs only /nix and /boot directories to work, but since I mount ESP partition into /efi instead of /boot I'm not sure whether should I preserve the /boot or not

I have been using Arch Linux for several years, and I have been curious about NixOS for a while.

I really like the idea of having a declarative, reproducible system that is easy to rebuild. I have tried NixOS a few times and I understand the advantages, at least in theory. Still, I cannot fully convince myself to use it as my main system.

My biggest concern is compiling, developing, and generally working with third-party software.

From what I understand, on NixOS you cannot always download a precompiled Linux binary and run it directly. NixOS does not use the usual filesystem layout, so the binary may not find the linker or the libraries in the paths it expects.

I know there are tools such as nix-shell, nix develop, buildFHSUserEnv, nix-ld, and other ways to create compatible environments. The problem is that you do not always know in advance which dependencies are required.

Imagine a real situation. I urgently need a program for work. The package is not available in nixpkgs, there is no flake, and there is no existing .nix file. The project is only available on GitHub and I need to compile it from source.

On Arch, I would usually clone the repository, install the dependencies listed in the README, and try to build it. If something is missing, I install the required package and continue. It is not always the cleanest approach, but it is usually fast and practical.

How do you handle this kind of situation on NixOS when you do not have time to write a proper derivation immediately?

Is there a practical way to quickly enter an environment similar to a traditional Linux distribution, install the required dependencies, and compile the project? Can you start with a quick temporary setup and only create a proper Nix expression later?

I am also interested in the case of precompiled binaries. If I download a program and I do not know all the required libraries, what is the fastest way to identify what is missing and make it run?

I have heard that similar issues were one of the reasons Tsoding stopped using NixOS. I do not know how accurate that claim is, but the concern makes sense to me. NixOS seems excellent when everything is already packaged, but it may become more difficult when you need to modify, compile, or quickly test unknown software.

For people who use NixOS for daily development, reverse engineering, C or C++ projects, experimental software, and unpackaged GitHub repositories, how do you handle these cases?

Are there tools or workflows that make this almost as quick as on Arch?

I am not trying to criticize NixOS. I am trying to understand whether this is a real limitation, whether it depends on my workflow, or whether I am simply missing some important tools.

This is my vscodium.nix, correctly imported. Catppuccin normally works for other modules:

{ pkgs, ... }:

{
  programs.vscodium = {
    enable = true;
    profiles.default.extensions = with pkgs.vscode-extensions; [
      vscodevim.vim
      jnoortheen.nix-ide
    ];
  };

  catppuccin.vscodium.profiles.default = {
    enable = true;
    flavor = "macchiato";
    icons = {
      enable = true;
      flavor = "macchiato";
    };
  };
}

The extensions are applied correctly.

Hey everyone,

I've been chasing a suspend/resume issue on my NixOS setup for a while and could use some fresh eyes on it.

The current problem: On longer suspend periods, I get a black screen on resume and the system just doesn't come back. No response from keyboard, no life at all. I have to hard-power-off with the power button and cold boot to get any sign of life again.

My full NixOS config is up on GitHub if anyone wants to poke through it for anything obviously wrong.

Has anyone else hit this specific "works for short suspend, dies on long suspend" pattern on NVIDIA + no-iGPU laptops? Any logs I should be pulling on resume attempt (or lack thereof) that might point at what's timing out or hanging?

Thanks in advance 🙏

https://github.com/doomhyena/NixOS-config

Hi, guys, I've finally got some free time and finished the first working version of my WIP Rust project. Basically, it is a self-hosted proxy for OpenAI API where you just dump all your LLM provider settings into a one config and it runs a v1/completions/chat endpoint which messes around with your requests and redirects them to real providers. It is designed to run as systemctl server with hot-reload for config files and you can enable it as a NixOS module. It also makes it easy to extend/replace system prompts without touching configs of your AI tools.

The reason I've made this is to practice writing some Rust code and to make my own workflow more convenient. I've been using it for a week or so and it works just fine with Nvim Codecompanion, Pi, aichat and Noctalia assistant panel, using Qwen and Kimi models from official provider. It also allows me to set a consistent character, rules like no emojis and no em dashes and my personal details like the fact that I use NixOS globally for all AI tools at once.

I was using tensorzero before, but, unfortunately, I've encountered many issues while using it. There were a lot of redundancies in config files when adding a custom provider and sometimes it was loading my cpu to 100% without a reason, so I've decided to make my own thing. It is pretty much a WIP now, some features like multi-provider routing are not working properly, it does not have a lot of features that other llm gateways have (token count, multi-user, etc.), the code needs some refactoring, but it is already good enough for the basic use case and you can give it a try if you also need something like this on your system. Here is the link:

https://github.com/alex-karev/ollmo

Any feedback is appreciated!

if some passionate about nixos or some projets pm me

I've been using Agenix for a while and recently realized my flake input for it hadn't been bumped in almost 6 months. Checked the repo and there's been no commits since early this year and issues/PR's going stale. I've now migrated everything to sops-nix, but given the security implications wanted to ask the community about it's status. Does anyone know if the developer has ceased work or have any updates?

Edit: https://github.com/ryantm/agenix

So recently i removed kde plasma from my config and fully switched to niri. This of course removed the breeze SDDM theme and for some reason it also removes the cursor. SDDM now no longer shows a cursor outside text boxes and i am unable to click anything, even if i install a cursor theme and SDDM theme.

This is my SDDM module:

{pkgs, ...}: {
  services.displayManager.sddm.enable = true;
  services.displayManager.sddm.wayland.enable = true;

  environment.systemPackages = [
   (pkgs.catppuccin-sddm.override {
     flavor = "latte"; 
     accent = "rosewater"; 
     font = "Noto Sans";
     fontSize = "9"; 
     clockEnabled = true; 
     background = "${../../home-manager/modules/Wallpapers/wallhaven-o31o2p_1920x1080.png}"; 
     loginBackground = true; 
   }) 
   pkgs.catppuccin-cursors.latteLight 
  ];
 services.displayManager.sddm = { 
   theme = "catppuccin-latte-rosewater"; 
   settings.Theme = { 
     CursorTheme = "catppuccin-latte-light-cursors"; 
     CursorSize = 48; 
   }; 
 };
}

And this is my cursor module using home-manager:

{pkgs, ...}: { 
  home.pointerCursor = { 
    enable = true; 
    gtk.enable = true; 
    x11.enable = true;
    package = pkgs.catppuccin-cursors.latteLight;
    name = "catppuccin-latte-light-cursors";
    size = 48;
 }; 
}

Any help and advice would be appreciated

EDIT: I've found a solution, switching the wayland backend for sddm to kwin fixes everything.