Editing Portal:FreeBSD,OpenBSD,etc (section)

== OpenBSD, NetBSD, DragonFly BSD, and Perl ==

The BSD family provides an unusually interesting comparison of operating-system philosophy through the treatment of Perl. FreeBSD removed Perl from its base system in the FreeBSD 5.0 era and moved it fully into ports/packages. OpenBSD took the opposite approach and continues to ship Perl in the base operating system. NetBSD’s story is centered on pkgsrc, its portable package system. DragonFly BSD inherited much of the FreeBSD ports model through DPorts.

Together, these systems show the major ways a Unix-like operating system can relate to Perl: as a base-system language, as a package-managed third-party language, as a ports-framework dependency, and as development infrastructure.

=== OpenBSD: Perl in the base system ===

'''OpenBSD''' is the major modern BSD that most clearly continues the older Unix tradition of shipping Perl as part of the base system. OpenBSD 7.8, released October 22, 2025, lists '''Perl 5.40.1 (+ patches)''' among the major outside components included in the system.<ref>OpenBSD Project, “OpenBSD 7.8,” https://www.openbsd.org/78.html, accessed July 3, 2026.</ref>

This is a sharp contrast with FreeBSD. FreeBSD decided that Perl should be managed outside the base system. OpenBSD continues to treat Perl as useful enough, stable enough, and integrated enough to remain part of the default operating system.

The OpenBSD manual page set includes `perl(1)` and the normal Perl documentation pages, and OpenBSD also has a `perlopenbsd(1)` page describing Perl version 5 on OpenBSD systems.<ref>OpenBSD Project, “perl(1),” https://man.openbsd.org/perl.1, accessed July 3, 2026.</ref><ref>Perl Documentation, “perlopenbsd - Perl version 5 on OpenBSD systems,” https://perldoc.perl.org/perlopenbsd, accessed July 3, 2026.</ref>

OpenBSD’s decision to keep Perl in base is not merely sentimental. Some OpenBSD infrastructure is written in Perl or has historically depended on Perl. Most notably, OpenBSD’s package tools and package-library code have a strong Perl history.

=== OpenBSD package tools and Perl ===

OpenBSD’s package manager, including `pkg_add`, is central to the system’s Perl story. The `pkg_add(1)` manual page describes `pkg_add` as the command used to install or update packages created from the ports tree.<ref>OpenBSD Project, “pkg_add(1),” https://man.openbsd.org/pkg_add, accessed July 3, 2026.</ref>

OpenBSD also documents Perl package-infrastructure modules under the `OpenBSD::` namespace. For example, `OpenBSD::Intro(3p)` describes package-system concepts such as dependencies, conflicts, and replacement behavior, while `OpenBSD::PackingList(3p)` documents Perl handling of package packing lists.<ref>OpenBSD Project, “OpenBSD::Intro(3p),” https://man.openbsd.org/OpenBSD%3A%3AIntro.3p, accessed July 3, 2026.</ref><ref>OpenBSD Project, “OpenBSD::PackingList(3p),” https://man.openbsd.org/OpenBSD%3A%3APackingList.3p, accessed July 3, 2026.</ref>

Marc Espie’s 2010 EuroBSDCon presentation “The long long road to pkg_add -u” explains the historical design choice. It describes the earlier package tools as C-based, slow, and a “hack,” then identifies the “most controversial decision” in the newer package-tool design as Perl. The presentation gives practical reasons for Perl: the need for a rapid application-development platform, Perl’s modularity and namespace system, and the fact that Perl was already part of the OpenBSD base system.<ref>Marc Espie, “The long long road to pkg_add -u,” EuroBSDCon 2010, https://2010.eurobsdcon.org/fileadmin/fe_user/espie/CBzd55.pdf, accessed July 3, 2026.</ref>

This makes OpenBSD unusual among modern operating systems. Perl is not only a scripting language available to users; it is part of the design history of the package system itself.

=== OpenBSD ports and Perl modules ===

OpenBSD also supports Perl modules through its ports tree. Perl module packages normally appear with the `p5-` prefix, as in other BSD package systems. OpenBSD’s `portgen(1)` utility can generate ports for module ecosystems, and its documentation says that the `p5` type is used for Perl modules on CPAN.<ref>OpenBSD Project, “portgen(1),” https://man.openbsd.org/OpenBSD-current/man1/portgen.1, accessed July 3, 2026.</ref>

The OpenBSD ports framework also has explicit Perl support. The `port-modules(5)` manual page says that the OpenBSD ports framework is based on `bsd.port.mk`, and that optional port modules exist for mechanisms such as GNU autoconf and `perl5`. It further notes that setting `CONFIGURE_STYLE` can be enough to get `perl5` support, although `perl5` is actually a ports module.<ref>OpenBSD Project, “port-modules(5),” https://man.openbsd.org/port-modules, accessed July 3, 2026.</ref>

This means OpenBSD uses Perl in two layers:

* Perl is part of the base system.
* Additional Perl modules are managed through ports and packages.

That split is important. The base Perl is part of the operating system and is maintained with OpenBSD. CPAN modules and third-party Perl applications belong in the ports/packages layer.

=== OpenBSD development process and Perl ===

OpenBSD’s Perl work follows the larger OpenBSD development model. OpenBSD is developed primarily through CVS, with public read-only Git mirrors. The OpenBSD source mirror on GitHub describes itself as a read-only conversion of the official CVS source repository and explicitly says that pull requests are not accepted; diffs should be sent to the `tech@` mailing list.<ref>OpenBSD Project, “openbsd/src,” GitHub mirror, https://github.com/openbsd/src, accessed July 3, 2026.</ref>

That applies to Perl-related base-system work as well. Perl in OpenBSD is not upgraded by a user running CPAN over the system interpreter. It is imported, patched, tested, and committed as part of the OpenBSD source tree.

OpenBSD release notes also describe Perl as an outside component with local patches, showing the project’s normal approach to imported software: take an upstream component, patch it for OpenBSD’s needs, and maintain it as part of the system release.<ref>OpenBSD Project, “OpenBSD 7.8,” https://www.openbsd.org/78.html, accessed July 3, 2026.</ref>

The OpenBSD package-tool maintainers continue to discuss Perl actively. In a 2023 message summarized by OpenBSD Journal, Marc Espie wrote about the future of `pkg_*`, testing, regression infrastructure, and converting package-tool code to Perl 5.36, specifically mentioning that signatures made the Perl code more readable and easier for new people to enter.<ref>OpenBSD Journal, “pkg_*: the road forward,” https://undeadly.org/cgi?action=article;sid=20230712135010, accessed July 3, 2026.</ref>

This illustrates the OpenBSD attitude toward Perl: conservative, integrated, pragmatic, and focused on maintainability. Perl is kept because it solves problems inside the system.

=== OpenBSD and security culture ===

OpenBSD is known for security-focused engineering, code review, correctness, and a small, coherent base system. At first glance, keeping Perl in base may seem inconsistent with minimalism. But OpenBSD’s position is more practical than minimalist absolutism.

Perl is already there, it is stable, its backward compatibility is strong, and important OpenBSD tooling uses it. Removing it would require rewriting working infrastructure, especially package tools and related scripts. OpenBSD therefore treats Perl as part of the trusted base rather than as an optional convenience.

OpenBSD 7.8 also shows that the project is willing to replace Perl tools when there is a practical reason. The release notes say that `pkg-config(1)` was switched to the C-based `pkgconf` because of major performance issues with an unmaintained homegrown Perl script.<ref>OpenBSD Project, “OpenBSD 7.8,” https://www.openbsd.org/78.html, accessed July 3, 2026.</ref>

This is a useful nuance. OpenBSD does not keep every Perl script forever. It keeps Perl where Perl remains useful, but it can replace Perl code when performance, maintenance, or correctness argues for a different implementation.

=== NetBSD and pkgsrc ===

'''NetBSD''' has a different Perl story. NetBSD is strongly associated with portability, and its package system, '''pkgsrc''', became one of the most portable package systems in the Unix world.

pkgsrc describes itself as a framework for managing third-party software on Unix-like systems, containing more than 26,000 packages. It is the default package manager of NetBSD and SmartOS and can also be used on many other Unix-like systems. The pkgsrc site notes that NetBSD already contains the necessary tools for using pkgsrc, while other platforms need to bootstrap pkgsrc first.<ref>pkgsrc, “The pkgsrc package management system,” https://www.pkgsrc.org/, accessed July 3, 2026.</ref>

Perl is available in pkgsrc as `lang/perl5`. The current pkgsrc page describes Perl as a general-purpose programming language originally developed for text manipulation and lists the current source version as `perl-5.42.2nb3`.<ref>NetBSD Packages Collection, “lang/perl5,” https://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc/lang/perl5/index.html, accessed July 3, 2026.</ref>

pkgsrc also contains many Perl module packages, traditionally named with a `p5-` prefix. For example, `devel/p5-Module-Runtime` and `devel/p5-IPC-Run` are typical pkgsrc Perl-module packages.<ref>NetBSD Packages Collection, “devel/p5-Module-Runtime,” https://ftp.netbsd.org/pub/NetBSD/NetBSD-current/pkgsrc/devel/p5-Module-Runtime/index.html, accessed July 3, 2026.</ref><ref>NetBSD Packages Collection, “devel/p5-IPC-Run,” https://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/devel/p5-IPC-Run/index.html, accessed July 3, 2026.</ref>

NetBSD’s Perl story is therefore less about Perl being a base-system scripting language and more about Perl as a first-class pkgsrc citizen. Perl and CPAN modules are packaged, built across architectures, and made available through the same framework that supports thousands of other packages.

=== pkgsrc as a Perl preservation layer ===

pkgsrc is historically important for Perl because it makes Perl portable beyond one operating system. Although pkgsrc began in the NetBSD world, it runs on many platforms. That means Perl modules packaged in pkgsrc can benefit users on NetBSD, SmartOS, illumos, macOS, Linux, and other systems supported by pkgsrc.

This is a different philosophy from OpenBSD. OpenBSD keeps Perl in base because it is part of the operating system’s own infrastructure. NetBSD/pkgsrc makes Perl portable by treating it as a package and by maintaining thousands of Perl modules through a cross-platform package framework.

For Perl users, pkgsrc is valuable because it provides a system package manager’s view of Perl modules. Instead of installing everything directly from CPAN, administrators can install `p5-*` packages that are tracked, upgraded, and removed through pkgsrc tools.

=== DragonFly BSD and DPorts ===

'''DragonFly BSD''' was forked from FreeBSD 4.8 and developed its own kernel and system architecture, especially around SMP, clustering ideas, and the HAMMER/HAMMER2 filesystems. Its third-party software model is based on '''DPorts'''.

DragonFly’s documentation says that DPorts is DragonFly’s own third-party software build system and that it is based on FreeBSD’s Ports Collection. The documentation adds that differences between FreeBSD ports and DPorts are intentionally kept to a minimum, both for familiarity and to leverage FreeBSD ports work.<ref>DragonFly BSD, “DPorts and pkg(8),” https://www.dragonflybsd.org/docs/howtos/DPortsUsage/, accessed July 3, 2026.</ref>

The same page says that DragonFly daily snapshots and releases starting with DragonFly 3.4 come with `pkg(8)` already installed, and that `pkg` is used as the binary package manager.<ref>DragonFly BSD, “DPorts and pkg(8),” https://www.dragonflybsd.org/docs/howtos/DPortsUsage/, accessed July 3, 2026.</ref>

The DragonFly DPorts repository describes DPorts as a derivative of FreeBSD’s Ports Collection. It says DPorts serves the same purpose for DragonFly that the Ports Collection serves for FreeBSD, and that products of DPorts are executable software manipulated by the `pkg(8)` binary package manager.<ref>DragonFly BSD, “DragonFlyBSD/DPorts,” GitHub, https://github.com/dragonflybsd/dports, accessed July 3, 2026.</ref>

Perl on DragonFly therefore follows the FreeBSD-like model more than the OpenBSD model. Perl is primarily a package/ports-managed language. Perl module packages follow the ports tradition, and Perl version changes are handled as part of the DPorts/pkg ecosystem rather than as a base-system language contract.

=== DragonFly DPorts development process ===

DragonFly’s DPorts development process is interesting because it is explicitly derivative and automated. DragonFly documentation says the DPorts workflow uses three repositories: FreeBSD Ports, DeltaPorts, and DPorts. DeltaPorts is an overlay applied on top of FreeBSD Ports to create DPorts.<ref>DragonFly BSD, “DPorts Contributions,” https://www.dragonflybsd.org/docs/howtos/DPortsContributions/, accessed July 3, 2026.</ref>

The same documentation describes monthly syncs with FreeBSD Ports, transformation scripts, staged builds, build-status tracking, and failure-fixing. It also explains that users can help by testing ports, reporting bugs, checking pull requests, and fixing DPorts failures.<ref>DragonFly BSD, “DPorts Contributions,” https://www.dragonflybsd.org/docs/howtos/DPortsContributions/, accessed July 3, 2026.</ref>

For Perl, this means DragonFly benefits from FreeBSD’s Perl ports work but must still account for DragonFly-specific build and runtime differences. Perl itself and Perl modules come through the package system, but the DPorts layer may need local fixes when FreeBSD ports do not build cleanly on DragonFly.

=== MidnightBSD, GhostBSD, HardenedBSD, and desktop BSD derivatives ===

Other BSD-family systems usually inherit their Perl approach from the system they are based on.

'''GhostBSD''' is a desktop-oriented system based on FreeBSD. Its Perl story generally follows FreeBSD: Perl and Perl modules are installed through packages rather than treated as part of the core base system.

'''HardenedBSD''' is also FreeBSD-derived. It focuses on security hardening, exploit mitigations, and related work. Its Perl handling likewise follows the FreeBSD ports/packages model, although package availability and build choices may vary depending on the HardenedBSD package repository and branch.

'''MidnightBSD''' was also originally derived from FreeBSD. It has its own ports-derived package system, but its Perl relationship is still broadly FreeBSD-like: Perl is managed as third-party software rather than as an OpenBSD-style base-system language.

These systems are historically interesting because they show FreeBSD’s influence. Once FreeBSD moved Perl out of base and into packages, FreeBSD-derived systems usually inherited that model.

=== macOS, Darwin, and BSD userland influence ===

macOS and Darwin are not BSD distributions in the same sense as FreeBSD, OpenBSD, NetBSD, or DragonFly, but they are BSD-derived in important userland and networking areas. Historically, macOS shipped Perl as part of the developer and Unix scripting environment, and Perl was used by administrators, packaging tools, and Unix-oriented workflows on macOS.

Modern macOS has moved away from encouraging reliance on Apple-provided scripting-language runtimes. Apple has deprecated or reduced emphasis on bundled scripting runtimes in favor of users installing their own current versions through systems such as Homebrew, MacPorts, pkgsrc, or language-specific installers.

In a BSD-history article, macOS is worth mentioning because it shows the same general trend as FreeBSD from a different direction: a vendor-provided Perl may exist for compatibility, but serious Perl development is usually better served by a package manager or user-installed Perl.

=== Comparing the BSD approaches ===

The BSD systems show several different models for Perl:

* '''OpenBSD''' keeps Perl in the base system and uses it in important operating-system infrastructure, especially package tools.
* '''FreeBSD''' removed Perl from the base system and manages it through ports and packages.
* '''NetBSD''' emphasizes pkgsrc, where Perl and Perl modules are package-managed and portable across many Unix-like systems.
* '''DragonFly BSD''' uses DPorts, a FreeBSD-ports-derived system, with Perl handled through packages.
* '''FreeBSD-derived desktop and security BSDs''' generally inherit the FreeBSD package-managed Perl model.
* '''macOS/Darwin''' historically shipped Perl but increasingly encourages separately managed language runtimes for serious development.

This comparison is useful because it shows that “BSD and Perl” is not one story. Each BSD made a different tradeoff between base-system convenience, package-system flexibility, portability, and maintenance burden.

=== Historical importance ===

The BSD family is important to Perl history because BSD systems are close to Perl’s Unix roots. Perl grew up in the same culture of text files, shell scripts, system administration, mail tools, source trees, ports, manual pages, and practical automation.

OpenBSD demonstrates the strongest continuing base-system commitment to Perl. FreeBSD demonstrates the consequences of moving Perl out of base. NetBSD demonstrates Perl’s package portability through pkgsrc. DragonFly demonstrates how Perl follows a ports-derived ecosystem in a smaller BSD.

These systems also show that Perl’s value is not only in web applications or CPAN modules. Perl has been useful inside operating-system infrastructure itself: package tools, port-generation tools, build scripts, regression tools, documentation helpers, and administration utilities.

=== Legacy ===

Perl’s BSD legacy is one of deep Unix integration. On OpenBSD, Perl remains a standard part of the operating system and a living part of package-management infrastructure. On FreeBSD and DragonFly, Perl is managed through ports and packages. On NetBSD, Perl is part of the broader pkgsrc portability story.

The differences are instructive. OpenBSD proves that a modern security-focused operating system can still choose to ship Perl in base when it serves the system’s needs. FreeBSD proves that removing Perl from base can simplify the core operating system while preserving Perl through packages. NetBSD proves that Perl can be supported across many architectures and operating systems through a portable package framework. DragonFly proves that Perl can ride along with a FreeBSD-derived ports ecosystem while adapting to a different BSD kernel and userland.

Together, the BSDs show Perl’s durability. Whether in base or in packages, Perl remains part of the Unix and BSD landscape because it is useful, portable, mature, and well suited to the practical work of operating systems.