You could just use disko and define all those btrfs subvolumes and the rest of your partitions in a config.

Reboot them once in a while

Switched to stable to get my system to fucking build and boot again, so I can get all the fixes

You know, if i can setup btrfs from the graphical install that might be the better way to go. I could then make different sub-volumes for @home @nix , etc. If I really want the quotas that can be enforced on the sub volumes.

This is the way. If you don't mind having your kernel pinned to the latest that ZFS supports.

I use ZFS on top of LUKS with the same three-way root/nix/home breakout and a separate SWAP partition.

Works pretty well and sidesteps the partition-sizing issue entirely, since the pools don’t have to be a fixed size.

Right, will bump my /nix partition to 100GB then just to have good room for growth.

I just checked my main PC which I use for playing games and development (Android and Rust), and it uses 45GB for /nix just after nh clean all which deletes all profiles but the current one. 50GB might be a bit tight during a rebuild where you inevitably have two copies of the software, but outside of that, it seems good enough.

Thanks for the info. I was only going to seperate /home onto a different partition, but then I took a look at sudo du -hs /nix and saw it was 17GB by itself on my current laptop. I was aware of the gc daily thing since i have automatic updates enabled, but I was not aware of the other two storage optimization things.

I am a pretty standard desktop user, but i do need some dev tools like androidsdk, flutter, java, and rust.

I suppose you are aiming for impermanence? 50GB seems good enough if you're not installing too many tools. If you haven't already, take a look at nix.* options because they have some storage optimisation options. That and CLI tool called nh, which cleans stuff up for you.

{
  nix = {
    settings = {
      auto-optimise-store = true;
    };
    gc = {
      automatic = true;
      dates = "daily";
      options = "--delete-older-than 10d";
    };
    optimise = {
      automatic = true;
      dates = [ "weekly" ];
    };
  };
}

Appreciate the update!

Sorry about that. I was in a rush. :)

https://github.com/nix-community/impermanence

Your root directory is mounted as a tmpfs which means it gets cleared every startup. The only way to persist config or data is to have it in your Nix config or use impermanence to bind mount a folder to a persisted directly.

I use it on my servers. I have Impermanence + LUKS with remote unlocking on my servers

Mind expending on that a bit, even if just a link to more info?

Impermanence

Edit: sorry I didn’t link. It has been an incredible overnight upgrade to security for me. I have all of my stateful directories LUKS encrypted and copying on write to a btrfs subvolume that gets cloned over at boot to each time and as a result, I have a minuscule attack surface. On top of that, all of the machines on my network are fully impermanent and write their state to a local NAS. It’s pretty elegant. I highly recommend rehearsing the switch to impermanent via a QEMU VM and not fully making the switch until your data is backed up.

I did a rehearsal on my home directory that took a few iterations to catch all of the files I needed to declare. A diff on the two btrfs directories each reboot made that fairly easy. I wish I could share the config but it would dox the shit out of me!

https://github.com/buildplan/du_setup

i love that, for homelabbing, NixOS does a lot of secure things by default. firewall ports are opened explicitly and declaratively and services run under their own user with their own data directory. everything, even on the same local machine, communicates over HTTPS.

also, IMO the way people should have been running agents from the beginning: agents get their own user and a pared down list of tools and specific directories with specific read/write access and their own git clone of whatever code i’m working on (i hate working on the same files as an agent). (running a local Qwen 27B with Hermes)

other than that the normal stuff like fail2ban, random SSH port, VPN for remote access, Adguard, etc.

I am also interested in this. I like that the execution of binaries is tied to the nix-store, but I am sure there are some things to be done to harden it further.

That's only on me. I've enjoyed putting emojis in READMEs and commit messages since I've been programming in 2009, even in with yahoo and MSN messages before that. It was the tech fad at the time and I just never grew out of it, nor making my graphics overly colorful. I relish that LLMs mimic that trend from their training data, like some kind of lingering graffiti or watermark we imparted on the corpus of AI data sets.

Did you mean to put that many emojis on the readme or was that Claude?

Well, I got it, and even went as far as making a NYX package for it.

https://github.com/Cuprate/cuprate/pull/730

Hey, thanks. I am on NixOS and will give this one a shot

Okay, this is going to depend on whether or not you are on Nixos.

If you are not on NixOS, then this shell.nix works for me, although you will need libstdc++ installed on your host. Also, I cut out some of the packages, because the default nix shell provides ldd and gcc already, so there is no need to specifically include them.

{ pkgs ? import <nixpkgs> {} }:

let packages = [
  pkgs.cargo
  pkgs.cmake		# Cmake
  pkgs.git		# Git version control system
  pkgs.pkg-config    # often needed for C dependencies
  pkgs.rustc          # Nix’s rustc (matches the store layout)
  pkgs.libcxx
  pkgs.gccNGPackages_15.libstdcxx
];

in

pkgs.mkShell {
  nativeBuildInputs = packages;

  LD_LIBRARY_PATH = pkgs.lib.makeLibraryPath packages;

  # Optional – tell Rust to prefer lld for Rust‑only code, but fall back to gcc
  # for build‑script / C‑linking steps.
  RUSTFLAGS = "-C link-arg=-fuse-ld=lld -C link-arg=-Wl,-rpath,/usr/lib -C link-arg=-Wl,-dynamic-linker,/lib64/ld-linux-x86-64.so.2";
  RUST_BACKTRACE = 1;
}

But if you are on NixOS, then things get a bit different. NixOS won't put some of the stuff that the rust compiler is expecting to be there by default, but not there. For the NixOS version, remove this part -C link-arg=-Wl,-dynamic-linker,/lib64/ld-linux-x86-64.so.2 from RUSTFLAGS.

You will probably have to either run it from the shell, or create a nix package for it.

Looks like it's been recently updated as of about an hour ago

Might be worth migrating your php apps to containerized builds to help avoid this issue

You can probably mount the same data into the container, depending on the apps configuration

Doesn’t help if you build a nix flake based app yourself though, but with that you can manually pin a build.