hi all, sorry if this question has been asked 500 times. i believe ive looked into it before, but didnt see any posts specifically to cybersecurity (could be wrong).

i took a class last year that covered linux systems and bash, fell in love. learned through the professor that something called "perl" used to be taught in the class years ago..also fell in love and have been slowly learning it since, for fun!

i am really tired of people asking me why the fck im learning perl though, and i should focus on "marketable skills"-- unfortunately my brain refuses to work that way. ​

i had a friend tell me recently "perl is strangely incredible for evading EDRs like crowdstrike" and said i can write a malicious perl script the cybersec team at my school can reverse engineer to train for competitions would be a great idea too. it had me wondering what other applications perl has in the cybersecurity world specifically in 2026 that i can focus on? im in the middle of trying to figure out my niche..i did take a class on reverse engineering which was fun. i wrote an awk script to find specific pairs of instructions that would be common in malware. i also took a course on steganography and found that there are a lot of stego tools written in perl.

people say its useless to learn, but im seeing a lot of useful tools written in perl!

if you all have any other ideas of paths i should pursue or just general info about the power of perl in cybersecurity today, i would greatly appreciate it. thank you

Hi everyone, I have a quick question for those experienced with CPAN distributions.

In my distribution, alongside the main modules, I have several internal sub-modules (for example, language-specific modules like Locale::Lang::en, de, fr, etc., which are only meant to be used internally by the main module).

Currently, every sub-module has the same $VERSION as the distribution itself. Would there be any issue if I completely removed the $VERSION from these internal modules? There is no real benefit to having them listed or indexed separately on CPAN.

The AmberDB::Locale module was originally a standalone localization engine. It contained far more methods than the database itself. However, search capabilities were unthinkable without Locale, so it was embedded within AmberDB.

You can use Locale both through AmberDB and directly. Example:

use AmberDB;
my $adb = AmberDB->new( cfg => { language => "tr" } ); # Turkish

# thus $adb inherits Locale's methods directly.

$adb->lc('İstanbul ÇarŞıSI') # => istanbul çarşısı
$adb->uc('işçi sınıfı') # => İŞÇİ SINIFI
$adb->to_ascii('Müller') # => Muller

my @sorted = $adb->sort(["İzmir", "Ankara", "Van", "Şanlıurfa", "Bursa", "Çanakkale"]);
# => ("Ankara", "Bursa", "Çanakkale", "İzmir", "Şanlıurfa", "Van")

Direct use of Locale:

use AmberDB::Locale;
my $loc = AmberDB::Locale->new( language => "de" ); # Germany

$loc->to_ascii("Große Straße"); # "Grosse Strasse"
$loc->to_ascii("Müller"); # "Mueller" (DIN 5007-2: ü → ue)

For more information, see:

https://github.com/marufcetin/amberdb/blob/main/docs/en/AmberDB-Locale_User-Guide.en.md

I have released **AmberDB**, the Perl database engine I have built and refined over 20+ years of professional software development, as an open-source project. You can access the project on GitHub and CPAN via the links below.

Why Did I Share AmberDB?

My primary goal is to make this practical and powerful engine accessible to the wider developer community. I had intended to open-source it for a long time; with comprehensive use cases, full documentation in both English and Turkish, and detailed POD documentation now complete, it is ready for production use.

---

Why Should You Use AmberDB?

1) Zero Dependencies, Maximum Developer Ergonomics

No dedicated database servers, daemon processes, or port configurations required. Install the module from CPAN anywhere Perl runs and start developing immediately. You can run it entirely in memory using `tmpfs` on Linux or `ImDisk` on Windows, or use it directly on-disk. It operates with a minimal system footprint.

2) PostgreSQL + Elasticsearch + Redis Capabilities in a Single Core

Combines relational querying flexibility, search-engine-grade filtering and ranking, and Redis-like in-memory operational speeds within a single lightweight engine. Eliminates the operational overhead and hosting costs of managing three separate infrastructure layers.

3) Variable-Width Records and Native Array Indexing

Avoids the traditional SQL constraint of splitting order headers and line items into separate tables requiring costly joins. Variable-length line items are stored directly within the primary record and indexed at the engine level with $O(1)$ efficiency. Queries such as *"Which orders contain this product?"* resolve instantly without multi-table scans.

4) Intelligent Schema Architecture and Multi-Criteria Active/Junk Handling

Every table operates on a declarative, JSON-like schema specification where business rules are enforced by the engine. The engine determines whether a record is active or passive (junk) based on multi-factor rules (stock, price, status, or parent entity constraints). For example, disabling a vendor automatically routes hundreds of thousands of associated items without requiring batch `UPDATE` operations:

* `A` Mode: Retrieves active records only (ideal for checkout and invoicing views).

* `AB` Mode: Ranks active records first, pushing junk records to the end (ideal for storefront search).

* `B` / `BA` Modes: Retrieves only junk records or prioritizes them (ideal for returns, archives, and clearance management).

5) Multi-Lingual and Accent-Folded Search with `AmberDB::Locale`

Normalizes complex language and accent variants directly within the indexing pipeline without requiring external system locales or heavy search stacks. Delivers precise phonetic and typographic matching across languages, including Turkish (`İ/i`, `I/ı`), German (`ß`, `ö/ä/ü`), French (`é`, `ç`), Spanish (`ñ`), and Azerbaijani (`ə`, `x`, `ğ`).

6) Schema-Level Automated Slug Generation (SEO)

Generates clean, search-engine-friendly URL slugs automatically upon insertion or update using a simple schema rule (e.g., `seo_block => [ 3, 4 ]`), fully synchronized with `AmberDB::Locale` without extra application-layer boilerplate.

AmberDB on CPAN

• r/perl
• r/programming
• r/opensource
• r/databases
• r/Backend

I've just released 0.001.0 of a Mojolicious app, Database::BI. In time, I hope it will become a business intelligence tool. For the moment, it will read in and INNER join databases in formats such as CSV, SQLite, etc. https://metacpan.org/dist/Database-BI

I wrote this script to convert times between time zones years ago and it has worked well:

#!/usr/bin/perl
use warnings;
use strict;
use feature qw{ say };

use Time::Piece;

if (! @ARGV || $ARGV[0] =~ /--?h(?:elp)/) {
    say 'tz FROM(TZ) FROM(YY/MM/DDTHH:MM) [ TO(TZ) ]';
    exit
}

my ($from_tz, $from_date, $to_tz) = @ARGV;
chomp( $to_tz //= qx{ date +%Z } );

-f "/usr/share/zoneinfo/$from_tz" or warn "$from_tz might be wrong.\n";
-f "/usr/share/zoneinfo/$to_tz" or warn "$to_tz might be wrong.\n";

$ENV{TZ} = $to_tz;

my $tp = do {
    local $ENV{TZ} = $from_tz;
    localtime->strptime($from_date, '%y/%m/%dT%H:%M');
};
say $tp->strftime("%y/%m/%d %H:%M:%S %Z");

Example usage (running in 5.34.0):

$ tz America/New_York 26/08/24T11:00 Europe/Prague
26/08/24 17:00:00 CEST                              

But, in 5.42.0, it doesn't work anymore:

$ tz America/New_York 26/08/24T11:00 Europe/Prague
26/08/24 11:00:00 CEST

There were many changes in Time::Piece in 2025, so I guess that's the reason. The question is: what should I use instead to convert time between timezones?

Hi r/perl!

I wanted to share a project I've been developing called Vispen. It's a Vim plugin that brings the power of Literate Programming (like Emacs Org-mode or Jupyter Notebooks) straight into your editor, using Vim's native, built-in Perl interface.

👉 GitHub Repository & Live Demo: github./vispen

💡 Why Perl?

While the modern Vim world is heavily shifting towards Lua (Neovim) or Vim9script, I realized that Vim's legacy +perl feature is incredibly powerful, blazing fast, and deeply underrated.

Instead of spawning heavy background node.js daemons, setting up active server sockets, or dealing with bloated .ipynb JSON files, Vispen leverages the embedded Perl interpreter to parse buffers, manage templates, and talk to external environments natively.

🚀 Key Features:

• Smart Content Evaluation: Execute SQL queries, format text, parse CSV/JSON, or dump structured database outputs directly from your source files or markdown documents, embedding the results straight back into the buffer.
• Format Flexbility: Output data into clean text tables, HTML, or ready-to-paste Jira markup (||3||str||).
• Zero Dependencies: No heavy infrastructure. If your Vim has +perl and you have Perl 5.006+ on your system, it just works out of the box. It runs perfectly even on low-spec hardware like my Orange Pi single-board computer.

I built this to automate my own database and data-transformation workflows without leaving the terminal. I'd love to hear your thoughts on how it uses the embedded Perl runtime, and any feedback or feature requests you might have!