Last Saturday, I played through Senua's Sacrifice,
a game first released 2017 to critical acclaim.
The game was rather disappointing - the story is good, but the gameplay is a mix between a walking simulator,
cutscenes telling a story, some small puzzles and boring melee fights against the same set of five enemies.
Luckily, the game was also quite short, because I don't think I would have spent a second evening
with that game.
If you want to play, I recommend getting it on discount and playing it on easiest difficulty. The story is
OKish and might entertain you for an afternoon or evening.
I missed last year but in 2024 I'm doing a dev release of Perl again. This time it is version 5.39.7.
And again, you can watch it live on Saturday 20th of January on Twitch:
You can expect to watch me talk through the steps of the Perl
Release Managers Guide and if you join the Twitch chat, or
#p5p on irc.perl.org, we can chat a bit.
I assume I'll start Saturday at 08:00 UTC (10:00 CET), and the whole thing will
take around 4 hours unless there are some major mishaps.
Usually I build and test Perl by copying the
C compiler from Strawberry Perl. But just today
I found w64devkit, which is a distribution
of busybox, gcc and mingw-w64, and it works well to compile and test
a fresh Perl:
cd perl5/win32
make -j CCHOME=C:\\Users\\Corion\\...\\w64devkit
make -j test
My upgrade of my home server from Debian 11 ("bullseye") to
Debian 12 ("bookworm") went
almost without a hitch. Yesterday I realized that the Postgres data hadn't
been migrated from the old DB to the Debian package of Postgres 15. But
luckily, the good Pg people provide a Debian
package of 9.6 (the version which held my data) for Debian 12.
I could install that one, fire it up, dump all data into SQL, fire up Pg 15
from Debian and import it there. Now I run such an SQL dump daily, just to have
the data available as SQL files.
I wonder if it would be worthwhile for Perl to provide prebuilt
binaries/packages of old Perl versions for current OSes, but then, there are so
many build options that it's not worth the effort in general.
The only use case I see would be to provide an emergency Perl when your
dist-upgrade nuked the system Perl [^1] , but some custom XS modules
or XS modules installed via cpan instead of the package manager
relied on that version. This would reduce the number of build options,
but I'm still not sure if that actually helps anybody.
Maybe simply taking the (Debian) build files for old packages/distributions and
running them for new distributions, with a prefix of /opt/perl5-xx could
already help. People would still need to edit the path of their scripts to
bring things back up.
This only makes sense when also rebuilding all the old CPAN modules
for the new OS version, except under /opt. That's a lot of effort for
little to no gain, except when people really need it.
[^1] : well, not nuked, but replaced with a newer major version that is
not binary compatible