Notes for September 15-21

A rather hectic week as work ramps up again and I start to progressively lose control of my calendar, but I’ve managed to slowly accrete some notes.

After a week living with the “26” software updates, I have a few more impressions:

• I still don’t like macOS Tahoe. The immaturity of the Liquid Glass redesign, the visual inconsistencies, and the waste of screen real estate are constantly in my face, but the transparent menu bar has grown on me—perhaps because I have very large monitors and love the landscape vistas I get via my Bing Wallpaper script. Having the wallpaper more visible is… nicer.
• None of the Tahoe desktop widgets seem to update properly. I have had to reset the calendar one (to pick our shared family calendar) twice in four days.
• I really like being able to switch to a named tab with the new Spotlight. All I’m missing from my QuickSilver days is invoking current application menus directly, which now feels tantalizingly close—and like a near miss from Apple at the same time.
• My iPhone and iPad batteries are indeed lasting a little less (as is my Watch’s).
• I have since installed iOS 26 on an iPhone 14 (for science) and it’s painful to watch Springboard render each icon individually when I page through apps. None of it feels optimized, and initial indexing can’t be blamed anymore.

Even though I haven’t reviewed any 3D printers in a while, I have started the long and arduous process of picking out something new since I need a more modern one, and have begun collating my notes on the Snapmaker U1, the Elegoo Centauri Carbon and the Flashforge AD5X while I wait to see if Bambu Lab revises their P1 range.

I’ve also printed a few PETG-CF replacement parts for my existing printers to make do while we wait…

I spent far too much time fiddling with Blender and DaVinci Resolve to no goal in particular.

Both appeal to my graphical design background in various ways, and both have node editors that are stupendously powerful—and fascinating rabbit holes I really shouldn’t dive into in the evenings if I want to keep sleeping enough.

That said, I’ve been finding a few interesting resources for either which I’ve added to their respective Wiki pages, and it’s always fun to refresh old creative skills.

I think it’s worth taking stock of where we are regarding LLM-assisted content, because this week GitHub Copilot was able to do something I actually value pretty much unprompted:

It took one of my legacy Wiki pages (written in Textile, which is still the format of most of my older posts), reformatted it into Markdown and generated a YAML table for the resource links on it—easily saving me 20 minutes to update it. And (this time) it didn’t make any mistakes (I was using GPT-5, which I currently favor because it isn’t chatty).

My actual prompt was “reformat this to Markdown according to repository standards”, and it then went off, looked at .github/copilot_instructions.md, figured out what templates to use, set up a task plan and converted the format as I like it.

This doesn’t seem like a very sophisticated thing (and I did take the time to write out how I prefer the conversion process to be done in the repository file), but it is so much better than the state of affairs this January that I think multi-step planning and execution is now reliable enough (for this kind of task) for me to finally give it a solid thumbs-up.

I also can now toss over an Obsidian note and prompt it to “reformat this for publishing and validate links”, which will tidy up all the front-matter, check spelling, grammar and links, and deal with image tags the way I prefer—so… great time saver.

In stark contrast, I vicariously decided a couple of months ago to use Copilot to tweak some things in the current site engine and… let’s just say it’s mostly gotten it right (sometimes surprisingly so considering how contrived some of the rendering logic is for handling dependencies between pages), but I’m still bashing out some of the subtle bugs it introduced when refactoring for batch database updates when indexing.

The one thing it did (that I would ordinarily never have bothered with) was to point out that word cloud generation (which I do to provide an OpenGraph preview for text-only posts) is computationally expensive and to recommend trimming some parameters, which helped during full site rebuilds.

So OK, it’s been helpful. It has not, however, saved me any time.

My new Wi-Fi is holding up fine with zero configuration changes since it’s been up (which I consider the best indicator of success), and I added to my infrastructure a 5-port version of the Sodola 2.5GbE switches I now use to fit a little nook where I needed more 2.5GbE ports.

Somewhere during that process and while setting things up on another switch, I realized there were some line errors on a port (good thing I have managed switches), and I decided to investigate.

It turns out that borg had been dropping off my Proxmox cluster randomly, which I initially ascribed to overheating but was actually a known issue with e1000 cards which causes entries like this to show up in the logs:

[  861.075538] e1000e 0000:00:1f.6 enp0s31f6: Detected Hardware Unit Hang:
                TDH                  <2a>
                TDT                  <76>
                next_to_use          <76>
                next_to_clean        <29>
                buffer_info[next_to_clean]:
                  time_stamp         <100075666>
                  next_to_watch      <2a>
                  jiffies            <100088a81>
                  next_to_watch.status <0>
                  MAC Status         <40080083>
                  PHY Status         <796d>
                  PHY 1000BASE-T Status  <7800>
                  PHY Extended Status   <3000>
                  PCI Status         <10>

Pulling the network cable and reinserting it causes the driver to reset, “fixing” it temporarily, but I searched the forums, and eventually added an ethtool invocation in /etc/network/interfaces to disable most (if not all) of the card’s hardware offloading features:

auto lo

iface lo inet loopback
iface enp0s31f6 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.1.20/24
        gateway 192.168.1.254
        bridge-ports enp0s31f6
        bridge-stp off
        bridge-fd 0

post-up ethtool -K enp0s31f6 gso off tso off rxvlan off txvlan off gro off tx off rx off sg off

I don’t think this is an issue with the switches at all (it does seem to be a well-known issue with e1000, and I’ve been having random disconnects from before I upgraded them that I attributed to summer heat), but it might be useful to somebody.