![\"An](\"media/huge-on-the-tray.jpeg\")
It's not like the world needs yet another WireGuard tutorial,\nbut I thought I'd write one since one of the top SEO-ranked ones I stumbled upon was pretty low quality,\nwith several obvious errors and omissions.
\nIn this post, I'll focus on how you can set up a VPN tunnel\nin the sense that such things were used before shady companies hijacked the term.\nIt's just a way to tunnel traffic between networks.\nFor example, to connect non-internet-facing servers behind a firewall\nto a public host that firewalls and selectively routes traffic over the tunnel.
\nI'll assume a pair of FreeBSD servers for the rest of the post,\none that's presumably more accessible (the "server"),\nand a client which is not necessarily routable over the internet.
\nWe'll start with the server setup.\nThis is where your client(s) will connect.\nAt a high level, we'll generate a keypair for the server,\na keypair for the client,\nand generate configuration files for both.\nAnd finally we'll do some basic firewall configuration.
\nThe following can be run,\neither in a script or line-by-line in a POSIX shell as root.
\n# Set this to your server's public IP\nSERVER_PUBLIC_IP="192.0.2.42"\n\n# We'll be setting up some config files here that we only want to be readable by root.\n# The umask saves us the effort of having to chmod these later.\numask 077\n\n# Wireguard kernel-level support is available in FreeBSD 14+,\n# but this port has a nice service wrapper\npkg install wireguard-tools\n\n# Set up WireGuard config directory\nchmod 770 /usr/local/etc/wireguard\ncd /usr/local/etc/wireguard\n\n# Create a keypair for the server\nSERVER_PRIV_KEY=$(wg genkey)\nSERVER_PUB_KEY=`echo $SERVER_PRIV_KEY | wg pubkey`\n\n# Generate the first section of our WireGuard server config.\n# We'll use 172.16.0.1/24 (no real reason for the choice;\n# it's just somewhat convenient as it doesn't collide with the more common\n# Class A and Class C private networks).\ncat > wg0.conf <<EOF\n[Interface]\nAddress = 172.16.0.1/24\nSaveConfig = true\nListenPort = 51820\nPrivateKey = ${SERVER_PRIV_KEY}\nEOF\n\n# Similarly, we need a client keypair\nCLIENT_PRIV_KEY=$(wg genkey)\nCLIENT_PUB_KEY=`echo $CLIENT_PRIV_KEY | wg pubkey`\n\n# Add peer to the server config.\n# This is what lets your client connect later.\n# The server only stores the client's public key\n# and the private IP that it will connect as.\nCLIENT_IP="172.16.0.2"\ncat >> wg0.conf <<EOF\n# bsdcube\n[Peer]\nPublicKey = ${CLIENT_PUB_KEY}\nAllowedIps = ${CLIENT_IP}/32\nEOF\n\numask 022 # Revert to normal umask\n\n# Enable the wireguard service\nsysrc wireguard_interfaces="wg0"\nsysrc wireguard_enable="YES"\nservice wireguard start\nDon't ditch this shell session yet!\nWe'll come back to the client config later and will need the vars defined above.\nBut first, a brief interlude for packet filtering.
\npf setupWe'll use pf, the robust packet filtering (colloquially "firewall") system\nported from OpenBSD.
I'm using vtnet0 for the external interface,\nsince that's the interface name with my VPS vendor.\nYou may need to change this based on what your main network interface is\n(check ifconfig).
DISCLAIMER: This is not necessarily everything you need to launch a production system.\nI've distilled just the parts that are relevant to a minimal WireGuard setup.\nThat said, here's a minimal /etc/pf.conf.
ext_if = "vtnet0"\nwg_if = "wg0"\n\n# Pass all traffic on the loopback interface\nset skip on lo\n\n# Basic packet cleanup\nscrub in on $ext_if all fragment reassemble\n\n# Allows WireGuard clients to reach the internet.\n# I do not nede this in my config, but noting it here\n# in case your use case is *that* sort of VPN.\n# nat on $ext_if from $wg_if:network to any -> ($ext_if)\n\n# Allow all outbound connections\npass out keep state\n\n# SSH (there's a good chance you need this)\npass in on $ext_if proto tcp from any to ($ext_if) port 22\n\n# Allow inbound WireGuard traffic\npass in on $ext_if proto udp from any to ($ext_if) port 51820\n\n# TODO: Forwarding for the services that YOU need\n# Here's one example demonstrating how you would allow traffic\n# to route directly to one of the WireGuard network IPs (e.g. 172.16.42.1/24 in this example)\n# over port 8080.\n# pass in on $wg_if proto tcp from $wg_if:network to ($wg_if) port 8080\n\n# Allow ICMP\npass in inet proto icmp all\npass in inet6 proto icmp6 all\nNext, we enable the service and start it.\nIf you're already running pf, then at least part of this isn't necessary.
# Allow forwarding of traffic from from WireGuard clients\nsysctl net.inet.ip.forwarding=1\n\n# Enable pf\nsysrc pf_enable="YES"\nservice pf start\nAnd now we come back to the client configuration.\nThe "client" in this case does not necessarily have to be routable over the internet;\nit just needs to be able to connect to the server.\nYou've still got the same shell session with those variables, right?
\ncat <<EOF\n[Interface]\nPrivateKey = ${CLIENT_PRIV_KEY}\nAddress = ${CLIENT_IP}/24\n\n[Peer]\nPublicKey = ${SERVER_PUB_KEY}\nAllowedIPs = 172.16.0.0/24 # Only route private subnet traffic over the tunnel\nEndpoint = ${SERVER_PUBLIC_IP}:51820\nPersistentKeepalive = 30\nEOF\nThat's it; that's the client config.\nRun through the same initial setup steps for adding the wireguard-tools package\nand creating the directory with the right permissions.\nThen put this config in /usr/local/etc/wireguard/wg0.conf.
The client will also need a similar pf configuration,\nbut rather than blanket allowing traffic in over $wg_if,\nyou probably want something a bit more granular.\nFor example, allowing traffic in over a specific port (e.g. 8080).\nI'll leave that as an exercise to the reader based on the specific scenario.
I'm approximately 2 weeks into using emacs as my daily editor and, well, I haven't opened JetBrains since.\nI honestly didn't expect that, but here we are.
\nHere's the list of things I noted in my last post that I said I'd come back to.\nThe list has changed a bit since the last post:
\nSolved:
\nglobal-auto-revert-mode)Haven't bothered to try resolving (infrequently used):
\nThe highlighting one is worth a bit of explanation.\nHere's what I had to do to get it working:
\n;; Highlight mutable variables (like RustRover/JetBrains).\n;; NB: Requires eglot 1.20+\n(defface eglot-semantic-mutable\n '((t :underline t))\n "Face for mutable variables via semantic tokens.")\n\n(with-eval-after-load 'eglot\n (add-to-list 'eglot-semantic-token-modifiers "mutable"))\nApparently this requires a fairly recent version of eglot to work,\nand it isn't necessarily supported by every LSP,\nbut it works for me with rust-analyzer.\nI spent way too much time on this because for some reason running M-x eglot-reconnect\nor M-x eglot and accepting a restart didn't reset the buffer settings or something.\nIf this doesn't work, try killing the buffer and then find the file again.
Here's a similarly categorized list of things that I found over the past week or so.
\nSolved:
\n(setq tab-bar-mode t)! It's great.\nIt's even better than I expected TBH since every tab can contain an arbitrary configuration of buffers.\nThis is a weird way of thinking at first, but it's really nice since stuff doesn't need to follow the traditional bounds\nthat I was used to in IDEs (e.g. a tab can be entirely terminal buffers, or cross "projects" which is useful to me).xref-matches-in-files was SLOW. Turned out to be an issue in my fish configuration (which isn't even my "preferred" shell,\nbut it's still my login shell due to being more supported than nushell, which I use for most things).\nRemoving pyenv fixed that.\nAlso you can set it to use ripgrep with (setq xref-search-program 'ripgrep)C-x p f (mnemonic: project find).consult-eglot package.\nSpecifically, it includes a consult-eglot-symbols command.Not solved yet:
\ndiff-hl package doesn't get the hint when files reload for some reason.I'll also add a quick note that it's (still) surprisingly easy to screw up your own config.\nEmacs as a system is super flexible but that also makes it somewhat fragile.\nEverything is programmable, in a single-threaded, garbage-collected language.
\nOne snag I hit was that after some period, the environment got super slow,\naffecting things like unit test runtimes in terminal buffers,\nand making input noticeably laggy.\nThe issue turned out to be my global-auto-revert-mode config.\nApparently if you do it wrong, it turns into a whole stack of polling operations for every buffer.\nThis was a consequence of Claude suggesting something dumb and me not researching it :P\nThe normal configuration will use filesystem notifications like kqueue or inotify.
I'm pretty happy with the new setup overall.\nObviously some room for tweaks, but it's pretty great overall,\nand I'm really enjoying the tab bar approach for organizing things.\nI'm also frankly shocked at how little CPU I'm using relative to previous norms on my MacBook.
\nNext up I'll probably try (in no particular order):
\nI have been a fan of JetBrains products for over a decade by now,\nand an unapologetic lover of IDEs generally.\nI've used PyCharm since shortly after it launched,\nand over the years I've used IntelliJ IDEA,\nWebStorm, DataGrip, RustRover, and more.\nI literally have the all products pack (and have for many years).
\nI truly believe that a good IDE can be a productivity multiplier.\nYou get refactoring, jump-to-definition, symbol-aware search,\nsaved build/run configurations, a nice and consistent interface\nto otherwise terrible tooling (looking at you CMake and the half dozen Python package managers\nof the last decade and change).
\nBut something has changed over the past few years.\nThe quality of the product has generally deteriorated in several ways.\nWith the advent of LSP, the massive lead JetBrains had in "code intelligence"\nhas eroded, and in many cases no longer exists.\nThe resource requirements of the IDE have also ballooned massively,\neven occasionally causing memory pressure on my amply equipped MacBook Pro with 32GB of RAM.
\n(Side note: I regularly have 3 JetBrains IDEs open at once because I need to work in many languages,\nand for some reason they refuse to ship a single product that does that.\nI would have paid for such a product.)
\nAnd as if that weren't enough, it seems like I have to restart to install some urgent nagging update\nseveral times/week, usually related to one of their confusing mess of AI plugins\n(is AI Chat what we're supposed to use? Or Junie? Or... what?).\nTo top it all off, stability has gone out the window.\nAt least once/week, I will open my laptop from sleep,\nonly to find out that one or more of my JetBrains IDEs has crashed.\nUsually RustRover.\nWhich also eats up like 30GB of extra disk space for things like macro expansions\nand other code analysis.\nThe taxes are high and increasing on every front.
\nSo, I decided the time was right to give Emacs another shot.
\nIf you know me personally, you may recall that I made some strong statements in the past\nto the effect that spending weeks writing thousands of lines of Lua to get the ultimate Neovim config was silly.\nAnd my strongly worded statements of the past were partially based on my own experiences with such editors,\nincluding Emacs.\nBasically, I appreciate that you can "build your own lightsaber",\nbut I did not consider that to be a good use of my time.\nOne of the reasons I like(d) JetBrains is that I didn't ever need to think about tweaking configs!
\nBut things have gotten so bad that I figured I'd give it a shot with a few stipulations.
\nWith these constraints, I set off to see if I needed to revise my philosophy of editors.
\nAside: why not (Helix|Neovim|Zed|something else)?\nA few reasons, in no particular order:
\nSo, how's it going so far?\nHere are a few of the highlights.
\nIt used to be the case that JetBrains had a dominant position in code analysis.\nThis isn't the case anymore, and most of the languages I use that would benefit from an LSP\nhave a great one available.\nThings have improved a lot, particularly in terms of Emacs integrations,\nover the past decade!\neglot is now bundled with Emacs,\nso you don't even need to go out of your way to get some funky packages hooked up\n(like I had to with some flycheck plugin for Haskell back in the day).
The LSP-guided tools for refactoring have also improved a lot.\nIt used to be that only a "real IDE" had much better than grep and replace.\nI was happy to find that eglot-rename "just worked".
I'm used to hovering my mouse over any bit of code, waiting a few seconds,\nand being greeted by a docs popover.\nThis is now possible in Emacs too with eldoc + your LSP.\nI added the eldoc-box plugin and configured it to my liking.
So far, every single quick-fix action that I'm used to in RustRover\nseems to be there in the eglot integration with rust-analyzer.\nIt took me a few minutes to realize that this was called eglot-code-actions),\nbut once I figured that out, I was rolling.
I frequently use the jump-to-definition feature in IDEs.\nUsually by command+clicking.\nYou can do the same in Emacs with M-., which is a bit weird, but okay.\nI picked up the muscle memory after less than an hour.\nThe weird thing though is what happens next.\nI'm used to JetBrains and most other well-designed software (glares in the general direction of Apple)\n"just working" with the forward+back buttons that many input devices have.\nEmacs did not out of the box.
One thing JetBrains did fairly well was bookmarking where you were in a file, and even letting you jump back after\nnavigating to the definition or to another file.\nThis had some annoying side effects with multiple tabs, which I won't get into but it worked overall.\nIn Emacs, you can return from a definition jump with M-,, but there is no general navigate forward/backward concept.\nThis is where the build-your-own-lightsaber philosophy comes in I guess.\nI knew I'd hit it eventually.
I tried out a package called better-jumper but it didn't immediately do what I wanted,\nso I abandoned it.\nI opted instead to simple backward and forward navigation.\nIt works alright.
(global-set-key (kbd "<mouse-3>") #'previous-buffer)\n(global-set-key (kbd "<mouse-4>") #'next-buffer)\nAside: I had to use C-h k (describe-key) to figure out what the mouse buttons were.\nAdvice I saw online apparently isn't universally applicable,\nand Xorg, macOS, etc. may number the buttons differently!
The emacs shell mode is terrible.\nIt's particularly unusable if you're running any sort of TUI application.\nA friend recommended eat as an alternative.\nThis worked pretty well out of the box with most things,\nbut when I ran cargo nextest for the first time,\nI was shocked at how slow it was.\nMy test suite which normally runs in under a second took over 30!\nYikes.\nI believe the slowness is because it's implemented in elisp,\nwhich is still pretty slow even when native compilation is enabled.
Another Emacs user recommended I try out vterm, so I did.\nHallelujah!\nIt's no iTerm 2, and it does have a few quirks,\nbut it's quite usable and MUCH faster.\nIt also works better with full-screen TUI apps like Claude Code.
I'm not going to get into the pros and cons of LLMs in this post.\nBut if you use these tools in your work,\nI think you'll be surprised by how good the experience is with vterm and the claude CLI.\nI have been evaluating JetBrains' disjoint attempts at integrations with Junie,\nand more recently Claude Code and Codex.
Junie is alright for some things.\nThe only really good thing I have to say about the product is that at least it let me select a GPT model.\nAnthropic models have been severely hampered in their ability to do anything useful in most codebases I work in,\ndue to tiny context windows.\nThat recently changed when Anthropic rolled out a 1 million token context window to certain users.
\nJetBrains confusingly refers to Claude Code as "Claude Agent" and team subscriptions automatically include some monthly credits.\nEvery single JetBrains IDE will install its own separate copy of Claude Code (yay).\nBut it is really just shelling out to Claude Code it seems\n(it asks for your permission to download the binary.\nCodex is the same.)
\nGiven this, I assumed the experience and overall quality would be similar.\nWell, I was VERY wrong there.\nClaude Code in the terminal is far superior for a number of reasons.\nNot just access to the new model though that helps.\nYou can also configure "effort" (lol), and the "plan" mode seems to be far more sophisticated than what you get in the JetBrains IDEs.
\nSo yeah, if you're going to use these tools, just use the official app.\nIt makes sense; they have an incentive to push people to buy direct.\nAnd it so happens that Claude Code fits comfortably in my Emacs environment.
\nMore directly relevant to this post,\nLLMs (any of them really) are excellent at recommending Emacs packages and config tweaks.\nSo it's never been easier to give it a try.\nI've spent something like 2-3x longer writing this post than I did configuring Emacs.\n(And yes, before you ask, this post is 100% hand-written.)\nMy basic flow was to work, get annoyed (thats pretty easy for me),\nand describe my problem to ChatGPT or Claude.\nI am nowhere near the hours I budgeted for config fiddling.\nThat surprised me!
\nWhile I'm no stranger to hacking around with nothing more than a console,\nI really don't like the git CLI.\nI've heard jj is better, but honestly I think GUIs are pretty great most of the time.\nI will probably try magit at some point,\nbut for now I'm very happy with Sublime Merge.
\nBut one thing I MUST have in my editor is a "gutter" view of lines that are new/changed,\nand a way to get a quick inline diff.\nJetBrains had a great UX for this which I used daily.\nAnd for Emacs, I found something just as great: diff-hl.
My config for this is very simple:
\n(unless (package-installed-p 'diff-hl)\n (package-install 'diff-hl))\n(use-package diff-hl\n :config\n (global-diff-hl-mode))\nTo get a quick diff of a section that's changed,\nI use diff-hl-show-chunk.\nI might even like the hunk review experience here better than in JetBrains!
I think JetBrains has the best search around with their double-shift, cmd+shift+o, and cmd-shift-f views.\nI have not yet gotten my Emacs configured to be as good.\nBut C-x p g (project-find-regexp) is pretty close.\nI'll look into other plugins later for fuzzy filename/symbol search.\nI do miss that.
The final pleasant surprise is that I don't miss JetBrains run configurations as much as I expected.\nI instead switch to putting a justfile in my repo and populating that with my run configurations\n(much of the software I work on has half a dozen switches which vary by environment).\nThis also has the side effect of cleaning up some of my CI configuration (just run the same thing!)\nand also serves as useful documentation to LLMs.
I have typos configured for most of my projects in CI,\nbut it drives me nuts when an editor doesn't flag typos for me.\nJetBrains did this well.\nEmacs has nothing out of the box (Zed also annoyingly doesn't ship with anything, which is really confusing to me).\nBut it's easy to add.
I went with Jinx.\nThere are other options, but this one seemed pretty modern and worked without any fuss, so I stuck with it.
\nThis is all a lot more positive than I was expecting to be honest!\nI am not going to cancel my JetBrains subscription tomorrow;\nthey still do make the best database tool I know of.\nBut I've moved all my daily editing to Emacs.
\nThat said, there are still some papercuts I need to address:
\neglot-x which I'll look into later.cargo fmt)!mut variables. I would love to get that back in Emacs.이제 漢字 쓰는 方法을 알게 되었다!
\nI was today years old when I finally figured out how to type Hanja (characters from China that were historically used to write Korean).\nIt struck me as very strange that this didn't seem possible in any of the obvious input methods.\nIn Japanese, for example, you get search-as-you-type style suggestions popping up as you type,\nwhether in Kana or Romaji mode.\nIn fact, until now, I mostly relied on my prior study of Japanese,\nswitched to that layout, and typed in a Japanese reading.\nThis was quite clunky though as I am now learning the Korean readings.
\nI even asked several Koreans if they knew how,\nand none did (at least for macOS), since it's relatively uncommon to use them these days,\nparticularly for younger people.\nWindows keyboards have a dedicated Hanja mode key,\nbut I've never seen an Apple keyboard with this,\nand I'm not even totally sure if macOS understands the key code\n(if anyone knows, let me know on Mastodon).
\nIt turns out this IS in fact possible; it's just uncharacteristically buried.\nThe trick is to press option+return.\nThen you'll get a menu where you can select Hanja matches\nfor the previous "word" (it seems to rely on spacing, which is not always completely consistent in colloquial writing,\nbut it's not too hard to get used to.)\nI found tip on Apple's website\nvia a search.
\nThis is probably only relevant to like 2 other people on the internet, but I thought I'd spread the word\nsince it was relatively hard to find!
\n", "summary": "", "date_published": "2026-03-07T00:00:00-00:00", "image": "", "authors": [ { "name": "Ian Wagner", "url": "https://fosstodon.org/@ianthetechie", "avatar": "media/avi.jpeg" } ], "tags": [ "macos", "i18n", "korean", "languages" ], "language": "en" }, { "id": "https://ianwwagner.com//reqwest-0-13-upgrade-and-webpki.html", "url": "https://ianwwagner.com//reqwest-0-13-upgrade-and-webpki.html", "title": "reqwest 0.13 Upgrade and WebPKI", "content_html": "In case you missed the announcement,\nthe reqwest crate has a new and very important release out!\nreqwest is an opinionated, high-level HTTP client for Rust,\nand the main feature of this release is that rustls\nis now the default TLS backend.\nRead the excellent blog posts from Sean and others on why rustls\nsafer and often faster than native TLS.\nIt's also a lot more convenient most of the time!
This post is about one of the more mundane parts of the release.\nPreviously there were a lot of somewhat confusing features related to certificate verification.\nThese have been condensed down to a smaller number of feature flags.\nThe summary of these changes took a bit to "click" for me so here's a rephrasing in my own words.
\ntls_certs_merge.tls_certs_only\nto limit verification to only the certificates you specify.The documentation and release notes also mention that tls_certs_merge is not always supported.\nI frankly have no idea what conditions cause this to be supported or not.\nBut tls_certs_only apparently can't fail. ¯\\_(ツ)_/¯
The reason I'm interested in this in mostly because at $DAYJOB, just about everything is deployed in containers.\nFor reasons that I don't fully understand (something about image size maybe??),\nthe popular container images like debian:trixie-slim do not include any root CAs.\nYou have to apt-get install them yourself.\nThis is to say that most TLS applications will straight up break in the out-of-the-box config.
Previously I had seen this solved in two ways.\nThe first is to install the certs from your distribution's package manager like so:
\nRUN apt-get update \\\n && apt-get install -y --no-install-recommends ca-certificates \\\n && rm -rf /var/lib/apt/lists/*\nThe second is to add the WebPKI roots to your cargo dependencies.\nThis actually requires some manual work; adding the crate isn't enough.\nYou then have to add all of the roots (e.g. via tls_certs_merge or tls_certs_only).
The net result is approximately the same, but not entirely.\nThe system-level approach is more flexible.\nPresumably you would get updates in some cases without having to rebuild your application\n(though you do not get these automatically; the certs are only loaded once on app startup\nby rustls_platform_verifier!).\nPresumably you would also get any, say, enterprise-level trust, distrust, CRLs, etc.\nthat are dictated by your corporate IT department.
The WebPKI approach on the other hand is baked at build time.\nThe crate\nhas a pretty strong, if slightly obtuse warning about this:
\n\n\nThis library is suitable for use in applications that can always be recompiled and instantly deployed. For applications that are deployed to end-users and cannot be recompiled, or which need certification before deployment, consider a library that uses the platform native certificate verifier such as
\nrustls-platform-verifier. This has the additional benefit of supporting OS provided CA constraints and revocation data.
Attempting to read between the lines, past that "instantly deployed" jargon,\nI think they are really just saying "if you use this, certs are baked at compile time and you never get automatic updates. Be careful with that."
\nSo it's clear to me you shouldn't ship, say, a static binary to users with certs baked like this.\nBut I'm building server-side software.\nAnd as of February 2026, people look at you funny if you don't deploy using containers.\nI can deploy sufficiently instantly,\nthough to be honest I would have no idea when I should.\nMost apps get deployed frequently enough that I would assume this just doesn't matter,\nand so I'm not sure the warning as-written does much to help a lot of the Rust devs I know.
\nMy conclusion is that if you're deploying containerized apps, there is approximately no functional difference.\nYour container is a static image anyways.\nThey don't typically run background tasks of any sort.\nAnd even if they did, the library won't reload the trusted store during application.\nSo it's functionally the same (delta any minor differences between WebPKI and Debian, which should be minimal).\nSimilarly, unless you work for a large enterprises / government,\nyou probably don't have mandated, hand-picked set of CAs and CRLs.\nSo again here there really is no difference as far as I can tell.
\nIn spite of that, I decided to switch away from using WebPKI in one of our containers that I upgraded.\nThe reason is that structuring this way\n(provided that the sources are copied from a previous layer!)\nensures that every image build always has the latest certs from Debian.\ncargo build is a lot more deterministic,\nand will use whatever you have in the lockfile unless you explicitly run cargo update.
And even though I'm fortunate to not have an IT apparatus dictating cert policy today,\nyou never know... this approach seems to be both more flexible and creates a "pit of success"\nrather than a landmine where the trust store may not see an update for a year\ndespite regular rebuilds.
\nIn other words, I think Sean made the right choice, and you should probably delegate to the system,\nunless you have a particular reason to do otherwise.
\nHope this helps; I wrote this because I didn't understand the tradeoffs initially,\nand had some trouble parsing the existing writing on the subject.
\n", "summary": "", "date_published": "2026-02-13T00:00:00-00:00", "image": "", "authors": [ { "name": "Ian Wagner", "url": "https://fosstodon.org/@ianthetechie", "avatar": "media/avi.jpeg" } ], "tags": [ "rust", "cryptography" ], "language": "en" }, { "id": "https://ianwwagner.com//even-safer-rust-with-miri.html", "url": "https://ianwwagner.com//even-safer-rust-with-miri.html", "title": "Even Safer Rust with Miri", "content_html": "Recently some of the Miri contributors published a paper that was accepted to POPL.\nI've been using Rust professionally for about 7 years now,\nand while I'd heard of Miri several times over the years,\nI think there's a wide lack of knowledge about what it does, and why anyone should care.\nI only recently started using it myself, so I'm writing this post to share\nwhat Miri is, why you should care, and how you can get started easily.
\nMiri is an interpreter for Rust's mid-level intermediate representation (MIR; hence the acronym).\nThat's how I first remember seeing it described years ago,\nand that's what the GitHub project description still says.
\nThe latest README is a bit more helpful though: it's a tool for detecting undefined behavior (UB) in Rust code.\nIn other words, it helps you identify code that's unsafe or unsound.\nWhile it would be a bug to hit such behaviors in safe Rust,\nif you're using unsafe (or any of your dependency chain does!),\nthen this is a real concern!\nMiri has in fact even found soundness bugs in the Rust standard library,\nso even a transitive sort of #![forbid(unsafe_code)] won't help you.
I think to understand why Miri matters,\nwe first need to understand why UB is bad.\nThis is not something that most professional programmers have a great understanding of (myself included).
\nIn abstract, UB can mean "anything that isn't specified", or something like that...\nBut that's not very helpful!\nAnd it doesn't really explain the stakes if we don't avoid it.\nThe Rust Reference has a list\nof behaviors that are considered to be undefined in Rust,\nbut they note that this list is not exhaustive.
\nWhen searching for a better understanding,\nI've seen people online make statements like\n"UB means your program can do literally anything at this point, like launch nuclear missiles."\nWhile this is technically true, this isn't particularly helpful to most readers.\nI want something more concrete...
\nThe authors of the paper put UB's consequences in terms which really "clicked" for me\nusing a logical equivalence, which I'll quote here:
\n\n\nFurthermore, Undefined Behavior is a massive security problem. Around 70% of critical security vulnerabilities are caused by memory safety violations [38, 18, 32], and all of these memory safety violations are instances of Undefined Behavior. After all, if the attacker overflows a buffer to eventually execute their own code, this is not something that the program does because the C or C++ specification says so—the specification just says that doing out-of-bounds writes (or overwriting the vtable, or calling a function pointer that does not actually point to a function, or doing any of the other typical first steps of an exploit chain) is Undefined Behavior, and executing the attacker’s code is just how Undefined Behavior happens to play out in this particular case.
\n
I never made this connection on my own.\nI equate UB most often with things like data races between threads,\nwhere you can have unexpected update visibility without atomics or locks.\nOr maybe torn reads of shared memory that's not properly synchronized.\nBut this is a new way of looking at it that makes the stakes more clear,\nespecially if you're doing anything with pointers.
\nAnother connection I never made previously is that UB is relative to a very specific context.\nHere's another quote from the paper:
\n\n\nThe standard random number crate used across the Rust ecosystem performed an unaligned memory access. Interestingly, the programmers seemed to have been aware that alignment is a problem in this case: there were dedicated code paths for x86 and for other architectures. Other architectures used read_unaligned, but the x86 code path had a comment saying that x86 allows unaligned reads, so we do not need to use this (potentially slower) operation. Unfortunately, this is a misconception: even though x86 allows unaligned accesses, Rust does not, no matter the target architecture—and this can be relevant for optimizations.
\n
This is REALLY interesting to me!\nIt makes sense in retrospect, but it's not exactly obvious.\nLanguages are free to define their own semantics in addition to or independently of hardware.\nI suspect Rust's specification here is somehow related to its concept of allocations\n(which the paper goes into more detail about).
\nIt is obviously not "undefined" what the hardware will do when given a sequence of instructions.\nBut it is undefined in Rust, which controls how those instructions are generated.\nAnd here the Rust Reference is explicit in calling this UB.\n(NOTE: I don't actually know what the "failure modes" are here, but you can imagine they could be very bad\nsince it could enable the compiler to make a bad assumption that leads to a program correctness or memory safety vulnerability.)
\nI actually encountered the same confusion re: what the CPU guarantees vs what Rust guarantees for unaligned reads in one of my own projects,\nas a previous version of this function didn't account for alignment.\nI addressed the issue by using the native zerocopy U32 type,\nwhich is something I'd have needed to do anyways to ensure correctness regardless of CPU endianness.\n(If you need to do something like this at a lower level for some reason, there's a read_unaligned function in std::ptr).
TL;DR - UB is both a correctness and a security issue, so it's really bad!
\nOne of the reasons I write pretty much everything that I can in Rust is because\nit naturally results in more correct and maintainable software.\nThis is a result of the language guarantees of safe Rust,\nthe powerful type system,\nand the whole ecosystem of excellent tooling.\nIt's a real pit of success situation.
\nWhile you can run a program under Miri as a one-shot test,\nthis isn't a practical approach to ensuring correctness long-term.\nMiri is a complementary tool to existing things that you should be doing already.\nAutomated testing is the most obvious one,\nbut fuzzing and other strategies may also be relevant for you.
\nIf you're already running automated tests in CI, adding Miri is easy.\nHere's an example of how I use it in GitHub actions:
\nsteps:\n - uses: actions/checkout@v4\n - uses: taiki-e/install-action@nextest\n\n - name: Build workspace\n run: cargo build --verbose\n\n - name: Run tests\n run: cargo nextest run --no-fail-fast\n\n - name: Run doc tests (not currently supported by nextest https://github.com/nextest-rs/nextest/issues/16)\n run: cargo test --doc\n\n - name: Install big-endian toolchain (s390x)\n run: rustup target add s390x-unknown-linux-gnu\n\n - name: Install s390x cross toolchain and QEMU (Ubuntu only)\n run: sudo apt-get update && sudo apt-get install -y gcc-s390x-linux-gnu g++-s390x-linux-gnu libc6-dev-s390x-cross qemu-user-static\n\n - name: Run tests (big-endian s390x)\n run: cargo nextest run --no-fail-fast --target s390x-unknown-linux-gnu\n\n - name: Install Miri\n run: rustup +nightly component add miri\n\n - name: Run tests in Miri\n run: cargo +nightly miri nextest run --no-fail-fast\n env:\n RUST_BACKTRACE: 1\n MIRIFLAGS: -Zmiri-disable-isolation\n\n - name: Run doc tests in Miri\n run: cargo +nightly miri test --doc\n env:\n RUST_BACKTRACE: 1\n MIRIFLAGS: -Zmiri-disable-isolation\n\n - name: Install nightly big-endian toolchain (s390x)\n run: rustup +nightly target add s390x-unknown-linux-gnu\n\n - name: Run tests in Miri (big-endian s390x)\n run: cargo +nightly miri nextest run --no-fail-fast --target s390x-unknown-linux-gnu\n env:\n RUST_BACKTRACE: 1\n MIRIFLAGS: -Zmiri-disable-isolation\nI know that's a bit longer than what you'll find in the README,\nbut I wanted to highlight my usage in a more complex codebase\nsince these examples are less common.\n(NOTE: I assume an Ubuntu runner here, since Linux has the best support for Miri right now.)\nSome things to highlight:
\nMIRIFLAGS to disable host isolation for my tests, since they require direct filesystem access. You may not need this for your project, but I do for mine.s390x-unknown-linux-gnu is the "big-endian target of choice" from the Miri authors. This requires a few dependencies and flags.Hopefully you learned something from this post.\nI'm pretty sure I wrote my first line of unsafe Rust less than a year ago\n(after using it professionally for over 6 years prior),\nso even if you don't need this today, file it away for later.\nAs I said at the start, I'm still not an expert,\nso if you spot any errors, please reach out to me on Mastodon!
\n", "summary": "", "date_published": "2026-01-07T00:00:00-00:00", "image": "", "authors": [ { "name": "Ian Wagner", "url": "https://fosstodon.org/@ianthetechie", "avatar": "media/avi.jpeg" } ], "tags": [ "rust", "software-reliability" ], "language": "en" }, { "id": "https://ianwwagner.com//2025-in-review.html", "url": "https://ianwwagner.com//2025-in-review.html", "title": "2025 in Review", "content_html": "I have never done one of these kinds of public posts, but saw a few from friends so I thought it might be useful!
\nThis year I was simultaneously more focused on my technical craft than ever,\nbut also had more of a "life" than ever.\nI took more random days off to go chill with friends, go skiing, etc.,\nand had more time with family.
\nIt is probably also one of the darkest years in world history as a whole.\nThe worst humanitarian abuses in a century continue,\nencouraged and perpetrated by what is supposed to be the "free world."\nBut enough ink has already been spilled on that and you don't need to hear it from me.\nAnd South Korean politics show that you DO have a voice.\nSo make it heard, and let's focus on the good stuff.
\nI also traveled more than any year since COVID.\nIn addition to my annual pilgrimage to Latitude59 in Tallinn,\nother highlights were going to Hong Kong for Rust Asia\nand London for Anjunadeep Open Air.
\nSurprisingly, this was my first time to visit the UK,\nand I have to say London is one of the few other cities I could actually see myself living in.\nDespite its flaws, London had a charming atmosphere,\namazing public spaces, loads of greenery,\ngreat food and drink (I don't really get the hate... I thoroughly enjoyed all of my meals),\nand well-functioning public transportation.\nOverall it was a very "livable" city to me,\nand joins Tallinn and Seoul as one of the few places I'd really enjoy living.
\n2025 was a great year for musical experiences.\nHere are a few of my highlights of the year (in no particular order)\nwhich get regularly stuck in my head:
\nBesides all the great albums and mixes,\nI enjoyed more live shows than I have in a very long time (probably since 2015 or so).\nThe club nights and live bands in Tallinn were as amazing as ever.\nI got extremely lucky with tickets to a sold-out Fred Again tour show just 15 mins from home.\nThat was probably the best live show I've ever seen; absolutely incredible production and musical talent!\nAnd Anjunadeep Open Air was great.
\n2025 also saw me get back into creating music for fun.\nI hadn't made much time for this in the past decade,\nbut the time felt right.\nI bought myself an Ableton Push,\nand will probably upload something on SoundCloud at some point.\nOr not.\nI'm making music for me, for fun.\nI wish I could do house parties where I'm just jamming,\nbut that probably won't happen in a Korean apartment anytime soon.
\nI initially used "conferences" as a section heading,\nbut it struck me that the reason I go to conferences,\nmeetups, coworking, and online forums is the same: community.
\nAs I do basically every year, I went to Latitude59 in May\nfor the community gatherings.\nIt was a great time, and I got an early look at how AI agents were being adopted.
\nThe other international conference I attended was Rust Asia in Hong Kong.\nWhat a cool and diverse group of people!\nIt was also great to be back in Hong Kong again for the first time in quite a few years.\nI really hope they do the conference again in 2026.
\nI also got to attend two local conferences late in the year: FOSS for All, and FOSS4G Korea.\nBoth conferences wouldn't have been on my radar if not for some friends being involved organizing them.
\nFOSS for All is also a new conference, and the first edition was a huge success.\nIt was far more international than I expected for a Korean conference,\nand a model for running a properly international, bilingual conference.\nI was somewhat surprised that I gave the only talk with a heavy focus on Rust.\nAnd I was pleasantly surprised to see how much of the Korean FOSS community is active on Mastodon.\nI think I tripled the amount of Koreans I follow in an afternoon.
\nIt was also a surprisingly good value for my company as a sponsor.\nI had something like 20 serious conversations with people at our table,\nwhich was something I didn't really expect (the conference was maybe 200 attendees)!\nI'll definitely be back next year.
\nFOSS4G Korea was also surprisingly great!\nI think I was the only non-Asian there; a few dedicated people flew in from Japan, which was awesome!\nAI was definitely a theme, and it wasn't the sort of slop generating 10x "productivity" sort of narrative.\nThe talks were overall even more interesting than I had expected; better than the last international FOSS4G I attended!\nThis was also the first time I fully participated in a conference conducted in another language.\nI'm setting a goal to give a talk in Korean next time.
\nAnd speaking of international FOSS4G, it seems the next edition will also be close by\nin Hiroshima!\nI'm very excited to go, after several years of them being quite far away.\nGuess I need to start working on my talk proposals ;)
\nMeetup-wise, I took over hosting the Seoul Rust meetup this year, and we did a lot more events than any year since COVID.\nWe've had some great talks, and even started a YouTube channel,\nwhere we'll post recordings of talks in the future (provided that the speaker is OK with it).\nI also gave two talks at the Seoul iOS Meetup: one on Ferrostar, and another on Apple's new Foundation models.\nThe iOS meetup also spawned a new, more general meetup called Dev Korea,\nwhich is growing really fast and has a great community on Discord!
\nI read a lot last year!\nI finally finished reading Dragonball in Korean.\nI had never read / watch the series before (because I grew up in relatively rural America without cable TV),\nbut it came highly recommended.\nYou can read about that in my other post.
\nHere are some other things that I read + highly recommend:
\nI probably talk about this enough elsewhere, but it was a really fun year work-wise, and we grew a lot too!
\nFerrostar started as one of those audacious ideas which I just couldn't resist trying.\nIt's now a healthy open-source project with weekly meetings of the core contributors,\nover 300 stars on GitHub, and 56(!!) forks.\nI think it's pretty safe to say that it's now regarded as the first choice\nunless you want to pay Google millions of dollars, or have an extremely simple use case.\nIt's being adopted by large companies in the space,\nwe're benefiting from contributions back upstream,\nand we're getting new business as a result.
\nI'm pretty proud of this as I think it's an example of how open source can balance\ncommunity, collaboration, and sustainability.\nThat last 2 points is worth emphasizing.\nAll of the core contributors are working in a professional capacity,\nand find it valuable to work together on a shared foundation.
\nThe other big achievement that I haven't written as much about is rewriting our geocoder,\nmore or less from scratch, in a matter of months.\nYou've probably heard of the second-system syndrome.\nThe popular trope these days is for engineers to take something that works but is clunky / limited,\nand decide to rewrite it (maybe in Rust, like me 🤣), and never ship, or ship VERY late due to feature creep\nand wanting to get everything perfect.\nI'm definitely guilty of being a perfectionist, but I also believe you can get there gradually while shipping something valuable quickly.
\nI approached this rewrite with a clear set of things that I wanted to change,\nand focused almost all of the time initially on getting the foundations right,\nwhich would let me replace the higher layers in a more "agile" way\n(in the sense of the normal use of the word, not a specific methodology).\nIt worked.\nWithin a few months, I had replaced the existing API layer with a new one,\nwhich was serving 99% of our traffic.\nWe didn't have any downtime, and I'm only aware of one accidental breaking change.\nThis is a result of careful testing, including snapshot testing at several levels (using the insta crate),\nand oracle testing (simple Python scripts in this case which hit the current and next gen APIs and flagged any differences).
There will always be more improvements to make, but what's important is that we shipped,\nand we have a solid foundation to build from here.\nAnd not just that, we also have a v2 API with a bunch of improvements.\nAnd since the new API system is serving all the traffic,\nwe even get to backport a lot of the improvements to v1!\nIn fact, we have zero plans of deprecating our v1 API, since the internals are shared,\nand we can continue improving it within the limits of that API contract.\nThis is an engineering achievement I'm really proud of.
\nI don't do new years resolutions per se,\nbut I expect to work at a slightly less crazy pace,\nand make more time side projects like music and non-work-related tech.\nI've also decided on my next Korean reading series: Neon Genesis Evangelion.\nI'm currently on volume 5, and expect to finish that this year.
\n", "summary": "", "date_published": "2026-01-03T00:00:00-00:00", "image": "", "authors": [ { "name": "Ian Wagner", "url": "https://fosstodon.org/@ianthetechie", "avatar": "media/avi.jpeg" } ], "tags": [ "reflections" ], "language": "en" }, { "id": "https://ianwwagner.com//using-tar-with-your-favorite-compression.html", "url": "https://ianwwagner.com//using-tar-with-your-favorite-compression.html", "title": "Using tar with Your Favorite Compression", "content_html": "Here's a fun one!\nYou may already know that tarball is a pure archive format,\nand that any compression is applied to the whole archive as a unit.\nThat is to say that compression is not actually applied at the file level,\nbut to the entire archive.
\nThis is a trade-off the designers made to limit complexity,\nand as a side-effect, is the reason why you can't randomly access parts of a compressed tarball.
\nWhat you may not know is that the tar utility has built-in support for a few formats!\nGZIP is probably the most commonly used for historical reasons,\nbut zstd and lz4 are built-in options on my Mac.\nThis is probably system-dependent, so check your local manpages.
Here's an example of compressing and decompressing with zstd:
tar --zstd -cf directory.tar.zst directory/\ntar --zstd -xf directory.tar.zst\nYou can also use this with any (de)compression program that operates on stdin and stdout!
\ntar --use-compress-program zstd -cf directory.tar.zst directory/\nPretty cool, huh?\nIt's no different that using pipes at the end of the day,\nbut it does simplify the invocation a bit in my opinion.
\nAfter I initially published this article,\n@cartocalypse@norden.social noted that some versions of tar include the\n-a/--auto-compress option which will automatically determine format and compression based on the suffix!\nCheck your manpages for details; it appears to work on FreeBSD, macOS (which inherits the FreeBSD implementation), and GNU tar.
I've been using nushell as my daily driver for about six months now,\nand wanted to show a few simple examples of why I'm enjoying it so much.\nI think it's a breath of fresh air compared to most shells.
\nIn case you've never heard of it before, nushell is a, well, new shell ;)\nbash has been the dominant shell for as long as I can remember,\nthough zsh have their fair share of devotees.\nfish is the only recent example I can think of as a "challenger" shell.\nfish gained enough traction that it's supported by tooling such as Python virtualenv\n(which only has integrations out of the box for a handful of shells).\nI think fish is popular because it had some slightly saner defaults out of the box,\nwas easier to "customize" with flashy prompts (which can make your shell SUPER slow to init),\nand had a saner scripting language than bash.\nBut it still retained a lot of the historical baggage from POSIX shells.
Nushell challenges two common assumptions about shells\nand asks "what if things were different?"
\nls and du) are replaced by builtins.By dropping the goal of POSIX compliance,\nnushell frees itself from decades of baggage.\nThis means you get a scripting language that feels a lot more like Rust.\nYou'll actually get errors by default when you try to do something stupid,\nunlike most shells which will happily proceed,\nusually doing something even more stupid.\nMaybe treating undefined variables as empty string make sense in the 1970s,\nbut that's almost never helpful.
\nnushell also takes a relatively unique approach to utilities.\nWhen you type something like ls or ps in nushell,\nthis is handled by a shell builtin!\nIt's just Rust code baked into the shell rather than calling out to GNU coreutils\nor whatever your base system includes.\nThis means that whether you type ps on FreeBSD, Debian, or macOS,\nyou'll get the same behavior!
I can already hear some readers thinking "doesn't this just massively bloat the shell?"\nNo, not really.\nThe code for these is for less than that of the typical GNU utility,\nbecause nushell actually (IMO) embraces UNIX philosophy even better than the original utilities.\nThey are all extremely minimal and work with other builtins.\nFor example, there are no sorting flags for ls,\nand no format/unit flags for du.
The reason that nushell can take this approach is because they challenge the notion that\n"text is the universal API."\nYou can't meaningfully manipulate text without lots of lossy heuristics.\nBut you can do this for structured data!\nI admit I'm a bit of a chaos monkey, so I love to see a project taking a rare new approach\nin space where nothing has fundamentally changed since the 1970s.
\nOkay, enough about philosophy... here are a few examples of some shell pipelines I found delightful.
\nFirst up: I do a lot of work with Elasticsearch during $DAYJOB.\nOne workflow I have to do fairly often is spin up a cluster and restore from a snapshot.\nThe Elasticsearch API is great... for programs.\nBut I have a hard time grokking hundreds of lines of JSON.\nHere's an example of a pipeline I built which culls the JSON response down to just the section I care about.
http get "http://localhost:9200/myindex/_recovery"\n | get restored-indexname\n | get shards\n | get index\n | get size\nIn case it's not obvious, the http command makes HTTP requests.\nThis is another nushell builtin that is an excellent alternative to curl.\nIt's not as feature-rich (curl has a few decades of head start),\nbut it brings something new to the table: it understands from the response that the content is JSON,\nand converts it into structured data!\nEverything in this pipeline is nushell builtins.\nAnd it'll work on any OS that nushell supports.\nEven Windows!\nThat's wild!
Pro tip: you can press option+enter to add a new line when typing in the shell.
\nHere's an example I hinted at earlier.\nIf you type help du (to get built-in docs),\nyou won't find any flags for changing the units.\nBut you can do it using formatters like so:
du path/to/bigfile.bin | format filesize B apparent\nThe du command always shows human-readable units by default. Which I very much appreciate!\nAnd did you notice apparent at the end there?\nWell, the version of du you'd find with a typical Linux distro doesn't exactly lie to you,\nbut it withholds some very important information.\nThe physical size occupied on disk is not necessarily the same as how large the file\n(in an abstract platonic sense) actually is.
There are a bunch of reasons for this, but the most impactful one is compressed filesystems.\nIf I ask Linux du how large a file is in an OpenZFS dataset,\nit will report the physical size by default, which may be a few hundred megabytes\nwhen the file is really multiple gigabytes.\nNot necessarily helpful.
Anyways, the nushell builtin always gives you columns for both physical and apparent.\nSo you can't ignore the fact that these sizes are often different.\nI like that!
\nIf you want to give nushell a try,\nthey have some great documentation.\nRead the basics, but also check out their specific pages on, e.g.\ncoming from bash.
\nFinally, here are two more that tripped me up at first.
\n$nu.pid instead of $$.$env. On the plus side, you can now explicitly differentiate from environment variables.If you're a developer or sysadmin, there's a pretty good chance you've had to transfer files back and forth.\nBack in the old days, you may have used the ftp utility or something similar\n(I think my first one was probably CuteFTP).\nThen you probably thought better of doing things in plaintext,\nand switched to SFTP/SCP, which operate over an SSH connection.
My quick post today is not exactly a bombshell of new information,\nbut these tools are not the fastest way to transfer.\nThere's often not a huge difference if you're transferring between machines in the same datacenter,\nbut you can do many times better then transferring from home or the office.
\nOf course I'm talking about rsync, which has a lot of features like compression, partial transfer resume,\nchecksumming so just the deltas are sent in a large file, and more.\nI don't know why, but it's rarely in my consciousness, and always strikes me as a bit quirky.\nYou need quite a few flags for what I would consider to be reasonable defaults.\nBut if you remember those (or use shel history, like me),\nit can save you a ton of time.
In fact, this morning, using rsync saved me more time than it took to write this blog post.\nI was transferring a ~40GB file from a server halfway around the world,\nbut I only had to transfer bytes equivalent to 20% of the total.
\nHere's a look at the rsync command I often use for pulling files from a remote server\n(I usually do this to download a large build artifact without going through a cloud storage intermediary,\nwhich is both slower and more eexpensive):
rsync -Pzhv example.com:/remote/path/to/big/file ~/file\nIt's not really that bad compared to an scp invocation, but those flags make all the difference.\nHere's what they do:
-P - Keeps partially transferred files (in case of interruption) and shows progress during the transfer.-z - Compresses data on the source server before sending to the destination. This probably isn't a great idea for an intra-datacenter transfer (it just wastes CPU), but it's perfect for long distance transfers over "slower" links (where I'd say slower is something less than like 100Mbps between you and the server... the last part is important because you may have a gigabit link, but the peering arrangements or other issues conspire to limit effective transfer rates to something much lower).-h - Makes the output more "human-readable." This shows previfexs like K, M, or G. You can add it twice if you'd like 1024-based values instead of 1000-based. To be honest, I don't know why this isn't the default.-v - Verbose mode. By default, rsync is silent. This is another behavior that I find strange in the present, but probably made more sense in the era of teletype terminals and very slow links. It's not really that verbose; it just tells you what files are being transferred and a brief summary at the end. You actually have to give two v's (-vv) for rsync to tell you which files it's skipping!Hope this helps speed up your next remote file transfer.\nIf there's any options you like which I may have missed, hit me up on Mastodon with a suggestion!
\nBonus pro tip: I had (until I recently switched to nushell) over a decade of accumulated shell history,\nand sometimes it's hard to keep the options straight.\nNaturally my history has a few different variations on a command like rsync.\nRather than searching through manpages with the equivalent of grep,\nI usually go to explainshell.com.\nIt seems to be a frontend to the manapages that understands the various sections,\nproviding a much quicker explanation of what your switches do!
It occurred to me that things which work well are often under-represented online.\nI absolutely love my listening headphones, so I thought I'd write a quick post about them.
\nTo say I love music is an understatement.\nMy iTunes... er... Apple Music library is has 61.5 days of it.\nAnd I am reasonably picky.\nAnd unlike my Steam library, I have listened to all of it!\nMany times over.
\nI also tend to listen a lot in situations where headphones are the best output device.\nEither nobody else is awake (I'm listening to Arthur Rbenstein's performance of Chopin's Nocturnes right now, if that gives you a clue)\nor others are very much around who may not appreciate classic trance blasting at 100dB.\nHeadphones are a really fantastic way to listen to music,\nand if you care about quality, they are some of the best bang for your buck.\nYou can get some AMAZING quality cans for a fraction of what you'd pay for a comparable speaker setup.
\nBut headphones are also hard to get right, and highly personal.\nWhat follows is my current favorite, and the journey to here.\nI'll try to note cases where I'm aware of my own subjectivity.\nbut I probably won't get everything.
\nI've worn headphones for a significant chunk of my computer time (an inordinate portion of my life) since 2011 or so.\nThat's about 15 years at the time of this writing.\nHere are some things that are important for me (or not important), which may help frame my opinion:
\nOver the years, I've really liked Sennheiser.\nI had several mid to high end pairs over the years.\nI rather liked my HD558s from years past.\nThey were mostly neutral response and open back.\nBut those were a long time ago (I bought them in 2013).\nAnd current Sennheiser isn't what they once were.
\nMore recently, I bought the Grado 325x.\nThey were crisp on the high end.\nBut after about 8 months, I couldn't stand them any more.\nThery were far too unforgiving of all but a perfectly mastered track.\nThe lower frequencies were off, especially for electronic music (but sounded great for rock).\nThey were heavy.\nThey were uncomfortable (I hated the headband and the weird angle of the earpieces,\nwhich look cool as a piece of steampunk concept art but are highly impractcial IMO).
\nTo make matters worse, the cable is non-detatchable and soldered all the way through.\nIt also weighs a ton and is super inflexible.\nI hear there are a bunch of people that do cable mods,\nbut by the time my pair developed a loose connection (probably due to the above)\nthat made them practically unlistenable, I was ready for something else.
\nModerately annoyed, I decided to buy some new headphones almost a year ago.\nI didn't find much help in reviews honestly, and you probably shouldn't expect to here either.\nBut I ended up going for some Beyerdynamic DT 900 Pro X's.\nI definitely over-indexed on the detatchable cable by the way\n(I haven't had a single issue with the cabling, nor have I bothered detaching it, but it's the principle of the thing).\nThe sound quality on these is excellent, and they have a better sound stage than my old Sennheiser's.\nI liked some things about the Grados better, but these are way more versatile.\nThey are also comfortable to wear for 2-3 hours:\nthey are lighter, and the cushioning is amazing.\nEspecially with my glasses.\nMy only complaint is they are a bit tight fitting for my large head,\nand I can actually hear some squeaks from my glasses frame when moving around sometimes.
\nHeadphones also need a solid amp (+ DAC if you're using it like most people).\nI currently use a Schiit Magni.\nA ridiculously under-priced amp+DAC.\nI really don't have much to say except that it's an excellent little unit that sounds great.\nI haven't had any issues in the 2 years I've owned it,\nbeyond the decade and change issues with certain music players not filling buffers fast enough\nduring a cold start of a new album.
\n", "summary": "", "date_published": "2025-11-25T00:00:00-00:00", "image": "", "authors": [ { "name": "Ian Wagner", "url": "https://fosstodon.org/@ianthetechie", "avatar": "media/avi.jpeg" } ], "tags": [ "gear" ], "language": "en" }, { "id": "https://ianwwagner.com//elecom-deft-pro-two-months-in.html", "url": "https://ianwwagner.com//elecom-deft-pro-two-months-in.html", "title": "Elecom Deft Pro - Two Months In", "content_html": "It's not quite two months in, but I said I'd give an update on the Elecom Deft Pro after some use, so here I am!
\nBad news first...
\nI'm not gonna lie, the initial adjustent period on this was rougher than I expected.\nThis trackballl was extremely uncomfortable for the first week,\nand not particularly comfortable for the following 2 or 3 weeks either.\nExpect to take some time getting used to this.
\nMy biggest complaint is probably that it's too small and too light.\nIt should be 2-3 times heavier in my opinion to stay put.\nAnd I guess I should have guessed it from the name, but it's really small.\nAlmost too small for my hands.
\nI'm not sure what it is with Elecom, but a lot of the angles make no sense to me.\n"Straight" as measured from the USB port puts the angle for the main ("left") click button off by like 5-10 degrees.\nSo I always want to have it off center, but that's challenging on my admittedly small keyboard tray.\nI'm also not really sure whose hand they designed whatever is further right than the right (alt-right?) button for.\nI never planned on using this or the middle click button anyways, but they are just weirdly positioned.\nThe forward and back buttons are also weirdly positioned.
\nThese were also weirdly positioned on the HUGE, but the Deft Pro seems worse.\nIt's exacerbated by the fact that the thing weighs basically nothing,\nwhich is not a positive thing when you're trying to poke it at weird angles that will definitely move it on your desk.\nAnd I'm not sure what the other weird button and switch are closest to the hand rest and on level with the left click button,\nbut they are in such weird positions I will NEVER use them.
\nOh my, this was a huge (lol) adjustment...\nThe scroll wheel is SO CRISP!\nI also kinda hate it, since even at max speed it's way too slow.\nI literally reach for my MacBook trackpad any time I want to scroll fast through a large document.\nThe scroll wheel is precise, but it's also kinda terrible IMO.\nAnd unlike the HUGE where you could sort of scroll horizontally by awkwardly nudging the wheel up or down,\nthe Deft is so tiny and light, and the wheel is so stiff, that you can just forget even the most awkward horizontal scrolling.\nUse your laptop trackpad for this.
\nI'm sure I sound VERY negative at this point.\nAnd I really do have a lot of bad to say about this trackball.\nBut I'm still using it and actually do have some good things to say.
\nHonestly I don't have any complaints about this.\nI saw some very polarizing opinions about the ball not rolling smoothly but I have had relatively few issues.\nIt's not sticking or anything for me and feels pretty good overall.\nMy precision feels slightly better than with the HUGE.
\nThe reason I replaced my HUGE was the unreliable buttons.\nMaybe my HUGE was a lemon, but the Deft Pro has been great.\nNo missed / duplicate click events.\nIt really just works.
\nWell, I'm still using it ;)\nSeveral things annoy me, but it's better than my HUGE.\nThe other trackball I considered was a Kensigton.\nI might still buy one, but only after I either:
\nOverall it's not a bad trackball, and you might even like it if you're primarily working mobile.\nBut I use this at my large desk and I have a few complaints.\nDespite my ergonomic complaints, it's still better than most mice,\nand your experience will probably be better than mine since my hands are large enough to make serious piano players envious.
\n", "summary": "", "date_published": "2025-11-19T00:00:00-00:00", "image": "", "authors": [ { "name": "Ian Wagner", "url": "https://fosstodon.org/@ianthetechie", "avatar": "media/avi.jpeg" } ], "tags": [ "gear" ], "language": "en" }, { "id": "https://ianwwagner.com//korean-music-beyond-k-pop-demon-hunters.html", "url": "https://ianwwagner.com//korean-music-beyond-k-pop-demon-hunters.html", "title": "Korean Music Beyond K-Pop Demon Hunters", "content_html": "Pretty much overnight, it seems that a movie I had never even heard of became the most-watched movie ever on Netflix.\nPeople everywhere are now singing the songs from K-Pop Demon Hunters.\nIt originally seemed more popular outside Korea\n(the first dozen or so people I heard about it from were not Korean, nor were they living here).\nBut now it's all over the promotional marketing locally too.
\nI absolutely love living here,\nand am immersed in many aspects of the culture,\nbut have never been a big K-pop fan.\nIn fact, I don't actually like most pop music anywhere in the world ;)
\nIf you, like me, have different musical tastes from the mainstream,\nthen this post is for you!\nIt's a collection of some of my favorite Korean music\nthat you've probably never heard of.
\nThere is no particular order to this post, so don't take this as some sort of ranking.\nIt's just a list of music and artists I like which can broaden your horizons.
\nOkay, let's kick off with some light... hip-hop?\nI don't really even know how to categorize this pair of songs,\nseparated by almost a decade but having a lot of similarities in both style and name.\nBefore the current American-influenced styles of rap and hip-hop started to dominate,\nthere was this more fun and weird side.
\nFirst up is boy band H.O.T. with Candy.\nThis was 1996, so it's probably the oldest on my list.\nIt's just light and fun.\nAnd very 90s... lighter side of hip hop.
\nOver the next decade, hip-hop and rap grew even more popular.\nThis next song, Lollipop, has one of the more bizarre music videos,\nand is a collaboration with more people than you'll be able to keep track of.\nHere's the MV.
\nThis song was released in the year 2000.\nThis style of dance+rock fusion was actually quite popular in Korea at the time,\nbut you don't hear very many producers putting out stuff like this today.\nThis song is well-known and loved by many in their late 30s or older,\nand is one of the most popular 노래방 (singing room = Karaoke) songs from that era,\neven today.\nThe song is full of passion and energy,\nand is very technically challenging.\nHere's a recent live performance.
\nThe gist of the song is a post-breakup story.\nIt's more of a power ballad, which is NOT my usual style of music.\nBut this song is just SO good, it has to be on my list.\nWhen it was released in 2017, it did extremely well,\nand got loads of radio play, despite not fitting the typical pop mold of the time.\nHere's a live performance\nthat also has some English subtitles.
\nOkay, this song probably does qualify as K-pop...\nThere is some good stuff in there ;)
\nThis is also the newest release on the list.\nIt grabbed my attention immediately\nbecause the musical structure, choice of scales, and rhythms\naren't typical in current K-pop.
\nHere's the music video.\nIt's definitely an idol group,\nbut the MV is artistically solid and generally quite creative\n(it alludes to both streamer culture and Korean-style photo booths)!
\nI have a hard time recommending a specific track,\nbecause this guy is a pretty wide ranging artist,\nand much of what he does is live.\nHe does everything from deep house on one of my favorite labels\nto ambient sets like this with a Eurorack modular.
\nThis song is getting REALLY out of the mold now...\nWe're in metal territory.
\nThe original was released back in 1997 by the group N.E.X.T,\nbut a newer in 2016 on a Korean TV show "The King of Mask Singer" made the song much more popular.\n(The concept of the show is that some famous singer puts on a mask, sings a song,\nand then celebrity judges have to guess who's behind the mask at the end).
\nOn one of these episodes, 하현우 does an absolutely stellar cover,\nwhich I liked even better than the original.\nHis vocal style is really on point for the song,\nand the high notes are absolutely killer!
\nYou can watch a video of the performance on YouTube.\nIt's truly something with a full orchestra, drums, guitar... the whole bit.
\nLast but definitely not least,\nthis song is fun, upbeat, and a bit punk-y in style.\nIt was released back in 2003 and bears a lot of resemblance to J-Rock at the time.
\nThe song is about a duck who dreams he can fly.\nHis mom scolds him and says ducks can't fly,\nbut that doesn't stop him from dreaming.
\nIt's such a beautiful song!\nAnd I love the metaphor about chasing your dreams.\nSomething that I really hope can continue to inspire the younger generation.
\nAnd the vocal style of the lead singer is pretty unique.\nShe's happy and has piercing high notes, but also has that rock edge at several points.\nAnd in live performances\nshe does this cute little hand motion throughout,\nmimicking wing flapping motion, which I thought was a cool and endearing!
\nI had this song stuck in my head for weeks after I discovered it.
\n", "summary": "", "date_published": "2025-11-09T00:00:00-00:00", "image": "", "authors": [ { "name": "Ian Wagner", "url": "https://fosstodon.org/@ianthetechie", "avatar": "media/avi.jpeg" } ], "tags": [ "music", "culture", "korea" ], "language": "en" }, { "id": "https://ianwwagner.com//const-assertions.html", "url": "https://ianwwagner.com//const-assertions.html", "title": "Const Assertions", "content_html": "I'm currently working on a project which involves a lot of lower level\ndata structures.\nBy lower level I mean things like layout and bit positions, and exact sizes being important.\nAs such, I have a number of pedantic lints enabled.
\nOne of the lints I use is cast_precision_loss.\nFor example, casting from usize to f32 using the as keyword is not guaranteed to be exact,\nsince f32 can only precisely represent integrals up to 23 bits of precision (due to how floating point is represented).\nAbove this you can have precision loss.
This lint is pedantic because it can generate false positives where you know the input can't ever exceed some threshold.\nBut wouldn't it be nice if we could go from "knowing" we can safely disable a lint to actually proving it?
\nThe first thing that came to mind was runtime assertions, but this is kind of ugly.\nIt requires that we actually exercise the code at runtime, for one.\nWe should be able to cover this in unit tests, but even if we do that,\nan assertion isn't as good as a compile time guarantee.
\nconstOne thing I didn't mention, and the reason I "know" that the lint would be fine is that I'm using a const declaration.\nHere's a look at what that's like:
pub const BUCKET_SIZE_MINUTES: u32 = 5;\npub const BUCKETS_PER_WEEK: usize = (7 * 24 * 60) as usize / BUCKET_SIZE_MINUTES as usize;\nThis isn't the same as a static or a let binding.\nconst expressions are actually evaluated at compile time.\n(Well, most of the time... there's a funny edge case where const blocks which can never executed at runtime\nis not guaranteed to evaluate.)
You can't do everything in const contexts, but you can do quite a lot, including many kinds of math.\nNot all math; some things like square root and trigonometry are not yet usable in const contexts\nsince they are not reproducible across architectures (and sometimes even on the same machine, it seems).
assert! in a const blockAnd now for the cool trick!\nI want to do a division here, and to do so, I need to ensure the types match.\nThis involves casting a usize to f32,\nwhich can cause truncation as noted above.
But since BUCKETS_PER_WEEK is a constant value,\nwe can actually do an assertion against it in our const context.\nThis lets us safely enable the lint, while ensuring we'll get a compile-time error if this ever changes!\nThis has no runtime overhead.
#[allow(clippy::cast_precision_loss, reason = "BUCKETS_PER_WEEK is always <= 23 bits")]\nconst PI_BUCKET_CONST: f32 = {\n // Asserts the invariant; panics at compile time if violated\n assert!(BUCKETS_PER_WEEK < 2usize.pow(24));\n\t// Computes the value\n std::f32::consts::PI / BUCKETS_PER_WEEK as f32\n};\nThis is all possible in stable Rust at the time of this writing (tested on 1.89).\nI saw some older crates out there which appeared to do this,\nbut as far as I can tell, they are no longer necessary.
\nHere's a Rust Playground\npreloaded with the sample code\nwhere you can verify that changing BUCKETS_PER_WEEK to a disallowed value causes a compile-time error.
I recently picked up a new trackball to replace my prematurely aging Elecom HUGE.\nHere are my first impressions after only a few hours, since there wasn't much I could find online comparing them properly.
\nNOTE: I have an updated review after ~2 months with the unit here.
\nTo get the obvious question out of the way first,\nI have used a trackball for about 5 years as my primary pointer device.\nI switched from all manner of mice and trackpads due to ergonomics.\nI had pretty bad RSI for many years, due to excessive computer use,\nand a trackball was one of the key changes that solved my issues.
\nThe trackball actually had a larger impact than switching to Dvorak (minimal improvement)\nor switching to a better ergonomic keyboard (Kinesis Advantage 2 QD; incremental, but not order of magnitude improvement).\nAnd yes, I'm aware of vertical mice.\nI tried a Logitech one for about 2 years and it actually made things worse.
\nThe biggest difference is probably the size.\nThe Deft Pro has a much smaller footprint than the HUGE.\nPart of the reason for this early replacement is that I ordered a replacement keyboard drawer online the other week.\nBeing too lazy to measure, and just going off the scale photos, it looked plenty big.
\n
Narrator: it was, in fact, far too small and barely fits the keyboard.
\nSo, with the HUGE practically falling off,\ncombined with my bad habit of snacking and drinking at my desk late at night contributing to click malfunction\n(weirdly it would DOUBLE register clicks!), I needed a replacement.
\n![\"An](\"media/deft-on-the-tray.jpeg\")
The Deft Pro is pretty much the size I wanted.\nIt fits (just barely) on my tiny keyboard tray,\nand it is quite comfortable to use.
\nI have to say I wish this thing were a bit heavier.\nI want the thing to sit on my desk like a rock and not move.\nI tend to manipulate the ball with my fingertips,\nand keep other fingers on the buttons, but this tends to push the base off to the left.\nMaybe I'll look at a sticky setup or something...
\nI can only give a partial review here, since I do not use most of the extra buttons.\nPartly because I can't be bothered to configure them (most apps won't support them easily),\nand partly because I don't like installing proprietary software with low level system access for marginal benefit.\n(This is a subtoot at Logitech Options, but Elecom is not much better.)\nSo, I only use the left+right click, and the forward/back buttons.\nThe forward/back buttons are plug-and-play\nwith my web browser and many dev tools like JetBrains IDEs.
\nI think the HUGE positioning was a bit better for the forward/back buttons.\nThe scroll and left click position are fine for my usage style.\nThe right click though... That will take some getting used to.\nI think they designed the Deft to be held in your hand pretty closely,\nbut that isn't how I got used to using the HUGE.
\nI'll give this a shot and see how it goes after a few weeks trying a different grip.\nI think right click is positioned fine for the intended style of gripping.
\nThe Deft allows for much better precision, with each step being a nice crisp click.\nI personally liked the HUGE better.\nIt was pretty fluid, smooth, and not "clicky."\nIt also could generate acceptable scrolling speeds.\nNot as good as an Apple trackpad, but acceptable.\nI had to jack up the scroll speed to max for the Deft,\nand will probably continue using my trackpad for gestures like this when I want to go fast.
\nThis is not a criticism of Elecom specifically; it's a universal gripe I have with most things\nexcept the Apple trackpad.
\nThe ball itself is great!\nI found some reviews online complaining that it was sticky,\nor hard to manipulate precisely.\nI have not had any issues so far; it feels as good or better than the HUGE.
\nIf I recall, the HUGE required you to select a connectivity option at purchase time.\nThe Deft Pro includes all in the same package: bluetooth, RF via USB wireless dongle, and cabled USB connection.\nThis is great if you like to travel with an external input device!
\nI personally don't since I love my MacBook trackpad.\nBut if you do, the only thing I'd flag is that there is no internal battery.\nYou need a single AA battery rather than an internal rechargeable like the higher end Logitech mice.
\nIt lives up to the name: it's Deft.\nI like a few things about the HUGE better (the scroll wheel and right mouse button position being the main ones),\nbut I did buy this for a smaller footprint,\nand I think I can get used to the button position with a tighter grip.
\nI'll post a follow up later once I have a chance to use it more.
\n", "summary": "", "date_published": "2025-09-28T00:00:00-00:00", "image": "media/huge-on-the-tray.jpeg", "authors": [ { "name": "Ian Wagner", "url": "https://fosstodon.org/@ianthetechie", "avatar": "media/avi.jpeg" } ], "tags": [ "gear" ], "language": "en" } ] }