Learning Nixos

purely functional software deployment model

files in import are made readonly and are copied to the nix-store with a unique hash code. so in a way nix-store is a immutable data store

Nix is a declarative package manager that enables users to declare the desired system state in configuration files (declarative configuration), and it takes responsibility for achieving that state.

the lack of version control and rollback mechanisms in EndeavourOS prevented me from restoring the system when problems arose.

Advantages

• No Dependency Conflict Issues
• Rollback Capability

Disadvantage

• Increased Disk Space Usage

Basics of the Nix Language

go to A tour of Nix

FLAKES!!

gixx here we go

Home Manager

Software packages and configuration files installed via NixOS Modules are global to the entire system Global configurations are usually stored in /etc, and system-wide installed software is accessible in any user environment.

On the other hand, configurations and software installed via Home Manager will be linked to the respective user's Home directory. The software installed is only available in the corresponding user environment, and it becomes unusable when switched to another user.

Folder Structure

` ├── flake.lock ├── flake.nix ├── home-manager │   └── home.nix ├── modules │   ├── home-manager │   │   └── default.nix │   └── nixos │   ├── boot.nix │   ├── default.nix │   ├── networking.nix │   ├── programs.nix │   └── users.nix ├── nixos │   ├── configuration.nix │   └── hardware-configuration.nix ├── overlays │   └── default.nix └── pkgs └── default.nix

`

Summer of Nix

Places to keep an eye MATRIX

Running executables on nixos

The Problem

when you try to run any executable file on linux, the shell uses execve system call to request the operating ystem to run the program

if the file is a dynamically linked ELF Binary file i.e if it uses libaries found on the system to function, it uses a link-loader program (interpreter) to locate and load these binaries The issue arries as nixos does not provide these paths to these binaries, as in traditional linux systems lib63/.. to work around this issue when packaging programs that do not have source code available, nix uses a build fucntion called autoPatchelfHook to analyze the binary and resolve any missing Dependencies this function rewrites the interpreter path to a specific version of the glibc package and populates the RPATH field in the ececutable with paths to all neccasst libaries for the program to run.

autoPatchelfHook works fine for most of the cases but it is not practical for few cases using binaries from third-party package managers

to solve these issues here comes Nix-ld to the rescue!