I’ve been spending a bit of time on LinkedIn lately after finally stopping my use of Xitter (you can find me on Mastodon instead). One of the tropes that I see being uncritically spouted over and over again is “I’m sooooooo productive, by spending $gazillion in LLM credits a day I’ll generate my new product at 50,000 lines of code day”.

While I’m applauding your effort to build a new, much needed product to fill a gaping hole in the market place, I’m sorry my dude (because it’s almost always a dude), but all you’re doing is generating technical debt at high velocity for a brief amount of time. Jon Bentley pointed out in his essays that turned into the book “Programming Pearls” (look it up) back in the 1980s that confusing, I’m sorry, measuring productivity by looking at the lines of code written is All The Wrong Measurements.

I’ve been using Samba with the time machine setting for years to back up the couple of Macs I own. I’ve recently been running into issues with Time Machine backups erroring out with "The network backup disk does not support the required capabilities". Poking around the Internet didn’t really point at an obvious culprit until I found some mumblings about this potentially begin a disk space issue.

Bingo!

While the Samba server had more than enough disk space left, I had set the maximum Time Machine volume size to 3.5TB using the setting fruit:time machine max size = 3.5T. Bumping this up to 4.5T magically made Time Maching backups work immediatly.

I’m currently rebuilding my main Windows machine after it had become close to unusable. Given that I upgraded it multiple times from Windows 7 all the way to Windows 11 without ever reinstalling the OS, this shouldn’t have come as a major surprise. Either way, this is the reason for the sudden outburst of Windows related posts so I can go and refer to my blog as my Internet Notes repository.

On my Windows machine, I’ve mostly moved from using separate virtual machine products like Hyper-V or Virtualbox to have access to a Linux machine to using WSL. The PC is dual-boot with a separate Linux install anyway, but sometimes I just want to quickly fire up a Linux machine, take care of a couple of quick tasks and go back to Windows.

WSL installs Ubuntu by default, but I tend to want a different distribution like OpenSUSE, Fedora etc. To not end up with a “spare” Ubuntu install, you can eitehr install WSL on a fresh Windows install without specifying a distributuion using wsl --install --no-distribution or by installing a different distribution immediately using wsl --install -d <distro name>.

In the time honored tradition of using one’s blog as an Internet-enabled notepad, here’s a quick not on how I build GNU Emacs on macOS using homebrew and the emacs-mac port cask:

brew upgrade -s railwaycat/emacsmacport/emacs-mac --with-mac-metal --with-imagemagick --with-native-comp --with-modern-icon --with-natural-title-bar

This - amongst other features - turns on some experimental macOS-relevant features and most importantly, the optional native compilation of Elisp code.

Version control system migrations are a fact of life for developers in any longer lived codebase. In fact, I’ve had a hand in quite a few migrations as newer, more workable version control systems became available. Also, like a lot of developers, I’ve got fragments of source code dating back quite some years floating around on various servers and development machines of mine. Not necessarily code that is still being used, but still code that I don’t want to just delete forever. Some of the oldest code I have uses RCS for source control and hasn’t been touched for a long, long time. As my machines generally don’t have anything as old as RCS installed for version control, I decided this might be a good time to migrate the code to my version control system of choice, Mercurial.

I’ve been trying to up my use-package game recently and converted my hand rolled package check and installer to use-package. I usually prefer to use packages from melpa-stable so I pin the default package source used by use-package to melpa-stable and override it where necessary That’s working well in general and looks something like this:

(setq use-package-always-pin "melpa-stable")

(use-package js2-mode
  :ensure t
  :defer  t
  :custom
    (progn (js-indent-level 2)
           (js2-include-node-externs t)))

(use-package kotlin-mode
  :ensure t
  :pin melpa)

So in other words, if I’m on a machine that doesn’t have js2-mode and kotlin-mode installed, use-package will install js2-mode from melpa-stable and kotlin-mode from melpa. So far, so good.

While I was implementing a few more changes on my web server - mostly adding the sorely needed blacklistd configuration for sshd - I noticed that NGINX’s log was showing occasional errors when trying to contact the Isso process. They all had one thing in common, namely that they were all trying to contact ISSO via IPV6 as the server has both stacks enabled. Turns out that isso only listens on an IPV4 socket and I could not find an obvious way to get it to listen on both.

I may have mentioned this before - I do run my own virtual servers for important services (basically email and my web presence). I do this mostly for historic reasons and also because I’m not a huge fan of using centralised services for all of the above. The downside is that you pretty much have to learn at least about basic security. Over the 20+ years I’ve been doing this, the Internet hasn’t exactly become a less hostile place. Anyway, Elliptic Curve Certificates, what about them?

First, I apologise for not noticing that the comments had been broken for a while. This was entirely my fault and not fault of ISSO, which I’m still super happy with as a self-hosted comments system. So in this post I’m going to describe what went wrong, and also how I made the system a little more resilient at the same time.

First, what did go wrong?

My web server is using FreeBSD as its OS, with a bunch of software installed via FreeBSD’s ports system. For those not that familiar with FreeBSD’s ports, the system essentially acts like a rolling distribution. As a result, you sometimes have to upgrade tools, especially languages like Perl, Ruby, and in this case, Python. A little while ago, the default Python version on FreeBSD was upgraded from Python 3.7 to Python 3.8, and I eventually followed along with that upgrade. ISSO is run out of a virtualenv as a regular user and the virtualenv was still using Python 3.7, but I decided I didn’t want to keep multiple Python versions on this machine. So, I upgraded the version in the virtualenv to 3.8 as well. So far, so good, especially as ISSO seemed to restart without issue.