Computers

Homebrew FU


To augment the relatively small amount of Open Source software included with MacOS (soon to be even smaller), I used to use Fink. Then I used to use DarwinPorts (now MacPorts). And just now, I started wondering if it’s time to give up on Homebrew.

Why? Because the maintainers very very quietly decided to gut the functionality of the tools by removing all of the compile-time options for every package, restricting them to a single flavor. The dozens of bugs filed since then just get closed with rude noises, and maybe a handful of the requests for lost functionality get added back as part of the one-and-only build flavor (but only if they’re submitted in precisely the correct format and don’t conflict with other undocumented policies). The best part is that if you had installed something with options selected, it silently broke the next time it was updated.

Their recommended solution: “create your own tap”, which is like telling someone who came in for an oil change to build their own fucking garage if they don’t want 5W30.

Graphics card bleg


What’s the best-bang-for-the-buck gaming graphics card that I can put into this?

Current specs:

  • Intel Core i7-6700, 3.4 GHz
  • NVIDIA GeForce GTX 980, 4 GB RAM
  • 32 GB RAM
  • 256 GB SATA SSD
  • 1 TB SATA SSD
  • 500 Watt power supply

I’m tempted to replace the original small SSD with an NVME PCI Express card and one of the many ridiculously-affordable M.2 NVME SSDs. (never mind, the free slot is only PCI Express x1)

How Open Source ‘Works’…


Seems there’s a trivial denial of service attack against GPG via the keyservers, and the fix is… well, there really isn’t one:

“​…the SKS software was written in an obscure language by a PhD student for his thesis. And because of that, according to Hansen, ‘there is literally no one in the keyserver community who feels qualified to do a serious overhaul on the codebase.‘”

Bootstrapping…


# tdnf install perl
# cpan App::cpanminus
# tdnf install man-db man-pages gawk tar diffutils
# tdnf install make gcc binutils glibc-devel linux-api-headers ncurses-devel
# su - build
% curl http://ftp.gnu.org/gnu/emacs/emacs-26.2.tar.gz | tar xzf -
% cd emacs-26.2
% ./configure --without-all --without-x
% make
# cd ~build/emacs-26.2
# make install
# cat <<EOF > /root/.emacs
(setq-default initial-major-mode 'fundamental-mode)
(defun set-auto-mode (&optional foo) (interactive "p") (fundamental-mode))
(when (fboundp 'electric-indent-mode) (electric-indent-mode -1))
(global-set-key (kbd "TAB") 'self-insert-command)
(setq-default tab-width 4)
(setq-default enable-local-variables nil)
(setq-default inhibit-eol-conversion t)
(setq inhibit-startup-screen t)
(setq inhibit-splash-screen t)
(setq line-move-visual nil)
(setq transient-mark-mode nil)
(setq sentence-end-double-space nil)
(setq isearch-lax-whitespace nil)
(setq search-whitespace-regexp nil)
(put 'narrow-to-region 'disabled nil)
EOF

Okay, now I can start exploring Photon.

File under baffling the fact that there’s no Emacs RPM at all. Admittedly, even my “minimal” build adds 200MB to /usr/local/, but:

“When you don’t have enough space for Emacs, you don’t have enough space.”
     — Sandy Wambold

No highlights, please


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.

related

“For the glory”


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.

togit:: and not togit, that is the answer!


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.

Finally!


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.