PetaMem

Since 2012 I have been saying in public that Perl needs applications, and that CPAN by itself is not the killer application. These apps never arrived, and the usual answer was "use the right tool for the job". In a time when AI reimplements whole software suites, the question is worth asking again. Our answer is PetaApps: a NAS, a hypervisor, a software-defined network, a mail server and a backup server, on one platform, built on Rust and Perl. None of it is finished. All of it is under way.

Applications are the killer application

In private it goes back to 2010, and the list was always long: a DMS, a CMS, an ERP, a CRM, groupware, a wiki, an issue tracker, a web shop, accounting, a mail server, a learning platform. However often the community presented CPAN as the killer application, by itself it is not one.

The rationale is simple. Applications get used. They are integrated into a company's processes, and the company comes to depend on them. When it wants to extend or customize them, it needs Perl programmers, and they need everything Perl programmers need - and behold, you have an ecosystem. A library collection, however good, is something programmers already in the ecosystem use. An application is what brings the next ones in.

In 2014, when PetaMem organized the first, and so far the last, Czech Perl Workshop, I restated this position, probably most prominently and certainly for the last time. Up to now. :-)

The cornucopia of Perl applications did not happen. The sparse, outdated and incomplete list on Wikipedia does not count as "it did happen". What I got instead was the community's sentiment: "what is the problem with using the right tool for the job?" As if a DMS, a CMS or a VCS in PHP, Python or Ruby were the right tool for the job. Of course any tool is more right than a tool that does not exist. That is not an argument. It is a capitulation, an unconditional surrender.

In a time when AI reimplements the Microsoft software suite, or Adobe's, why not revisit the topic?

PetaApps

pperl 0.6.25 runs the internal libraries and products of PetaMem and its sister companies. Right after that, we started to unify them: every library, application and tool the companies have, consolidated, refactored and extended into one framework. What came out of it is meant to be

• unified: one platform, one model, one schema;
• DRY and orthogonal: a disk, a schedule or a retention rule is implemented once and used by every application;
• object-oriented from the start, not retrofitted;
• comprehensive: whole applications, not building blocks left for the user to assemble;
• composable: each application runs on its own, and several run side by side on one machine and share what they have in common;
• built on Rust and Perl - Perl as pperl runs it, Rust where the work is native.

Underneath is a library, PetaLib, the generic Peta::* family into which our older libraries for text processing, the physical world and protocols and devices are being merged. On it sits PetaCore, a platform that manages a Linux machine as desired state. Every change starts as a plan that says what will change, what it affects, how risky it is and whether it interrupts a service; it is approved, by a person or by an AI agent within its rights, applied as a job and journaled, and rolled back where the domain allows it. The command line, the API, the web interface and the AI tools (MCP) are generated from the same schema, so a human administrator and an AI agent see the same operations, risks and reasons.

The applications on it:

• PetaStore, a NAS: disks, pools, shares and files; intended to replace or compete with TrueNAS, openmediavault or even NAS appliances. It takes over an openmediavault configuration as a plan.
• PetaVisor, a hypervisor: virtual machines and containers on upstream QEMU and libvirt. Proxmox, OpenStack, VMware ... yeah.
• PetaWall, a software-defined network: firewall and NAT over named hosts, networks and services, compiled to nftables, growing into a network. From fwbuilder over Netgate and Ubiquiti to ... Check Point?
• PetaMail, a mail server: mail domains, filtering and mailing lists. You know Majordomo, Sympa, Modoboa, iRedMail...
• PetaVault, a backup server: deduplicated backups, encrypted on the client. A little of Bacula here, a little of Proxmox Backup Server there...

PetaVisor, PetaWall and PetaMail are working titles.

None of them is finished, and this post claims nothing as available today. At best they will be early versions by the time you read this, and they are marked as work in progress. This is an announcement: the story does not end with pperl. A runtime makes the case for Perl to people who already write Perl. Applications make it to everyone else.

Why "Peta"

Everything of this family carries the Peta prefix, in its product names and in its module namespace. It keeps the family together under one name, so that anyone hesitant about code written with AI can tell at a glance what belongs to it. And it keeps CPAN's namespace clear: nothing of PetaApps squats on a name a CPAN author might want.

The namespace is not only infrastructure. Peta::NN, our micro neural networks in Perl, and Peta::Synth, a software synthesizer in Perl, are components of the same family and will be slurped into it as well.

Is it AI slop?

We are convinced it is not. The code is written by AIs and reviewed by other AIs, but the requirements are always specified by humans, and checking what is delivered against them is the humans' job too. Test coverage and code audits are heavily AI-assisted, and they have to meet the same high standard as in any traditional software engineering environment.

Is most of it still unfinished? Yes. Should you put it into production right away? Most definitely not. Should you take a peek and get acquainted with what is coming? Yes, because it will come, and you do not want to be caught flat-footed. https://perl.petamem.com/PetaApps/

• Richard C. Jelinek, PetaMem s.r.o.