Recently I spent a weekend setting up neovim for Rust development, at first basically as a fallback solution to VSCodium and IntelliJ, because these tools became really sluggish on my rather weak laptop, especially in low battery conditions. IntelliJ also likes a good deal of memory, which is a scarce reasource on my laptop, and eats a lot of CPU and thus drains the battery a lot.
But after a while I became really impressed how far neovim got since I last looked at it seriously. Treesitter highlighting, builtin LSP support, Lua really make neovim a modern editor, and enabled a bunch of awesome plugins—I particularly enjoy Telescope, whichkey and lightspeed.
What started as a simple fallback solution quickly became a passion and my primary editor, to a point where I’ve already uninstalled VSCodium.
I don’t think I can drop IntelliJ soon, as it’s just too powerful when it comes to Scala support, but I’ll sure try metals soon.
This is how the result looks like now (left side inside wezterm, right side Neovide):
Incidentally, I also dropped Gnome Terminal for good and finally embraced Wezterm which is a really great terminal emulator. I’m a bit surprised that alacritty is so much more popular apparently even though it’s got so much less features (no images, no real hyperlinks, no splits, no tabs, no ligatures 🙈); I can really recommend wezterm for all serious terminal needs.
This article describes my Arch Linux setup which combines Secure Boot with custom keys, TPM2-based full disk encryption and systemd-homed into a fully encrypted and authenticated, yet convenient Linux system.
Historically cryptsetup and LUKS only supported good old passwords; however recent systemd versions extend cryptsetup with additional key types such as FIDO tokens and TPM devices.
I like the idea of encrypting the rootfs with a TPM2 key; it allows booting without ugly LUKS password prompts but still it keeps data encrypted at rest, and when combined with secure boot also still protects the running system against unauthorized access.
Secure boot will prevent others from placing custom kernels on the unencrypted EFI system partition and booting these, or changing the kernel cmdline, in order to obtain root access to the unlocked rootfs. LUKS encryption with a TPM-based key bound to secure boot state protects the data if someone removes the hard disk and attempts to access it offline, or tries to disable secure boot in order to boot a custom kernel.
A node hosts a Gitlab runner and a small k3s cluster which runs a few services as regular kubernetes deployments. A CI job pinned to that runner builds Docker images for these services services, updates the image of the corresponding deployments, and starts a few system and acceptance tests. The CI job does not push those images to the in-house registry; to avoid polluting the registry with hundreds of images it just builds locally.
Each test then scales each deployment to zero replicas to effectively stop all services, clears the system’s underlying database, and scales the service deployments back to a small number of replicas sufficient for testing.
The whole thing runs fine until one day the replicas randomly fail to start.