Boost 1.77 is working well with it, and I’ve fully migrated to boost::json, which is working out great. The straw that broke the camel’s back was map.contains(), lolz. I was ready! I feel like I’ve had a hot bath. Nice.

TL;DR add this config to dnsmasq.conf to expand your LAN single-label hosts into FQDNs that systemd won’t hate:


For decades, DNS resolution was fine, and then systemd arrived and it was not. For the past couple years, for me and many others, systemd-resolved has been quite a headache, failing basic DNS resolution on any fresh Ubuntu (and other) installs. A real joy when you just want to get things going ASAP. After years of getting around it with shitty hacks, I finally nailed down what was going on.

Poettering and his crew decided that “single-label” host names on your LAN should never be allowed to resolve, even though it always used to in what he calls “classic DNS”. The systemd-resolved DNS handler in a vanilla install of Ubuntu 20.04 will drop your name resolution requests simply because the name does not have a dot in it. End of story. How nice. This awful default behavior follows some 2013 guidelines that were never previously enforced, at least not on me.

I use the simplest possible solutions that work, and for me that is dnsmasq. You can use one config file to configure static IPs for the MACs of all your LAN boxes. I just needed to reconfigure it to expand single-label names into longer “fake” FQDNs, with some dnsmasq hackery, and DNS on new boxes now works out of the gate. See the top of post (or this SO answer) for the configuration details.

There are supposed to be other solutions, like flipping on the LLMNR flag of systemd-resolved. That didn’t work for me, and I don’t want to have to futz with every single new LAN box and VM anyway. Hopefully this nightmare is behind me now. I hope for you, as well.

From zero to new-domain-with-gmail-backed-email:

  • Register your brilliant name (like mine, at (ok i lied, that sets you back $12/yr). Hey look, is available!
  • Create a new google account for it, something like
  • Domains > Email > Email forwarding > add email alias:
    bossman ->
  • Google account avatar > manage your account > security > Signing into google:
    Turn on 2fa if it is not already on (they will keep shoving this on us, capitulate.)
    App Passwords > app: Mail, device: Custom, name:
    (NOTE I had to futz with form to get name field to show up.)
    Copy the 16-digit code that you get.
  • Gmail settings > accounts > Send mail as: > Add
    The second page of the forms will ask for SMTP server, use, default port, username myshitcutter, paste key from prev step.
  • Validate email as requested.
  • From gmail, you can now send and receive using <>. You can keep going if desired if you want to add one or a bazillion other users at that domain.

Congratulations! Now you’ve guaranteed that the biggest big brother the human race will ever know, outside of the US government, can read your every thought, in realtime. And don’t worry, they’ll pass it all on, proactively, to the government, for free.

The thread_local scope tells the compiler to create one unique version of a variable per thread. Then you can access it without worrying at all about in what thread you are. (Grammar Nazis, help me out here. I think I got that right…) It is absolutely genius for making multi threaded programming that much easier. W00t.

UPDATE: of course, every razor blade comes with its share of nicks. In this case, the expectation that different objects in the same thread would still have different thread_local members. Nope! Vet your ideas before you change to this scope too fast! Me, I’m all better now, and still love it. Good luck girls and boys.