Optioned Linux for a dev environment
git clone --no-checkout https://github.com/klarkc/dotfiles
mv dotfiles/.git ~
rm -r dotfiles⚠ Next command will replace current home files with repo files (backup first!)
git checkout main- Lemurs Window Manager
- Pipewire Sound Server
- Alacritty + Tmux + vim
- Vim Language Server Protocol + Automatic Servers
- Nord Theme
- Fira Code with ligatures support
- LSD replaces
lswith the modernlsdalternative - CapsLock as Escape
- Using satty with scrot for annotated screenshots
Each machine has specific configurations and enabled features so I'm splitting it between different branches.
ssdinarch: my personal laptopsol098(default): work machine
l:ls -lll:ls -lalt:ls -lt
- Maintenance systemd scripts
- Sunshine game streaming server (to play games on my TV)
- Handlr manage default apps
- AI models with ollama
- AI Agents with crush, codex and lumen
- Fusion
Below are the supported distro setups
pacman -Syu yay
# TODO re-enable alacritty-ligature-git
yay -Syu openssh pwvucontrol pipewire pipewire-audio pipewire-pulse pipewire-alsa git git-lfs gvim alacritty qt5-styleplugins nix ttf-fira-code noto-fonts-emoji lsd dconf-editor picom xorg-xmodmap notification-daemon lemurs haskell-language-server xmonad xmonad-contrib xorg-xsetroot feh the_silver_searcher satty scrot wget xorg-server taffybar libappindicator-gtk3 blueman dmenu sword
sudo chmod +s .local/bin/pacman-*
systemctl enable --now nix-daemon.socket
systemctl enable --now lemursBelow dependencies are not mandatory but highly recommended
yay -Syu ffmpeg unzip htopBelow dependencies are not mandatory (see Optional Features)
yay -Syu snapper pacreport yay-cache-cleanup-hook sunshine bat git-delta ripgrep handlr ollama-cuda discord enpass-bin crush btduLumen
yay -Syu lumen
yay --asdeps fzf mdcatYazi as file manager with optional deps
yay -Syu yazi
yay -S --asdeps 7zip jq poppler fd fzf zoxide resvg imagemagick xclip xsel chafanix profile install .
make
systemctl --user daemon-reloadFusion's systemd service uses ~/.fusion/ssh_config for Git SSH operations. Keep that file generated when OpenSSH configuration changes so sandboxed Fusion can read a stable SSH config.
Install the pacman hook so this generated SSH config is refreshed after openssh or systemd package updates:
sudo install -Dm644 .local/share/pacman/hooks/fusion-ssh-config.hook /etc/pacman.d/hooks/fusion-ssh-config.hookBelow steps are not mandatory (see Optional Features)
systemctl --user enable home-cleanup.timer
systemctl --user enable nix-cleanup.timer
systemctl --user enable pacreport.timer
systemctl --user enable --now sunshine.service
systemctl --user enable --now fusion-backup.timerThe vLLM/Fusion workflow is target-based. Only one vLLM model target should run at a time:
vllm-qwen3.6-35B-a3b.targetstartsvllm@qwen3.6-35B-a3b.servicevllm-qwen3.6-27B.targetstartsvllm@qwen3.6-27B.service
Use vllm-config to choose the active local model. It stops Fusion and all vLLM units, disables the non-selected target, enables the selected target for future user-session starts, starts the selected target, and follows the relevant journal logs until vllm@...service and fusion.service are active.
The target starts only the selected vLLM service. The vLLM service then patches local Crush/Fusion/Pi defaults, starts the model, waits for GET /v1/models to respond with the selected served model, and only then restarts Fusion so it rereads changed config files. Fusion is intentionally not pulled directly by the target; readiness is owned by vllm@...service.
Pick the model interactively:
vllm-configOr switch directly:
vllm-config qwen3.6-35B-a3b
vllm-config qwen3.6-27BVerify which target will start with the user systemd session:
systemctl --user is-enabled vllm-qwen3.6-35B-a3b.target
systemctl --user is-enabled vllm-qwen3.6-27B.targetThe selected target should be enabled; the other target should be disabled.
User systemd services start when the user manager starts. To start the selected vLLM target after reboot before an interactive login, enable lingering once:
loginctl show-user "$USER" -p Linger
sudo loginctl enable-linger "$USER"After lingering is enabled, re-check:
loginctl show-user "$USER" -p LingerExpected:
Linger=yes
Watch startup progress:
journalctl --user-unit vllm-qwen3.6-35B-a3b.target -f
journalctl --user-unit vllm@qwen3.6-35B-a3b.service -f
journalctl --user-unit fusion.service -fFor the 27B target, replace 35B-a3b with 27B in the commands above.
Both model configurations use at least 48k context and 2 parallel sequences. The current default local winner is qwen3.6-35B-a3b; qwen3.6-27B is kept available as an experimental/secondary target.
Run the benchmark wrapper instead of invoking vLLM's Python module directly:
vllm-benchmarkvllm-benchmark reads the selected model from the latest ~/.cache/vllm-*/benchmark.env, uses the pinned Nix vLLM runtime, caps benchmark concurrency at 2, and runs small, medium, and long-context random request cases. It writes logs, summaries, systemd status, vLLM/Fusion journals, runtime metadata, process state, and GPU state to a timestamped tarball under:
~/.cache/vllm-benchmarks/The default cases are:
Small: prompts=4, input=1024, output=32, concurrency=2
Medium: prompts=4, input=4096, output=64, concurrency=2
Long: prompts=2, input=48000, output=64, concurrency=2
Any case can be overridden from the environment:
SMALL_PROMPTS=8 SMALL_OUTPUT_LEN=64 LONG_PROMPTS=1 vllm-benchmarkFusion is packaged by .config/nix/fusion-npm.nix and launched by the sandboxed user service. The service runs the long-lived Fusion dashboard/server process directly under systemd; it no longer owns a tmux session.
The Nix package preserves the npm global-install layout enough for Fusion to detect its installed package, but the package itself lives in the immutable Nix store. Do not use Fusion's self-update flow for this setup. Upgrade Fusion by bumping the version and fixed-output hash in .config/nix/fusion-npm.nix, then restart fusion.service or select a vLLM target with vllm-config so Fusion is restarted after model readiness.
Fusion 0.29 exposes fn dashboard/fusion dashboard as the command that starts the dashboard/server. There is currently no known CLI command that attaches a terminal UI to an already-running dashboard instance. Use the browser for the running dashboard:
xdg-open http://127.0.0.1:4040fusion-attach is intentionally a log observer for now:
fusion-attachIt starts fusion.service if needed, then tails journalctl --user-unit fusion.service. Do not make fusion-attach start another fusion dashboard; that creates duplicate dashboard instances, port conflicts on 4040, and Fusion peer/service-name collisions.
Trail tip for future agents: when upstream lands a real "connect to existing dashboard" or terminal UI attach command, replace fusion-attach's journal tail with that command. Keep fusion.service as the single owner of the long-running dashboard/server process.
Service logs are available with:
journalctl --user -u fusion.service -fFusion project state from ~/Sources/Fusion/*/*/.fusion except .fusion/backups, and git worktrees from ~/Sources/Fusion/*/*/.worktrees, are snapshotted daily at 06:00 to ~/.fusion-backup/snapshots/<timestamp>/projects. ~/.fusion-backup/latest points to the newest snapshot. Snapshots use hardlinks to the previous snapshot when possible, so deleted worktrees remain recoverable from older snapshots without duplicating unchanged files. Snapshots are rotated after 7 days.
Fusion-generated .fusion/backups directories are kept outside snapshots and mirrored separately to ~/.fusion-backup/mirrors/projects with rsync --ignore-existing, so backup files are not overwritten or removed by later runs.
To customize a .dotfile you can write a corresponding .dotfile_override.
See `COMMIT_GUIDELINES.md.