The problem this actually solves On a normal distro, if a network mount goes stale … the connection dropped, the server bounced, whatever … the fix is usually sudo umount then sudo mount -a, reading straight from /etc/fstab. Simple, because fstab is a plain text file you can just point tools at. NixOS doesn’t work that way. fileSystems entries in configuration.nix get compiled into individual systemd .mount units automatically at build time. There’s no /etc/fstab to edit or run mount -a against in the traditional sense … the mounts exist purely as generated systemd units with names like mnt-t620\x2drelationships.mount. ...

Why I bothered making this an alias at all Btrfs needs a bit more active maintenance than ext4 or XFS … it’s got its own checksumming, its own way of allocating chunks across a volume, and if you never touch it, things can quietly degrade in ways you won’t notice until something actually breaks. I got tired of typing three separate commands in the right order every time, so I turned it into one alias that does all three, in sequence, with actual visible output so I know what stage it’s on. ...

The hardware I built this on an HP T620 … a thin client, not a real server. Dual-core AMD GX-217GA SoC, the kind of chip that used to sit in front of a cash register or a hospital terminal, not something anyone would call fast. No AES-NI either, which matters more than you’d think once you’re running encrypted traffic through it all day. If you’ve got something like this sitting in a drawer, it’s genuinely enough to run a small personal NAS. Don’t expect it to be quick. Expect it to just work, reliably, once it’s set up right. ...

Why negativo17 over RPM Fusion RPM Fusion’s NVIDIA packages work, but negativo17’s repo tends to track driver releases faster and packages them with fewer of the DKMS-related headaches that show up after a kernel update. For a desktop where I don’t want to babysit whether the driver rebuilt correctly after every dnf upgrade, that reliability matters more than which repo is more “official.” Adding the repos Two separate repos … one for the driver itself, one for the multimedia codec stack that pairs with it: ...

The actual bug WPS Office’s flatpak ships a background helper called wpscloudsvr that reliably segfaults … null-pointer deref inside libqingbangong.so, r15=0x0, the works. Not a config issue, not something I broke, just a genuinely broken binary shipped in the package. It doesn’t crash the whole app, just spams crash reports and burns CPU respawning itself. The fix nobody’s going to like, but it works You can’t easily patch a binary inside a flatpak sandbox, and there’s no config flag to just disable this one helper. So: bind-mount /dev/null directly over the broken executable. The file still “exists” as far as the OS is concerned, it just contains nothing … attempting to execute it does nothing, silently, forever. ...

The advice everyone repeats without checking it Every “speed up your Linux install” guide tells you to slap noatime on every mount in /etc/fstab and call it a day. It’s not wrong exactly, but it’s not universally the win people treat it as either, and blindly copying it cost me nothing to try but also gave me nothing to gain on one of my own filesystems, for a reason worth actually understanding. ...

The same sysctl file, three different machines I run the same core network tuning across the NAS (Fedora Server), the desktop (NixOS), and a laptop or two … not because every machine has the same workload, but because the underlying kernel-level wins are the same regardless of what’s actually running on top. The differences show up in what else gets layered on, not in the base config. BBR + CAKE, together The single biggest win of the lot. tcp_congestion_control defaults to cubic on most distros, which is fine but not great, especially over Tailscale/WireGuard tunnels where the effective path characteristics don’t always match what cubic assumes. bbr measures actual bandwidth and round-trip time instead of just reacting to packet loss, and pairs specifically well with cake as the queuing discipline … cake handles bufferbloat and fair queuing far better than the kernel’s default fq or pfifo_fast. ...

Why this even matters Every block device on Linux has an I/O scheduler sitting between your applications and the actual disk, deciding the order requests get sent in. Get the wrong one for your workload and you’re leaving real performance on the table, or worse, adding latency you didn’t need to. Check what’s currently active and what else is available: cat /sys/block/sda/queue/scheduler The one in brackets is active. On modern kernels you’ll usually see some combination of none, mq-deadline, kyber, and bfq listed. ...

The idea was simple All I wanted was for my T620 to mount the QNAP shares, retire the QNAP as the “brain,” and have the T620 do everything … Samba, SFTP, the lot … while the QNAP just sat there as dumb storage in the background. Simple networking. I have never been more wrong about something taking one evening. Boot failure #1: the NFS ordering cycle First attempt, I set up NFS mounts from the QNAP onto the T620, then re-exported those same paths back out via NFS so other machines could reach them through the T620. Seemed logical … one machine, one point of access. ...

Two boxes, two philosophies I run Fedora Server on my T620 NAS and NixOS with KDE Plasma on my daily driver desktop. Not a lab experiment, not “let me try this for a week and write a hot take” … these are both machines I actually depend on every day, which means whatever broke, I had to actually fix, not just note down and move on. Fedora: familiar, fast to fix, one config file at a time Fedora Server feels like driving a car you already know how to drive. Something breaks, you find the config file, you edit it, you restart the service. dnf, systemctl, /etc/. No new mental model required. ...