What's it all about, Alfie?

It's been a wild couple of weeks for the log4j team... I mean, the problem with a logger is that you don't really want to limit it, and adding the url handlers probably seemed like a great idea at the time, but once they started to be used, it was understandably hard to drop support for them. And then the exploit hit.

It's just one of those nearly universal components of JVM systems that is being supported by volunteers, and trying to thread the needle between keeping as much of the functionality as they can... while restricting the vulnerability to something that can't be exploited. It's clearly not easy, as they've had at least three releases of the 2.x codebase to try and correct the vulnerability, and each time, there seems to be more there is to do.

This is certainly going to shift how some open source teams function... it's great to be the author, or maintainer of something as used as log4j, but to have this kind of attention... well... I'm sure it's not what they were hoping for this Christmas. 🙂

I just got Day 19 of Advent of Code, and it was brutal... I mean yes, the concept of change of axes, and then translation - that's not horrible, and while getting the individual translations right took a little time, the fact was, it worked, and I found the overlaps. What came next was the real challenge - Searching was not going to work.

This is not something new, as it's often that Part 1 is something that's reasonably direct, and can be solved directly, but Part 2 adds a much larger scope, and so can't really be solved in the same way. Not always... but often enough, that it didn't surprise me. So I knew I needed to thin the search space - I just didn't know I'd have to remove it entirely, and come up with an "execution plan" for the work.

Thankfully, I expect each translation to need the working rotation function, and offset so that once I had two sensor data matched, I could then move any point on one sensor to the other. But I then needed a faster way to find the overlaps, and then an order with which to collect all the beacon locations.

As it turns out, the unique set of inter-beacon distances is a nice "fingerprint" for a sensor data list, and we can use that to identify the "pairs" of sensors that overlap. Then it's the matter of order of mapping - and there we had to start at 0 and work up. If the pair had a sensor that we'd already mapped, then add it, and put it in the list. If not, put it at the back of the list, and try again. Eventually, all the pairs will be put in order, forming a chain of translations.

To get this, I worked on so many variations it's crazy. I easily spent over 10 hours on this day's puzzle. But in the end, the feeling of seeing the quick response was just fantastic! 🙂

It's December again, and that means 25 days of some of the funniest, most frustrating coding problems of the year. Yes, Advent of Code is back, and it'll be interesting to see how things work out. I will confess that today's problem wasn't too bad, but that's how the month always starts out. 🙂

We will see how things progress as we go through the month, but it's always fun to play along with the puzzles as they put you in the middle of the action to help Santa and the elves. It just makes me smile.

I just got back from getting my Moderna 6-month COVID booster, and I was a touch nervous - the Walgreen's website made it seem like all the data collection and ID verification was going to be done before I got there - but things rarely turn out as well as that. So when I got there, and needed to do some paperwork, I wasn't really surprised.

Still... it wasn't too bad, and it didn't take long for the pharmacist to take care of the gal before me in line, and then me. Pretty standard stuff. Given that Thanksgiving is this week, and I'm going to be visiting family in Indy, it seems smart to get it before going, as opposed to after. Sure, it'll not have generated the maximum antibodies, but it's a start, and every little bit helps.

With the update to macOS Monterey, the previous macOS command-line program for generating UUIDs, uuid, has been replaced with uuidgen. I'm not at all sure why the change, but I was glad that a little investigation with ls /usr/bin revealed something that turned out to be the winner.

With this, one of my favorite aliases is now:

alias uupb="uuidgen | tr '[:upper:]' '[:lower:]' | tr -d '\n' | pbcopy"

which generates a new UUID, lower-cases all the characters, removes the trailing new-line, and then puts it into the paste buffer for pasting in an editor, or on a form... as many times as you need.

I don't know if there are even release notes about the changes at this level of macOS, but they usually get figured out - one way or another. 🙂

It looks like my new MacBook Pro is Out for Delivery today, and it could be a good day. 🙂 I'm planning on using Migration Assistant to move my User files and Settings, but not anything in /usr - which I have done in the past, but this time, I'm going to leave Homebrew installed on my Intel machine, and I'll just install the ARM-version of Homebrew once I get the laptop all set-up.

When I get it set up, I'll then install the ARM Homebrew, and then:

  $ brew install --cask temurin
  $ brew install leiningen
  $ brew install jq

And from there, I can set up nodenv and rvm... and then just work my way to getting back to running everything I need. Should be an interesting day or two... 🙂

I knew it was coming... they warned me with macOS 11 Big Sur... but it was still a bit of a surprise this morning to reconfigure Apache 2 to use userdir, which macOS Monterey doesn't enable by default, and undoes if you have it already configured. That's OK, it's not a huge deal to turn it back on, but the big news was the complete loss of PHP.

I haven't used it in many years, but it was the one tool that shipped with macOS that I could talk to Postgres, and script, but hey... things change, and they did warn me. 🙂

I guess it would be nice to have something like Node automatically handled, but then that would likkely clash with the Node devs and the nodenv installs, etc. So I'll live with Apache 2, and the userdir, and then just serve up static content on port 80, and leave the other stuff for the development environments.

I did a little digging over the past few days to see what's new in the latest release of Blink (v14.0.2) - the terminal/shell for iOS and iPadOS. It's a nice tool - has even more features than I initially thought. It's really a nice subset of a Unix shell without needing to connect to any other hosts. But that's not really the point of this dig... I was hoping that they had implemented SSH Agent Forwarding in mosh connections so that I'd be able to use git on the remote machines. If you don't forward the SSH key, then you have to have them on the remote hosts, and ssh-add them there. That's not ideal for me, as it opens up the location of the key to a somewhat untrusted host.

I read the release notes and it seems they have re-written the SSH Agent component, and yet they didn't get very specific about the Mosh improvements, so I did a little more digging on the mosh-client code itself, and it seems that there's a bit of a disagreement about including Agent Forwarding in mosh due to security reasons. The conveneince of using git and SSH keys for git operations means that most folks want to have the key forwarding. And you can do it in simple ssh connections.

But for mosh, eventhough it's built on ssh, it seems they don't want to add it. Odd. But hey... it's their code, it's their choice, and that's why I have the workflow where I do the commits on my iPad, and use Blink with mosh just to run the code. It would be nice to have SSH Agent Forwarding, but the durability of mosh trumps the need for agent forwarding... so I'll just stick to what I have now.

But it sure would be nice... maybe they'll figure it out.

I started preparing for the new MacBook Pro by making sure that I had Universal Binary versions of all the apps I use on a daily basis. A lot of them were simple updates - and the latest versions would run natively on the Apple Silicon chips. But a few need a little help.

There are a few where I simply need to download the Apple Silicon version of the app:

• Docker
• GitHub Desktop
• Google Chrome
• Zoom

and a few I read are in the process of creating native Apple Silicon versions:

• Adium
• CodeRunner
• VoodooPad

and a few I've sent off support requests for to see if they are planning on delivering an Apple Silicon version of the app:

• Base
• PDFelement 7

One that I was a little surprised about was Dropbox. They have iOS, and iPadOS clients, but not a Universal Binary client - or even one that's specific to the Apple Silicon architecture. Seems odd that being the case, but it was a chance for me to drop my usage of Dropbox, not renew my $120/yr subscription, and just move all the files to iCloud+. After all, I'm already using iCloud, and with the upgrades to iCloud+, and the cost being less, it seemed like a good move.

So I moved all the files, let them sync up to iCloud, and then removed the files from Dropbox. Then I simply logged out of each device, and then my laptop, and finally cancelled by subscription on the website. It was interesting that they wanted to keep me at the Free Tier, so it seems there's no easy way to really wipe out your Dropbox account, but this is good enough. It's off my machines, and I won't have to worry about the emulation on the new laptop.

In all, not bad... most are converted. In order to update Homebrew, I think I'm going to uninstall the complete Intel Homebrew install, and then start by putting back only those packages that I need - Postgresql, Node, and AdoptOpenJDK. I think that will be far easier than trying to migrate all the Homebrew tools I have now, most of which I really no longer need.

It's going to be an interesting transition. 🙂

UPDATE: Some news about Homebrew and Apple Silicon. I did a little digging to see what the status was on the support for Apple Silicon for the packages I needed to have on Day 1. It's in interesting mix.

• Java - it seems that AdoptOpen JDK has been renamed to Temurin, and the only ARM version is JDK 17. This means no more backward support for JDK 8 or JDK 11. This is going to then mean that I need to make sure everything is working OK, but I'm hoping it won't be bad.
• Postgresql - the latest is Postgres 14, and it's ready to go on ARM. Good. 🙂
• Leiningen - it appears to be OK, as it's just a script, so I think it's fine.
• jq - this is ready to go on ARM. Good. 🙂
• nodenv - this is ready to go on ARM. Good. 🙂

I'm sure there will be more support as the Mac machines all move to Apple Silicon, but it looks like I'll have only a few questionable apps on Day 1.

Today, at Apple's Event, they introduced their newest MacBook Pros - based on the M1 Pro and M1 Max chipsets. They are pretty spectacular: great display, more ports, better thermal design... I have been hoping they would be this good, with the same basic RAM and SSD that I have now in my current MacBook Pro - and they did not disappoint. 🙂

The news I've received from folks with the original M1 Mac Minis is that they are amazingly fast, and quiet, and as the M1 Max is going to be even better than the M1, things are only going to improve. A little after the event ended, I ended up ordering one - should arrive the first week of November.

It'll be great to migrate things over and see how some of the apps perform on the new hardware. I'm betting it'll be exceptional.