As usual, partway through a couple weeks in Mallorca, we’re just getting the hang of it. After a few days of only the pool, it’s been pool mornings and beach afternoons. Every day, each kid gets more bold in both. I’ve managed to avoid getting sunburnt so far, though it’s getting harder to stay ahead of the situation. For mealtimes it’s kind of fun to be stuck in a tiny kitchen trying to cook my way out; bedtimes, down a sleepable room due to a broken air conditioner, were less so. My carcass got taken over by mosquitoes, who then rented most of it back to me. In a few days I might be ready to buy them out.
Usually here I’d consider taking a nap when the littles do. Definitely tired enough. But a little solo computer time feels more like what I’m needing: Refactoring some code, backing up some photos, updating pkgsrc stuff, writing posts on my website, that sort of thing.
For this summer vacation we’re hopping around more, which happens to simplify our transatlantic travel days. (Traditionally we’d have connecting flights before arriving anywhere.) One flight into Munich, where we stayed in the area for a few days visiting in-laws. From there a quick hop to Mallorca, the meat in our vacation sandwich. From here a quick-ish hop to Hannover for a week back in the little north-central German village where we lived out the first two years of COVID. Then we’ll drive to Frankfurt to see friends before our return flight to New York. Hopping around like this means we get to see more people and places, in exchange for which we get to find out what happens when kids try to sleep in a wider variety of environments and configurations. So far, sokay.
We have a 2017 13” MacBook Air that’s periodically of interest to the kids, but Apple doesn’t offer macOS updates for it beyond Monterey (12.x).
I just installed OpenCore Legacy Patcher on it, clicked “Build and Install OpenCore”, rebooted, ran Software Update again, and was offered Sonoma (14.x), the latest available macOS at the time of writing.
Upgraded, rebooted, ran OpenCore Legacy Patcher, clicked “Post-Install Root Patch”, rebooted when prompted, and that was that.
On my home network, some important jobs are performed by little ARM computers.
AirPlay to sound system
The house came with a decent sound system wired in. The receiver can take 1/8” stereo input — from AirPlay, with help from a decade-old Raspberry Pi 1 Model B Rev 2.
1. Prepare disk
With a 4GB SD card, from macOS:
$ diskutil list # inspect output
$ SDCARD=disk6
$ diskutil unmountDisk ${SDCARD}
$ links https://raspi.debian.net/tested-images/
$ DISKIMAGE=20231109_raspi_1_bookworm.img.xz
$ fetch https://raspi.debian.net/tested/${DISKIMAGE}
$ xzcat ${DISKIMAGE} \
| sudo dd of=/dev/r${SDCARD} bs=64k oflag=sync status=progress
$ diskutil eject ${SDCARD}
2. First boot
Place the RPi somewhere convenient.
Connect SD card, keyboard, HDMI, Ethernet, and power.
Log in as root, no password:
# apt update
# apt -y install etckeeper
# cd /etc
# git branch -M main
# apt -y install sudo
# visudo # for the sudo group, insert NOPASSWD: before the final ALL
# useradd -m -G sudo -s /bin/bash schmonz
# passwd schmonz
# exit
Log in as schmonz:
$ sudo passwd root
$ sudo sh -c 'echo 127.0.1.1 schleierplay >> /etc/hosts'
$ sudo hostnamectl hostname schleierplay
$ sudo ln -sf /usr/share/zoneinfo/US/Eastern /etc/localtime
$ sudo etckeeper commit -m 'Set root password, hostname, and timezone.'
$ sudo apt -y install shairport-sync
$ sudo vi /etc/shairport-sync.conf
$ sudo etckeeper commit -m 'Set AirPlay name.'
$ sudo shutdown -h now
3. Deployment
Place the RPi where it’ll live. Connect audio cable, Ethernet, and power.
$ ssh-copy-id schleierplay.local
4. Usage
Make sure receiver is set to AUX input. Use AirPlay.
5. Maintenance
As with any Debian:
$ ssh schleierplay.local -t 'sudo apt update && sudo apt -y upgrade && sudo apt -y autoremove'
To back up /etc, git push it someplace trustworthy and private.
6. Wishlist
I’d rather run NetBSD, but on 10.0 with shairport-sync, I saw a lot of AirPlay Speaker Not Available: 'House' is being used by someone else (even when it wasn’t).
AirPrint to old printer
My ancient USB-only HP LaserJet P1006 remains reliable for our basic needs and we’ve still got a pile of toner cartridges. A friend recently sent me a comparatively beefy Pine A64 board.
1. Prepare disk
With a 4GB SD card, from macOS:
$ diskutil list # inspect output
$ SDCARD=disk6
$ diskutil unmountDisk ${SDCARD}
$ links https://www.armbian.com/pine64/
$ DISKIMAGE=Armbian_24.5.1_Pine64_bookworm_current_6.6.31_minimal.img.xz
$ fetch https://dl.armbian.com/pine64/archive/${DISKIMAGE}
$ xzcat ${DISKIMAGE} \
| sudo dd of=/dev/r${SDCARD} bs=64k oflag=sync status=progress
$ diskutil eject ${SDCARD}
2. First boot
Place the A64 somewhere convenient.
Connect SD card, keyboard, HDMI, Ethernet, and power.
Follow the prompts to set the root password, create a user account, and select a locale.
Then continue:
# apt update
# apt -y install etckeeper
# cd /etc
# git branch -M main
# visudo # for the sudo group, insert NOPASSWD: before the final ALL
# exit
Log in as schmonz:
$ sudo sh -c 'echo 127.0.1.1 schleierprint >> /etc/hosts'
$ sudo hostnamectl hostname schleierprint
$ sudo ln -sf /usr/share/zoneinfo/US/Eastern /etc/localtime
$ sudo etckeeper commit -m 'Set root password, hostname, and timezone.'
$ sudo apt -y install hplip avahi-daemon
$ sudo usermod -a -G lpadmin schmonz
$ sudo etckeeper commit -m 'Make myself a printer admin.'
$ sudo shutdown -h now
3. Deployment
Place the A64 where it’ll live. Connect printer, Ethernet, and power.
$ ssh-copy-id schleierprint.local
$ ssh schleierprint.local
$ sudo hp-setup -i # follow prompts, mostly defaults; name the queue 'hpljp1006'
$ sudo etckeeper commit -m 'Add initial hplip config for P1006.'
$ sudo sed -i \
-e '/^\*ColorDevice: True$/s|True|False|' \
-e '/^\*OpenUI \*Duplex\/Double-Sided Printing: PickOne$/,/^\*CloseUI: \*Duplex$/s|^|*% |' \
-e '/^\*OpenUI \*ColorModel\/Output Mode: PickOne$/,/^\*CloseUI: \*ColorModel$/s|^|*% |' \
/etc/cups/ppd/hpljp1006.ppd
$ sudo etckeeper commit -m 'Correct advertised printer capabilities.'
$ sudo sed -i \
-e 's|^Info $|Info HP LaserJet P1006|' \
/etc/cups/printers.conf
$ sudo lpadmin -d hpljp1006
$ sudo etckeeper commit -m 'Name printer and set it as default.'
$ sudo cupsctl --remote-any
$ sudo etckeeper commit -m 'Let local network talk to CUPS.'
$ sudo sed -i \
-e '/^WebInterface /a PreserveJobFiles No' \
/etc/cups/cupsd.conf
$ sudo etckeeper commit -m 'Maybe avoid some disk writes.'
$ sudo systemctl restart cups
On macOS, do not override the generic driver with “HP LaserJet P1006”.
You won’t be able to print (with filter failed in the server logs), except that every “Supply Levels” check —
including the ones that happen as part of every print job —
will produce a piece of paper containing the single line @PJL INFO SUPPLIES.
As I understand it, some versions of CUPS have a server bug where it can’t discern whether incoming data has already been filtered for the target queue:
filters converted the data (via application/vnd.cups-raster) to the printer’s native command set (whatever that might be)… but when the job got sent to the CUPS server it was tagged as application/vnd.cups-raster rather than, say, application/octet-stream.
While that discussion is over a decade old, its advice — leave the filtering to the server, and make sure clients don’t do any — has me printing from macOS, iOS, and Windows.
4. Usage
On macOS, add the printer. When it autoselects “Generic PostScript Printer”, leave it (details in sidebar). Print.
On iOS, print.
On Windows, add the printer. Print.
5. Maintenance
As with any Debian:
$ ssh schleierprint.local -t 'sudo apt update && sudo apt -y upgrade && sudo apt -y autoremove'
To back up /etc, git push it someplace trustworthy and private.
6. Wishlist
I’d rather run NetBSD, but neither 10.0 nor -current brought up HDMI.
I could try writing NetBSD to an SD card, mounting it from another NetBSD system, setting hostname in rc.conf, adding a non-root user, and then booting the A64 from it in order to do the rest over ssh.
(Other systems that also didn’t bring up HDMI, wherefore I landed by trial and error on Armbian: FreeBSD 14, OpenBSD 7.5, Debian 12.)
AirPlay to old Sonos
Since one of my old Sonos speakers can’t be upgraded to AirPlay-compatible firmware, I’m not eager to upgrade the other. Instead, I’ve added AirConnect on the Pine A64 as an AirPlay relay.
Contents of /etc/systemd/system/airupnp.service:
[Unit]
Description=AirUPnP bridge
After=network-online.target
Wants=network-online.target
[Service]
ExecStart=/home/schmonz/bin/airupnp-linux-aarch64-static -l 1000:2000 -N '%%s' -x /home/schmonz/etc/airupnp.xml -Z
Restart=on-failure
RestartSec=30
[Install]
WantedBy=multi-user.target
Contents of /home/schmonz/etc/airupnp.xml (to omit my UPnP router from the AirPlay list):
<?xml version="1.0"?>
<airupnp>
<device>
<udn>uuid:1e38fc78-51f5-5f5d-9268-50c6b1dc59f8</udn>
<name>Verizon FiOS-G1100 ManageableDevice+</name>
<mac>bb:bb:bb:bb:bb:bb</mac>
<enabled>0</enabled>
</device>
</airupnp>
I’d rather install AirConnect from a system-provided package, but there isn’t one for Debian. Maybe I can puzzle out the AirConnect build system and add it to pkgsrc.
On Friday, May 10, I presented “Not So Extreme Programming” for Large Scale Scrum (LeSS) in NYC & Global.
The abstract:
Where “Agile” sounds pleasant and inclusive, “Extreme Programming”… doesn’t. But it’s a differentiator: teams practicing XP are seen to move with uncommon agility. The name has other problems, too. For one, XP is about much more than programming. For another, when compared with other ways software still gets developed, XP is much less extreme. This talk — for anyone involved with Agile in any role, at any scale — will take you through where Extreme Programming came from, where it’s going, what it requires, why it remains as relevant as ever, and how to take advantage.
Video:
My early imaginings of a collaborative Open Source successor to qmail, let me assure you, did not include going nearly four years between releases. Well, at least it hasn’t been more than four. notqmail 1.09 is here:
For decades, due to each administrator needing to patch in their particular missing bits of functionality, the qmail source code itself has effectively been a public API. Some future release of notqmail will include everything most everyone needs. On that day, we’ll freely make desirable code changes without worrying about breaking people’s patches. On that day, notqmail will have become a relatively normal software project operating under relatively normal constraints.
This is not that day. notqmail remains a uniquely challenging legacy-code rehabilitation project, and 1.09 is merely a solid, long-overdue release that includes the work of a couple dozen new contributors.
Since this release took too long, our next development cycle will be
- Time-bounded
- Focused on process improvements
In legacy code, every time we can turn a vicious cycle virtuous, it’s a big win. By making the code easier and safer to change, we’ll have more fun; by having more fun, we’ll make more progress; by making more progress, we’ll get more feedback; by getting more feedback, we’ll have more fun; and so on.
Have fun with notqmail 1.09! Let us know how the upgrade goes for you. (I’ll be updating the pkgsrc package soon.) And if getting involved is your kind of thing, please feel welcome to join us.