I've uploaded a new #Perl Critic policy that checks code for naive random data generation from a hash over not-so-randonm sources like rand(), system time, pid such as
md5_hex( rand . time . $$ . ++$counter )
This anti-pattern is used in many places, and has been the reason for several CVEs.
https://metacpan.org/release/RRWO/Perl-Critic-Policy-Security-RandBytesFromHash-v0.1.0
As a scholarly aside, I am curious as to who first came up this anti-pattern.
A new blog post on the nature of #CPAN-based experiments at adding new syntax and features to the #Perl language.
Or at least, the first half before I get around to writing the thing I was actually going to say, in likely a follow-up post next week.
https://leonerds-code.blogspot.com/2026/03/cpan-based-experiments-reminder.html
Gonna build a #CPAN testing VM with #DragonflyBSD. Any gotchas that my fedihomies think that a seasoned Unixhead should know about?
A few days ago I tried to build some perls with 32 bit ints and 128 bit floats. Cue test failures. Today I tried again, and this time I read my notes from last time on how to do it, and it Just Works.
Yay past me!
(the #BigInt modules bundled with some versions of perl don't like that combination of data sizes; the solution is to ignore their test failures, install anyway, and then upgrade to the latest versions from the #CPAN)
I have released a new version of App::CpanDak, my sub-class of App::cpanminus / cpanm with "some sort of distroprefs"
You could already apply patches, skip tests, and set environment variables, to any distribution you installed; now you can augment version specifications.Some::Fancy::Library has released a new version 1.3.4 that doesn't install cleanly? add a Some-Fancy-Library.options.yml with:
---
add_version_spec: "!= 1.3.4"and that version will be skipped, even if pulled in via indirect dependencies!Popular Distributions - metacpan.org
https://metacpan.org/favorite/leaderboard