#libreops

https://drwho.virtadpt.net/archive/2025-10-16/why-is-it-cynicism-when-youre-right/

While tinkering with a new project last week that involved my old BBS tagline database I rediscovered the tagline that I used as the title of this post. I've been trying to keep up with my pattern of posting at least once every month but it's been hard, what with everything going on. Out of an abundance of caution I ran a post I'd been working on past my lawyer for advice and was informed that I should refrain from publishing it, even with multiple disclaimers because we live in a time that would have given Cardinal Richelieu an erection. I guess we really do live in a Cold War-like era once again. We also seem to live in an era where people are hiding their neighbors because there are masked kidnappers executing military raids in the United States.

Anyway, taglines.

Sometimes for the sake of my mental health I poke around with stuff just to have something constructive to do. In this case I was reading through the documentation for Homer, the personal dashboard I use to organize all my stuff 1. I don't really read the docs for it because it's a static web page that reads a config file on the back end and displays links with nice icons when you load it. Not much to it. What caught my eye was that there is now a feature where you can have a message box at the top off the page that can pull from a REST API, parse the output, and display it on a schedule. There didn 't seem to be anything out there that would do what I wanted, which was pick an entry randomly from a datastore and return it as part of a JSON blob so I took a stab at writing one. My first few attempts didn't come to much so I decided to try my hand at PHP, which is a language that I haven't really don't much with (except for one quick hack a few jobs ago). I decided to approach it the way I would a Python project:

Open a text file for input.

Read every line in the text file into an array.

Close the input file.

Pick a random element of the array.

Clean up the text a little.

Pack the string into a little blob of JSON with the key "tagline".

Print the JSON, which sends it to the HTTP client.

Breaking it down like that I was able to look up how to do each task in PHP separately and I had it up and running inside an hour. It's a dumb little hack, not even 30 lines of code, but it was fun to tinker with.

Something I've been kicking around in the back of my head is an article that talks about the state of web browsers in general. These days options are pretty thin on the ground - there's Firefox and all of its forks 2, Chrome and all of its forks 3, and Safari if you use Apple stuff 4. There are, however, some alternatives out there that aren't one of the big three. I've got links stashed away and half-baked plans of putting them through their paces but I haven't had the time or compute cycles to sit down and do it. What I do have is a few months of kicking the tires on Librewolf after Mozilla stuffed LLM support into Firefox, which I trust about as far as I can throw a Buick. 5 Anyway, I ran into two particular problems (well, one annoyance and one problem) that I finally sat down and figured out a while ago. When reorganizing some things in my wiki a few days ago I stumbled across my notes and figured that I should post them because somebody else might find them helpful.

The annoyance was that trying to open something that didn't use HTTPS for its control panel (like most wireless access points and DSL modems) would result in an error window and a "Yes, for pete's sake I'm sure" button the click through. In theory it's a great idea for keeping people from clicking on phishing sites but in practice phishing sites were the very first to take advantage of cheap-to-free and easy to get SSL certificates 6 so it's just a pain in the ass for the rest of it. This is because web browsers in general (and Librewolf in particular) have an HTTPS only setting that needs turned off. To do so:

Type about:config into the URL bar.

Search for dom.security.https_only_mode

Flip that setting to false

Try loading the annoying page in question again.

Also along those lines, and it was a big enough pain in the ass that I kept Firefox installed in parallel only for this purpose was getting through the captive portals at coffee shops and hotels. What I usually did was hit a URL that I know supports HTTP (I Can Haz IP?) and that would be enough to trigger the captive portal (and captive portal detection in the browser). However, for some reason Librewolf wasn't having it and it took me a while to collect enough information to troubleshoot it. It comes down to the above "HTTPS only mode" and a few configuration options that I think were changed as part of the fork-and-rebrand part of Firefox's license. So, here are the config changes I had to make in addition to the above HTTPS-only one:

Type about:config into the URL bar.

Search for captivedetect.canonicalContent

Set it to <meta http-equiv="refresh" content="0;url=https://support.mozilla.org/kb/captive-portal"/>

Search for network.connectivity-service.enabled

Set it to true if it's not already.

Search for network.trr.wait-for-portal.

Set it to true if it's not already.

Search for network.connectivity-service.IPv4.url.

Set it to http://detectportal.firefox.com/success.txt?ipv4 if it's not already.

Search for network.connectivity-service.IPv6.url.

Set it to http://detectportal.firefox.com/success.txt?ipv6 if it's not already.

After making those changes I no longer had any trouble with Librewolf, and it's worked with the last three or four releases of Librewolf.

All of that said and done and said and done again, I leave you with this bit of wisdom:

This message is for one reason alone: To tell the strongest among you - those with the greatest power protect those without. That's my message to the world. --Professor Charles Xavier, X-Men: Apocalypse

I keep forgetting to write about Homer. It's extremely helpful software, and about as lightweight as any recently written web stuff can be these days. ↩

All of which basically have the same codebase, just different branding and user.js files which may or may not be helpful or useful. ↩

Ditto. ↩

I don't know if you can call Webkit it's own browser or not. It's an engine that can be used to build a web browser. ↩

I know, I said "not a fork of one of the big three." I need a daily driver web browser than I can trust somewhat more than the big three and doesn't have nerfed adblocking support. I know that Mozilla said they have no plans to remove Manifest v2 support from Firefox, but much of the Mozilla Foundation's funding comes from Google and a half billion US dollars never, ever comes without strings attached. It is a truism that the best way to control the opposition is to lead it yourself. ↩

https://drwho.virtadpt.net/archive/2025-09-05/picking-up-sticks/

It's been a bit since I've checked in with everyone.

About a week after my last post I found out that I'd been moved back to day shift at work. Through a miscommunication I found this out the hard way, which is to say right after logging in one evening my boss wanted to know where I'd been all day. Long story short, I used the entire week to slowly wind my sleep schedule back to normal, getting up an hour earlier and going to bed an hour earlier every day until I was back on day shift. It didn't take long for my mental health to start improving once that happened. Even introverts need some kind of interpersonal contact, if only to remind oneself that there are other people out there. So, it's back to 0800-1600, which now gives me the option to go out and do stuff if I want, and have to worry significantly less about noise because everyone's awake anyway.

My office is pretty well cleaned up. As cleaned up as it's ever going to be, I suppose. The last shipping crate was moved into storage about a week ago and I now have more floor space than I can recall having since the Before Times. It's kind of odd - there is so much I can do with that floor space (and space on the shelves) but I have to stop myself from doing so, because I need that space to not feel so claustrophobic. Space on my bookshelves is great, but that doesn't mean that I should run out and get more books. Space over my desk is great but that's for displaying things that I didn't have anywhere for before. Maybe once I've got everything set up I'll post a few pics.

Some time ago a colleague of mine put me on to a new piece of equipment, the GL-AXT1800 from GL.inet. It's a travel router, which is to say that when you go somewhere you plug it in, connect your laptop to the travel router, and then use it to connect to the local guest network. Once that's done multiple other devices can connect to the travel router. It doesn't seem like much but there are still places where you have to pay for wireless access per unit, plus there are security concerns; for example, there are circumstances in which it's useful to have everybody all going through teh same VPN connection. It even has a built in mechanism for clearing captive portals called Travelmate. So I ordered one off of Amazon (I don't know if this is an affiliate link or not, Amazon's changed it up so much) and when it arrived I put it through its paces. For one thing, it has easily the best documentation for a piece of equipment that I've seen in a very long time, 172 pages of goodness. Second, it runs OpenWRT right from the manufacturer, which saved me a lot of work figuring out if it'll work in the first place. I was able to both configure it and get it hooked into my exocortex with very little trouble. I'm on retreat right now and using the GL-AXT1800 in my hotel room, and it's required zero messing around to get working. I even have a VPN connection running from the router keyed to the physical switch on the side. All in all, quite a nice piece of kit.

Somewhat along those lines, when I go traveling I normally bring a Raspberry Pi running RasPi OS (I wish they hadn't renamed it from Raspbian - it looks much more interesting when someone pronounces it) and Kodi with a couple of flash drives full of stuff to watch and listen to. 1 Just about everywhere one goes these days has a flatpanel display with at least one HDMI jack, so there is little sense in not putting them to use once in a while. I also, incidentally, used Long Haul for testing that GL-AXT1800 at home. Specifically, I ran a regular system update (sudo apt-get upgrade and sudo apt-get dist-upgrade) to see how the travel router would hold up (perfectly, as it happens) but in the process something got messed up. Namely, when I cleaned everything up (sudo apt autoremove, per the output of apt) it broke Kodi. When I plugged Long Haul in at my hotel I didn't get the Kodi splash screen, just a blinking text mode login screen, and occasionally a black screen with a single cursor at the top left. My travel router makes it possible to SSH in to take a look around, and I noticed thlis in the system logs:pi@long-haul $ journalctl -u kodi.service -xf ... Aug 30 15:10:27 long-haul kodi-standalone[1239]: did not find extension DRI_Mesa version 1 Aug 30 15:10:27 long-haul kodi-standalone[1239]: failed to bind extensions Aug 30 15:10:27 long-haul kodi-standalone[1239]: did not find extension DRI_Mesa version 1 Aug 30 15:10:27 long-haul kodi-standalone[1239]: failed to bind extensions Aug 30 15:10:27 long-haul kodi-standalone[1239]: did not find extension DRI_Mesa version 1 Aug 30 15:10:27 long-haul kodi-standalone[1239]: failed to bind extensions Aug 30 15:10:27 long-haul kodi-standalone[1239]: did not find extension DRI_Mesa version 1 Aug 30 15:10:27 long-haul kodi-standalone[1239]: failed to bind extensions Aug 30 15:10:28 long-haul kodi-standalone[1239]: ERROR: Unable to create GUI. Exiting

Long story short, the DRI_Mesa libraries went missing, probably when I ran sudo apt autoremove a few weeks back. The fix was simple: Reinstall it with the command sudo apt-get install libgl1-mesa-dri and answer yes to any questions you are asked. Kodi started working again immediately.

That's about all I've got right now. I have one or two other things in mind, but those can wait for another post (which really should be dedicated and not a "things I'm doiing right now" entry).

A couple of weeks ago I found that I had to replace the wireless router upstairs because its radios were spiking to extemely high temperatures a couple of times a day. 1 When anything spikes over ten standard deviations in the universe, generally speaking it's probably a very bad thing. So I did a little research and picked up a new wireless router, a Linksys EA8300 (affiliate link) which has very good OpenWRT support, 256 megs of RAM (which is a lot for a wireless router) and 256 megs of on-board flash storage. Most importantly, the EA8300 has three separate wifi radios, which means that it can cover much more area with less of a chance of neighboring wireless devices crosstalking and interfering with each other. Net result: Much better bandwidth, which speeds everything up overall.

Flashing OpenWRT onto the unit was fairly straightforward and unremarkable. Configuring the new router took a little time and involved locating a couple of settings which had changed position over the last couple of years. It was largely a matter of copy-and-pasting from the old router into the new one and then changing the IP networking at the very last minute. Same with setting up WDS for the downstairs router, like last time. Swapping in the new router was the work of a couple of minutes. But then I noticed something weird (isn't there always?)

A couple of systems I have at home dropped off the Net and wouldn't reconnect, even though everything else did within a minute or two. And there didn't seem to be any rhyme or reason behind which systems had vanished. One could reasonably guess that, say, every Raspberry Pi wouldn't come back online, or every weird-ass little sensor built on top of an ESP8266 was having trouble but that wasn't the case. Leandra wouldn't come back online. My weather station outside promptly found one of the wireless networks but the printer and our Kodi server didn't. They weren't on the wireless network so I couldn't just shell in and take a look around, so I had to plug in a spare keyboard and display; given that my office is still full of shipping crates of family stuff from my mom's estate, it was anything but a straightforward exercise. The one thing they all had in common was that every isolated system was throwing "CTRL-EVENT-ASSOC-REJECT status_code=16" errors a couple of times per second. Did any of the machines have a different wireless password? Not that I could tell. Recent system update? Nothing within the last week or so. IPv6? Some of those boxen were already IPv6 enabled and some weren't, so that didn't change. Searching for that error was somewhat difficult given that a fair amount of my exocortex was offline, and the answers I was finding ran the entire gamut from reinstalling Windows 11 (which nothing in the house runs, and certainly doesn't apply to an ESP8266 sensor pod) to HDMI interference.

I decided to start walking back my configuration changes on the new router, one at a time to see which, if any machines would suddenly pop back onto the wireless network. As luck would have it I stumbled onto the solution almost immediately. For every wifi radio in the router (in the OpenWRT control panel for v22.03.2 go to Network -> Wireless -> pick a radio -> Edit -> Interface Configuration -> Wireless Security) there is a checkbox for 802.11w Management Frame Protection 2 support. If 802.11w is turned on, turn it off for every radio, click the Save & Apply button, and then restart each radio by clicking Disable and then Enable 3 (or power cycle the router). If this was the problem you should start seeing other systems start popping back onto your wireless network by themselves.

Why 802.11w caused problems, I don't know. I haven't dug deeply enough into it to tell. I definitely don't know why the set of all of my at-home machines that were having trouble didn't have a discernable pattern. Logically, if Leandra (Intel wireless chipset, running Arch Linux) was having problems, Windbringer (laptop, same chipset, also running Arch Linux) should have also, but this wasn't the case.

Monitoring and alerting of said wireless router done with System Script, a rewrite of my System Bot as a pure shell script for embedded devices. Alerts sent via XMPP using a copy of go-sendxmpp compiled for that system architecture. ↩

In as nutshell, 802.11w protects wifi management frames (which implement stuff under the hood like detecting new devices on the network, negotiating joining and leaving the wireless network, and sending out "Hey, I'm here!" beacons) from certain kinds of wireless attacks, like replay attacks and deauth attacks. ↩

Some weeks ago when I was trying to get the bot that runs my weather station stable, I ran yet again into a problem that for various reasons I hadn't put forth the brainpower to come up with a solution for. Stability implies that a system of some kind doesn't crash, which Weather Station Bot was doing occasionally. Part of this wound up being due to the microSD card Clavicula 1 was running on wasn't well suited to being outside all the time, but part of this was due to bugs in my code that I hadn't quite shaken out yet. While systemfail does a fairly good job of restarting things when they crash, what it's not good at is letting the user know when something crashes or why. In other words, I wanted to know when Weather Station Bot crashed so that I could shell in and take a look around.

Academically, I knew that crash handlers, functions or subsystems that do something when a system trips over its shoelaces and faceplants are a thing. Windows' blue screen of death is a fine example of a crash handler. Rather than just freeze up, leaving the display stuck on the last frame it showed with unresonsive keyboard or mouse, the BSoD gives you at least some idea of what happened 2 and a shot at saving your work before rebooting. Plenty of other software has crash handlers as well, so the question became "How do I write one of my own in Python?"

As it turns out it's pretty easy to do once you know the trick. Tucked away in the sys module is a function named sys.excepthook that you can attach a callback function to. If something terminal happens to the running process sys.excepthook is called by the Python interpreter, which in turn calls the function attached to it. Most of the time this doesn't do anything because there's nothing there by default. If the programmer attaches a callback to it, however, in theory anything could be done as a last ditch effort to save life, limb, and sanity. What I elected to do was stick with the running gag of six robots, all distinct 3 and send myself a message:

# scream_and_die(): A function that is registered with the sys.excepthook() # handler, and fires if and when the bot crashes. def scream_and_die(type, value, traceback): logging.critical("Crash handler executed!") send_message_to_user("AAAAAAHHHH!") send_message_to_user("FC: So much for that robot. Too bad.")

Adding a crash handler was far more simple than I imagined it'd be, to be honest. I'd been putting it off in part because I was concerned about how much work it would be to retrofit the functionality into my bots. In theory I could put anything in that function but what I wanted to do was get notice of a crash so I could examine the system state as quickly as possible (which helped me iron the problems out). Once written it was a simple matter to set scream_and_die() as the callback function and then get back to business:

# Set the crash handler. sys.excepthook = scream_and_die logger.debug("scream_and_die() set as sys.excepthook crash handler.")

I'll get around to retrofitting the rest of my bots and the bot template at some point RSN.

The hostname of my weather station. ↩

If you're a Windows developer, anyway. ↩

A very common problem one has if one has enough files stacked up in one place, is whether or not those files have been copied to another system already. Have they already been copied off? To where on the other system were they copied? Sure, you can deduplicate them through various means but that tends to be kind of a sledgehammer thing to do, especially when one of the things with files is a mobile device. You could always upload the files to a provider's cloud1 storage, like Google Drive or iCloud or something.

But what if you don't want to? What if your Google account doesn't have enough space and you don't want to buy more for whatever reason? Maybe you like self-hosting things you use. Maybe you use several different platforms (Android phone, Apple laptop, Linux server) and want to readily and easily have access to those files from any of them? What if the storage capacity on your mobile device is limited and you can't pop a microSD card in (which is a direction many mobile manufacturers seem to be going in)? What if you want to automatically move those files off as they're saved to keep the amount of usable space at more or less the same volume in your constrained environment? On the flip side of the coin, what if you want to easily copy stuff up to one of your devices, which isn't necessarily an easy thing to do these days?

Enter Syncthing

Syncthing is a tool for keeping one or more configured directories synchronized on multiple devices. If a file is created in a shared directory on one device it gets replicated onto all the other devices that the directory is shared with. Conversely, if a file gets deleted or changed on one device the deletion (or a new, edited copy) gets propagated to all of the others within seconds. You don't need to key in or remember IP addresses or anything like that. If the device is on the Net it's potentially syncable. I've found that Syncthing is remarkably good at figuring out how to punch holes through multiple layers of firewalls, which I had not expected. It takes some tinkering to set up Syncthing the first two or three times (or at least I had to tinker with it for a while) but once it's up and running it's pretty solid.

Unlike commercial storage providers, only your devices ever see those files. The synched files are encrypted when they leave the device, and are decrypted when they arrive on the other devices. Additionally, only devices that you've specifically authorized can have files shared to them. Syncthing is also granular in what and how you share files: If you install Syncthing on some of your devices you can share whatever files you want with any combination of those devices. It is not all or nothing.

Syncthing is available for pretty much every platform you're likely to use and even a few that you probably aren't. I installed Syncthing for Android out of the Google Play store, but if you're feeling saucy it's also in the F-Droid software collection. There is also an implementation of Syncthing for Apple iOS, but I haven't tried it. For Linux users Syncthing is available in the package repositories of Arch Linux, Ubuntu, and Debian (all of which I'm using), and probably others. If you want to play around with the source code or compile it yourself you can always find it on Github.

Let's start with installing Syncthing on two devices, a Raspberry Pi running Raspbian sitting on my desk and an Android phone I've added to my collection of things to test on. Let's assume for the moment that you're SSHing into said Linux box from a laptop or desktop machine. I recommend that, when you do so, you do it like this; I'll explain why in a minute:

{18:47:49 @ Sat Jan 28} [drwho @ windbringer ~] () $ ssh -L 10000:localhost:8384 pi@setec-astronomy

The stuff after -L means, roughly, "Open port 10000 on my computer when you open the SSH connection. Connect it to port 8384 on the computer I just SSH'd into." This is called SSH port forwarding, which you need in this case because there is no desktop app; the control panel is a web page. If you want, you can make port 8384 available to your entire home network later so you don't have to mess with this, but for the moment it is what it is.

The mobile apps, however, do have their own control panel, so don't worry about that.

The Raspbian install is about a straightforward as it gets (and, of course, it works like this on pretty much any Debian-derived install):

{18:25:26 @ Sat Jan 28} [pi @ setec-astronomy ~] (2) $ sudo apt-get install syncthing {18:26:18 @ Sat Jan 28} [pi @ setec-astronomy ~] (2) $ systemctl --user enable syncthing.service Created symlink /home/pi/.config/systemd/user/default.target.wants/syncthing.service → /usr/lib/systemd/user/syncthing.service. {18:26:25 @ Sat Jan 28} [pi @ setec-astronomy ~] (2) $ systemctl --user start syncthing.service

Note: I'm doing this inside of a Screen session. If you do and you get a "Failed to connect to bus" error, it means that your shell doesn't have the XDG_RUNTIME_DIR variable set. To fix this, temporarily disconnect from your Screen session and run the following command:

{18:31:51 @ Sat Jan 28} [pi @ setec-astronomy ~] () $ export | grep XDG_RUNTIME | sed 's/^declare -x //' >> .bashrc

When you resume your Screen session, run the command source ~/.bashrc so the variable will take effect and you won't get that error anymore.

Now, the reason I had you set up that SSH port forward is because we're going to configure Syncthing on your Linux box. Plug the URL http://localhost:10000/ into your web browser. You will see Syncthing asking you if you want to turn on anonymous reporting. I just click "no" and move on with my life, and I suggest that you do as well. Once that's sorted you'll see the Syncthing control panel. "Default Folder" will just be a gray bar on the screen; click it to unroll it into what you see in the screenshot. By default you'll have a directory called Sync/ which is pretty much what it says on the tin. That is the default directory that Syncthing sets up for you and creates it if the directory doesn't exist already. You can get rid of this by hitting the Edit button and then the Remove button, but I advise against it. In general, you want to tweak as few settings as possible to get things running smoothly, and from experience I've found that Syncthing is no different in this regard. For our purposes things are fine as they are.

The second part of our proof of concept is installing Syncthing on a cellphone or tablet. All you need to do is search your appstore of choice for 'Syncthing' and install it. I would also recommend installing a file manager on Android devices because it makes a few later steps much easier to perform. I recommend Material Files because it's easy to use and lets you set bookmarks for some directories on your phone.

Now let's do something simple: We're going to keep a directory on our mobile device synched up with the shared directory on the Linux box. Let's throw a couple of random files in there so we know if it worked:

{16:11:29 @ Sun Jan 29} [pi @ setec-astronomy ~] (2) $ ls -alF Sync/ total 52 drwxr-xr-x 3 pi pi 4096 Jan 29 16:11 ./ drwxr-xr-x 17 pi pi 4096 Jan 29 16:09 ../ -rw-r--r-- 1 pi pi 5947 Jan 28 20:59 laid-off.md -rw-r--r-- 1 pi pi 503 Jan 28 20:59 neologism-thousand-meter-stare.md -rw-r--r-- 1 pi pi 6325 Jan 28 20:59 setting-up-syncthing.md drwxr-xr-x 2 pi pi 4096 Jan 28 18:26 .stfolder/ -rw-r--r-- 1 pi pi 16610 Jan 28 20:59 tools-on-the-bench.md

Start up Syncthing on your mobile device. Tap through until you see the "Storage Permission" screen; this means that Syncthing is asking your permission to read and create files on your device, and it won't work without it. Tap "Grant Permission" and when you're asked, tap "Allow access to manage all files." Then hit the back arrow. Continue. Then you'll see a screen asking you for "Location Permission." What Syncthing is asking is whether or not it's allowed to run only on wireless networks that you give it permission to. You can tap continue and not really cause yourself any trouble. Then Syncthing will churn for a while and then you'll get a popup that says "Battery Optimization." If you tap "Turn off for Syncthing" your phone's power cell will be used up a little faster than usual. You can also tap "Later" to skip this, but you can come back to it later. For our purposes, hit "Later."

Now to connect the two devices with Syncthing. Go to the Syncthing control panel you have open in your web browser and hit the "Actions" button in the top right corner, then hit Show ID. You will be presented with a popup window that says Device Identification and has a long string of capital letters and numbers and a large QR code that contains the same information. We want the QR code because that means not having to retype that device ID which never gets keyed in correctly the first time.

On your mobile device tap on "Devices" in Syncthing. You'll see "No devices found" because you haven't configured any yet. We're about to change this - tap the plus sign in the top-right corner of Syncthing to open the Add Device panel. Tap on the little QR code looking icon next to "Device ID." A window will pop up asking you if you want to allow Syncthing to take pictures and record video; tap "while using the app" because Syncthing needs to photograph the QR code in your web brower. Point the camera at your screen and it'll catch the QR code and translate it into the system ID. Tap on the "Name" field and type in a name you'll remember, then tap the checkmark in the top right corner. You don't need to set anything else here. In your desktop web browser, tap the escape key to close the "Add Remote Device" window.

Now the somewhat annoying part: Telling Syncthing on your Linux box about your mobile device. If you click the "Add Remote Device" button in your web browser you will be shown the Add Device popup. If you go back to your phone and in Syncthing tap the three-bars menu icon in the top left and then Show device ID, you will see the long alphanumeric string and QR code that identifies your mobile. Glance back at your web browser and, if you're lucky you'll see your mobile device's Device ID in the list of nearby devices. If you're not you'll have to retype your phone's Device ID in that field, or find a way to copy it off of your phone so you can just copy-and-paste it. If you tap the sideways V shaped icon on your phone you'll see a scrollable list of ways that you can get that ID off of your phone. I e-mailed it to myself (see the topmost icon), then copy-and-pasted it into the "Device ID" field. I also recommend putting text in the "Device Name" field so that you know what device it is.2 It should look something like this.

The connection's set up, so now let's share the default Sync/ folder with your phone. In your web browser on your desktop, click on the bar that says Default Folder, which will show you the vital statistics for that share (note "Folder Path" which shows you the directory on the Linux box it corresponds to; in this demonstration it's /home/pi/Sync). Click the Default Folder's Edit button and then click on the Sharing tab. You will see a list of Syncthing devices that you can connect the shared directory to. Check the box next to the name of your mobile device (in this example, Crappy Android Burner Phone (affiliate link - it's a nice little phone to keep in your emergency kit, plus you don't have to activate it if you're only using wifi)) and then click the Save button.

Now, back on your mobile phone, look at your notifications (Android: Pull the notification bar down; iOS: I don't know, do whatever it is that works) and you should see a little message saying "Device wants to share folder..." Tap on it, tap on "Default Folder" and give it a name that makes sense to you (for the purposes of this writeup, call it Sync). Don't touch any of the other settings, then tap the checkmark in the top-right corner of the screen. Tap on the "Directory" field because you have to tell it where on your mobile the synched files will live. To make life much easier I'm going to tap Documents in the location picker that comes up because it already exists and it's right there. You can, of course, get more creative later but as I said earlier, keep it as simple as possible to make it work. Tap "Use this folder." When the popup on your phone asks "Allow Syncthing to access files in Documents?" tap the Allow button. Then tap the checkmark icon in the top right corner to save your settings.

On your mobile drop back to the app screen and tap the Material Files icon (or use whatever file manager you prefer; substitute as appropriate for this paragraph). When you're asked if you want to allow Material Files to manage all files, tap the toggle to turn it on and then the back arrow (because otherwise it can't do its job, which is navigate the files on your phone). Tap on the Documents folder that you connected Syncthing to and you should see the files you copied into the Sync directory on your phone.

And now you're done, as annoying as it was. The nice thing is that you only have to do it once - get your devices to know about each other and you're done. Share a directory once and then you never have to worry about it again. Syncthing has the nice property of being "set it and forget it," as they say. Copy files into the Sync directory on one device and they'll be copied automatically over to the other one. Conversely, delete one of the files (or move it out of the shared directory) and it'll be erased from the other devices.

A thing I learned while writing this: if the copies of Syncthing you're using have very different version numbers you will run into problems, usually the devices won't be able to see each other. On the RasPi I used for this demonstration I wasn't seeing the files moving in either direction, and Syncthing on my Android test phone kept throwing a server selected unsupported protocol version 303 error. What I did was follow the procedure here to add the official Syncthing package repo to my RasPi and then did a sudo apt-get update to install the latest stable version of Syncthing. That fixed the problem without needing to do anything else.

Happy hacking!

I hate calling things "cloud whatever." Cisco's one piece of clipart ruined an entire field as far as I'm concerned. ↩

Note: As I wrote this article, I realized that there wasn't much in the way of actual tutorial documentation for some of this stuff. So, I'll be revisiting it in the near future to rewrite parts in such a way to fit this purpose.

If you keep your ear to the ground about the online world, you might have heard something about Google gearing up to break adblocking, ostensibly as a way to crack down on malicious Chrome addons on a wide scale. As a bit of background, Google isn't really a search company because web search doesn't actually bring in much money, nor a products company (though you can pay money for their services (as long as they keep them alive, anyway)). Free services cost money, after all - electricity, hardware, storage capacity, bandwidth - they aren't free. Google is an advertising company with a lot of leverage over how the Net can be used.

To wit (and I wouldn't be surprised if my blog all but disappears from Google's earch indices for writing this), the Manifest API is the Chrome subsystem that makes it possible to write third-party addons to plug additional functionality into the browser. Additional functionality such as ad blocking, which makes the Net actually usable for most us but also cuts into their revenue. A year or two ago Google announced that version 2 of Manifest was going away, to be replaced with v3. At first scratch this doesn't sound unreasonable because new releases happen. However, not a few skilled and knowledgable technologists have figured out that Manifest v3 breaks adblockers first and foremost by preventing addons from determining what HTTP requests can be made, which is how adblockers work ("Oh, this thing is on my ad blocking list, I won't execute this request.").

If you've ever tried to browse the web without an adblocker, you know all too well how slow and poorly designed many websites are due to all the trackers and advertisements that get loaded.

The obvious solution should be to change browsers, to something like Firefox. Unfortunately the Mozilla Foundation is also going to implement Manifest V3 around the same time. Which will also break adblocking in that browser as well as everything derived from it. While Mozilla makes quite a bit of money from partnered orgs that pay to use them as a platform, as well as partnerships with search engines and distribution deals, Google also funds them. Perhaps I'm thinking conspiratorially, but when a megacorp1 sends a lot of money your way there are usually strings attached, and those strings don't negatively impact said megacorp. It would be incredibly, naively foolish of them to not do so.

At any rate the Manifest v3 changes limit the number of filtering rules to 30,000 and they can't be easily updated periodically.2 So, let's stick a pin in this and talk about something else for a moment.

You might have heard some folks talking about something called Pi-Hole, which is a service that you can deploy on your home network (or, as I'll talk about later, your VPN server) that does adblocking at the DNS level. Basically it's a replacement DNS server that has its own blocklists, just like adblocking browser addons. When your browser (or anything, really) on your network makes a DNS request for something (say, your browser loads a page and part of it is a bit of Javascript that tracks your activity), the DNS server on your network (which is usually built into your wireless access point) asks your Pi-Hole to resolve it for you. The Pi-Hole checks the request against the blocklists that it has configured, in this example finds it and sends back a response saying the IP address is 0.0.0.0 which, per RFC 5735 means "Forget it, that's not a valid IP."

Your web browser (or whatever else) then says, "Oh, well," and moves on with its life. You don't get tracked and stuff loads faster.

So I built a Pi-Hole for my home network. Scrounging around in my inventory I discovered that I had an older Orange Pi single board computer (from before the Silicon Dry Spell) in a drawer that I then installed Armbian on. I plugged it into the private side of my wireless access point with a length of Ethernet cable and gave it a static IP address:

OpenWRT -> Network -> DHCP and DNS -> Static Leases, select the hostname of the box (Octothorpe) in the MAC-Address column, retype the hostname in the Hostname column, select it in the IPv4-Address column, Save & Apply

This is necessary because your DNSes must always have the same IP address to be useful because you want to find them in the same place all the time. Once that was done I was able to SSH into Octothorpe (the name of my new Pi-Hole), run the configuration utility, and then install the Pi-Hole software using the official instructions. Always a bit paranoid about the stuff I install, I used Method 2 and read through the basic-install.sh script before running it. The installation went smoothly and was almost boring. I then went to the LAN interface on the AP (again, running OpenWRT) and configured them to use Octothorpe as its upstream DNS.

Network -> Interfaces -> click the Edit button for each one -> scroll down to "Use custom DNS servers) -> type the IP address of your Pi-Hole (it should be a private address) -> click "Save & Apply"

Even before you configure your Pi-Hole install it's a regular old DNS, so you won't break anything. Then log into your Pi-Hole with a web browser (if you follow the instructions exactly you'll be hitting http://pi-hole/admin/, in my case it's http://octothorpe/admin/) and configure it. There doesn't seem to be any official docs for doing this, so here's a first attempt on my part.

For some reason it's really hard to find a decent list of blocklists to use; I spent quite a while digging and after some experimentation and testing here are the resources I found the blocklists I use:

firebog.net

Ad Wars

Ad Away

hostsVN

pgl.yoyo.org

Steven Black's Blocklist

Steven Black's Fakenews Sites

If you are concerned about family members falling into a certain conspiracy community's rabbit hole you may wish to investigate this blocklist.

At any rate, when you log in you'll see a dashboard that looks like this. To make your Pi-Hole do what it's supposed to do the first thing is to scroll down and click on Adlists on the left-hand side; this is where you specify which lists of things to block. To add each blocklist, do the following:

Copy the URL to the blocklist in question in your browser's URL bar.

On the Adlist group management page, paste the URL into the Address field.

Optionally, type a comment in the other field. It's generally a good idea to leave a note for yourself here that says what the blocklist is for (ads, malware, whatever).

It should look something like this.

Click the Add button.

If you scroll down a little bit you'll see your configured blocklists. You're not done yet, though, now you have to tell your Pi-Hole to download and incorporate the contents of those lists into its database and keep them up to date. If you read the text at the bottom of the "Add a new adlist" box you'll see "Please run pihole -g or update your gravity list online after modifying your adlists." While you can shell back into your Pi-Hole box it's much easier (and faster) to just click the "online" link that will take you to the "Update Gravity (list of blocked domains)" page. Click the big blue "Update" button. It'll take a little while to download the new blocklists (every time you click it, every blocklist you have will be updated), sort them, eliminate the duplicates, and add them to the Gravity database.3 All you really have to do is wait for the green "Success!" box to appear when it's done.

It is helpful to configure a couple of upstream DNSes on your Pi-Hole, also. Here's the thing: Only resolution requests that your Pi-Hole forwards will ever show up, which means that anything caught by the ad blocking filter will never appear, thus helping to preserve your privacy. Click on "Settings" on the left-hand bar, then "DNS" on the top row. I like to use OpenDNS and Quad9 (unfiltered, no DNSSEC) for this. Check all of the boxes for those two services (for both IPv4 and IPv6) and make sure that "Allow only local requests" is checked. If you scroll down a bit I would recommend also checking "Never forward non-FQDN A and AAAA queries" and "Never forward reverse lookups for private IP ranges" for privacy reasons. I find it also speeds things up a little bit by avoiding some pointless DNS lookups. Then scroll all the way to the bottom and click the Save button. If you are concerned about privacy (and if you're setting up network-wide adblocking you probably are) you can also tweak some privacy settings for your Pi-Hole's statistics and dashboards. At least when you're fine-tuning and making sure everything's working, it might be a good idea to set "DNS resolver privacy level" to "Show everything and record everything," because you might need the information to debug. When you're sure everything's stable you can change the privacy settings to "Hide domains and clients" unless something starts acting up. For maximum privacy (or if the system you're running Pi-Hole on doesn't have a lot of available storage) you may wish to set it to "Anonymous mode," which logs nothing. At any rate, make your choice (which you can change later) and click the "Apply" button.

This configuration is highly stable but a little weird. If you look at my dashboard for the last 24 hours (as I write this post) several tens of thousands of DNS queries were made in the last 24 hours, but only two clients were noted, localhost and _gateway. The thing about this is, when you have a really common home network setup (a wireless access point that is both DNS and DHCP server, and every clients runs everything through or to services running on the AP) everything is coming from _gateway (the wireless access point) as far as Pi-Hole is concerned. It's not anything to worry about but it can be confusing at first.

Long-time readers are probably somewhat aware of my network at home and all the stuff on it. You're also probably wondering just what I get out of having a Pi-Hole installed. As I was typing this part of the post I took a quick screenshot of Octothorpe's stats for the last 24 hours. As you can see, everything on my network made a grand total of 41,998 DNS queries in the past day, of which 16,941 of them (roughly 40%) were detected and blocked by Octothorpe.4 If I had more smart devices on my network that I didn't build myself I'm pretty sure those stats would be way higher, as Matt C.A. Smith discovered about two years ago.

I also have a VPN server running Ubuntu Server LTS that I keep forgetting to write up which offers both OpenVPN and Wireguard with an in-house DNS running Unbound for clients to use. Again, I used the standard installation procress from the Pi-Hole documentation but ran into a couple of problems. First of all, Pi-Hole requires and installs lighttpd for its control panel, which is written in PHP. My VPN server had Nginx installed and the two battled it out until I finally uninstalled Nginx.5 Second, on Ubuntu Server the installation script didn't install two important PHP packages, php-pear or php-json. The obvious fix is to install them manually: sudo apt-get install php-json php-pear

The third problem is that one of the packages, php-json isn't enabled so that the PHP service can't find it. The fix is a little tricky to figure but here's how to do it:

sudo su - cd /etc/php/7.4/cgi/conf-d ln -s /usr/share/php7.4-json/json/json.ini 20-json.ini cd /etc/php/7.4/cli/conf-d ln -s /usr/share/php7.4-json/json/json.ini 20-json.ini # Bouncing lighttpd also restarts php-cgi. systemctl restart lighttpd

Once you've done this (and you might want to do this before running the Pi-Hole installation script) the control panel will work as expected. If it might help, uninstall Pi-Hole, install those PHP packages, and then re-install it. Then I had to make a couple of minor modifications to my VPN server. I first had to shut Unbound down to get it out of the way for a moment: sudo systemctl stop unbound

Unbound from Ubuntu packages puts all of its configuration information into separate files in /etc/unbound/unbound.conf.d/*.conf to separate them. I have one configuration file for each VPN service, like so:

{23:46:04 @ Sun Oct 23} [drwho @ jackpoint:(3) unbound.conf.d]$ pwd /etc/unbound/unbound.conf.d {23:46:05 @ Sun Oct 23} [drwho @ jackpoint:(3) unbound.conf.d]$ ls -alF total 24 drwxr-xr-x 2 root root 4096 Sep 20 20:36 ./ drwxr-xr-x 3 root root 4096 Aug 17 06:07 ../ -rw-r--r-- 1 root root 2412 Sep 20 20:36 openvpn.conf -rw-r--r-- 1 root root 302 Aug 27 2018 qname-minimisation.conf -rw-r--r-- 1 root root 190 Aug 27 2018 root-auto-trust-anchor-file.conf -rw-r--r-- 1 root root 2426 Sep 20 20:34 wireguard.conf {23:46:06 @ Sun Oct 23} [drwho @ jackpoint:(3) unbound.conf.d]$

openvpn.conf and wireguard.conf both describe what (VPN) network interface and port to listen on as well as sundry other configuration options. For our purposes they aren't relevant. What is relevant, however, is what port Unbound listens on for each VPN interface. To make room for Pi-Hole I moved each port from 53/tcp and udp to port 5400/tcp and udp (arbitrarily chosen). The salient part of the openvpn.conf file now looks like this:

server: interface: 10.8.0.1 interface: 127.0.0.1 port: 5400 do-ip4: yes do-ip6: yes do-tcp: yes do-udp: yes

The wireguard.conf file looks pretty much the same, only the first interface line reads 10.9.0.1. Restart Unbound: sudo systemctl restart unbound.service

Once that is done, I went back to the Pi-Hole admin panel on my VPN server, Settings -> DNS. Rather than turning on any upstream DNSes I checked the boxes for Custom 1 (IPv4) and Custom 3 (IPv6) and entered the loopback addresses I'd just configured for both and then hit the Save button:

Custom 1 (IPv4): 127.0.0.1#5400

Custom 3 (IPv6): ::1#5400

The way the VPN server is now set up, Pi-Hole's DNS resolver (called FTL) is listening on ports 53/tcp and 53/udp on Jackpoint's loopback interface and the two VPN network interfaces. Unbound is listening on ports 5400/tcp and 5400/udp on the same interfaces. There's no real reason they have to be but it doesn't hurt anything, either. The Pi-Hole, whenever a DNS resolution request passes all of its blocklists, asks Unbound for the answer. Unbound then does the usual DNS resolution request song and dance to get the answer, caches it for later, and returns it to Pi-Hole. Pi-Hole then returns it to the VPN client.

One thing I did notice was that the Pi-Hole doesn't seem to prevent Youtube advertisements from butting in. Keeping uBlock Origin enabled in my web browsers does, however. I don't yet know if it's actually possible to use DNS level blocking for this. A stumbled across this blocklist while researching this article but the last time it was updated was about six months ago, and I haven't tested it. There may be others out there, I'm not sure. The reason I thought it important to mention is due to the fact that, even though ad blocking addons will be nerfed by Manifest v3 I think it might be feasible to use browser-side ad blocking to filter commercials out of online streams6 and network-side DNS ad blocking to get rid of the rest. It's something I'll have to test when I have some time.

Google's revenue is, as of June 2022.ev, 69.69 billion US dollars (nice) and the year's not over yet. They also have offices on six out of seven continents with over 170,000 employees globally. If that doesn't fit the definition of a megacorporation (local copy) I don't know what does. ↩

I don't think anybody's done a study of how many rules are in a blocklist on average. I did some digging and didn't find anything useful. So I took a look at my uBlock Origin configuration on Windbringer (installed in Firefox v105.0.1, 64-bit build, Arch Linux), did some match, and the average number of rules was 13942 (rounded up to the nearest whole number), not counting any custom rules I added myself. The total number of rules in this configuration was 153359 10 blocklists were the ones that uBlock Origin has turned on by default, one was the Online Malicious URL Blocklist that I added myself. Of note, three of those lists are malware and malicious URL blocklists. ↩

I really don't know what it's called that. ↩

This is everything on my network that is not otherwise running an adblocker. Windbringer as well as my work laptop both have uBlock Origin installed, and my personal cellphone and tablet both use Blokada for the same purpose. If I didn't I'm fairly sure that those figures would be much higher. ↩

Amusingly, after I stopped using Nginx on Jackpoint it suddenly became stupidly simpler to proxy YaCy for my website's search engine. ↩

Note: I'm retraining on a new keyboard as I write this, so I apologize for any egregious typos in advance.

Over on birbsite a couple of weeks back a thread was spun up about your worst fuckup on the job and I figured that, because it's been nearly twenty years I'd tell my worst story. However, much to my chagrin and concern I found that I'd bobbled a few of the details. Seeing as how it was one of my career's formative moments this scared me quite a bit. I'd been considering putting some work in on my memoirs anyway (because, as I write this, I'm coming up on the first anniversary of my mom's Greater Feast), so why not start things off this way? And it worries me a bit how the memory of such an important thing could have faded so much. So, time to do a little background research and fix it up a little.

In late 2003.ev, after finishing my degree I finally landed my first full time gig in the security field (as a permatemp, but still) for a county government back home. I started out there on a team of IT temp workers taking inventory of the facility, but a couple of weeks into the gig it turned out that I was working alongside a guy that I ran into at Defcon in 2001.ev (we geeked out on cryptography for a couple of hours) and he pulled a couple of strings to get me detached from the IT inventory team and onto his security team (bringing the number of people on the team up to two). I was duely issued a desk in the cubicle gulag and a fairly old Dell workstation (Pentium-II CPU, 32 megs of RAM, 2GB hard drive, Windows XP), which was one of the more powerful workstations on the floor, and was told to familiarize myself with the network because I was going to be building some IDSes with Snort as my first assignment.

I figured that the easiest way to go about that was to run an nmap scan of the network, record the output, and read through it to see what I was dealing with. I'd been using nmap since college so I was already familiar with it and what it could do. I hasten to add that, in the documentation, the user it warned that port scanning can crash services or entire systems if you're not careful. I'd been using nmap since 1998.ev or therabouts and had yet to crash any machines in my network, so I'd chalked the warning up to an overabundance of caution. I figured out the network addressing configuration from the output of ifconfig, fired off a scan, and went to get lunch because it was going to take a while.

Something I was not aware of was that the network in question had a dinosaur pen with an honest-to-pete mainframe, an IBM S/390 running OS/390. Inside of that monster of a machine were running a large array of virtual machines, each of which was running a crucial bit of business infrastructure - payroll, archival (I found out later that there was a team of greybeards maintaining an entire library of reel to reel magnetic tape storage - they were migrating away from reel to reel to tape cartridges that were newer, held more data, and were smaller. Their VM was running in there, too.

When I got back from lunch, my boss was standing in my cubicle holding an armful of greenbar printout about four inches thick. I hadn't seen greenbar since undergrad, because we used it to print out our source listings on the campus VAX, so this immediately worried me. You don't break out the greenbar hardcopy without good reason. Pete threw the printout on my desk and ordered me to look at it and tell him what it was. I flipped through it and felt my blood run cold. I'm no mainframe expert, but when I see the strings "OS/390," "virtual machine," and "crash dump" over and over and over again, each time referencing a different hostname, I can add 2 and 2 and get 4. The presence of the string "TCP/IP" strongly implied that my nmap'ing the network had caused the TCP/IP stack of each virtual machine to shit itself, causing the mainframe to print a crash dump to the default printer. Eventually, OS/390 had enough of my shenanagains and shot itself in the head.

One mainframe, dead on arrival.

I quietly told my boss what I thought it meant, and he confirmed my worst fears. "Do you know how long it's going to take the admins to IPL that S/390? At least two weeks, maybe more."1

At that moment my dreams of getting into security as a career seemed to turn turtle and sink. I'd be lucky if I could land an IT position fixing printers after that. Maybe I could go to grad school for a few years, get a job as a TA and a masters' degree, and let the heat die down. So, I turned, walked to the copy room, grabbed a mostly empty cardboard box of copier paper (putting the last two reams on the shelf), and began packing my few office belongings for the frog march out of the building.

To this day, I still don't know why Pete didn't treat me like a Russian oligarch. I'd certainly earned it. I didn't get fired. I definitely got one of the worst dressings down of my life; the greybeards in the dinosaur pen beating the hell out of me would have hurt less. I'm pretty sure that they wanted my head as well, not that I could blame them. This was, as a bit of IBM folklore would have it, a million dollar education.2

What my boss drilled into my head that day (note: if you're easily squicked, don't click on that link - you have been warned) was that passive measures are, in some ways, just as effective as active ones. You can learn a great deal about a network (if you're positioned in the right places, anyway) using, say, tcpdump and analyzing the packet captures, or examining the ARP cache of your workstation or a server you have access to. Firing a metric assload of strangely configured packets at a couple of million IP addresses that may or may not exist3 is just begging to get whacked upside the head by Murphy's law.

The other thing I learned was that warnings are published for a reason. There are theoretical problems, to be sure, but if someone puts a notice in their documentation to the effect of "You can kill a machine by running this tool against it and fuck things up for weeks," chances are they made the same mistake (possibly on a smaller scale) and put the warning in there so that others could learn from their mistake.

So, if you're just getting into the business, please learn from my mistake. I got really, REALLY lucky. You might not.

It took closer to three and a half weeks. ↩

My takeaway from this was that, assuming no malice or sabotage are detected, give newbies the same education and second chance. ↩

In the last couple of weeks, a meme has been going around the blogging community where people talk about the stuff they use on an everyday basis. So, I figured, why not. I write about everything else, right?

Hardware-wise you're probably already familiar with Windbringer's specs because I document all of my laptops. It's also no surprise that I run Arch Linux everywhere I can get away with it. Not a whole lot has changed on that front. I'm running the MATE Desktop Environment as my daily user interface, I'm trying to get used to neoVIM as my go-to text editor (none of the third-party GUIs grab me, so I'll probably rig up a Mate Terminal window instead), and Vivaldi as my web browser, because Google is breaking adblocking in Chrome by requiring v3 addon manifests and is pretty much forcing Firefox to go the same way.*

Will Vivaldi go the same way, because it's built on top of Chromium? I don't know. They say they won't but I don't know how difficult it will be to swim against that particular current. Time will tell, an d another blog post will undoubted come of it.

As for what I have Vivaldi tricked out with, I have a set of extensions installed that I find useful. Love it or hate it, the contents of the Chrome Web Store are compatible with Vivaldi so I pulled everything from there. In alphabetical order, first I have Downloads Router because it makes it easier to save files by re-adding user interaction, Font Changer Plus because I can tweak font sizes without wrecking entire pages (yes, I need new glasses), Lastpass for credential management (I also haven't found a self-hosted alternative that has the features I use all the time, such as having a mobile app as well as plugins for browsers that I actually use), uBlock Origin (I know that Vivaldi has much of that functionality built-in, but it's not nearly as configurable), Wallabagger for times when I don't feel like running links through Paywall Breaker (which also archives the pages on a half-dozen services), and Yet Another REST Client for hacking around with REST APIs.

Listening to music? MP3s and FLACs stored on Windbringer played with QMMP. For renaming and retagging music I use Musicbrainz Picard, which is also nice because I can use it to fix up the tags on the music stored on my phone by ejecting the microSD card, plugging it into Windbringer, and loading up the files. Video playback? VLC or Kodi. Writing code or blogging? vim or neovim with GNU Screen if it's not on Windbringer. Instant messaging (and communication with my exocortex) - Psi Plus (though it takes a lot of tweaking to make it nice - I wish I could export my configs to re-import elsewhere) and Signal's desktop client. File sharing and ocassionally chatting - Keybase even though it's effectively dead (thank you and fuck you, Zoom).

I don't think I've written up Leandra's hardware specs since the last time I worked on her. I last rebuilt her in 2020.ev because her old configuration was getting a little long in the tooth for my research. I started with an Asus ROG X570 Crosshair VIII Hero motherboard (affiliate link), which has a very nice 802.11Ax wifi chipset on board, an M.2 interface for an SSD (which is bootable, for the record), and USB v3.2 jacks all over the place. I paired it with an AMD Ryzen 9 3900XT (affilate link) processor, which has 12 cores (24 threads) at 4.7 GHz and a Cooler Master Hyper 212 cooling system (affiliate link). I also picked up a matched pair of G.Skill RipJaws V 32 GB memory modules to triple the amount of RAM Leandra had available (eat your heart out, Acid Burn). And, also because the new processor core and mainboard weren't compatible with her old RAM. Oh, well. Rounding the rebuild out is an Asus GeForce GTX 1660 (affiliate link) (the output of lspci says that the card is an nVidia TU116) with 6 GB of onboard video RAM and (most helpfully) CUDA support.

For fun I ran John the Ripper compiled with CUDA support armed with about a half terabyte of dictionaries against a certain .zip file and after a couple of days (because I tried a number of different character encodings and word mangling rules) and got a couple of passwords that seemed to work. In case you're curious I got the wordlists from this Git repo, this repo and used wordlistctl to pull down the rest. As for desktoppy application stuff? I don't use Leandra for that, she's a pure server. I do pretty much everything from inside a Screen session. Sorry, nothing interesting there.

I also have never written up my work laptop because... well, it's a work laptop. It's a 13-inch Macbook Pro, model A2251. We use Google Chrome because it can be centrally managed and everything else I do for work uses either vim or SSH. Nothing interesting or special here, either.

As for the obligatory keyboard writeup, I'm using a Redragon K552 mechanical keyboard that I change the backlighting pattern on whenever I get bored (more or less) and a generic USB clone of the Apple touchpad plugged into a USB-C hub. I have a boring Dell flatpanel display next to me on the workbench plugged into a mini Displayport-to-USB-C adapter, which then gets plugged into an available USB-C jack on the laptop I'm using at the moment. I also keep a couple of HDMI-to-USB-C adapters handy.

And that's pretty much it. You're probably reading this several weeks after everybody's forgotten about the "describe your everyday desktop" meme. That's fine. I do scheduled posts and I'm sticking to it.