Home on I.M Blogging

Using Reuse

imran@imranmustafa.net (Imran Mustafa) — Fri, 09 May 2025 00:00:00 -0400

reuse is a software tool that can annotate your git repos with copyright information, download licences, and automatically check for compliance with the reuse standard. All from the command line. Leaving you with more time to work on what actually matters instead of the tedium of copyright law.

Installation

reuse is widely packaged¹ so its likely already present in your distros repo. Making installation through your preferred package manager simple.

Usage

The first and most important command is reuse annotate, which creates the copyright notice, and references to the licences. It needs three arguments, the first being the notice information (-c "YOUR_NAME <YOUR_EMAIL@example.com>"), as well as the licence to use (-l "SPDX_LICENSE_IDENTIFIER"), along with files to be annotated. Putting it all together will give you this.

reuse annotate -c "YOUR_NAME <YOUR_EMAIL@example.com>" -l "SPDX_LICENSE_IDENTIFIER" YOUR_FILE

This will add a header compliant with the reuse standard to the file in question. it will look something like below, though it can change depending on the specific notice style² and file type.

# SPDX-FileCopyrightText: YOUR_NAME <YOUR_EMAIL@example.com> 
#
# SPDX-License-Identifier: SPDX_LICENSE_IDENTIFIER

Now this command is quite unwieldy, which is why I would recommend you to create aliases or abbreviations in your shell to infill the data.

While this will cover most of your uses, sometimes you'll need to annotate a binary file or one that you shouldn't edit. In these situations you should pass --force-dot-license which will create a seprate file with the notice. Other times reuse wont recognize a file type, in which case you can use a dot licence like before or as a fallback (--fallback-dot-license). Forcing a style with --style=STYLE³ is useful when you know the correct encoding for a particular file.

After you have notices for all the files, reuse download --all will place the needed licenses into a LICENSES folder at the root of the repo.

reuse lint is a simple command that will check the repo for files that have no notices, and other missing information. Giving a few recommendations on how to fix the issues and insure compliance.

Footnotes

This is the table of supported styles

name	example
spdx	SPDX-FileCopyrightText: 2025 YOUR_NAME <YOUR_EMAIL@example.com>
spdx-c	SPDX-FileCopyrightText: (C) 2025 YOUR_NAME <YOUR_EMAIL@example.com>
spdx-symbol	SPDX-FileCopyrightText: © 2025 YOUR_NAME <YOUR_EMAIL@example.com>
string	Copyright 2025 YOUR_NAME <YOUR_EMAIL@example.com>
string-c	Copyright (C) 2025 YOUR_NAME <YOUR_EMAIL@example.com>
string-symbol	Copyright © 2025 YOUR_NAME <YOUR_EMAIL@example.com>
symbol	© 2025 YOUR_NAME <YOUR_EMAIL@example.com>

Here is the complete list of styles.

applescript
aspx
bat
bibtex
c
cpp
cppsingle
f
ftl
handlebars
haskell
html
jinja
julia
lisp
m4
ml
f90
plantuml
python
rst
semicolon
tex
man
vst
vim
xquery

Simplifying Syncthing With Nix

imran@imranmustafa.net (Imran Mustafa) — Sat, 07 Dec 2024 17:34:52 -0500

Syncthing is a wonderful tool that I use to sync folders quickly and securely across my devices without having to use a proprietary tool like Dropbox. You can use this tool on almost any system, and I definitely would recommend it to anyone who wants to sync files across their devices due to its ease of use and security.

This post doesn't go over how you would use Syncthing normally as you would on any other distro, instead showing off how nix can be used to manage Syncthing. Which can be especially great when you need to manage a lot of devices or folders. If you want a standard guide I would recommend Syncthing's great guide and documentation.

The Issue

Something that may come up as a hurdle with Syncthing is when dealing with networks of more then just a few devices/folders (i.e more then 3). As adding new devices or managing shared folders, becomes far more tedious as each individual machine will need to be configured to manage the network as a whole¹.

For example, if you had five devices that you wanted to link together. After installing and setting up Syncthing on each machine, device one will need to connect device two. Then device two will need to accept the connection from device one, this will be repeated between each device pair if you want all devices to connect to each other. After each device is connected, sharing a folder will require a similar process of creating, configuring, and sharing with all relevant devices. Then accepting the folders, and configuring the there settings on the new devices as well.

This can be very annoying when dealing with large number of devices or folders that need to be connected together. While there are methods within Syncthing itself, such as autoAcceptFolders. I feel that the nix method I will show makes this all so much easier.

With Nix

When you add in nix to this you get the ability to define all devices, and the folders that they share in one file. With changes reflected across all devices without the need to individually manage each devices' folders and settings.

This is done using the Syncthing service in nix, which has the options services.syncthing.settings.devices which lets you define all devices in the network and services.syncthing.settings.folders which defines folders. For example if you had three devices you could define them all in the service like so.

 services.syncthing.settings.devices = {
 "device1" = {id = "XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX";}; 
 "device2" = {id = "XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX";};
 "device3" = {id = "XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX";};
 };

With each device getting a name, and their device ID set. You can then use these devices when defining folders. For example.

 services.syncthing.settings.folders = {
 "/home/youruser/sync" = {
 devices = ["device1" "device2" "device3"]
 };
 };

This is a pretty simple folder config, but you can already see how much easier it will be managing devices and folders with everything defined in one file. As any changes to which devices share which folders will be automatically made with and devices that use this service configuration. Adding devices is simply done by extending services.syncthing.settings.devices and then adding them to the respective folders.

 services.syncthing.settings.devices = {
 "device1" = {id = "XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX";}; 
 "device2" = {id = "XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX";};
 "device3" = {id = "XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX";};
 "device4" = {id = "XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX";};
 };
 services.syncthing.settings.folders = {
 "/home/youruser/sync" = {
 devices = ["device1" "device2" "device3" "device4"]
 };
 };

That's it. Just update the config the machines are using and then they will sort out the rest.

Adding non-nix hosts

Now this is great for managing Syncthing between NixOS hosts, but you may be wondering how to add non-NixOS host into your config. This is pretty simple, as adding the non-nix device ID to the devices list and then treating them the same as a NixOS host. Though you'll need to manually accept the connections and folders on the devices that aren't managed by nix.

Manual management

If you want to have manual management of device connections and folders , set overrideFolders, and overrideDevices to False, along with localAnnounceEnabled set to true. This will allow you to manage the Syncthing service outside of the configuration set in the file. I don't recommend this but it is an option that you can take if it's what your most comfortable with.

Also to note, without both override options set to false changes that you make through the Syncthing UI will be reset after the system restarts.

Other Config Options

While everything till this point will give you most of what you need to know, there are some extra options that you can configure to fine tune your personal setup.

`services.syncthing.settings.options.urAccepted`

Syncthing reports anonymous usage data back to the development team, normally this would show a pop-up when you first access the web UI. While in NixOS you can declare your decision in the service itself. A negative number is a no, and a positive number is a yes. While 0 (the default) will prompt the software to ask you through the web UI as normal.

`services.syncthing.settings.options.relaysEnabled`

The relay system in Syncthing is how devices on separate networks that normally wouldn't be able to connect with each other, interact. It's useful when you need your devices to connect even when they move to another location/network (i.e your laptop, or phone), or if some devices are just on disparate networks normally. Relaying is disabled by default, though setting services.syncthing.settings.options.relaysEnabled to true will allow the device to connect through the relay service provided by the Syncthing team.

It's possible to reconfigure the relay service that your network will make use of, helpful if you self-host a relay or use one from another provider². Though since I make use of the default relay service I'm not 100% certain on how to set this up³.

`services.syncthing.settings.folders.<name>.versioning`

Versioning is important as it offers some protection against deleting files by accident⁴. To enable versioning on a folder set services.syncthing.settings.folders.<name>.versioning.type to a supported versioning strategy⁵. Then pass the arguments through services.syncthing.settings.folders.<name>.versioning.params to override any default values you want⁵. This is the example setup of a staggered folder in the nix docs.

 services.syncthing.settings.folders.<name>.versioning = {
 type = "staggered";
 params = {
 fsPath = "/syncthing/backup";
 cleanInterval = "3600";
 maxAge = "31536000";
 };
 };

Basic Template

Putting it all together you might have something like this for the service configuration.

 # SPDX-FileCopyrightText: 2024 Imran Mustafa <imran@imranmustafa.net>
 #
 # SPDX-License-Identifier: GPL-3.0-or-later
 {
 pkgs,
 lib,
 config,
 ...
 }: {
 options = {
 syncthing.enable = lib.mkEnableOption "Syncthing";
 };
 config = lib.mkIf config.syncthing.enable {
 services.syncthing = {
 enable = true;
 dataDir = "/home/YOUR_USER";
 openDefaultPorts = true;
 settings = {
 options = {
 urAccepted = -1;
 relaysEnabled = True;
 };
 devices = {
 "device1" = {id = "XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX";};
 "device2" = {id = "XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX";};
 };
 folders = {
 "/home/YOUR_USER/sync" = {
 devices = [device1 device2];
 versioning = {
 type = "staggered";
 params = {
 fsPath = "/syncthing/backup";
 cleanInterval = "3600";
 maxAge = "31536000";
 };
 };
 };
 };
 };
 };
 }

Footnotes

I'm assuming the network is maximally connected to show off the problem.

A list of public relays is available at https://relays.syncthing.net/, These are not provided by the Syncthing team.

Sorry if you needed that information.

⁴

Though this wouldn't count as a proper backup.

⁵

https://docs.syncthing.net/users/versioning.html

Simple Restic Backups on Nixos

imran@imranmustafa.net (Imran Mustafa) — Sat, 16 Nov 2024 16:32:42 -0500

When it comes to all the things that nix lets you do, defining complex services deterministically in text, is probably the most powerful. For example I have nix manage all of my system backup jobs. Which could be handled with a shell script, but can be so much more extensible when configured entirely within nix. I hope showing off how I manage this can help you further understand what you can do with nix, especially with configuring services.

This post will go over how I use nix to manage restic, which is my preferred backup system. Nix supports other programs, which you can lookup at https://search.nixos.org/options or https://nixos.org/manual/nixos/stable/options to see there configuration options.

The Important Config Options

There are (at time of writing) 22 configuration options for the restic backup service in nix. Though you don't need to set all of them to get restic working. I'll go over the most important ones that need to be set and what they mean.

what's `<name>`

The restic service in nix is setup to have separate configuration options for each backup job that you set. <name> is the placeholder that the documentation uses, and can be changed to whatever you think best describes that backup. For example.

services.restic.backups.my-remote-backup = {
 thing = True;
}; # Settings aren't shared between each backup
services.restic.backups.my-other-remote-backup = {
 thing = False;
}; They can be set diffrently
services.restic.backups.my-local-backup = {
 other-things = 1;
};

Each of these would be a separate systemd service with its own wrapper and timer¹. This is quite handy when managing multiple backups which each need to be configured differently.

`paths` and `exclude`

paths is a simple list of strings that represent the paths that you want restic to backup. While exclude will tell restic what you don't want included in the final backup. Useful for caches, a steam library and anything you wouldn't want in the final snapshot.

services.restic.backups.<name>.paths = [
 "/home/" # backup all user home directories
];
services.restic.backups.<name>.exclude = [
 "/home/*/.cache"
 "/home/*/somereallybigfile/youdon'tneed/backedup"
];

`initialize`

This is a boolean that when set to true will allow the restic service to initialize repositories. As by default the backup job will fail if it does not find a preexisting repository at the set URL, which will require you to setup each repository manually before this service will work.

I like letting restic deal with initialization on its own, and I would recommend this to you as well.

services.restic.backups.<name>.initialize = True;

`pruneOpts`

This one doesn't absolutely need to be set but I recommend some pruning of your repositories just to clean up older and less important snapshots. It's simple to define as well, just pass each prune options as a string in a list. The example below is just what I use, you are free to change things around to suit your needs.

services.restic.backups.<name>.pruneOpts = [
 "--keep-daily 7"
 "--keep-weekly 5"
 "--keep-monthly 12"
 "--keep-yearly 10"
];

`timerConfig`

Having your backups occur regularly is extremely important, and timerconfig is what defines the systemd unit that triggers the backup you defined. The options are the standard system.timer(5) that systemd uses. So setting a regular backup is as simple as defining OnCalendar to "daily"/"weekly" or whatever else you prefer. Persistent Should also be set to true so your machine can catch up on backups That it's missed while powered off.

Important note, if the computer uses wifi to connect to the internet (e.g laptop). The backup will fail at boot due to the wifi not being connected at that point. It'll work normally after it connects, or if it had Ethernet at boot. The simplest workaround I've found is setting OnBootSec to a minute or 2 so I can log in. After which the wifi connection will be working, and the backup will occur just fine.

services.restic.backups.<name>.timerConfig = {
 # OnBootSec = "3m"; # uncomment this this line if your on wifi
 OnCalendar = "daily";
 Persistent = true;
};

`passwordFile`

If you encrypt your backup (which you should) this is where you would tell nix where the password would be stored. I would recommend using sops-nix when it comes to managing secrets. Though you could also just hardcore a path and place a file there manually if you don't want to setup sops.

services.restic.backups.<name>.passwordFile = config.sops.secrets.restic-passphrase.path;
# or
services.restic.backups.<name>.passwordFile = "/home/user/.restic-password.txt";

`repoFile` / `environmentFile`

The repoFile defines the URL² that the repository is located at. While the environmentFile defines the environment variables³ needed to access the repo. These would be the best way to define repo locations, though it is possible to use rcloneConfigFile if you would prefer to use that back end.

services.restic.backups.<name>.environmentFile = config.sops.templates."environmentFile".path;
services.restic.backups.<name>.repositoryFile = config.sops.templates."repositoryFile".path;

again you could just make these files and then hard code the paths, but again sops-nix lets you create files that contain your secrets with templates. So I really would recommend it or a similar system when encoding secrets in a git repo.

# Example sops.templates
sops.templates."repositoryfile".content = ''
 s3:s3.example.com/${config.sops.placeholder."bucket"}
'';

sops.templates."accessfile".content = ''
 AWS_ACCESS_KEY_ID="${config.sops.placeholder."keyid"}"
 AWS_SECRET_ACCESS_KEY="${config.sops.placeholder."accesskey"}"
'';

My Setup

This is my personal setup from my own flake, which is meant to be imported into your system config after which you enable the option (e.g restic.enable = true). You can use this as a base for your own backup setting, or a template to what you will implement in your own system config.

# SPDX-FileCopyrightText: 2024 Imran Mustafa <imran@imranmustafa.net>
#
# SPDX-License-Identifier: GPL-3.0-or-later
{
 pkgs,
 lib,
 config,
 ... # these are the funciton package imports
}: {
 options = {
 restic.enable = lib.mkEnableOption "restic"; # making this easy to toggle with an option
 };
 config = lib.mkIf config.restic.enable {
 services.restic = {
 backups = let
 initialize = true;
 exclude = [
 "/home/*/.cache"
 ];
 paths = [
 "/home"
 ];
 checkOpts = [
 "--with-cache" # just to make checks faster
 ];
 extraBackupArgs = [
 ];
 extraOptions = [
 ];
 passwordFile = config.sops.secrets.restic-passphrase.path;
 pruneOpts = [
 "--keep-daily 7"
 "--keep-weekly 5"
 "--keep-monthly 12"
 "--keep-yearly 10"
 ];
 timerConfig = {
 OnBootSec = "3m";
 OnCalendar = "daily";
 Persistent = true;
 };
 in {
 backup = {
 inherit initialize exclude paths timerConfig checkOpts extraBackupArgs extraOptions passwordFile pruneOpts;
 # using inherit lets you share common options between backups and make everything cleaner

 environmentFile = config.sops.templates."environmentFile".path;
 repositoryFile = config.sops.templates."repositoryFile".path;
 };
 };
 };
 };
}

One thing that you might not get is the let statement that comes after backups . It is simply there to define common options that I would normally want all my backups to share. This makes it easy to share variables between multiple backups without having to redefine the same values for each. For example if I wanted to set up another backup job to another location I could just define this.

other = {
 inherit initialize exclude paths timerConfig checkOpts extraBackupArgs extraOptions passwordFile pruneOpts;

 environmentFile = config.sops.templates."other-environmentFile".path;
 repositoryFile = config.sops.templates."other-repositoryFile".path;
};

Another neat thing that nix does is it creates a wrapper for each of the backups you setup (I.e restic-<name>) that already have the environment values set. Making it simple to interact with the repos.

This should be enough to get you going on the path to writing your own backup service for your Nixos systems. As well as showing off the ways that nix can be more extensible while being simpler to implement then more conventional methods of implementing a automated backup.

If set.

URL = scheme ":" ["//" authority] path ["?" query] ["#" fragment]

Formatted in accordance with systemd.exec(5)

Distrobox Is Why We Can Have Nice Things

imran@imranmustafa.net (Imran Mustafa) — Mon, 05 Aug 2024 00:00:00 +0000

In my last blog post I went over the best ways to get Nix working on Debian, so you could get tons of new packages on the system in a stable way. Not even a month later I found out about Distrobox which is a tool based around containerization, allowing you to bring any package manager and package repository to your distro of choice.

Is Distrobox Right For You?

Distrobox is essentially a wrapper around a container engine. That creates lightweight and highly transparent containers, bringing the user land of any containerized Linux OS to your current system. This can do lots of great things especially with development work, but another great use is an expansion to what package managers you can use. This becomes even easier with Distrobox's ability to export binaries out of the containers and into your regular Linux system. Making it even easier to install and manage programs not naively available through your distro.

Setup

Installing and setting up Distrobox is a breeze on most systems, as the only requirement besides Distrobox itself is a container engine. Specifically Podman, Docker, or Lilipod. I recommend Podman, but any of these are fine. Installing a container engine on most distros is a straight forward process, and better covered in other resources. You should look at both your distros documentation and packages along with the official instructions of your desired engine. I myself used nix to get everything onto my system.

Engine	Documentation
Podman	https://podman.io/docs/installation
Docker	https://docs.docker.com/engine/install/
Lilipod	https://github.com/89luca89/lilipod?tab=readme-ov-file#getting-started

After you've confirmed you container engine is working a-okay, Distrobox is already packaged in these distributions (look under repositories for your distro). This should have you covered, but in the odd case you can't there are also alternative methods documented.

Basic Usage

Distrobox has a pretty simple CLI and good documentation as well, but if you want the basics form me, they are based around the distrobox create and distrobox export. The first allows you to make a box while also configuring what base image to use (--image), hooks to execute (--init-hooks or --pre-init-hooks) as well as other options. You can also use .ini files and distrobox assemble to declarative configure boxes. Export is what allows you to push binaries out of the container and into the host OS. Which makes expanding the packages you have access to trivially easy. The rest of the commands concern managing your boxes. There is also a good GUI you can use if you want to skip over a lot of the command line stuff.

Getting the AUR Working on Debian

Warning: AUR packages are user-produced content. These PKGBUILDs are completely unofficial and have not been thoroughly vetted. Any use of the provided files is at your own risk. – Arch Wiki

Now that you understand some of the basics of Distrobox, I want to show something fun that you can do with all of this. Which is getting the AUR working on Debian. It was honestly a lot easier then I thought it was going to be. First use this config as the base for where you'll put all the AUR packages.

[aur]
additional_packages="neofetch"
image=quay.io/toolbx/arch-toolbox:latest
init=true
nvidia=false # nvidia seems to not work with the arch image
pull=true
root=false
replace=false
start_now=true

After using distrobox assemble you'll end up with a basic arch system and you can already get regular arch packages, and AUR packages using git clone and makepkg. Though I like using a helper program to make it easier to manage the system. yay is a very popular option which can be installed quite simply with the below commands while in the aur box.

git clone https://aur.archlinux.org/yay.git && \
cd yay && \
makepkg -si

Which you can use to install packages from the AUR or regular repositories.

yay -S [PACKAGENAME]

Also don't forget to export the binaries out of the box if you want the base OS to have access to them.

distrobox export --app [PACKAGENAME]

Nix on Debian

imran@imranmustafa.net (Imran Mustafa) — Sat, 04 May 2024 14:10:10 -0400

A guide on the best way to use the Nix package manager on Debian.

Nix?

If you haven’t heard, NixOS is a declarative and reproducible Linux distro that prides itself on extreme stability while also maintaining close to bleeding edge packaging. Its got a whole ecosystem of components capable of doing some really amazing stuff. While all of this is great, one of the coolest parts of Nix is the over 100,000 packages that it has available through Nixpkgs. The largest by any degree.

The best part, the package manager can be used on unrelated distros. Allowing almost any Linux system access to Nixpkgs trivially.

Why Debian?

Cause I ❤️ Debian.

The Setup

For this guide/tutorial I’m going to be using a Debian 12 (bookworm) system to install Nix onto, though anything since 11 should work fine. If you’re using a Debian based system all these steps should also work.

Installation

There are two main ways to install Nix. First you could use the native Debian package, the second would be the official install script. I’ll be going over the native package since I think that’s the best way to get Nix on Debian.

Debian Nix

Debian actually packages Nix (since bullseye) in it’s stable branch making it easy to install the binaries though regular old apt. Though I do recommend using the nix-setup-systemd package, which does a lot of the heavy lifting automatically.

sudo apt install nix-setup-systemd

Now that Nix is on your system you’ve got to add yourself to the nix-users group to be able to interact with the package manager.

sudo usermod -aG nix-users $(whoami)

After you’ve added yourself to nix-users make sure to login again for the changes to take affect (sudo su $(whoami)). Then you have to add a channel that Nix will pull its packages from. The easiest one to use is nixpkgs-unstable.

nix-channel --add https://nixos.org/channels/nixpkgs-unstable nixpkgs && \
nix-channel --update

Finally add ~/.nix-profile/bin to the PATH, and add ~/.nix-profile/share to XDG_DATA_DIRS if you want your desktop environment to be able to find anything that you install. I recommend doing this in your ~/.profile, but ~/.bashrc or ~/.zshrc also work. Below is what I use to make sure PATH and XDG_DATA_DIRS are set on my system.

### set PATH so it includes user's nix bin if it exists
if [ -d "$HOME/.nix-profile/bin" ] ; then
 PATH="$HOME/.nix-profile/bin:$PATH"
fi

### set XDG_DATA_DIR so it includes user's nix share if it exists
if [ -d "$HOME/.nix-profile/share" ] ; then
 XDG_DATA_DIRS="$HOME/.nix-profile/share:$XDG_DATA_DIRS"
fi

After all of that you can pretty much install anything from Nixpkgs.

Further Configuration

Nix does have extra features and config options that are not enabled by default. The most popular ones to change are allowing non-free packages, and new CLI along with flakes.

non-free packages

Nix does not allow you to install the non-free packages from its archive unless you explicitly tell it to. There are different ways to do this depending on whether you want it temporally, or allowing non-free by default. adding { allowUnfree = true; } to you’re Nixpkg config (~/.config/nixpkgs/config.nix) is the simplest way to enable non-free packages. Though if you only need it for a temporary shell or a build just export NIXPKGS_ALLOW_UNFREE=1 when you need to use non-free software.

experimental features

Nix have some features that are still in the works which is why they are not on by default. Nix will check ~/.config/nix/nix.conf for which features you’ve enabled, and you probably just want nix-command and flakes to start off with.

experimental-features = nix-command flakes

Both ~/.config/nixpkgs/config.nix and ~/.config/nix/nix.conf may not be created by default. If that is the case, create the appropriate directory and files.

Basic usage

Now that you have a working Nix install, you can use it to easily and safely install tens of thousands of new packages onto your machine. For installing a package just find it on https://search.nixos.org/packages which will show you the package name and some commands to install, though they generally look like this.

nix-env -iA nixpkgs.PACKAGENAME

To uninstall packages just use nix-env -e

nix-env -e PACKAGENAME

Updating

First Nix needs to update the channel(s) that you’ve added with nix-channel --update, after which you can call nix-env -u to update everything, or nix-env -u PACKAGENAME to update a specific package.

nix-channel --update && nix-env -u

I also recommend that you use nix-collect-garbage when you update, as Nix keeps each generation of packages that you’ve installed/updated/uninstalled, so there is always a working version of them to rollback to. This eats up a lot of space, especially if you make a lot of changes to the system in quick succession.

I usually run something like this when I update my packages.

nix-channel --update && nix-env -u && nix-collect-garbage -d

Broken Things

While Nix will add tonnes of stable packages to you system with ease, there is one downside to this all. GUI applications are more of a crap shoot of if they’ll work, while anything with a CLI has worked 100% of the time I’ve tried. This is something that I’ve still working on, so expect an update when I find out how to fix this. In the mean time I recommend using flatpak as that’s how I usually get GUI apps.

TL-DR

Run this to install.

sudo apt install -y nix-setup-systemd && \
sudo usermod -aG nix-users $(whoami) && \
newgrp nix-users

Then run this.

nix-channel --add https://nixos.org/channels/nixpkgs-unstable nixpkgs && \
nix-channel --update && \
newgrp -

Add ~/.nix-profile/bin to your PATH and ~/.nix-profile/share to XDG_DATA_DIRS, use nix-env -iA nixpkgs.PACKAGENAME to install stuff that you find on https://search.nixos.org/packages.

Home on I.M Blogging

Using Reuse

Installation

Usage

Footnotes

Simplifying Syncthing With Nix

The Issue

With Nix

Adding non-nix hosts

Manual management

Other Config Options

services.syncthing.settings.options.urAccepted

services.syncthing.settings.options.relaysEnabled

services.syncthing.settings.folders.<name>.versioning

Basic Template

Footnotes

Simple Restic Backups on Nixos

The Important Config Options

what's <name>

paths and exclude

initialize

pruneOpts

timerConfig

passwordFile

repoFile / environmentFile

My Setup

Distrobox Is Why We Can Have Nice Things

Is Distrobox Right For You?

Setup

Basic Usage

Getting the AUR Working on Debian

Nix on Debian

Nix?

Why Debian?

The Setup

Installation

Debian Nix

Further Configuration

non-free packages

experimental features

Basic usage

Updating

Broken Things

TL-DR

`services.syncthing.settings.options.urAccepted`

`services.syncthing.settings.options.relaysEnabled`

`services.syncthing.settings.folders.<name>.versioning`

what's `<name>`

`paths` and `exclude`

`initialize`

`pruneOpts`

`timerConfig`

`passwordFile`

`repoFile` / `environmentFile`