This years Hugo Awards
finalists and winners have been announced, and as I'm always looking
for new authors with stories worth my reading time, I ordered a random
selection of them as used books. As I don't care much for the books as physical
items, getting them used is fine - they will be read in the bathtub anyway.
Murder by Memory is ab interesting 100 page murder mistery novella,
maybe in the "cozy" genre of crime fiction. The premise is that the ship
detective of a star faring slow ship gets woken up because some backups were
destroyed and somebody was murdered. They now have to find the murderer, the
motive and also the mechanism.
The book is part one of a three part series.
I think it was Charles Stross
who wrote that it is basically impossible nowadays to sell a single book, you
always have to sell them as a trilogy to a publisher. The other two books
are already listed on Amazon but not yet published, or at least, not yet
available as used books, so I will stay patient.
Some of the trappings of the story remind me of Altered Carbon, but the story
is quite short
and fast-paced, so it doesn't hurt too much. The book does not go too deep into
the societal consequences of human backups. On the other hand, you would expect
most people on a 1000-year voyage to be on board with backups and restoration,
in contrast to the larger, and more layered society of Altered Carbon.
There are some things that don't feel sensical to me, but that may be because I
think too much about society and money. The ship has a (backed up) population
of 10.000 persons, but they seem to have money, huge interest rates and at
least one large bank. While I understand that the conceit is to keep people
exercising their skills until landfall on a new planet, I don't understand how
the interest rates could work like they do in the story. As a mostly stagnant
population, I wonder where the need for that much capital and loans goes into,
with no economy to grow. But most likely, I'll attribute this criticism to my
view of the small population.
Story wise, the book could be double the size, as it has some traces of a
longer noir story that aren't followed up on. Maybe it started out as a longer
story and was then trimmed back for publication instead of trying to bring it
to an Altered Carbon style lobger story. There could be one or two more plot
twists to stretch out the story and my instincts led me to suspect deeper
machinations to the murder. But the story works as-is , and better a published
story that is short than an unpublished story that does not go anywhere, or is
too similar to comparable setups like Altered Carbon or Glasshouse .
I took this image last year on my way through downtown Frankfurt. The sun was shining and it was a relatively warm day for Winter. The non-traditional view of the skyline is what drew me in. I'm not entirely happy with the large free space in the foreground, but then again, the image is good enough.
Now that I have a shell script to send images to my Eink display, I'm looking
at improving the experience. Mostly by porting the tools to Perl to better
integrate them with my other tools. But also, by making it more convenient to
find and select new images to display on the screen.
Shell script
I want to build a good collection of images to display on the Eink display.
As I often lose track of the filename of a very good looking image (
I'm already looking at it on the display and I like it, why should I bother with the filename?
), I've added logging to my interim shell script so that I have a log of files
to go through and re-evaluate.
I'm using JSONL as the log format, not because it is especially easy to create
from the shell, but it is highly convenient for later processing with other
tools.
#!/usr/bin/perl
use 5.020;
use JSON::Tiny 'encode_json';
use Getopt::Long (qw(:config pass_through permute)); # stop at the first unknown option or first argument
use POSIX 'strftime';
my $result = {};
my $name;
GetOptions(
'<>' => sub( $v ) { if( ! $name ) { $name = $v =~ s/^--//r; } else { $result->{$name} = $v; undef $name }; },
);
$result->{ timestamp } //= strftime '%Y-%m-%dT%H:%M:%SZ', gmtime();
say encode_json( $result );
I've also added bas64-encoded thumbnail images to the log lines so that I can
easily display the logfile as an HTML page to better pick out good images or
images to discard.
Shell integration
After adding the appropriate file in ~/.local/share/applications/eink.desktop
I can send any image to the frame by using a right-click. This is highly
convenient and encourages me to quickly try out new images.
The Perl port of the sender script will likely use
request/response mechanism, easily adapted into Future / Future::Mojo
I need to port the mdc Javascript module and create a test suite to properly
encode the blobs.
MDC documentation PDF
While looking at the Javascript code, I found the official MDC documentation
version 15.0 PDF from 2020-11-06 . This describes the actual protocol
(serial, or over IP) in detail.
The command blocks are simple, consisting only of 8-bit bytes. This is a
problem for payloads (like URLs) that are longer than 230 bytes. But for my
use-case, that is no problem.
The inconvenient thing is that the length does not immediately precede the
payload, so that unpack does not work. Instead I've used a regular expression
to extract the parts.
The blobs are sent and received via port 1515. I have not found a way to
change this port, but I'm not sure why I would want that.
Whenever I prepare the videos of the German Perl Workshop for release, I dread that my custom build of ffmpeg broke due to a Debian upgrade. Neither does happen often, the German Perl Workshop happens once every year, and a Debian upgrade maybe every two years. But still.
I'm in the process of preparing the videos of the 2026 German Perl Workshop, and it occurred to me that I can simply patch the Debian distribution and recompile it instead of cloning the ffmpeg repository and then hunting down the prerequisites etc. .
So, without further ado here is the process which the good folks at Debian already documented quite well:
Get the ffmpeg source
apt source ffmpeg
Patch debian/rules
To append our new instructions, we need to edit the CONFIG command in debian/rules and append at the end of the stanza:
