My primary laptop.
athena is a 2023 16" MacBook Pro with an M2 Max. It used to be a work laptop, but I was allowed to keep it when I left that job. After it was wiped, I installed NixOS on it almost immediately, using the nixos-apple-silicon project.
I lucked out here, as the M2 is currently the most powerful Apple Silicon processor that has decent Linux support. It's a pretty beastly machine aside from the 32GB of RAM, which feels a bit anemic when trying to do big Nix builds.
This is probably the workstation I use the most often these days.
{
config,
lib,
inputs,
pkgs,
...
}:
{
imports = [
./hardware-configuration.nix
"${inputs.nixos-apple-silicon}/apple-silicon-support"
];
networking.hostName = "athena";
services.openssh.enable = true;
system.stateVersion = "25.05";
<<nixos-config>>
}boot.loader.systemd-boot.enable = true;
My systems use systemd-boot wherever possible, as it's a simple reliable bootloader for UEFI. athena is my only workstation that can't use Lanzaboote for SecureBoot, because it lacks a traditional TPM. Instead, it has Apple's Secure Enclave, which doesn't currently have Linux support.
mjm.desktop.enable = true; mjm.desktop.niri.enable = true;
Since it's a workstation, it uses my own desktop module with all of the desktop configuration. I'm using niri on all of my workstations.
services.kmscon.config.font-dpi = 192;
athena has a pretty high resolution display, so I've configured the console DPI to be a bit higher than default so it's actually readable.
environment.systemPackages = [ pkgs.tuxvdmtool ];
tuxvdmtool is a special tool from Asahi Linux. I think its main purpose is getting a serial console to an Apple Silicon device, but that's not why I have it installed. There's a bug around USB devices and suspend on Asahi Linux, where the devices don't reconnect when waking. This is annoying for the YubiKey that I always have connected to this laptop for SSH. With this tool, I can run "run0 tuxvdmtool disconnect" and any USB devices will reconnect. That's annoying, but less annoying than physically pulling out the very small YubiKey.
nix.settings.max-jobs = 4;
By default, Nix will run as many concurrent builds as you have CPU cores. athena has 12 cores, but only 32GiB of RAM. Without extra configuration, that makes it very easy for a Nix build to exhaust RAM by running too many jobs at once, so I've configured it to only run four builds at a time.
Even if I had more RAM, it would probably still be a good idea to limit concurrent Nix builds more than the default. Each build can potentially use all of the cores in the system (unless you configure that limit to be lower), so with the default settings you can end up with pretty high resource contention. You're generally better off reducing these a bit, so that you have some oversubscription (in case you have builds that don't use many resources) but not nearly as much as there is by default.
hardware.asahi.extractPeripheralFirmware = config.hardware.asahi.peripheralFirmwareDirectory != null;
Asahi Linux makes use of some firmware blobs that it extracts on the macOS side when installing and stores on the EFI partition. These then need to be gathered up and extracted and exposed to Linux. These blobs are proprietary, so legally they needed to be loaded off the actual system they were pulled from: they can't be redistributed from somewhere else.
This poses a small hiccup when building this system in CI to check for build errors. That firmware directory on the ESP is not available, so extracting the firmware is not possible. To workaround that, I just disable the extraction when the directory can't be found. When building and applying locally, the extraction will happen as it needs to, but otherwise, it can still build the rest of the system without issue.
nixpkgs.config.permittedInsecurePackages = [ "electron-39.8.10" ];
My workstations install Bitwarden Desktop to use with my Vaultwarden install. Unfortunately, Bitwarden Desktop is using an end-of-life version of Electron, so I have to allow that insecure package. This nixpkgs config key doesn't merge well across multiple modules, so I keep a single list at the host level instead.
specialisation.plasma.configuration = {
mjm.desktop.niri.enable = lib.mkForce false;
mjm.desktop.plasma.enable = true;
programs.ssh.startAgent = true;
};I keep around a specialisation of the system that uses Plasma 6 instead of niri. The SSH agent option is because the Niri setup uses gnome-keyring, which includes an SSH agent as part of it. Plasma doesn't do something like this by default, so I need to enable starting the normal SSH agent.
{
<<home-config>>
}athena has a few small customizations to my default home-manager config.
mjm.homelab.enableYubiKey = true;
I have some special SSH configuration for logging into my home servers, and by default that expects to use a key from the TPM via ssh-tpm-agent. Since athena doesn't have a TPM, I use a key on a YubiKey instead. This option enables that change in configuration.
programs.ssh.settings."*" = {
AddKeysToAgent = "yes";
ControlMaster = "auto";
ControlPersist = "5m";
ControlPath = "\${XDG_RUNTIME_DIR}/ssh-%C.sock";
};This SSH configuration largely exists to mask some of inconvenience of using a YubiKey for SSH instead of a TPM-based key. Adding the key to the agent prevents needing to enter a PIN every time, but a touch of the key is still required on every connection. I'm quite prone to just sitting there waiting for SSH to connect without realizing that the YubiKey is flashing waiting for a touch. So persisting connections and reusing them can help alleviate that a bit, at least when making multiple connections to the same host.
text/gemini;lang=en-USThis content has been proxied by September (UNKNO).