I’m writing this mostly because I want to print it out and add it to my cookbook, but since I don’t have anything else to post about right now, you get to come along for the ride.

The rub is flavorful but not too spicy. My kid loves it.

Equipment

• Gas grill with top rack
• Grill tongs
• Meat thermometer
• Small bowl for mixing rub
• Large bowl for seasoning chicken
• Small bowl for BBQ sauce
• Silicone brush for BBQ sauce

Ingredients

Meat

• 2 pounds chicken wings, cut up
• Around 1 1/2 pounds chicken legs (about six legs)

Rub

• 2 tablespoons brown sugar
• 1 tablespoon chili powder
• 1 tablespoon paprika (smoked preferred)
• 1 tablespoon black pepper
• 1 tablespoon salt
• Some quantity of garlic-infused olive oil

Dressing

• Your favorite BBQ sauce

Instructions

Preparation

1. In a small bowl, mix all the components of the rub together until they are evenly distributed throughout the mixture.
2. Place all of the chicken in a large bowl.
3. Drizzle the chicken with garlic-infused olive oil.
4. Sprinkle about 1/3rd of the rub over the chicken.
5. Mix the chicken around in the bowl until the rub is evenly distributed.
6. Repeat drizzling the chicken with oil, dusting it with rub, and mixing it two more times, until you are out of rub

Cooking

1. Preheat your grill at maximum heat with the lid closed for 10 minutes.
2. Using tongs, arrange your chicken on the top rack of the grill.
3. Close the lid of the grill and cook the chicken for 8 minutes.
4. Open the lid and flip the chicken over.
5. Close the lid and cook the chicken for another 8 minutes.
6. Using the meat thermometer, ensure that your chicken has reached an internal temperature of 165 degrees Fahrenheit. If it has not, lower the grill’s heat to medium-low to avoid charring the skin too much, flip the chicken, and grill it for an additional 3 minutes. Continue flipping and grilling for 3 minutes until the chicken has reached an internal temperature of 165 degrees Fahrenheit.
7. Lower the grill’s heat to the minimum.
8. Using the silicone brush, baste the chicken with BBQ sauce.
9. Close the lid and cook the chicken on minimum heat for 2-3 minutes, in order to set the sauce.
10. Open the lid and flip the chicken over.
11. Using the silicone brush, baste the other side of the chicken with BBQ sauce.
12. Close the lid and cook the chicken on minimum heat for another 2-3 minutes.
13. Remove the chicken from the grill and serve it.

Photo

Your chicken should look something like this:

Astro is great, and I still like it, but back when I started this blog it was version 1.x, and as of this writing, the latest version is 4.x. Dependencies move pretty fast in the JavaScript world, and I had not been keeping up at all, with the result that the code that generates this site has become a bit of a bit-rotted mess. When I first got the notion to write something for WeblogPoMo, it actually took me several hours to get the site in a state where it could even build again.

I’ve been working on giving everything a fresh coat of paint and getting it all working with the latest-and-greatest, but I’ve ended up in a very deep yak shave, doing a bunch of late-night coding, and while this is fun, it leaves me with NoPo for the PoMo! So, here’s an intermediate update on what’s happened so far and what I’m still working on.

Moved from GitHub Pages to self hosting

Instead of serving this blog from GitHub Pages, I’m now hosting it on my own server. Initially, I did this because I could get the blog to build locally, but not with GitHub Actions 😄 — the quickest way for me to get a post out for WeblogPoMo was to switch the DNS for jordemort.dev and point it at a server where I could deploy my locally-built copy. I had been playing with the idea of doing this for a while, and not being able to get my build going in Actions provided the kick in the ass I needed.

Moving to self-hosting has a few upsides:

• GitHub doesn’t need to know what you’re reading on my blog
• I can get actual server logs, instead of just client-side analytics
• I can pick off certain URLs and do things other than serve static content with them

Speaking of picking off certain URLs…

ActivityPub integration

This blog is now an ActivityPub actor. This means that you can now follow this blog with Mastodon or your local moral equivalent at the following address:

@jordemort.dev@jordemort.dev

This is powered by a neat thing called Hatsu that consumes my JSON feed and turns it into ActivityPub activities. You can play with the API if you’d like!

I haven’t quite finished setting this up; there’s some <link> tags I need to generate in my page headers for complete integration, but following the blog works!

Coming soon: PageFind

Implementing my own client-side search was fun, but the libraries I built it on were already unmaintained when I built it, and PageFind is a much better and more complete implementation of the same idea that I won’t have to maintain myself.

Coming soon: better embeds

This is the big yak. I’ve been using remark-plugin-oembed to render embedded versions of things like YouTube videos and tweets on this site. It was kind of broken by upgrading other things, so I decided to build my own replacement.

I’ve never really loved how oEmbed works; most providers give you some perfunctory metadata, and then a chunk of HTML that you’re supposed to just include in your page. Generally, the HTML that you’re given contains an <iframe>, that loads an “embedded” view of the link from the site that you’re linking to. Twitter’s oEmbed HTML gives you a <blockquote> instead, along with a <script> that styles the blockquote, loads any photos or videos, and does who knows what else.

I hate this. I hate blindly including HTML on my site that I did not write or generate myself. I hate making your browser communicate with a third-party that you did not consent to communicate with, simply because you viewed a page on my site with an embedded link. I hate running random third-party scripts in the context of my site, which are probably collecting and all sorts of analytics that neither you nor I consented to. I hate everything about it.

So instead, what I’m working on right now is gluing together oEmbed, Metascraper, and FxTwitter, into something that generates embeds that look like this:

Some points to note:

• No more third-party styling; all embeds will be styled consistently with the rest of the site
• No more third-party assets; everything needed to display the embedded will be served from jordemort.dev.
• No more third-party players; instead, standard HTML <audio> and <video> elements will be used.
  • If you play audio or video, it will still be loaded from the third-party server, but preloading will be turned off, so nothing will be loaded until you specifically ask your browser to do so.
• No more rot; all the data needed to regenerate an embed will be cached in the site’s repository after the first time it is generated.
  • I’m thinking about also automatically submitting anything I embed to the Wayback Machine and/or archive.today.
• A button to go ahead and load the third-party embed anyway, if you still really want to do that for some reason 😜

Anyway, all of that probably needs another night or two to finish up, which is what I’ve been saying for the past three days or so, but I just keep on having more ideas on how to make them even better, so… you know how it is.

From this end-user’s perspective, Just Walk Out was magical. I used to be able to grab a cart, arrange my bags in it, fill them up, and leave. A few hours later, Amazon sent me a bill. What I especially liked was being able to bag as I go; this allowed me to have dedicated bags for meat, produce, dry goods, non-food items, and so on — this made unloading things when I got home so much easier.

Of course, it wasn’t magic on the backend. If you ever looked up at the ceiling while in the store, you would notice a grid containing a mind-blowing number of cameras, spaced 3 feet or so apart from each other. These cameras recorded your every move through the store, through multiple angles. When you left the store, this footage was combined with data collected through a network of sensors on the shelves and sent to a human working in India to review and ring you up. A lot of people seemed surprised to learn it wasn’t powered by AI, but it was always obvious to me that there was still a human in the loop, given the several-hour delay between leaving the store and receiving your receipt.

Sadly, the magic is now gone; Amazon decided that these humans cost too much and took too long to do their jobs, so they killed the Just Walk Out program in their stores. In its place, they now offer the Dash Cart.

Using the Dash Cart is a truly wretched experience. After about 5 minutes with it, I missed Just Walk Out so badly that I put everything back on the shelf, logged out of the cart, and just walked out of the store, never to return again.

The cart is unlike any other grocery cart you’ve used, in a bad way. It is essentially a large rigid plastic bin on wheels. It features a comically large grey box housing a touch screen and a sensor package above the handle, where the child seat would normally be, which extends over a good portion of the cart. If you’re shopping with a young child that can’t walk on their own for the entire trip, well, no, you’re not; not with this cart, anyway. If, like me, you frequently used this space for delicate produce and squishable items like bread and chips, a small auxiliary bin is provided underneath the sensor package, but it doesn’t have enough clearance to hold a bag standing upright.

Unlike the carts currently on display on Amazon’s PR website, the cart I used didn’t have any sort of venting on any of the bins or on the lower level. Instead, they were just solid plastic. This means that any fluids that leak or are spilled in the cart over the course of its use are there forever, until it is hosed out. If one was left outside in the rain, it would fill up with water.

After I logged into the cart (by using a hidden unlabeled scanner on the underside of the cart that the attendant had to show me,) the screen instructed me that it was a good time to load my own bags into the cart, if I had brought any. I dutifully started arranging my bags in the cart; it gave me seemingly about 30 seconds to do so before it started screaming at me and demanding to know what I had removed from the cart. After a couple of attempts at appeasing it, I started to ignore its complaints and went about finishing arranging my bags. Keep in mind that this was in the vestibule of the store; I hadn’t even gotten within reach of any merchandise yet.

Once I had my bags in place, I was seemingly able to negotiate some sort of peace with the screen by reassuring it that I hadn’t removed anything. Unfortunately, this peace was short-lived; any time the cart was jostled (by, say, pushing it around the store,) it would again demand to know what had been removed. It asked me what I had removed from the cart at least three more times as I made my way from the vestibule to the produce section.

I got as far as the cooler containing grapes and strawberries, selected a carton of strawberries, and put it into my produce bag in the cart. The cart beeped at me. “Whoops,” I thought, “I forgot, I have to scan things now.” I removed the strawberries from the bag, found the barcode, and held it up to one of the two large openings in the sensor package that presumably contained cameras. It scanned the barcode and added the strawberries to my receipt. Success! “Well, this is less convenient but I can make it work,” I thought.

I then selected a bag of grapes. I found the (clearly legible, undamaged) barcode on the grapes and held it up to the cameras; the cart made a positive sounding noise, so I put the grapes into the produce bag. I went to move on to my next objective, but then the cart indicated that it did not recognize the item I had put in the cart.

Folks, I tried to scan the bag of grapes no less than six different times. Each time that I did, the cart would make a positive sounding noise, as if it had recognized the item, and then pop up the screen indicating it had not a few seconds later, after I had put the grapes back into the bag. This was a particularly shitty experience because the screen is angled in a way that it is not visible unless you are standing in the back of the cart, but the sensor package is too large to be convenient to reach over; you have to scan and load each item from the front or side of the cart, and then walk around to the back to be able to see if it worked.

At this point I decided the whole endeavor was untenable. I was shopping for a week’s worth of groceries for my family and had about 70 items on my list, and I came to the conclusion that repeating this song and dance 69 more times would not be very nice at all. I put the strawberries back, logged out of the cart, took my bags back to the car, and drove over to the local incarnation of Kroger, where I was able to complete my shopping without having to deal with any testy machines. Now that Just Walk Out is gone, there is no reason whatsoever for me to choose Amazon over any of their competitors for groceries, and many reasons not to, like that shelf full of green potatoes.

In short, the experience of using the Dash Cart is very similar to using one of those early self-checkout machines (UNEXPECTED ITEM IN BAGGING AREA) except that you push the machine around with you in the store and it harasses you the entire time that you’re shopping. It should be embarrassing to Amazon that these things can’t reliably scan a bag of grapes with a sensor package larger than many “self-driving” vehicles. The only good thing about these carts is that they’re so poorly designed that they surely won’t last. If rain, cars, and the rough-and-tumble life of a grocery cart in a parking lot don’t do them all in by the end of summer, a Chicago winter will surely finish the rest of them off.

I do still fully intend to get back to a bunch of that stuff, but… later, ya know? I’ve decided I’m taking a well-being year :)

Anyway, it’s WeblogPoMo 2024! Given historical trends, I probably will not be posting every day this month, but in the spirit of things, I thought I’d at least try to post a little.

Vacation

As of a roughly a week or so ago, my wife and I have been married for 10 years! Continuously!

To celebrate, we ditched the kid with his aunt & uncle and headed down to Cancun. We stayed at a brand-new all-inclusive resort, and I could write a whole tribute to A Supposedly Fun Thing That I’ll Never Do Again about that particular establishment, but I’m not trying to be DFW here. Despite my issues with the resort, it was overall a very successful, fun, and relaxing vacation.

Here’s a picture of a Mayan ruin:

Here’s a picture of an iguana:

While I was on vacation, I read the three books! Here’s what I thought about them:

System Collapse by Martha Wells

At some point last year, Martha Wells made a post on Mastodon saying something like “I’ve got 3 things coming out this year, and you can preorder them all,” and so I did! Out of the three, I only ever got around to reading Witch King last year, though; I intended to read System Collapse after that, but then I got distracted by Ninefox Gambit and was compelled to read the entire Machineries of Empire series, and by the time I had finished with that, System Collapse had disappeared somewhere into my office. Luckily, I found it the week before I left for vacation.

My favorite bits of this were the interplay between SecUnit and the central system, and the developing aro life partnership between SecUnit and ART. One day I’ll need to sit down and re-read this series from start to finish in one go; I always have a hard time remembering specifics of what happened in previous books. I also have a hard time remembering who any of the human characters are, or what differentiates them from each other, but I think at least a little bit of that is deliberate on the part of the author. I don’t read these for the humans, though.

Throne of Glass by Sarah J. Maas

I didn’t think this was a YA book when I picked it up, and it doesn’t appear to be marketed as such, but it contains a lot of teenage yearning, and a plot that would be resolved much more easily if any of the characters who obviously care deeply for each other actually talked to each other about anything. The main plot has a bit of a Hunger Games vibe, with the protagonist taken captive and forced to train for and participate in a lethal tournament by a wicked and corrupt dictator, and developing friendships with her trainer and some of her competitors along the way by being one of the few not-totally-awful people in the vicinity. There’s also a “mean popular girl versus exciting new girl” subplot that seems to differ wildly in tone from the main plot, until it is tied together at the end; I expect mean girl to reemerge as a harpy queen or something later in the series.

This was pretty different from my usual fare. Romantic concerns are not usually as much of a factor in the stuff I read, and the author describes the main character’s outfits with the same care that is given to describing feasts in the Redwall books. I enjoyed it, though, and intend to continue with the series, although the blurb I read for the next book was something like “everyone keeps secrets from each other and shit hits the fan” so I will probably continue to be frustrated with the characters’ lack of communication with each other for at least one more book.

City of Bones by Martha Wells

This is an updated and revised version of one of Martha Wells’ earlier novels. The original was released long before I was aware of Martha Wells, so I can’t tell you how the revised edition compares to that, but it does compare favorably to her other work. This reminded me the most of Witch King, which makes sense because that’s the other fantasy novel of hers that I’ve read so far. The setting also reminded me a bit of Rosemary Kirstein’s Steerswoman series; I won’t spoil you on either, but the backstory of how stuff got wrecked and how it’s been going since then is similar, although the Steerswoman apocalypse is a lot further in the past than the City of Bones one.

Khat is very much a protagonist in the vein of SecUnit and Kai, severed from his people and his original “purpose in life” and using his unique abilities to help his new found family of misfits. There’s a fair amount of intrigue going on and several plot twists; the big revelation at the end was very satisfying and an excellent payoff to all of the world-building. It almost reminded me of some of William Gibson’s weirder stuff, except that Martha Wells can actually write a decent ending to a story instead of just chopping it off and calling it done.

The ending of this one was bittersweet; it was believable but I think the romantic dimension of the relationship between the two characters was undersold and brought in too late. There weren’t a lot of hints that the characters might be starting to feel that way about each other, although it made sense given what they had been through together. This is a standalone book and works well as one, but I certainly wouldn’t mind a couple more short stories set in this universe, hint hint nudge nudge.

Work

I took a full-time job at one of mu consulting clients in May. It’s been a good experience, but I recently received a very exciting offer from an old friend to join their team at Danger Devices. I’m winding up my current position, and then I’ll have a couple weeks of funemployment over the Thanksgiving holiday before starting at Danger in December.

Coinciding with starting my new job, I’ll be winding up Caketop (my consulting persona) and parking the domain for now. I like the freedom of being a freelancer, but I don’t like the uncertainty, and I really don’t like having to buy health insurance on the exchange. This is a bit of a shame, because I have a sweet new logo for Caketop that I commissioned from Dzuk that I never got to deploy, but once I start my new gig I will no longer want or need to solicit any additional work.

Play

Exposition

Before I got on the internet, I hung out a lot on assorted BBS systems, and even ran a grievously unpopular one of my own (called “Norwegian Wood”) for a short time.

Along with allowing me to exchange files and messages with other users, many of my local BBSs featured door games. These are multiplayer games, but they operate in a uniquely asynchronous way. All of the players exist within the same “world” but, but in most BBS door games the players never interact with each other in real-time. Instead, each player is given a limited number of turns per day; you log in, take your turns, and log off. If you do something particularly noteworthy during your session, the game may announce your feat to other players when they log on; other than that, interaction between players is mostly limited to competition for spots on one or more leaderboards.

This sort of multiplayer model was particularly suited to the constraints imposed by running as part of a BBS. Remember that we were dialing into these things with modems; the number of users that could be logged on to a BBS simultaneously was limited by the number of modems, phone lines, and possibly computers (because you couldn’t take multitasking as a given in those days) that the operator of the BBS was willing to pay for. As a consequence, most BBSs run by hobbyists were single-node; usually only companies, rich people, and for-pay BBSs were willing to shell out for the equipment and phone lines needed to host multiple nodes. It would be pretty difficult to do real-time multiplayer without multiple nodes, and if you only had a single phone line, you wouldn’t want one player hogging it all day.

I always loved door games; many hours were spent running up my mom’s phone bill to play Legend of the Red Dragon on all of the local BBSs. I’ve also made multiple attempts to “bring them back”, but a bit more on that in a few paragraphs…

Inspiration

A couple months ago, I was lucky enough to be invited by Elissa to be a beta tester for Swords of Freeport. Swords of Freeport (or “SFP”, as we cool kids call it) is essentially a love letter to the door games of yore. I love it. I’ve played the crap out of it and I’m the solidly the mightiest hunter and tenuously the richest person on the test server.

I liked it so much that I even made a map! It’s a few versions out of date, but it should still be useful, if you’re going to play. I plan to update this for the release version during my holiday downtime:

I made the map with diagrams.net — here it is on Google Drive if you want to remix it or update it before I get around to it.

Anyway, go buy Swords of Freeport on itch.io now. It’s amazing, it’ll encourage Elissa to make more weird games, and it’s priced in Australian dollars so the exchange rate ought to be favorable if you’re in the US.

Revisitation

Anyway, back to the idea of bringing these door games back. There is, of course, plenty of prior art on this. There are several BBS software packages still being maintained, like Citadel, ENiGMA½, Mystic, and Synchronet, as well as projects like GameSrv and services like DoorParty. All of these software packages offer paths to getting old door games running on modern systems, and if I was looking to replicate the old school BBS experience as closely as possible, I would grab one or more of these and be on my merry way.

The rub is that I don’t actually want to replicate the old school BBS experience. I don’t want BBS-style message boards; even if I did want to exchange messages in text mode, I’d just run an NNTP server, or fire up mutt. I don’t want BBS-style file bases; if I want to distribute files, I’ll just do it over HTTP like everyone else does these days. This is not to disparage those that still enjoy running and/or using BBSs, but for me, almost every part of the BBS experience has been supplanted in my heart by some newer internet-age technology. The only thing I really miss is the doors.

What I’ve really always wanted is a door launcher that uses the local user database (i.e. /etc/passwd and friends) on a Linux system. Essentially, I’d like to be able to make doors work like the bsdgames - they should be just another program that someone can launch from their shell account, with a system-wide shared scoreboard. I’m not interested in running a BBS again, and I doubt any of my friends would use it if I did, but I bet at least some of my friends would be interested in a shell account that came with a bunch of games.

I’ve made multiple abortive attempts at this, going back to college days, and have had almost everything working (at least on the bench, in manual hacky ways) multiple times, but there are a couple things that stopped me from finishing them.

The soft reason not to

First of all, there’s the nagging feeling that very few people are going to appreciate this but me. I’m not exactly building the Field of Dreams here; BBS door games were a pretty niche interest, even in their heyday. Elissa has inspired me to ignore this feeling, though. Swords of Freeport has brought me great joy, and if I can bring the same level of joy to even one person, it’s worth it, even if that person is only myself.

The hard reason not to

The second reason that kept me from ever finishing this was technical. DOSEMU (and more lately DOSEMU2) has always offered a variety of ways to attach sockets or file descriptors or FIFOs or what have you to emulated serial ports, but what it didn’t offer was a way to signal disconnection of those serial ports. On a real serial port, there are some additional lines for signaling, separate from the lines that carry data; modems used these lines to tell the PC if a connection was active or not. If a caller hung up, the modem would signal the disconnection to the PC, and software using the modem could handle this and wrap things up cleanly.

Up until September 22nd of this year, there was no way to emulate this behavior with DOSEMU2 - emulated serial ports always indicated that they had a connection, even after the other end of the socket/file descriptor/whatever they were connected to was closed. This meant that there was no way to cleanly handle someone who disconnected in the middle of playing a door, unless I wanted to build something around a weird out-of-tree kernel module, and I did not. This was particularly frustrating, because I could absolutely detect a user disconnecting in software, but there was no way to signal it to the emulated DOS program. I couldn’t just signal the process in DOS, because DOS doesn’t actually have signals, or processes, or really the concept of multitasking at all - once the door was running in DOSEMU, there was no out-of-band way of telling it to cleanly stop. The only options were:

• Wait for the door time time out due to inactivity - this sucks because it leaves dead sessions around for 10 minutes or more, and especially sucks because it locks that node of the door for the duration.
• Kill the emulator process - this just really isn’t an option because I don’t want to corrupt the door’s game data.

So, what happened on September 22nd? I happened! I cracked open the sources to DOSEMU2 and pinpointed the code that was causing the behavior that I didn’t like. Then, with the gracious guidance and help of the DOSEMU2 maintainer, I fixed things, so that DOSEMU2 will notice that the other end of an emulated serial port is closed and indicate a dropped connection.

Even if I went no further, I feel like my patch has improved the state of play for other people wanting to do things related to fake modems in DOSEMU2. This effort has already borne more fruit than my previous ones; that improvement is out now and included in software that (some) people are actually installing on their machines!

Introduction

Introducing Doorman, the door launcher I’ve always wanted! It’s early days; there is no documentation yet. There are no usage instructions yet. There is, however, working code, that people are using to play LORD on a server in my house at this very moment.

I decided to use Doorman to teach myself Rust. I like it a lot! During the process, lots of very nice people also stepped in and taught me proper Rust idioms, instead of the nonsense I had come up with on my own.

The current implementation of Doorman works, but there’s a lot about it that could be better. Originally I envisioned it as a single setuid/setgid binary and no daemon process, ala bsdgames, but I’m running DOSEMU2 in a container and I want to support rootless Podman and it turns it it’s a real pain-in-the-ass to run rootless Podman without a proper user session, which being setuid definitely does not get you. So right now I’m reworking it to use a daemon process, and using a nifty trick of passing client file descriptors over a UNIX socket (suggested to me by Jamey Sharp) to avoid having to get too involved in terminal handling.

I won’t have a lot of time to work on Doorman until I wrap up my current job on the 15th. After that, I’ll have a bunch of time to work on it, at least for a couple weeks. Hopefully I can get an initial “proper” release out by the beginning of December.

Thanks for reading! Hopefully I’ll be back in not-too-long with a release announcement!

Android contains support for USB ethernet adapters. There’s even menus for them!

This means that if you very carefully select a USB Ethernet adapter that you know has a chipset compatible with your Android device, you can plug it in and these settings will spring to life. How do you know what chipsets are compatible with your phone?

Hearsay!

I’m not entirely kidding. If the company that you bought your phone from sells a USB ethernet adapter as an accessory to it, you have a pretty good chance of that one working. Otherwise, it’s hit-or-miss; phone manufacturers rarely, if ever, publish lists of supported Ethernet adapters. The best you’re going to get is finding a forum post from someone that has the same phone as you saying that they bought a particular adapter that worked, and hoping you can find the same thing to buy.

Or is it?

As you may know, if you dig deep beneath Android’s Googly carapace, you’ll find a Linux kernel. To build the Linux kernel, you must first configure it. This configuration determines what features and hardware the resulting kernel will support. Thus, the list of Ethernet adapters supported by your phone will more-or-less correspond to those selected in the kernel configuration for your phone, although it’s possible (but unlikely) that your phone’s manufacturer doesn’t ship all of the drivers that they build, or that they build additional third-party drivers separately.

So, in order to figure out what Ethernet adapters your phone supports, you’re going to want to find your phone’s kernel configuration. How do we do that?

First, enable USB debugging and install ADB

If you’d like to follow along with this blog post, you’re going to need enable USB debugging and to install ADB (Android Debug Bridge) — this is a command-line tool that is used by developers to interact with Android devices. In this post, we will be using it to run shell commands on a phone.

There’s good documentation elsewhere on how to do these things so I’m not going to waste time by rewriting it poorly. Instead, have some links:

1. First, enable USB debugging on your phone
2. Install ADB on your computer
3. Run adb shell, which will give you a shell prompt on the phone.

Congratulations, you can now run commands on your phone. Type exit and press enter when you’re ready to exit the ADB shell.

Next, we need to switch things up so that ADB connects to the phone over the network, instead of via USB. We need to do this because we’re going to try plugging some network adapters into the phone’s USB port, so we can’t also use the port for debugging.

With your phone connected to your computer via USB:

1. Connect your phone to the same network as your computer via wifi
2. Figure out your phone’s IP address - you can do this by digging around the Settings app, or you can try adb shell ifconfig wlan0
3. With the phone still connected via USB, run adb tcpip 5555
4. Disconnect the USB cable from the phone
5. Reconnect to the phone by running adb connect YOUR_PHONE_IP:5555 (replacing YOUR_PHONE_IP with the IP address from the phone)
6. Try adb shell to make sure it still works

Once you have ADB working over the network, you can proceed with trying to figure out what version of the kernel your Android device is running.

If you have a newer phone…

These days, Google publishes an Android Common Kernel, which downstream phone manufacturers are required to derive their kernels from. The source to this kernel is hosted in a Git repository at googlesource.com.

If your phone shipped with Android 11 or later, you have something called a GKI kernel - in this case, Google builds the kernel and the phone manufacturer puts all of their model-specific secret sauce into kernel modules. In this case, you can find the configuration that Google is using by navigating to the appropriate branch of the kernel repository, and looking at the file arch/$ARCH/configs/gki_defconfig, where $ARCH is the processor architecture of your phone. For example, if your phone has a 64-bit ARM processor (and it almost certainly does) then you will find this configuration at arch/arm64/configs/gki_defconfig.

How do I find out for sure what kernel version and processor architecture my phone has?

Now that we have the ability to run shell commands on the phone, we can turn to good old uname to discover the kernel version and architecture that’s currently running.

1. Go back and enable USB debugging and install ADB, if you haven’t arleady
2. Run uname -a on the phone, either by running adb shell and then running uname -a, or all in one go by running adb shell uname -a.

You should get output something like this:

Linux localhost 4.19.113-26203352 #1 SMP PREEMPT Tue Apr 18 16:05:51 KST 2023 aarch64 Toybox

You’ll the kernel version in the third field and the architecture in the second-to-last; you’ll have to make an educated guess about which branch or tag in Google’s kernel repository corresponds to the one running on your phone.

What if I have an older phone?

If you have an older phone, then you’re in the same boat as me; I have an iPhone as a daily driver, but I keep a Samsung Galaxy s20 around as an Android testbed. Unfortunately, the s20 shipped with Android 10, which is the version just before all of this standardized kernel stuff from Google became required. Even though the s20 has since been upgraded to Android 13, Google doesn’t require phone manufacturers to update the kernel along with the Android version, and so Samsung didn’t; it still runs a kernel based on Linux 4.19.

In this case, you need to get the kernel configuration from your phone manufacturer, so you’d better hope they’re actually doing regular source releases. Samsung does do this; you can find sources for their phones at opensource.samsung.com.

Once you have the sources for your device, you’re going to have to dig around a bit to figure out what kernel config. The sources I obtained for my phone from Samsung included a Kernel.tar.gz; inside of this archive was a Linux kernel source tree, along with a few additions. One of those additions was a shell script called build_kernel.sh, which goes a little something like this:

#!/bin/bash

export ARCH=arm64
mkdir out

BUILD_CROSS_COMPILE=$(pwd)/toolchain/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/bin/aarch64-linux-android-
KERNEL_LLVM_BIN=$(pwd)/toolchain/llvm-arm-toolchain-ship/10.0/bin/clang
CLANG_TRIPLE=aarch64-linux-gnu-
KERNEL_MAKE_ENV="DTC_EXT=$(pwd)/tools/dtc CONFIG_BUILD_ARM64_DT_OVERLAY=y"

make -j8 -C $(pwd) O=$(pwd)/out $KERNEL_MAKE_ENV ARCH=arm64 CROSS_COMPILE=$BUILD_CROSS_COMPILE REAL_CC=$KERNEL_LLVM_BIN CLANG_TRIPLE=$CLANG_TRIPLE vendor/x1q_usa_singlex_defconfig

make -j8 -C $(pwd) O=$(pwd)/out $KERNEL_MAKE_ENV ARCH=arm64 CROSS_COMPILE=$BUILD_CROSS_COMPILE REAL_CC=$KERNEL_LLVM_BIN CLANG_TRIPLE=$CLANG_TRIPLE

cp out/arch/arm64/boot/Image $(pwd)/arch/arm64/boot/Image

If you squint at this long enough, you’ll spot a reference to something that looks like a kernel config: vendor/x1q_usa_singlex_defconfig. There isn’t a subdirectory called vendor in the root of the archive, so I used find to figure out exactly where the file lives:

$ find . -name x1q_usa_singlex_defconfig
./arch/arm64/configs/vendor/x1q_usa_singlex_defconfig

Aha, there it is, deeply nested in a subdirectory.

Finding the kernel config sounds hard, is there an easier way?

There might be, if you’re lucky! Give this a shot:

$ adb shell zcat /proc/config.gz

If you’re lucky, and your phone manufacturer has enabled the relevant kernel option, then a compressed copy of the configuration that your kernel was compiled with is available at /proc/config.gz. If this is the case, you’ll have a large amount of output streaming to your terminal. You probably want to redirect it somewhere so you can peruse it at your leisure:

$ adb shell zcat /proc/config.gz > my_kernel_config

If you’re unlucky, you’ll see something like this:

zcat: /proc/config.gz: No such file or directory

In this case, there is no easy way out; you’ll have to refer to the sources your phone’s kernel was built from.

What does a kernel configuration look like?

In case you’re interested, here is the kernel configuration for my Galaxy s20: x1q_usa_singlex_defconfig

Your kernel configuration should look very similar to this, but not identical, unless you have the same phone that I do.

OK, I have the kernel configuration for my phone, what now?

For the purpose of determining which USB Ethernet adapters the kernel supports, most of the configuration variables that we are interested will start with USB_NET, so just grep the kernel configuration for that string:

$ grep USB_NET my_kernel_config
CONFIG_USB_NET_DRIVERS=y
CONFIG_USB_NET_AX8817X=y
CONFIG_USB_NET_AX88179_178A=y
CONFIG_USB_NET_CDCETHER=y
CONFIG_USB_NET_CDC_EEM=y
CONFIG_USB_NET_CDC_NCM=y
# CONFIG_USB_NET_HUAWEI_CDC_NCM is not set
... and so on ...

Look for a CONFIG_USB_NET_something that looks like it relates to the chipset of the adapter you want to use. The best news is if it is set to y; that means the driver is built-in to your kernel and that your phone’s kernel definitely supports that chipset. If it’s set to m, that’s still probably good news; that means that the driver was compiled as a module when your kernel was built, and that the module is likely loadable on your phone unless your phone’s manufacturer specifically left it out. If you see is not set, then that is the worst news; the driver was neither built-in to your kernel, nor was it compiled as a module, so it’s likely not available for you to use.

If you’re having trouble figuring out which configuration items correspond to which chipsets, have a look at drivers/net/usb/Kconfig in your kernel tree. This file will contain extended descriptions of each configuration item.

Unfortunately, to figure out which chipset a particular adapter uses, you’re mostly back to hearsay; few manufacturers of USB Ethernet adapters explicitly advertise which chipset they use.

So what’s this about CDC Ethernet and why should I care?

CDC stands for Communications Device Class. This is a set of interrelated standards that manufacturers of USB devices can follow; among them are a trio of standards called EEM (Ethernet Emulation Model), ECM (Ethernet Control Model), and NCM (Network Control Model) that can be used to build USB Ethernet adapters. Most of the difference between these three standards is a matter of complexity; EEM is the simplest to implement and is easy to support on underpowered devices, but may not result in the best performance. ECM is more complex to implement for both the USB host and the device, but promises better performance than EEM; NCM is a successor to ECM that promises even higher speeds. Many devices implement more than one of these protocols, and leave it up to the host operating system to communicate with the device using the one that it prefers.

The point of these standards is that, assuming manufacturers follow them, operating systems can provide a single common driver that works with a variety of drivers. You generally don’t need special drivers for USB keyboards or mice because of the USB HID standard; the USB CDC standard attempts to accomplish the same for USB networking devices.

One particularly fun thing is that Linux implements both the host and the device side of the CDC Ethernet standards. That means that if you have hardware with a USB OTG port, which is common on the Raspberry Pi and other small ARM devices, you can tell the kernel to use that port to pretend to be an Ethernet adapter. This creates a USB network interface on the host that is directly connected to an interface on the guest; this lets you build cool things like embedded routers, firewalls, and VPN gateways that look like just another Ethernet adapter to the host.

Linux, as well as Windows and macOS (but not iOS) include drivers for CDC Ethernet devices. Unfortunately, none of this works on Android devices, despite Android being based on Linux. Why is Android like this?

Based on the kernel configuration, Android appears to support CDC

Let’s have another look at our kernel config, and grep for USB_NET_CDC:

$ grep USB_NET_CDC my_kernel_config
CONFIG_USB_NET_CDCETHER=y
CONFIG_USB_NET_CDC_EEM=y
CONFIG_USB_NET_CDC_NCM=y
... and so on ...

Here we can see that Samsung has built support for all 3 CDC Ethernet standards into their kernel (CONFIG_USB_NET_CDCETHER corresponds to ECM). Google’s GKI kernels are somewhat less generous and appear to leave out ECM and NCM, but still include support for EEM as a module.

I’ve got a device with an OTG port that I’ve configured as an Ethernet gadget. It works when I plug it into my Mac. It works when I plug it into my Ubuntu desktop. It even works when I plug it into my Windows game machine (actually the same computer as the Ubuntu desktop, booted off of a different drive 😁). It doesn’t work at all when I plug it into my Galaxy s20. The Ethernet settings are still greyed out:

Let’s grab a shell on the phone and dig in a bit.

The Linux kernel exposes information about itself in a pseudo-filesystem called sysfs - this looks like a directory tree full of files, but reading the files actually gets you information about the current state of the kernel.

Among other things, sysfs contains a directory named /sys/class/net, which contains one entry for every network interface that the kernel is aware of. Let’s connect our Ethernet gadget to the phone and see if anything shows up there:

$ adb shell ls /sys/class/net
... lots of output ...
usb0
wlan0

Could usb0 be the gadget? Let’s use ifconfig to check it out:

$ adb shell ifconfig usb0
usb0      Link encap:UNSPEC    Driver cdc_eem
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 TX bytes:0

That certainly looks like our gadget. Too bad the interface is down. Unfortunately, the Ethernet settings on the phone are still greyed out:

Let’s unplug the gadget and make sure usb0 goes away when we do:

$ adb shell ls /sys/class/net | grep usb
$ # no output

Yep, it’s gone.

It looks like we’re using EEM mode. In addition to the g_ether module, Linux also includes a thing called configfs that can be used to create custom gadgets. Let’s try one that only supports ECM and see if that works:

$ adb shell ls /sys/class/net | grep usb
usb0
$ adb shell ifconfig usb0
usb0      Link encap:UNSPEC    Driver cdc_ether
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 TX bytes:0

It’s still detected, but it’s still down. Will NCM fare any better?

$ adb shell ls /sys/class/net | grep usb
usb0
$ adb shell ifconfig usb0
usb0      Link encap:UNSPEC    Driver cdc_ncm
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 TX bytes:0

No, it will not.

So why doesn’t CDC work on Android?

At this point, we’ve more-or-less established that everything is fine on the kernel level. I’m pretty sure that if I wanted to, I could root this phone, manually configure the interface with ifconfig, and it would pass traffic just fine. That means the problem must be somewhere in the stack of software above the kernel.

If this was a regular Linux system, this is the point where I’d start poking at systemd-networkd, or NetworkManager, or ifupdown, depending on the particulars. This is not a regular Linux system, though; it’s an Android device, and none of that stuff exists here. What do I know about how Android configures network interfaces?

NOTHING. I know nothing about how Android configures network interfaces. How do we figure this out?

Well, Android is at least sort of open source; many of the good bits are closed behind the veil of something called “Google Play Services” but maybe there’s enough in the sources that are released to figure this out.

To play along with this bit, you’ll need to download the source to Android. This is a whole process on its own, so I’ll leave you to Google’s documentation for this, except to note that you’ll need a special tool called repo. This seems to be meant to make it easier to download sources from multiple Git repositories at once; sometimes it feels like I’m the only person that actually likes Git submodules. There are a lot of sources to download, so start this process and then go knock off a few shrines in Zelda while it wraps up.

I figure that searching for the string Ethernet is probably a good starting point. Because there is so much source to go through, I’m going to skip vanilla grep this time and enlist the aid of ripgrep. There’s a lot of configuration files and other clutter in the Android sources, as well as most of a Linux distro, but I know that any code that we’re going to care about here is likely written in Java, so I’m going to restrict rg to searching in Java files:

$ rg -t java Ethernet
... SO MUCH OUTPUT ...

At this point, there’s not much else to do but look at the files where we’ve got hits and try to figure out what part of the code we can blame for our problem. Fortunately for you, I’ve saved you the trouble. After reading a bunch of Android code, I’m certain that our culprit is EthernetTracker.java. This appears to be a service that listens on a Netlink socket and receives notifications from the kernel about new network interfaces. The EthernetTracker contains a method that determines if an Ethernet interface is “valid”; if it is valid, the EthernetTracker reports to the rest of the system that an interface is available, and the Settings app allows the interface to be configured. If an interface is not valid, then the EthernetTracker simply ignores it.

How does the EthernetTracker determine if an interface is valid?

private boolean isValidEthernetInterface(String iface) {
    return iface.matches(mIfaceMatch) || isValidTestInterface(iface);
}

With a regex, of course.

Where does this regex come from?

// Interface match regex.
mIfaceMatch = mDeps.getInterfaceRegexFromResource(mContext);

It comes from a method called getInterfaceRegexFromResource. Where does that method get it from?

public String getInterfaceRegexFromResource(Context context) {
    final ConnectivityResources resources = new ConnectivityResources(context);
    return resources.get().getString(
        com.android.connectivity.resources.R.string.config_ethernet_iface_regex);
}

There’s actually a nice comment at the top of the file that explains this:

/**
 * Tracks Ethernet interfaces and manages interface configurations.
 *
 * <p>Interfaces may have different {@link android.net.NetworkCapabilities}. This mapping is defined
 * in {@code config_ethernet_interfaces}. Notably, some interfaces could be marked as restricted by
 * not specifying {@link android.net.NetworkCapabilities.NET_CAPABILITY_NOT_RESTRICTED} flag.
 * Interfaces could have associated {@link android.net.IpConfiguration}.
 * Ethernet Interfaces may be present at boot time or appear after boot (e.g., for Ethernet adapters
 * connected over USB). This class supports multiple interfaces. When an interface appears on the
 * system (or is present at boot time) this class will start tracking it and bring it up. Only
 * interfaces whose names match the {@code config_ethernet_iface_regex} regular expression are
 * tracked.
 *
 * <p>All public or package private methods must be thread-safe unless stated otherwise.
 */

Let’s go back to ripgrep to see if we can skip to finding out what config_ethernet_iface_regex is:

$ rg config_ethernet_iface_regex
...

frameworks/base/core/res/res/values/config.xml
410:    <string translatable="false" name="config_ethernet_iface_regex">eth\\d</string>

...

packages/modules/Connectivity/service/ServiceConnectivityResources/res/values/config.xml
170:    <string translatable="false" name="config_ethernet_iface_regex">eth\\d</string>

...

…and there it is. The default value of config_ethernet_iface_regex is eth\d; in regex parlance, that means the literal string eth, followed by a digit.

The kernel on the phone calls our CDC Ethernet gadget usb0. This doesn’t start with the string eth, so EthernetTracker ignores it. Unfortunately, this setting is not user-configurable, although you can hack it by rooting the phone.

It really is that silly; an entire USB device class brought low by a bum regex.

Is it a bug?

I can’t tell if this is intentional or not; it feels like an oversight by Google, since even the newest GKI kernels apparently go out of their way to include support for EEM adapters, but because the interface name doesn’t match the regex, the kernel’s support for EEM adapters is unusable. This puts you in a rather perverse situation when shopping for USB Ethernet adapters to use with Android; instead of looking for devices that implement the CDC standards, you need to explicitly AVOID the standards-based devices and look for something that is supported with a vendor/chipset-specific driver.

Thanks for playing!

I hope you enjoyed going on this journey with me, or even better that I saved you from duplicating my efforts. Perhaps if I am feeling feisty, I will try to figure out how to submit a patch to Android to change that regex to (eth|usb)\d in the next few weeks. If a real Android dev or someone at Google reads this and beats me to the punch, I owe you the beverage of your choice.

I’m not normally a person that makes games, but my brain kept telling me that there’s a game mechanic in this. So, in order to appease it, I am pleased to present:

The License Plate Game

This is a party game for at least 4 players, although at least 5 is a more ideal number. In addition to the players, you will need:

• Scraps of paper
• A writing implement

Cast of characters

The applicant

One player is the applicant. The applicant wins by getting the clerk to incorrectly approve a plate that is offensive, or by getting the clerk to incorrectly deny an innocent plate. The applicant must walk the line between fooling the clerk while still having the meaning of their plate be recognizable to the audience.

The clerk

One player is the clerk. The clerk wins by correctly guessing the meaning of the plate, or what “most people” would say the plate means. If the clerk fails at that, they may also win by denying an offensive plate, even if they got the meaning wrong.

The audience

The rest of the players are the audience. The audience is mostly along for the ride; they can neither win nor lose. They serve as a check on the clerk’s interpretations and vote to settle disputes. Otherwise, their job is to heckle the clerk.

How to play

1. The applicant makes up a plate number, and secretly writes down the true meaning of their plate. The meaning may or may not be offensive (as defined by your local community standards.)

   • You can make your own house rules for what sorts of plate numbers are allowed, but here’s a starting point: up to 8 characters, A through Z and 0 through 9, spaces are allowed but don’t count toward the limit. Some US states also allow special characters like a heart (❤️) - feel free to adjust this to your taste or to better simulate your own state or country.

2. The applicant reveals their plate number to the other players. The clerk has 5 seconds to announce what they think the true meaning of the plate is, and if it is approved or denied. If the clerk thinks the plate is offensive, they should deny the plate; otherwise, they should approve the plate. If 5 seconds pass without the clerk announcing a decision, the plate is considered to be approved.

   • The time limit is meant to simulate the experience of being an overworked clerk in an understaffed bureaucracy.

3. Each audience member announces what they think the true meaning of the plate is. They may choose to agree with the clerk’s interpretation, or supply their own. Audience members may discuss their interpretations with each other before committing to them. There is no hard time limit on audience deliberations.

   • Think of the audience as other people on the road who might notice the plate or get stuck behind it in traffic.

4. The applicant reveals the true meaning of the plate.

Scoring

1. If the clerk correctly guessed the true meaning of the plate and correctly judged it as either offensive or innocent, the clerk wins the round.

   • Generally, if the clerk gets the meaning of the plate correct, then they will also get the judgement correct, but the clerk’s judgement can be disputed by the applicant or any audience member; see “Exceptional cases” below.

2. If the clerk incorrectly guessed the true meaning of the plate, but at least half of the audience agrees with their interpretation, the clerk wins the round.

   • This discourages applicants from providing bad-faith interpretations of their plate numbers.

3. If neither the clerk nor any member of the audience correctly guessed the true meaning of the plate, the round is a draw.

   • This discourages applicants from providing completely inscrutable plate numbers.

4. Otherwise, at least one person other than the applicant has correctly guessed the true meaning of the plate:

   • If the meaning of the plate is offensive, and the clerk denied it, the clerk wins the round.

   • If the meaning of the plate is offensive, and the clerk approved it, the applicant wins the round.

   • If the meaning of the plate is innocent, and the clerk denied it, the applicant wins the round.

   • If the meaning of the plate is innocent, and the clerk approved it, the round is a draw.

Exceptional cases

If the applicant or an audience member disagrees with the clerk’s judgement about what is offensive or innocent, they may dispute it. Disputes are resolved by a vote of the audience.

If an audience member thinks deliberations are going on too long, they can call for cloture. This is also decided by a vote of the audience. If the vote succeeds, all audience members who have not done so must immediately supply an interpretation or be quiet for the rest of the round. An individual audience member can only call for cloture once per round, but if a cloture vote fails, a different audience member may call for cloture later.

In either case, if the vote of the audience ends in a tie, the clerk casts the deciding vote.

Notes

I haven’t actually played this yet, but I suspect that, as in real life, the rules favor the clerk. To ensure that everyone has the most fun, each of the players should rotate through the roles. You may also want to weight applicant wins more heavily; i.e. an applicant win is worth 3 victory points whereas a clerk win is only worth 1.

Thinking up clever plates on the fly can be hard, so you might want to have a brainstorming session before playing, where all the players spend time thinking of and writing down ideas for plates to use when they are the applicant. Obviously, the players should keep their ideas secret from each other during this process, to avoid tipping off their future clerk.

If you decide to play this, I’d love to know how it goes! Assorted ways to contact me can be found on the front page.

I move around a lot between various machines. I may not have permission/inclination/space to install a bunch of additional software on some of the machines I find myself on. Some of them might not even be running Linux 😱!

This nomadic lifestyle has had a big influence on my choice of tools. I try to keep my dependencies light and avoid coming to rely on things that might not be easy to install everywhere. This is why I settled on Bash; it’s almost always already available on any machine I might need to log in to. My dotfiles follow a philosophy of progressive enhancement - they should work out-of-the-box with only Bash and a reasonably POSIX-compliant set of CLI tools. If I want to put something outside of the standard set of tools into my dotfiles, I add a check to see if it’s installed first, and avoid calling it if it isn’t.

An actual tour of my dotfiles would be a bit like taking you through my utility room, in that you might see many things that you find awkward, inexplicable, and/or gross, so I’m not going to do that. I thought it might be nice to highlight some of my favorite tools, though.

Absolutely essential

homeshick

The first thing that gets installed when I’m moving into a new system is homeshick. This is a tool that helps you synchronize your dotfiles between machines by keeping them in one or more Git repositories. It started out as a clone of homesick, but homesick is written in Ruby, whereas homeshick is written in Bash. Since it requires no other tools besides my preferred shell to bootstrap, I picked homeshick over homesick, eventhough homesick is written by a former coworker 😁.

My dotfiles contain a setup.sh that, among other things, handles installing homeshick and setting it up. All I need to do to move into a new machine is clone the repo and run the script. When I was at GitHub, a “spiritual successor” of Codespaces would run this script for me automatically when spinning up a new development machine; it looks like Codespaces borrowed this feature from the internal tool that preceded it.

asdf

I want to be upfront about this; the way I use asdf might be considered a bit of an abuse! It is designed to be a version mananger; it’s meant as a one-size-fits-all replacement for tools like nvm, pyenv, and rbenv. If you were using it the way it was intended, you would create a .tool-versions file in each of your projects and put whatever version of Node, Python, Ruby, or whatever in there, so that other people could attempt to reproduce your results using the same versions. This is not how I use it.

Instead, I use asdf as a sort of ad-hoc package manager. I get the feeling that I’m not the only one doing this, because there are asdf plugins to install all sorts of tools that you would never think need versioning; I just checked and as of this writing, asdf plugin list all indicates that asdf is capable of installing 591 different tools. Whenever there’s a tool I want to use that I don’t have installed, I check to see if there’s an asdf plugin for it. If there is, I do this and I’m off to the races:

asdf plugin add foo
asdf install foo latest
asdf global foo latest
asdf reshim

Like homeshick, asdf is written in Bash. That means I can just make it a submodule of my dotfiles and have it automatically installed and available when my dotfiles are set up. It’s the package manager you can keep in your pocket.

Pretty much essential

ripgrep

ripgrep is a better grep. It’s so much better than grep that I’m willing to seek it out and install it on any system that I’m going to be living on for more than a day or two. I appreciate that it has sane defaults; it won’t dig into hidden files or binaries without being specifically asked to, and it even respects .gitgnore. It defaults to recursively searching the current directory, so you can leave off the filename entirely if that’s what you want (and like at least 80% of the time that’s exactly what I want):

$ rg JordanRules123
src/pages/blog/stuff-i-use-feb-2023.md
79:<!-- NOTE: Change GitHub password from JordanRules123 -->

Lots of distros and package managers have packages for ripgrep; there’s also an asdf plugin for ripgrep, which is what I usually use to install it.

McFly

First: did you know that you can hit Ctrl+R in Bash to search your shell history? I didn’t, for like, the first 10 or 15 years that I used Bash. I was grepping ~/.bash_history like an animal.

Anyway, that’s pretty great, but when you get to my age, sometimes you can’t remember exactly what it is that you’re looking for. Sometimes your memory is a little… fuzzy. That’s where McFly comes in! It replaces Bash’s stock Ctrl+R experience with a slick full-screen interface and fuzzy search. McFly also takes in all sorts of contextual cues when sorting its search results, including your current directory and how recently commands were run.

Sadly, there is no asdf plugin for McFly, but there are pretty easy installation instructions for a variety of platforms. It looks like McFly’s maintainer is currently looking for additional help; I’d step up but my Rust skills are rudimentary at best. Perhaps this could be an opportunity for you?

Fun enough to install most places

Starship

Once upon a time, I spent a lot of time fine-tuning my hand-rolled, extremely custom Bash prompt. Eventually I threw most of that out, and just vendored git-prompt.sh into my dotfiles. Such was the state of things until last year, when I started longing for something flashier, but found myself utterly without motivation to put it together myself. That’s when I found Starship.

Starship comes with a fully-loaded prompt with a version indicator for just about anything you could think of; if you’ve got a lot of stuff on your machine you’ll quickly be overwhelmed. Fortunately, it is highly configurable. I turned most of the stuff off and got a little creative with Powerline characters:

Now I have a very fancy prompt that I put very little work into. My dotfiles fall back to the pre-Starship version of my prompt if it’s not available. There are lots of ways to install Starship but I usually use the asdf-starship plugin.

LSD

LSD is a drop-in replacement for ls; that is to say, you can alias ls=lsd and it will behave more-or-less as you expect, even if you have been using ls for a long time. The main reason that I use LSD is that in addition to color-coding different types of files like GNU ls, it also adds icons:

This is at least party just for fun, but there’s a real case for it being a usability improvement as well; the icons give your tired eyes one more distinct thing that they can latch on to when you’re scanning that directory listing at 2AM.

If you’re thinking “those don’t look like official Unicode characters,” you’re right. You’re going to need a special font for this one; you can grab an appropriate one from Nerd Fonts.

Unfortunately there’s no asdf plugin for LSD, but there are lots of ways to install it.

That’s all for now!

Congratulations on getting through January! I barely made it myself. I landed a big contract that’s probably going to keep me pretty busy until springtime, so my posting frequency might drop off a bit, but I will try not to abandon you entirely. Thanks for reading!

Version 1.0.0 of python-starlark-go is now available on PyPI.

This comes hot on the heels of the previous release; the universal2 binaries that I published for v0.1.2 turned out to be not-so-universal. Once again, this issue was noticed and fixed by Colin Dean.

There were a couple of different things that prevented us from publishing working universal2 wheels:

• We’re using cibuildwheel to build the wheels, and that understands how to cross-compile things, but since part of the extension is written in Go and needs to be compiled with CGo, some additional tweaks were needed to make sure the compiled bit was coming out for the correct architecture.
• Go currently doesn’t support creating universal binaries on its own; you need to do it by hand with lipo, and we’d need to build our own tooling for that.

As a consequence, we’ve decided it’s simpler to drop universal2, and just publish separate x86_64 and arm64 wheels for macOS. That means we have to publish more wheels, but the upside is that pip will definitely be able to find one that works on your Mac. I also added back i686 wheels for Linux; they had inadvertently been dropped from the previous release.

The embedded version of starlark-go has been updated to the latest available version as of this writing, which is v0.0.0-20230122040757-066229b0515d.

I went ahead and bumped the version to 1.0.0 because there was no reason not to; I consider the code to be feature-complete, I am reasonably certain that everything works as intended, and I have no plans to break the API in the foreseeable future. I intend to follow SemVer for future releases; any breaking changes will come with a major version bump.

The main thing I’d still like to add is pre-built wheels for Windows; if you’re a Windows-loving Pythonista that can help, please stop by the GitHub repo and say hello!

Version 0.1.2 of python-starlark-go is now available on PyPI.

python-starlark-go provides Python bindings for starlark-go, which allows you to embed a Starlark interpreter into your Python interpreter.

Starlark is a dialect of Python designed for hermetic execution and deterministic evaluation. That means you can run Starlark code you don’t trust without worrying about it being able access any data you did not explicitly supply to it, and that you can count on the same code to always produce the same value when used with the same input data.

Aside from the usual smattering of updated dependencies, the main feature in the new release is pre-built wheels for aarch64 on Linux and universal2 on macOS (which includes both aarch64 and x86_64). This is brought to you through the noble efforts of Colin Dean, who is python-starlark-go’s first contributor!