Why I Hate Syntax Highlighting: Mac Pascal.
(via)
Had to use this in a programming class back in the Eighties, and if the windows in the lab had been openable, I’d have defenestrated about three Macs a day.
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.
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:
do all development locally in Mercurial (one branch, lots of little commits and extra test files I don’t plan to release).
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
hg log -r 'togit:: and not togit'
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
.
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.
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.
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.
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).
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
.
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.
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)
Note: need to run the CFG-CFG
command for the Uputronics board
while ntpsec isn’t running.
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…
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.
I wanted some additional local dnsmasq overrides, so I put them in
/etc/dnsmasq.d/00-local.conf
.
Naturally I made a copy of my MicroSD card after I got it working…
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…