personal netspace


Wed 2020-11-04 04:26

  • Note
  • Posted: 2020-11-04 04:26 UTC

Well, shit. This is shaping up to be the worst case scenario: a nail-biter neck-and-neck race. If you live in a major city this is probably a good time to make sure your property insurance is paid up. And maybe consider taking an impromptu vacation to somewhere rural.

Wed 2020-11-04 02:29

  • Note
  • Posted: 2020-11-04 02:29 UTC

Seems like the best election coverage show tonight is Joe Rogan, Tim Dillon, and Kyle Kulinski just bullshitting live on YouTube. Supposedly, Alex Jones might also pop in. I find the guy frequently entertaining and occasionally informative but I kinda hope he doesn't crash the broadcast and turn it into a trainwreck.

Wed 2020-11-04 02:05

  • Note
  • Posted: 2020-11-04 02:05 UTC

I mean... I know my math skills aren't that great but... WTF Google? Calling Virginia "won" for Biden when he holds only 40% of the vote and every news outlet is reporting that Trump currently has a huge lead there?

Virginia election returns

Tue 2020-11-03 13:14

  • Note
  • Posted: 2020-11-03 13:14 UTC

Election Day has finally arrived, and so now begins the championship game. Or a civil war, depends on how pessimistic you are.

I've aleady voted and so, obviously, I have a preference as to who wins this year. But regardless of which presidential candidate takes the electoral college, my real hope for this election is that it's an uncontestable landslide in either direction. I feel like the worst possible outcome for my country would be a tight "every vote must be counted, we demand recounts, they cheated, they suppressed, what about these people who didn't get to vote?" re-run of the 2000 election. We're already pretty divided as a nation, I feel like such an outcome could cause irreparable harm.

So whoever wins today, let them win big.

Lastly, if your favorite old, white, rich guy doesn't happen to win today please take that disappointment like a grown-up. Have a beer, have a smoke, and console yourself with the knowledge that another election is just a few years away. Let's not throw a galactic temper tantrum and burn down every city in America, okay?

Sun 2020-10-11 13:26

  • Note
  • Posted: 2020-10-11 13:26 UTC
  • Edited: 2020-10-11 13:31 UTC

Conservationists warn that producing a coronavirus vaccine could result in the killing of half a million sharks.

"A conservation group is warning that the development of an effective coronavirus vaccine on a global scale could ravage shark populations worldwide, as researchers race to produce a vaccine using an oil derived from sharks."

I ask you, were our roles reversed - would the sharks even hesitate? I think not.

UPDATE: The conservation group cited is Shark Allies. I think their bias is pretty obvious.

Tue 2020-10-06 21:28

  • Note
  • Posted: 2020-10-06 21:28 UTC

Jesus H. Christ, can 2020 get any worse? Well, I guess so.

Rest in peace, Eddie Van Halen. You were the person who most inspired a 16 year old me to pickup a guitar and learn how to play. The world you leave behind is a little more awesome because you were here, but also a little sadder now that you've gone.

The angels are rockin' tonight. Eddie

Fri 2020-10-02 21:54

  • Note
  • Posted: 2020-10-02 21:54 UTC

For anyone thinking about buying an Ergodox-EZ, here's a protip: save yourself $30 and don't splurge for the custom cut wrist rests. They're comfortable but the material they are made of:

  1. Grabs every single hair, spec of dust, piece of lint, etc. After 24 hours of use, my wrist rests are fuzzy. Gross.
  2. Doesn't grab the surface of my desk. Like, at all. The rests slide around while I type, pushing around the keyboards with them.

Basically, the damn things grab everything but the table. Not really cool. My $8 wrist rest from the local office supply store works about 100x better for a fraction of the cost.

Fri 2020-10-02 03:18

  • Note
  • Posted: 2020-10-02 03:18 UTC

I received my new Ergodox-EZ keyboard yesterday. It took me a few tries to program in a layout that works for me, and I'm still trying to get used to it. It's taken me about five minutes to type this message, versus my normal 80-100wpm. I think I'll likely spend the next couple months learning how to type again. This thing is exposing all my bad (typing) habits.

Wed 2020-09-30 12:35

  • Note
  • Posted: 2020-09-30 12:35 UTC

I put a good friend in the ground last night. May she rest in peace.


Unknown (ca. 2009) - September 29, 2020

She was a fussy eater, an opinionated individual, and when irritated - a biter. She was also a traveling companion without complaint, a lap warmer par excellence, and a loving and loyal friend. She will be sorely missed.

Charlie - a damn fine cat

Fri 2020-09-25 16:37

  • Note
  • Posted: 2020-09-25 16:37 UTC
  • Edited: 2020-09-25 16:45 UTC

I'm going to throw this up here because I've not found it documented elsewhere and it took me a bit to figure out.

Let's say you want to setup a file synchronization connection between two remote hosts that don't share connectivity (e.g., WAN, VPN, etc.). You might rightly suggest Syncthing as a solution. Install Syncthing on each host and configure the hosts to share one or more sync'd folders. Great, but what if both hosts are behind a NAT firewall and neither of these hosts have open ports exposed to the public Internet?

No problem. Syncthing normally solves this limitation by using relay hosts, of which there is a public pool run by the Syncthing project and other volunteers. Two Syncthing clients that need to share files but cannot directly connect to one another discover a mutually accessible relay server and use that host to connect. The relay servers themselves do not keep a copy of any sync'd files. They don't even have the ability to read the files being synchronized between clients. Instead, they only register clients and forward Syncthing traffic between them, allowing hosts to sync files without direct connectivity.

Okay, simple enough. However, let's add a wrinkle to this problem and suppose that you don't want the synchronized files to traverse any third-party servers. Perhaps you want to control all servers in the file sync path, or provide dedicated resources to ensure that your relayed files don't have to compete with other files being relayed. Or maybe security is a concern. True, Syncthing traffic is encrypted end-to-end... but still. Maybe it's just paranoia or maybe it's due to regulatory compliance and security audits, but you don't want the synchronized files to pass through unknown systems. Further, you might not even want the Syncthing clients to use the Syncthing global discovery servers and share metadata publicly.

The somewhat documented solution for that requirement is to run your own private instance of the Syncthing Relay Server on a trusted public-facing host to which both syncing hosts have access.

Installing and configuring the Syncthing Relay Server itself is not that difficult. If you're running a major Linux distro there's probably a package for it in your repos (for fellow openSUSE users it's the syncthing-relaysrv package.) To run a private instance that does not join the Syncthing relay pool, start the service with the following option flags:

/usr/bin/strelaysrv -pools="" -status-srv=""

The first time Syncthing Relay Server is run it will generate its crypto keys and Syncthing device ID. Thereafter, each time the service is run it will report it's own relay URI, which will be in the form relay://ip_address:port/?id=syncthing_id. As instructed in the Syncthing documentation, you can configure the Syncthing client to use the relay by going to Actions / Settings / Connections and editing the Sync Protocol Listen Addresses field. Remove default and add the normal listening ports and the relay URI provided by the relay host. For a relay at on port 23456, the field might look like:

tcp://:22000, quic://:22000, relay://

Turn off Enable NAT traversal, Global Discovery, and Local Discovery. Make sure Enable Relaying is turned on.

If you restart Syncthing on the client hosts and check the client logs, you should see a secure connection established to the relay. If you look at the IP connections on the relay using netstat or ss you should see connections from both clients.

Now here's the (afaik) undocumented part: how in the name of Odin's right buttcheek do you get the two clients to find each other through the relay? This is not immediately obvious, and much searching and parsing docs revealed no answers on the matter. It turns out it is relatively simple.

First, you will need the Syncthing device ID of each host (Actions / Show ID). Copy those down and share the partner ID with each client in the connection (the IDs are public keys, and are not secret info).

Next, on each client create a remote device for the opposite host (via + Add Remote Device). On the General tab, enter the Device ID and Device Name as normal.

Up to this point, things are pretty typical for making a connection to a Syncthing peer. But one more step is required to allow the hosts to discover each other and connect via the relay.

On the Advanced tab of the remote device configuration page, edit the Addresses field. Remove dynamic and replace it with the relay URI (e.g. relay:// Click Save.

Once that has been done on both sides (a Syncthing restart may be required), the two hosts should now discover each other through the relay to which they are both registered and folders can now be shared and sync'd. So simple, but definitely not self-evident.

Anyway, I hope the above info spares someone else a couple hours of their life mucking around with Syncthing trying to figure this out.