Wow, VMware wasn’t kidding about Photon being a small, clean Linux distro, although it would have been nice if they’d also left out colorized ls output. Shame about systemd, but tdnf looks like a nice cleanup of yum, even if my brain reads the name as to-die-in-fire.

I barely even remember the ads for this, but I was in college at the time, and wouldn’t have spent my money on 15 pounds of laser-tag gear anyway. I did like the Peter David novelizations, though, which were better than you had any right to expect.

Update

Nearly one-eighth of the packages in the Photon repo are Perl modules. That sounds about right. No, wait that was the Alpine Linux window that I had open at the same time; Photon’s package list is only about 2.5% Perl. Which is actually better, since mixing packaged modules with CPAN downloads has always been a mess, and you can never get everything you need from just the packaged stuff. You should avoid the vendor-supplied scripting languages anyway, and use perlbrew/rbenv/pyenv/etc to build clean ones.

Also, to my surprise, I found four of the six “David Peters” Photon novels on my shelves without much effort. They’re apparently rare as hen’s teeth now, with dealers listing them for ridiculous prices that make hundred-page books on Japanese pickles look affordable.

With PDF::Cairo, I’ve formalized my dev/release process a bit. I have a handful of repos published on GitHub, because it’s the place people look, but I dislike Git. Bluntly, it exposes a lot of potentially destructive features by default, including the whole tissue-paper “branch” model. I’m of the rather firm belief that the most important task of a version control system is to preserve the history of your files, and Git doesn’t.

Git didn’t win the DVCS wars for any significant technical reason, it won because: the Linux kernel devs use it, team leads really like the GitHub pull-request model, and junior devs just out of college freeze when confronted with anything unfamiliar.

When I migrated all my little projects out of RCS, I chose Mercurial as their new home, and I don’t regret it. First, because the usage reflects design choices rather than implementation details; second, because most dangerous commands are disabled by default; third, because extending its functionality is quite simple even for people who dislike Python; and fourth, because it stores your revisions in append-only files with honest-to-gosh reversible transactions.

Even on a project where I’m the only user, I appreciate the fact that “cut-and-paste from StackOverflow” is unlikely to destroy my repo, something that is definitely not true for Git. On real projects at work, there are devs who will cheerfully follow any instructions they find online when they get in over their head, and not tell anyone else unless they can’t undo the resulting damage on their own.

For solo projects, I obviously don’t get into elaborate workflows, but I do like being able to push to a remote repo as an instant backup, so I have Kallithea running in a Docker container on my Synology NAS. Not visible from the Internet, of course, but I can always VPN back to the house, which also comes in handy when I’m out and about on an untrusted network.

With that out of the way, here’s my process for PDF::Cairo:

1. do all development locally in Mercurial (one branch, lots of little commits and extra test files I don’t plan to release).

2. snapshot the code and copy into the local Git repo, as a single changeset containing only files explicitly listed in the project MANIFEST file:

perl Makefile.PL
make dist
cp PDF*.tar.gz $GIT
cd $GIT
tar xzf PDF*.tar.gz
cd $GIT/PDF-Cairo
git add .
git commit
git push

3. To keep track of exactly what changed, I have a Mercurial bookmark (which is more-or-less what Git calls a “branch”) named “togit”, which is applied to the last commit already pushed to GitHub. The following command gives the details of all of the changes since then, in chronological order:

hg log -r 'togit:: and not togit'

4. Once the new version’s on GitHub, I move the bookmark to tip-of-tree and set it to not auto-update to new commits:

hg bookmark -i togit

The result is a clean public repo with a sensible history, backed by a messy private repo filled with random test scripts, todo lists, rude comments about poorly-documented APIs, etc. The distribution tarball can be uploaded to GitHub as a release, but someone who chooses to just download the automatically-created Zip/Tar archives will also get a complete usable release.

The only potential complication is accepting a pull request on Github and then merging that back to Mercurial. For that, if it ever happens, I’ll use git diff -r... followed by hg import --no-commit.

Sigh…

Submitted PDF::Cairo to CPAN, and PAUSE complained because it thought I was trying to take over ownership of the Cairo::ImageSurface and Cairo::RecordingSurface namespaces.

Because I added some convenience methods to them:

package Cairo::ImageSurface;
sub height {
        my $self = shift;
        $self->get_height;
}
sub width {
        my $self = shift;
        $self->get_width;
}

package Cairo::RecordingSurface;
sub height {
        my $self = shift;
        $self->{h};
}
sub width {
        my $self = shift;
        $self->{w};
}

Admittedly, this is a hack (and I can probably work around it by explicitly naming them Cairo::RecordingSurface::height, etc, instead of using package), but it strikes me as a rather aggressive behavior by their uploader (“Index all the things!”).

I managed to give up “ownership” of Cairo::RecordingSurface, and I’ve re-uploaded a new version with the hack to the hack. Seems to work now.

Fun with automated testing…

One feature of CPAN is that there are a bunch of people around the world with automated testbeds that attempt to build each new module on a wide variety of Perls and operating systems. Within a few hours of uploading 1.03, I got email from one that failed on 100% of his test platforms.

In the vast majority of cases, it complained that there was no such thing as a Cairo::RecordingSurface->create() method. Looking at the source for the Cairo module, this can only happen if it’s linked against a version of libcairo older than 1.10.0, released in September 2010.

Yeah, I’m okay with that. I just noted it in the docs, and added that some future features will require 1.16.0 or newer (although all current functionality will continue to work).

Unfortunately, the failure reports don’t include the C library versions, so I’ll have to add that to the test suite to make it clear that it should fail if your libraries are that old.

First item in the release notes for Ghostscript 9.27:

Version 9.27 (2019-04-04)

IMPORTANT: It is our intention, within the next 12 months (ideally sooner, in time for the next release) to make SAFER the default mode of operation.

I only suggested this 27 freaking years ago.

My combination stratum 1 NTP server and Pi-hole is up and running.

Notes

0. Definitely boot from Raspbian Stretch Lite, as described in the instructions. No point in having it auto-login to a graphical console, or even having the packages installed, especially since you disable video memory as part of this setup.

1. NTP first, Pi-hole second; they both want to reconfigure your machine, so you have to be careful with the canned configuration scripts, although there are no direct conflicts at this time. Also, the NTP setup script is far less complex and invasive, so it’s much easier to know what it changes (530 lines versus 2,649).

2. Pi-hole sets a static IP address in /etc/dhcpcd.conf, which is a bad idea. It prevents you from building a server on one network which will be installed elsewhere, and in a home environment without static leases, it’s only guaranteed for the uptime of the router. I commented out their change (don’t delete it; the installer greps for the current IP address to decide if you’re configured ‘correctly’), and instead uncommented the local nameserver line in /etc/resolvconf.conf.

3. I went with the Uputronics hat and external antenna, which is the solder-free, battery-free option. Purchased from their US distributor, Airspy.US. This costs basically the same as a Pi and a case, plus shipping.

4. I used the clockmaker script with only one problem: ntpsec’s configure script blew chunks. Clockmaker pulls down tip-of-tree, and the team develops directly in the main branch, so they sometimes break the build (Eric Raymond made the aes_siv library mandatory before someone else committed the supporting code). The quick fix is to cd into the ntpsec directory and run something like this to switch to the most recent release: git checkout $(git tag --list --sort -taggerdate | head -1)

5. Note: need to run the CFG-CFG command for the Uputronics board while ntpsec isn’t running.

6. Fuck Patriot, by the way. I bought a 5-pack of their Class 10 16GB MicroSD cards on Amazon about 14 months ago, and 2 of them came up read-only when I went to use them for this project. They all worked the first time…

7. I don’t know about the other GPS boards, but the Uputronics shouldn’t be put in a clear/open case, because it has a nice bright LED that flashes once a second. Really lights up a dark room.

8. I wanted some additional local dnsmasq overrides, so I put them in /etc/dnsmasq.d/00-local.conf.

9. Naturally I made a copy of my MicroSD card after I got it working…

Update

Changed /etc/ntp.conf to add a static offset for the non-PPS clock: refclock shm unit 0 refid GPS time1 +0.114. See ntpsec issue 9.

…and filed a bug on the clockmaker script.

On Win10 machines with relatively modest CPUs, perhaps you shouldn’t run security scans on downloads in parallel. And maybe set an upper bound on the scan time based on file size, so that if it gets deeply confused (by, say, the MSI for Amazon Corretto), it doesn’t lock up the system to the point where it takes two minutes just to recognize a three-finger-salute.

Tried out the Fedora 29 beta. I can get past having to reset the screen resolution every time it boots, since it’s running under VMware Fusion and thus may not be Fedora or GNOME’s fault, but this definitely is:

Yes, the Media Size menu is mostly offscreen. At least, the first time I click on it; it’s just plain missing after that, which leads me to believe it’s completely offscreen.

Not shown is the batshit-craziness of having to unlock the printer configuration with your password before you’re allowed to change anything on this screen at all: page orientation, paper size, duplex, tray, anything.

Dinking with parody O’Reilly covers reminded me of the one I’m in:

I wasn’t involved at all with the book, and I was, as they say, “just another Perl hacker”, but I did have one thing going for me: I ran tut.

tut.cis.ohio-state.edu was our “big iron” back in the day, a multi-user Unix box that had the dubious distinction of running both BSD and SysV Unix, at the same time. It was one of the few machines that was more for research than instruction, and among its many hats were: Usenet backbone site, GNU mailing list to Usenet gateway, anonymous FTP site, anonymous UUCP site, and (for a while) Compuserve’s tape-based Internet email relay.

[seriously; Karl Kleinpaste would drive 9-track tapes over to their office and back]

In its FTP/UUCP capacity, it hosted all the GNU software, and Perl. Because the official distribution method was Larry posting multi-part shar archives to Usenet, until it got too darn big.

Anyway, my only appearance in the book is my old email address on page xxii, as the UUCP contact address. This was still enough for me to get support email a few times, from people who didn’t want to bother “the big names”.

Fun facts:

“The text of this book is set in Times Roman; headings are in Helvetica®; examples are Courier. Text was prepared using SoftQuad’s sqtroff text formatter. Figures are produced with a Macintosh™. Printing is done on an Apple LaserWriter®.”

You’ve come a long way, baby.

Oh, and when I dug my copy out of a box, I discovered two things: it’s signed by Larry and Randal (something I forgot decades ago), and it still has the original postage-paid mail-in card. I’d be tempted to send it in, but they moved their headquarters sometime after 1991…

When L. Peter Deutsch first added the file I/O operators to Ghostscript (1992?), I submitted a security patch to disable them by default, requiring you to use -dUNSAFE to enable them. He accepted the patch but reversed the logic, enabling them unless you provided the -dSAFER option. I no longer remember precisely how he handwaved away my concerns in his email, but it doesn’t matter.

I was right then, and I’m still right.

(At the same time, I also submitted a patch to the crude -dASCIIOUT option to make it possible to extract the text correctly and post-process it into a document that preserved formatting pretty well, but he only accepted half of it, because he was concerned that adding a Perl script to the base distribution would impair its portability…)