Flake.nix & Garbage Collection

Garbage Collection in LuxNix

Deleting old generations can be done on LuxNix using

sudo rm /nix/var/nix/gcroots/auto/*

In default.nix, the path: modules/nixos/system/nix/default.nix, contains the following setting:

auto-optimise-store = lib.mkDefault true;

• This setting deduplicates identical files in the Nix store (/nix/store).
• This saves disk space but does not actually delete anything.
• If garbage collection (nix-collect-garbage) runs later, the system will use fewer resources because redundant files were already optimized.

Users in the wheel, root, and admin groups can run Nix commands, including nix-collect-garbage. List of Shortcuts:

Cleanup runs Nix garbage collection and aggressively deletes old system generations.
Cleanup-roots deletes all automatic GC root references in /nix/var/nix/gcroots/auto/
Warning Removing GC roots could break running applications if they still reference store paths.
Optimize deduplicates identical files

Garbage Collection in NixOs

Garbage collection in NixOS is all about cleaning up old, unused packages and configurations to reclaim disk space. NixOS keeps previous generations of system state available in case rollback is desired, old package versions aren't deleted from your system immediately after an update. You can clear store paths manually [1]

Nix-collect garbage however will clean old store paths. These are paths that have been generated from derivations and that are no longer needed.

# delete generations older than 30 days
$ nix-collect-garbage --delete-older-than 30d

# delete ALL previous generations - you can no longer rollback after running this
$ nix-collect-garbage -d

To delete all old (non-current) generations of your current profile [2]:
nix-env --delete-generations old

Instead of old you can also specify a list of generations, e.g.,
nix-env --delete-generations 10 11 14

The following are equivalent and will clean old store paths:
nix-collect-garbage
nix-store -gc

The code located at modules/nixos/cli/programs/nh/default.nix serves the purpose of configuring the nh (Nix command-line helper) utility for managing NixOS systems for Garbage Collection purposes.

Code Overview

This NixOS module defines a configuration for integrating and managing nh, a Nix command-line helper, in a modular and declarative manner. The configuration is located within the file and context provided by the path.

Purpose of the Code

Nh is a reimplementation of

• nixos-rebuild {switch,boot,test}
• home-manager switch
• nix-collect-garbage -d

The primary goal of this module is to introduce configurable options for nh and conditionally apply them if the nh program is enabled. The configuration automates cleaning policies and integrates custom behavior for managing the Nix store and system.

Detailed Breakdown

1. Module Options

• Path in Module Hierarchy: cli.programs.nh
• Defined Option:
  • enable:
    • Type: Boolean (mkBoolOpt)
    • Default Value: false
    • Description: Allows users to enable or disable nh (Nix command-line helper).
    • Purpose: Provides modularity, ensuring the configuration for nh is applied only if explicitly enabled by the user.

2. Conditional Configuration (mkIf)

When cli.programs.nh.enable is set to true, the following configuration is applied:

1. Enable nh:
   • The program is explicitly enabled via programs.nh.enable = true;.
2. Automated Cleaning:
   • Cleaning Behavior:
     • clean.enable: Activates automatic cleaning functionality for nh.
     • clean.dates: Specifies a cleaning schedule. The default value is "weekly".
     • clean.extraArgs: Provides custom cleaning parameters:
       • --keep-since 4d: Retains packages created or used in the last 4 days.
       • --keep 3: Ensures at least 3 recent items are preserved.
     • The cleaning arguments allow precise control over garbage collection, balancing retention and disk space usage.
3. Custom Flake Path Integration:
   • flake:
     • Dynamically points to a flake configuration path (config.luxnix.generic-settings.configurationPath), providing additional flexibility for managing user-defined system configurations.

Recommendations

1. Automated Garbage Collection with Systemd Timer

Automating garbage collection ensures it runs on a regular schedule without manual intervention. This is simple, reliable, and highly scalable.

What's Missing: Your code uses nh to schedule garbage collection via clean.dates = "weekly", but it doesn’t integrate with Nix's native garbage collection commands (nix-collect-garbage -d) or systemd timers for automation.

Difference: nh clean is a wrapper around Nix commands but doesn’t automate garbage collection via system-wide timers

Why It’s Important:

• Automates garbage collection, keeping the system clean.
• Runs safely without manual effort or interfering with other configurations.
• Scales well for any size system.

This would however require carefully choosing the data that would be cleared, since the nix-store paths don't always need to be rebuilt.

Frequent rebuilding can hurt performance and stability of the system.

2. Optimize the Nix Store (nix optimise-store)

Optimize the Nix [3] store by deduplicating files to save disk space. It’s a safe, non-destructive operation that works seamlessly with existing configurations.

What's Missing: The code doesn’t optimize the /nix/store by deduplicating files (nix optimise-store). This is a separate feature from garbage collection and works at the file level to save disk space.

Difference: Store optimization is a one-time or periodic operation outside the scope of nh and needs its own service/timer.

Why It’s Important:

• Saves significant disk space in large systems.
• Non-intrusive and doesn’t impact existing builds or dependencies.
• Scales efficiently for systems with heavy package usage.

Check What Files Will Be Deduplicated Before Running Optimization:nix path-info --sigs --recursive /nix/store | awk '{print $1}' | sort | uniq -d

optimise:nix store optimise

What files were deduplicated:nix path-info --sigs --recursive /nix/store | awk '{print $1}' | sort | uniq -d

Check if timer is activated: systemctl list-timers | grep nix-store-optimise
Status of timer: systemctl status nix-store-optimise.timer

3. Limit System Generations

Set a policy to automatically remove older system generations. This prevents unnecessary accumulation of system snapshots without interfering with your ability to roll back recent changes.

What's Missing: Your code doesn’t define a system-wide policy for cleaning old system generations. It uses nh to configure cleaning options (--keep-since 4d --keep 3), but this doesn’t affect system generations managed by nix-collect-garbage.

Difference: System generation management ensures old system profiles are pruned automatically, while nh focuses on cleaning package-level data.

Why It’s Important:

• Reduces clutter in the system.
• Safely removes older generations while keeping recent ones intact for rollbacks.
• Scales well, even on multi-user systems.

Deleting old system generations can be done on LuxNix using:
sudo rm /nix/var/nix/gcroots/auto/*

However, a less radical system generation clearance would be helpful, since often old generations are the only way to roll back system failures after a build.

Nix Flakes

Nix flakes provide a standard way to write Nix expressions (and therefore packages) whose dependencies are version-pinned in a lock file, improving reproducibility of Nix installations [4].

• Flakes are a new feature in Nix that standardize how projects (written in Nix expressions) are defined and managed.
• Dependencies are "version-pinned," meaning the exact versions of all dependencies are locked in a flake.lock file.
• This ensures reproducibility, meaning the same project will behave identically no matter where or when it's built.
• Flakes can launch virtual environments containing support for various tools, such as a python environment or CUDA support.

Example

You write a project that depends on specific versions of nixpkgs and nixos-generators.

• Without flakes: Those dependencies could change over time, leading to inconsistent results.
• With flakes: The flake.lock file ensures that the same versions of nixpkgs and nixos-generators are used every time.

The experimental nix CLI lets you evaluate or build an expression contained within a flake, install a derivation from a flake into a User Environment, and operate on flake outputs much like the original nix-{build,eval,...} commands would, for further detail please visit the official documentation [4].

• Nix introduced a new CLI (Command-Line Interface) that works with flakes.
• It allows you to:
  1. Evaluate or build an expression inside a flake.
  2. Install a derivation (a buildable artifact, like a program or library) from a flake into your system's environment.
  3. Interact with flake outputs (like packages, NixOS configurations, or ISOs) in a way similar to older Nix commands like nix-build or nix-eval.

Example:

1. Evaluate or build a flake expression:
   • Run nix build . in a directory containing a flake.nix file. This builds the default output of the flake.
2. Install a derivation:
   • Run nix profile install .#my-package to install a package (my-package) defined in the flake into your system.
3. Interact with outputs:
   • Use nix flake show to see all outputs defined in the flake (like packages, nixosConfigurations, or custom scripts).

Open the flake.lock file in your project directory to see the pinned versions. Alternatively, run these commands.

nix flake show : To list the inputs and their versions
nix flake metadata : To retrieve detailed metadata, including revisions, run

Inputs:

• Inputs are external dependencies or other flakes that your flake relies on.
• Think of them as building blocks or references to other pieces of code, libraries, or configurations.

Outputs:

• Outputs define what your flake provides or generates.
• These are the "products" of the flake, such as:
  • NixOS configurations.
  • Packages.
  • DevShells (development environments).
  • Home Manager configurations.

The file path /home/admin/dev/luxnix contains a flake.nix file that imports several inputs, each serving a specific purpose in building, configuring, or deploying the system.

Nixpkgs

• URL: github:nixos/nixpkgs/nixos-24.11
• Role: Provides the Nix package collection (e.g., core packages, tools, and libraries) for the system. It is the largest package repository on the internet.
• Usage: All packages, configurations, and overlays in this flake rely on this as the foundational dependency.
• Why: It is the backbone of any NixOS-based system.
• Example Usage: Used to build packages and set the system's foundation.

Home-Manager

• URL: github:nix-community/home-manager/
• Role: Enables managing user configurations.
• Usage: Adds home manager modules for managing user environments.
• Why: To ensure user-specific configurations are reproducible.
• Modules define:

1. The available options (e.g., settings, themes, or plugins for a program).
2. How to apply those options declaratively.

NUR (Nix User Repository)

• URL: github:nix-community/NUR
• Role: A community repository providing access to additional packages not available in the official Nixpkgs. The NUR was created to share new packages from the community in a faster and more decentralized way.
• Usage: Provides overlays for extended package availability.
• Why: Allows the use of community-contributed packages in the system configuration.
• For Installation: Please visit the official site.

Snowfall-lib

• URL: github:snowfallorg/lib
• Role: Provides the lib.mkFlake helper function for managing the flake's structure and configuration.
• Usage: Wraps and organizes the Nix flake into a reusable library structure.
• Why: Simplifies flake management and improves modularity.
  lib.mkFlake is a helper function provided by snowfall. It acts as a wrapper around the output attribute in flakes and is designed to streamline the process of defining what your flake provides (e.g., system configurations, packages, applications). Reduces boilerplate: No need to manually structure the output block.

Deploy-RS

• URL: github:serokell/deploy-rs
• Role: A declarative deployment tool for managing remote NixOS configurations.
• Usage: deploy-rs is a Rust-based deployment tool designed for deploying NixOS configurations to multiple nodes (remote machines) using Nix flakes. It simplifies the process of managing infrastructure declaratively and reproducibly.
• Why: To automate and simplify deploying NixOS configurations to multiple systems.

Nixos-Hardware

• URL: github:nixos/nixos-hardware
• Role: Provides hardware-specific NixOS modules for easier configuration of devices like laptops and servers.
• Usage: Add and update the nixos-hardware channel using sudo nix-channel, import the appropriate system profile path by adding them to etc/nixos/configuration.nix
  Alternatively use flake support by adding it to inputs and defining it as a module.
• Why: Simplifies the configuration of hardware-specific details like drivers.

Sops-Nix

• URL: github:mic92/sops-nix
• Role: Integrates SOPS (Secrets OPerationS) for managing secrets declaratively in NixOS configurations. SOPS files are decrypted during activation.
• Usage: Adds secret management functionality through the sops-nix NixOS module.
• Why: To securely manage secrets like API keys and passwords in the NixOS configuration.

Impermanence

• URL: github:nix-community/impermanence
• Role: Provides NixOS and Home Manager modules for declaratively managing ephemeral (non-persistent) system configurations.
• Usage: Allows specific directories or files to be ephemeral, useful for stateless systems.
• Why: Helps create systems where only a specific subset of data persists.

NixGL

• URL: github:nix-community/nixGL
• Role: Provides GPU support for applications inside Nix environments.
• Usage: Added as an overlay to manage GPU acceleration for Nix-based applications.
• Why: Simplifies the use of GPU-accelerated software.

Disko

• URL: github:nix-community/disko
• Role: Declaratively configures disk partitions and filesystems in NixOS.
• Usage: Adds the disko NixOS module for disk configuration. Please visit the documentation.
• Why: Ensures reproducible and consistent disk setups.

Nix-LD

Dated: 17.01.2025 - Please note that this configuration is subject to changes in the near future. Updates or modifications might occur as the project evolves.

• URL: github:Mic92/nix-ld/…
• Role: Provides support for running dynamically linked binaries in NixOS. This is useful, since some packages depend on specific binaries that are usually pre installed and will be searched for during compilation. Linking them centrally using nix-ld avoids having to do this in each virtual environment.
• Usage: Adds the nix-ld module for managing dynamic linker setups.
• Why: Allows running binaries that are not Nix-native.

Nixos-Anywhere

• URL: github:numtide/nixos-anywhere
• Role: Deploys NixOS to remote systems over SSH(SSH is a protocol used to securely connect to and manage remote systems over a network.It encrypts the connection, making it safe to send commands and data even over insecure networks).
• Usage: Provides functionality for remote installation of NixOS.
• Why: Simplifies deploying new NixOS systems remotely.

NixOs Generators

• URL: github:nix-community/nixos-generators
• Role: A tool to create NixOS images in various formats.
• Usage: Converts NixOS configurations into disk images, containers, ISO files, and more.
• Why: Simplifies deploying NixOS in different environments (e.g., VMs, cloud providers, or physical machines).

Comma

• URL: github:nix-community/comma
• Role: A utility for running tools from nixpkgs easily using a shorthand syntax. Comma runs software without installing it. Basically it just wraps together nix shell -c and nix-index. You stick a , in front of a command to run it from whatever location it happens to occupy in nixpkgs without really thinking about
• Usage: Provides a convenience tool for running commands.
• Why: Reduces the effort needed to invoke commands from the Nix store.

Catppuccin-obs

Plasma-Manager

• URL: github:nix-community/plasma-manager
• Role: It allows users to manage and configure their KDE Plasma desktop environment using declarative Nix configurations.
  • KDE Plasma is a graphical desktop environment for Linux and Unix-based systems.
• Usage: Plasma-Manager is integrated into Home Manager as a module, enabling users to easily define settings and customizations for their Plasma desktop directly in their Nix configuration files.
• Why: Plasma desktop configurations can be complex to manage manually. By using Plasma-Manager, users can automate and simplify the process, ensuring a consistent setup across installations or environments.

Nix-Topology

Declarative Management: With Nix-Topology, you can declaratively define the structure and configuration of all systems in your setup using Nix expressions.

• Example: Specify that Host A is a web server, Host B is a database server, and they need specific configurations to interact.

Modules and Overlays: It provides NixOS modules and overlays to make managing these relationships easier, ensuring all machines in the topology are consistently configured.

• URL: github:oddlama/nix-topology
• Role: Manages system topology configurations declaratively.
• Usage: Adds NixOS modules and overlays for system topology management.
• Why: Generate useful svg views of the system topology.

Let's break down the provided outputs expression and explain what it does in the flake.nix

1. Inputs Parameter:

   • The inputs parameter contains all the dependencies defined in the inputs block of your flake.nix.
   • In this case, inputs.snowfall-lib is a flake dependency being used.

2. Let Binding:

   • The let block declares a local variable lib using inputs.snowfall-lib.mkLib.

3. What's Happening Here:

   • inputs.snowfall-lib.mkLib: This is likely a function provided by the snowfall-lib flake.
   • It initializes or creates a "library" (referred to as lib) with some settings:
     • inherit inputs: Passes the inputs from the flake to mkLib, so it can access all dependencies.
     • src = ./.: Sets the source of the library to the current directory (./.).
     • snowfall: Defines additional configuration, like metadata and namespace.

4. snowfall Configuration:

   • This block customizes the "snowfall" library being created. Here's what the fields mean:

     • metadata = "luxnix";: Adds metadata information, typically for identification or categorization.
     • namespace = "luxnix";: Defines a namespace, which could be used for scoping within the library or its output.
     • meta: Provides descriptive metadata about the flake.
       • name: The name of the flake ("luxnix").
       • title: A human-readable title for the flake ("AG-Lux' Nix Flake").

     Dated: 17.01.2025, 16:22 - Please note that this configuration is subject to changes in the near future. Updates or modifications might occur as the project evolves.

5. Purpose of the Output:

   • The outputs here are likely building or exposing a library (lib) using the snowfall-lib dependency.
   • The snowfall configuration within the library defines its metadata, namespace, and descriptive information.
   • This library could then be used in other flakes, projects, or as part of a larger system configuration.

Additionally the role of helper function lib.mkFlake

Support for Unfree Software:

• allowUnfree = true enables the use of unfree/proprietary software.

Home Manager Integration:

• Adds the Home Manager module from plasma-manager, allowing management of KDE Plasma desktop configurations for all users.

System-wide NixOS Modules:

• Includes various modules to enable key features:
  • nix-ld: Dynamic linker support for running programs without patchelf.
  • home-manager: Integrates Home Manager with NixOS for user-level configuration.
  • disko: Provides declarative disk partitioning capabilities.
  • impermanence: Supports managing ephemeral file systems.
  • sops-nix: Adds secrets management with SOPS.
  • nix-topology: Enables multi-host system topology management.

Custom Overlays:

• Adds overlays (extensions to nixpkgs) to provide additional functionality:
  • nixgl: GPU driver overlays for better GPU support.
  • nur: Provides access to the Nix User Repository (NUR).
  • nix-topology: Overlay for topology management.

Deployment Configurations:

• Uses lib.mkDeploy to define deployment settings and integrate with deploy-rs.

Deployment Checks:

• Sets up deployment checks using deploy-rs to ensure correctness before deploying configurations.

Topology Management:

• Configures system topology with nix-topology for managing multi-host setups.
• Dynamically imports and applies topology settings specific to each host.

Sequence of Execution

1. Inputs Are Fetched

• All inputs (like nixpkgs, snowfall-lib, plasma-manager, etc.) are fetched and made available to the outputs block.
• Dependencies marked with follows inherit their nixpkgs version for consistency.

2. Library (lib) Is Created

• inputs.snowfall-lib.mkLib initializes a library (lib) with:
  • Metadata, namespace, and source (src = ./.).
  • Snowfall-specific configurations (metadata, namespace).

3. lib.mkFlake Generates Outputs

• lib.mkFlake uses the configuration defined inside it to generate:
  • System Configurations:
    • NixOS modules (e.g., nix-ld, impermanence, etc.).
  • Home Manager Configurations:
    • Adds Home Manager modules like plasma-manager.
  • Overlays:
    • Provides overlays for additional functionality.
    • Overlays allow the user to override packages from Nixpkgs with default configurations.
  • Deployments:
    • Defines deployment configurations.
  • Topology:
    • Creates multi-host topology setups.

4. Overlays and Modules Are Loaded

• Overlays and modules are added to the respective outputs.

5. Deployment Infrastructure Is Built

• Deployment configurations and checks are generated using deploy-rs.

Ref:-
https://nixos.wiki/wiki/Overview\_of\_the\_NixOS\_Linux\_distribution\#Generations
https://nix.dev/manual/nix/2.20/package-management/garbage-collection
https://nix.dev/manual/nix/2.23/command-ref/new-cli/nix3-store-optimise