FreeBSD The Power to Serve

FreeBSD Status Report Third Quarter 2024

Here is the third 2024 status report, with 32 entries.

Unfortunately we are late this quarter, just like last quarter. As our readers know, many FreeBSD contributors are volunteers, so it is natural that less important deadlines like the status reports ones are not always met. Indeed, if you are not a FreeBSD contributor yet, please consider joining us: you could help lighten someone’s burden while learning new skills, working side by side with developers all over the world.

Have a nice read.

Lorenzo Salvadore, on behalf of the Status Team.



FreeBSD Team Reports

Entries from the various official and semi-official teams, as found in the Administration Page.

FreeBSD Core Team

Contact: FreeBSD Core Team <core@FreeBSD.org>

The FreeBSD Core Team is the governing body of FreeBSD.

Core welcomes René Ladan (rene@) as their new secretary.

Liaisons

Core selected new liaisons for the various teams among themselves:

  • bugmeister: glebius

  • ci: olivier

  • clusteradm: mat

  • doceng: lwhsu

  • foundation: hrs

  • portmgr: tcberner

  • re: dch

  • secteam: allanjude

  • srcmgr: glebius

DevSummit 202409

  • The Core Team was almost fully present at EuroBSDCon 2024 in Dublin. The following people were present: allanjude, dch, glebius, hrs, lwhsu, mat, olivier, rene

  • Slides are available at https://wiki.freebsd.org/DevSummit/202409

  • Core met with the FreeBSD Foundation to have their periodic meeting and take the change to do it in face-to-face. Topics included improving alignment and communications between the two groups and the community.

New support timeline for FreeBSD releases

  • Core approves the proposal by re@ to reduce the support timeline for FreeBSD releases from five to four years, after which the release is supported on a best-effort basis. This proposal is also backed by portmgr and secteam.

srcmgr

  • Core helped in forming a new srcmgr team. Their charter is not fully set in stone yet, it can be adjusted if needed in 6-12 months from now.

  • Nominations for new src commit bits should from now on be sent to srcmgr@ instead of core@

  • A lurker program is suggested to keep an influx of new members.

  • Core announced srcmgr during DevSummit 202409 and sent a follow-up to developers@ on September 29.

Commit bits

  • Core welcomes Igor Ostapenko (igoro) as a new src committer.

  • Core extended the text that the grim reaper script sends to include ways on how to get commit bits of developers re-activated.


FreeBSD Foundation

Contact: Deb Goodkin <deb@FreeBSDFoundation.org>

The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and worldwide community, and helping to advance the state of FreeBSD. We do this in both technical and non-technical ways. We are 100% supported by donations from individuals and corporations and those investments help us fund the:

  • Software development projects to implement features and functionality in FreeBSD

  • Sponsor and organize conferences and developer summits to provide collaborative opportunities and promote FreeBSD

  • Purchase and support of hardware to improve and maintain FreeBSD infrastructure

  • Resources to improve security, quality assurance, and continuous integration efforts

  • Materials and staff needed to promote, educate, and advocate for FreeBSD

  • Collaboration between commercial vendors and FreeBSD developers

  • Representation of the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity

Even though the summer months tend to be slower, we accomplished a lot of work and you will see that in our Q3 report! Some highlights include raising over $135,000 from individual donors, and kicking off two major projects. First, thanks to a large investment from the Sovereign Tech Fund, we will be doing even more to improve our infrastructure. Second, thanks to a large investment by Quantum Leap Research and the Foundation, we will be working to accelerate a FreeBSD on Modern Laptops project. We also continued work on the Alpha-Omega funded project, hired a userland software developer, and opened a job position for a solutions specialist.

As you will see below, spreading the word about FreeBSD through advocacy and community is still an important part of our mission. Over the summer, we sponsored EuroBSDCon, and the upcoming FreeBSD and OpenZFS Summits, and provided travel grants to around eight FreeBSD contributors to attend EuroBSDCon. Our advocacy team was busy producing content that promotes the benefits and strengths of FreeBSD, why companies are using FreeBSD, and why you should use FreeBSD if you care about security. We also promoted work within the Project and Foundation on social media.

During EuroBSDCon, Foundation and Core Team members met to discuss Core’s questions as they navigate what they want to accomplish during their term. We identified 2 key areas to work on in the near term:

  1. Financial reporting transparency - Break out operating system improvements spending in our quarterly reports. We are working with our accountant so that starting in 2025, we can report how much we are spending on certain projects and key areas, like laptop, enterprise, security…​ In the meantime, we will add notes to our financial reports that document which projects are included in the OS Improvement expense category. We are aware that we have not posted financials this year. Our accounting team is introducing us to improved reporting, while integrating our books into a new accounting system.

  2. The projects we are funding are not mentioned on the Project’s website. We document these on our website, because we want to show our donors where their financial contributions are being spent. We recognize that we need to also add documentation about these projects on FreeBSD.org, so we will investigate how to better connect our software development work with the Project.

We are funding a lot of software development work to advance, improve, and keep FreeBSD secure. We received funding for some of this work, but most of it is being funded by your donations and our investments. Our purpose is to focus on the long-term sustainability of FreeBSD. To do this, we need more companies stepping in to help fund our efforts. Our investments will only carry on this work for a year or two at most. If your company relies on FreeBSD, please consider giving a financial contribution so we can ensure it stays the secure, reliable, and innovative platform you depend on. Not sure how to go about asking? Please reach out. We can help you navigate the process.

Please go here to make a donation: https://freebsdfoundation.org/donate/. To find out more about our Partnership Program, go here: https://freebsdfoundation.org/our-donors/freebsd-foundation-partnership-program/.

OS Improvements

During the third quarter of 2024, 263 src, 37 ports, and 11 doc tree commits identified The FreeBSD Foundation as a sponsor.

Several members of the FreeBSD Foundation’s development team attended the FreeBSD Developer Summit in Dublin, Ireland prior to EuroBSDCon 2024. You can watch a video of the Hello From the Foundation talk to open the Summit, when:

  • Deb Goodkin introduced the FreeBSD Foundation

  • Joe Mingrone introduced members of the development team and said a few words about FreeBSD’s 2024 Google Summer Code campaign

  • Ed Maste described some of the current or recently completed Foundation development projects.

Alice Sowerby, who recently began supporting the Foundation in Technical Program Management role, gave a talk to introduce the CHAOSS (Community Health Analytics for Open Source Software) project and how to start collecting and working with community health metrics.

The Foundation, along with new funding and investment partners, is currently supporting four major projects.

  • The first, partially funded by Alpha-Omega, is to improve FreeBSD security. As part of this effort, the Foundation enlisted Synacktiv to run a code audit on two significant subsystems: bhyve and Capsicum. For details, refer to the dedicated Capsicum and Bhyve Code Audit report entry.

  • The second project, jointly funded by AMD and the Foundation, is to develop an AMD IOMMU driver for FreeBSD. The impetus for the project was to better support large core AMD systems. However, the driver will be useful in different scenarios when interrupt remapping is required. The work is nearing completion, and developer Konstantin Belousov is testing the driver on some of AMD’s large-core-count systems before committing.

  • The third project, backed by an investment from the Sovereign Tech Fund, is to improve FreeBSD through five key sub-projects:

    • Zero Trust Builds: Enhance tooling and processes

    • CI/CD Automation: Streamline software delivery and operations

    • Reduce Technical Debt: Implement tools and processes to keep technical debt low

    • Security Controls: Modernize and extend security artifacts, including the FreeBSD Ports and Package Collection, to assist with regulatory compliance

    • SBOM Improvements: Enhance and implement new tooling and processes for FreeBSD SBOM

    To reduce technical debt, we have partnered with Bitergia to analyze and assess our open Bugzilla bugs. By implementing improved issue management processes and establishing open-source tooling for the long term, our goal is to achieve and sustain a manageable bug backlog. The remaining four sub-projects will begin in 2025.

  • The fourth project, which will be funded by both the Foundation and Quantum Leap Research, is to improve FreeBSD laptop usability. We have begun (or will soon start) supporting developers working in the following areas:

    • Enhanced wireless chipset support: Expanding chipset compatibility to ensure reliable wireless connectivity and support for newer wireless standards.

    • Power management: Implementing modern power-saving states (such as s2idle and s0ix) to improve battery life and energy efficiency.

    • Graphics enhancements: Improving support for Intel and AMD graphics by integrating the latest DRM drivers.

    • Audio improvements: Enhancing audio routing, headphone switching, and digital microphone (DMIC) functionality for a more user-friendly multimedia experience.

    • Laptop-specific hardware features: Addressing specialty buttons, touchpad gestures, and other unique hardware components found in modern laptops.

The Foundation has been providing project management support for the FreeBSD Open Container Initiative (OCI) Working Group, with Alice Sowerby hosting the bi-weekly meeting, and running the recent Podman on FreeBSD testing project. The OCI develops open industry standards for cloud native container formats and runtimes, ensuring platform consistency. The FreeBSD OCI Working Group is defining these standards for FreeBSD, with implementations using jails and potentially lightweight VMs with bhyve. Refer to the Foundation’s OCI Container Support Project page for details.

In other Foundation news:

  • Isaac Freund joined the Foundation’s development team as a Userland Developer. As the lead developer of the River Wayland Compositor and a member of the Core Zig Team, we are excited about the experience Isaac will be bringing to FreeBSD.

  • Alfonso Sabato Siciliano is working on a Vision Accessibility Subsystem for blind, low-vision, and color blind users. New features will include a Braille refreshable display framework, a communication channel for the virtual terminal console, a speech synthesizer, high-contrast TUI utilities, and an accessibility book to document assistive technologies available on FreeBSD.

  • Tom Jones, completed his work with RGNets to port the Vector Packet Processor (VPP), a layer 2-4 multi-platform network stack in userspace, to FreeBSD. You can read about Tom’s next project to support full-cone NAT for FreeBSD firewalls in his Endpoint-Independent NAT report entry.

  • Christos Margiolis continued to improve FreeBSD’s audio stack and provide audio developers with useful tools and frameworks to facilitate sound development on FreeBSD. Refer to the Audio Stack Improvements entry for the latest news.

  • Olivier Certner has two entries in this report. You can read about his latest work in the Scheduling Priorities: 256-queue Runqueues Sub-Project and mac_do(4), setcred(2), mdo(1) report entries.

  • Bjoern Zeeb continued to improve wireless networking on FreeBSD. You can read the latest news in Bjoern’s Wireless Update entry.

  • Philip Paeps continued work on a contract to modernize the FreeBSD cluster.

  • Chih-Hsin Chang has continued work to port OpenStack components so that the cloud computing platform can be run on FreeBSD hosts. Refer to the OpenStack on FreeBSD entry for the latest information.

  • Other members of the Foundation’s technology team contributed to FreeBSD development efforts. For example:

    • Mitchell Horne committed work for RISC-V, including adding support for the Supervisor-mode: Page-Based Memory Types (Svpbmt) extension

    • Ed Maste removed the deprecated mergemaster tool in favor of etcupdate(8) for updating files not managed by install world

    • Joe Mingrone updated our base libpcap and tcpdump(1)

    • Li-Wen Hsu kept our Jenkins port tracking the latest upstream versions with a number of port updates.

Continuous Integration and Workflow Improvement

As part of our continued support of the FreeBSD Project, the Foundation supports a full-time staff member dedicated to improving the Project’s continuous integration system and test infrastructure.

Advocacy

During the third quarter of 2024, we continued growing our efforts to drive awareness, advocate for the project, highlight users, and bring educational content to the FreeBSD community. Below are some of those efforts.

Legal/FreeBSD IP

The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We also provide legal support for the core team to investigate questions that arise.

Go to https://freebsdfoundation.org to find more about how we support FreeBSD and how we can help you!


FreeBSD Release Engineering Team

Contact: FreeBSD Release Engineering Team, <re@FreeBSD.org>

The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes and maintaining the respective branches, among other things.

The Team managed 13.4-RELEASE, leading to the final RELEASE build and announcement in September. Planning has started for the upcoming 14.2-RELEASE cycle.

The Release Engineering Team continued providing weekly development snapshot builds for the main, stable/14, and stable/13 branches.


Continuous Integration

Contact: Jenkins Admin <jenkins-admin@FreeBSD.org>
Contact: Li-Wen Hsu <lwhsu@FreeBSD.org>
Contact: freebsd-testing Mailing List
Contact: IRC #freebsd-ci channel on EFNet

In the fourth quarter of 2024, we worked with the project contributors and developers to address their testing requirements. Concurrently, we collaborated with external projects and companies to enhance their products by testing more on FreeBSD.

Important completed tasks:

  • Update main and stable/14 build environment to 14.1-RELEASE

Work in progress tasks:

  • Improving the src/tests/ci work to support running test suites

  • Merging Pre-commit CI with CIRRUS-CI

  • Designing and implementing pre-commit CI building and testing and pull/merge-request based system (to support the workflow working group)

  • Proof of concept system is in progress.

  • Designing and implementing use of CI cluster to build release artifacts as release engineering does, starting with snapshot builds

  • Simplifying CI/test environment setting up for contributors and developers

  • Setting up the CI stage environment and putting the experimental jobs on it

  • Redesigning the hardware test lab and adding more hardware for testing

Open or queued tasks:

  • Collecting and sorting CI tasks and ideas

  • Setting up public network access for the VM guest running tests

  • Implementing use of bare-metal hardware to run test suites

  • Adding drm ports building tests against -CURRENT

  • Helping more software get FreeBSD support in its CI pipeline (Wiki pages: 3rdPartySoftwareCI, HostedCI)

  • Working with hosted CI providers to have better FreeBSD support

Please see freebsd-testing@ related tickets for more WIP information, and do not hesitate to join the effort!

Sponsor: The FreeBSD Foundation


Ports Collection

Contact: Tobias C. Berner <portmgr-secretary@FreeBSD.org>
Contact: FreeBSD Ports Management Team <portmgr@FreeBSD.org>

The Ports Management Team is responsible for overseeing the overall direction of the Ports Tree, building packages, and personnel matters. Below is what happened in the last quarter.

According to INDEX, there are currently 36,504 ports in the Ports Collection. There are currently ~3,379 open ports PRs. The last quarter saw 11,594 commits by 154 committers on the main branch and 832 commits by 78 committers on the 2024Q3 branch. Compared to last quarter, this means a slight increase in the number of commits on the main branch (from 10,525) and about half of the backports to the quarterly branch (compared to 1,771). The number of ports also increased (up from 32,471).

The most active committers to main were:

A lot has happened in the ports tree in the last three quarter, an excerpt of the major software upgrades are:

  • Default version of PostgreSQL switched to 16

  • chromium updated from 126.0.6478.126 to 129.0.6668.100

  • firefox updated from 127.0.2 to 131.0-rc1

  • firefox-esr updated from 115.9.1 to 128.3.0-rc1

  • rust updated from 1.79.0 to 1.81.0

  • sdl2 updated from 2.30.3 to 2.30.7

  • wlroots updated from 0.17.4 to 0.18.1

  • wine-devel updated from 9.4 to 9.16

  • qt5 updated from 5.15.14 to 5.15.15

  • qt6 updated from 6.7.2 to 6.7.3

  • plasma6 updated from 6.1.1 to 6.1.2

During the last quarter, pkgmgr@ ran 24 exp-runs to test various ports upgrades, updates to default versions of ports, and base system changes.


Bugmeister Team

Contact: Bugmeister <bugmeister@FreeBSD.org>

Charts and graphs

Ed Maste from the FreeBSD Foundation has expressed an interest in seeing useful charts and graphs added to Bugzilla. The few that we have now are not very informative. Many of the interesting Bugzilla queries for them have been documented, but the information there is really dense.

If you are interested in working on this task, contact Ed directly.

Bugzilla version upgrade

Recently, upstream Bugzilla has released 5.0.4.1, which is a minor bugfix release. Preliminary work suggests that the update will be unobtrusive. Work is continuing.

PR statistics

PRs continue to come in and get triaged. Over the longer term, we are nearly at steady-state.

The number of PRs over the past quarter (and year) has fluctuated. Vladimir Druzenko pointed out that the number dropped by around 200 during 2023Q4. (We have not done the data analysis to find out why that was.) However, slowly, the number has come back to where it was a year ago. But we do seem to be closing incoming PRs more quickly these days. For reference:

The overall number of PRs remains at slightly over 11,600. We do have a lot of technical debt.

Bugmeister is also working towards restarting the Bugathons.

Acknowledgements

Bugmeister would like to thank a number of people who have assisted with bugbusting, including new triagers Alexander Vereeken, Alexander Ziaee, and Frederick Lee.


FreeBSD Samba Team

Contact: FreeBSD Samba Team <samba@FreeBSD.org>

Samba provides secure, stable and fast file and print services for all clients using the SMB/CIFS protocol. It is an important component to seamlessly integrate FreeBSD/Linux/Unix Servers and Desktops into Active Directory environments. It can function both as a domain controller or as a regular domain member.

The new FreeBSD Samba Team was created to better coordinate maintenance efforts of the Samba ports and its dependencies, in particular:

Notable changes in the last quarter include:

Currently, the FreeBSD Samba team is coordinating efforts in the following areas:

Testing and community contributions are welcome, please reach out on Bugzilla or via the team email.


Projects

Projects that span multiple categories, from the kernel and userspace to the Ports Collection or external projects.

Audio Stack Improvements

Contact: Christos Margiolis <christos@FreeBSD.org>

The FreeBSD audio stack is one of those fields that does not attract the same attention and development as others do, since it has been left largely unmaintained, and, although high in quality, there is still room for improvement — from lack of audio development frameworks, to missing userland utilities and kernel driver-related bugs. This project is meant to touch on all those areas, and as such, is more of a general improvement project, than an implementation of a specific feature.

Important work since last report:

Future work includes:

  • More bug fixes and improvements.

  • Finalize and commit of audio(8) and mididump(1).

  • Implement a generic MIDI layer, similar to pcm/, and improve/modernize the MIDI codebase in general.

  • Implement a bluetooth device management utility.

  • More virtual_oss patches and improvements.

  • Attempt to implement an snd_hda(4) pin-patching mechanism.

  • Investigate SOF/DMIC support.

You can also follow the development process in freebsd-multimedia@, where I post regular reports.

Sponsor: The FreeBSD Foundation


A bhyve management GUI written in Freepascal/Lazarus

Contact: José Alonso Cárdenas Márquez <acm@FreeBSD.org>

Bhyvemgr is a bhyve management GUI written in Freepascal/Lazarus on FreeBSD. It needs a bunch of tools mostly installed by the base system and some installed from ports/packages. The main goal is to be a desktop application focus on desktop user to easily and quickly setup and run virtual machines on FreeBSD hosts.

It should be used for virtual machines testing purpose (not for production). For a tool for production virtual machines management, take a look at sysutils/vm-bhyve, sysutils/bmd, or sysutils/cbsd.

Bhyvemgr supports aarch64 on 15-CURRENT only, and amd64 from FreeBSD 13.x to 15-CURRENT. It can be compiled from sysutils/bhyvemgr as a port, or installed as packages with gtk2, qt5, or qt6 interface support.

People interested in helping the project are welcome.

Version at the end of 2024Q3: 1.1.0

TODO

  • Test on real aarch64 hardware

  • Add uart device support

  • Add missing global setting entries (bios, board, chassis, system)


Changes to dhclient to speed up the FreeBSD boot process

Contact: Isaac Cilia Attard <icattard@FreeBSD.org>

As part of my Google Summer of Code 2024 project, involving speeding up the FreeBSD boot process, I have worked on decreasing the time it takes for ARP resolution within dhclient to happen. This involved reducing the default ARP resolution timeout from 2000 ms to 250 ms, and adding an option to disable it altogether. The latter is useful within cloud environments, where a node is certain to have an IP address allotted to it.

As a consequence of this, connecting to a DHCP network is now faster, including the boot process during which this happens. The speedup experienced is about 2 seconds.

This causes FreeBSD systems to boot significantly faster than before.

Sponsor: Google LLC (GSoC 2024)


Capsicum and Bhyve Code Audit

Contact: Ed Maste <emaste@FreeBSD.org> Contact: Pierre Pronchery <pierre@freebsdfoundation.org>

With the support of the Alpha-Omega project, the FreeBSD Foundation undertook code audits of two important subsystems — the bhyve hypervisor, and the Capsicum sandboxing framework. In addition to uncovering vulnerabilities in these systems to correct, the audits look to identify classes of vulnerabilities and/or suboptimal coding practices that we can look to address across the project.

The Foundation interviewed several firms, and selected Synacktiv to perform the audit. A number of issues with critical and high severity were identified, which have been fixed as documented in security advisories:

Fixes are in progress for a number of lower-severity issues. The code audit report will be shared in the near future, after issues above a severity threshold have been addressed. The FreeBSD Foundation will also publish a report including commentary on the impact of the Synacktiv code audit report, classes of vulnerabilities identified, and lessons learned.

More information is available in the Alpha-Omega repository.

Sponsor: The FreeBSD Foundation


Endpoint-Independent NAT

Contact: Tom Jones <thj@freebsd.org>

This project aims to add support for Endpoint-Independent Mappings for UDP to the pf and ipfw firewalls.

End Point Independent NAT enables applications behind a NAT speaking to multiple remote hosts to receive the same mappings. This allows an application without any NAT traversal mechanisms to work around NAT issues to perform peer discovery. From the remote hosts perspective the NAT is transparent and it is as-if there is no NAT at all. This form of NAT has been given several names over the last few decades and might be known as 'full-cone' NAT.

Patches to pf landed in early September based on work by Damjan Jovanovic and Naman Sood with updates to work on pf in main. The patches add a new 'endpoint-independent' suffix to UDP pf nat rules.

ipfw support for endpoint-independent is going to be made available via libalias, allowing any system which uses libalias for address translation to benefit from the change. There is an in-progress review D46689 to add support to libalias.

The in-progress change and the committed pf change could both benefit from testing in more and diverse environments.

Sponsor: The FreeBSD Foundation Sponsor: Tailscale


Kyua Jail Support

Contact: Igor Ostapenko <igoro@FreeBSD.org>

The FreeBSD test suite is executed by the kyua(1) utility. Kyua supports parallel execution of tests with kyua -v parallelism=<n> test, however many network tests leverage jail(8) features like VNET(9) and have conflicts with jail naming and network configuration. As a result they are marked with the is_exclusive=true metadata property to prevent them from running at the same time and interfering with each other. It creates a dilemma when a project aims to increase test coverage, but the accumulation of exclusive tests proportionally increases the time required to run them. This, in turn, affects the development process from multiple angles.

Kyua has recently got a change in 15-CURRENT to support a new concept called "execution environment". By default, tests run in the so-called "host" execution environment, where they are executed as before. A test can opt-in to use a brand new execution environment, the "jail" one. In this case, kyua creates a jail before running the test, and then executes the test within the jail. That opens up the opportunity to run more tests in parallel due to the extra isolation provided by the jail concept itself, and specifically by the VNET. It depends on hardware and configuration, but there are reports that having the same environment netpfil/pf tests can be run around 4 times faster — a few minutes instead of half an hour.

The following Makefile change is a quick demo of how netpfil/pf tests were switched to run in parallel with jail execution environment:

-# Tests reuse jail names and so cannot run in parallel.
-TEST_METADATA+=        is_exclusive=true
+# Allow tests to run in parallel in their own jails
+TEST_METADATA+= execenv="jail"
+TEST_METADATA+= execenv_jail_params="vnet allow.raw_sockets"

More details:

This change also brings new sysctl read-only variables, which expose more details about current jail, and may be generally useful:

  • security.jail.children.max: Maximum number of child jails

  • security.jail.children.cur: Current number of child jails

A hint: the sysctl -n security.jail.children.cur run from prison0 provides the number of all jails in the system.

Further improvements to Kyua, such as requirements definition and automatic resolution, are currently in the design phase. Potentially new metadata properties like required_klds and required_pkgs provide a clue to these topics. Please contact Igor to discuss ideas and use cases that can help shape these upcoming Kyua enhancements.


Linux Source Compatibility Wiki page

Contact: Edward Tomasz Napierala <trasz@freebsd.org>

There is now a wiki page to track source compatibility differences between FreeBSD and Linux — and it needs your input!

FreeBSD and Linux are already largely compatible at the source code level due to both being Unix systems and following the same standards. There are however certain system calls specific to Linux; there are also differences in header files, constants and so on. Implementing them in FreeBSD would make porting software easier.

Not all of the items there are fixable. Some differences cannot be eliminated due to naming clashes, disagreements on how the system is supposed to work, or because it would make autoconf pick up a less functional compatibility API instead of the native one. In such cases we should document it and advise what API to use instead.

The wiki page aims to provide an overview and help track progress. That is where your help is needed. I need people who actually port software to FreeBSD to add missing APIs, based on their experiences. This also includes non-syscall items, like missing headers and unsupported constants. Preferably also mention the name of the software that could use them.

  • Add missing items

  • Add prospective API consumers

Sponsor: Innovate UK


Userland

Changes affecting the base system and programs in it.

Service jails — Automatic jailing of rc.d services

Contact: Alexander Leidinger <netchild@FreeBSD.org>

Service jails extend the rc(8) system to allow automatic jailing of rc.d services. A service jail inherits the filesystem of the parent host or jail, but uses all other limits of the jail (process visibility, restricted network access, filesystem mounting permissions, sysvipc, …​) by default. Additional configuration allows inheritance of the IPs of the parent, sysvipc, memory page locking, and use of the bhyve virtual machine monitor (vmm(4)).

Since the last report several ports have been modified to come with a service jail config. Out of about 1460 start scripts in the ports collection, about 80 start scripts are changed. Prominent examples out of those are postgresql, DNS servers, FTP servers, PHP, dovecot, postfix, rspamd, amavisd-new and clamav. Some more changes are waiting for a treatment by the corresponding port maintainers.

Any help in changing more start scripts (most of the time just one line to add) is welcome. If you want to help, you can check the bugtracker link above for changes which are already under review.


Userspace UFS Driver (fuse-ufs)

Contact: Benjamin Stürz <benni@stuerz.xyz>

During this year’s Summer of Code, I wrote a userspace UFS driver using FUSE and Rust. The project was meant to ease the process of mounting FreeBSD UFS filesystems on other operating systems. Up to this point, only read-only filesystem access has been implemented. But as a bonus, fuse-ufs has the ability to mount filesystems with endianness different from the host’s endianness.

I am currently working on splitting the project into a binary and library part, to make it easier to integrate it into other operating systems. As part of this refactoring, an additional FUSE2 backend will be implemented, to be able to run it on OpenBSD. Currently there is testing infrastructure for Linux and FreeBSD with OpenBSD coming in the future. Although there is no CI for MacOS, a friend of mine tested it with MacFUSE and it works.

Once the big refactor is done, I will start concentrating on implementing write support. Thanks to being bribed by Robert Clausecker, I will also add soft-updates and mounting Sun’s UFS in the future.

The driver can be installed using cargo install fuse-ufs, or (if on Arch Linux) using your favorite AUR helper. Thanks to Robert Clausecker a port for FreeBSD exists in sysutils/fusefs-ufs.

A big thanks to Alan Somers and Kirk McKusick for mentoring me and thanks to Robert Clausecker for the FreeBSD port and suggesting this GSoC project to me in the first place. Another thanks to Davids Paskevics for writing a fuzzer for me.

Sponsor: Google Summer of Code 2024


Kernel

Updates to kernel subsystems/features, driver support, filesystems, and more.

FreeBSD V4L2 & kernel USB Video Class driver

Contact: Alvin Chen <weike_chen@dell.com>
Contact: Li-Wen Hsu <lwhsu@FreeBSD.org>

This work is to create FreeBSD UVC (USB Video Class) kernel driver and follow v4l2 APIs, so that most of the Linux camera applications can be easily ported to FreeBSD.

The code is still cleaning up and will be submitted to official review after completing.

Current Status:

  1. The key functions of the UVC driver are enabled.

  2. The key v4l2 IOCTLs are implemented.

  3. Support most of USB cameras (up to 4K resolution): Jabra, Logitech, etc.

  4. Some applications validated: VLC, Cheese, pwcview.

Future Work:

  1. A couple of v4l2 IOCTLs need be implemented: make all cases in v4l2-compliance test suite be passed.

  2. Some UVC APIs need be implemented: uvc control mapping callbacks, etc.

  3. UVC lock issue related to USB.

  4. PCI based AI camera supporting.

  5. Code refactoring if needed.

Sponsor: Dell Technologies for the development
Sponsor: The FreeBSD Foundation for assistance of upstreaming


mac_do(4), setcred(2), mdo(1)

Contact: Olivier Certner <olce.freebsd.statusreports@certner.fr> Contact: Baptiste Daroussin <bapt@FreeBSD.org>

This project aims at allowing controlled process credentials transitions without using setuid executables but instead leveraging our MAC framework.

Traditional programs for credentials change have to execute preliminary operations as root (if not as the effective UID, at a minimum as the saved UID). Some of these programs (e.g., sudo(8)) have lots of lines of codes and comprise features (e.g., loadable security modules) that can be dangerous from a security standpoint. Thus, they have a non-negligible attack surface and are difficult to prove correct. Additionally, in most scenarios, the extra features they bring are not necessary.

More generally, the threat model for the mac_do(4) kernel module part is that of compromised userland programs, be they credentials changers or credentials providers ones. This stance implies that calls to the kernel’s credentials-changing API must be monitored by the kernel without upcalls to userland. In practice, mac_do(4) must be configured beforehand by the administrator to indicate which transitions of credentials are valid (through a sysctl(8) knob, security.mac.do.rules).

Currently, the companion userland program, mdo(1), is the only one that can be authorized to proceed by mac_do(4) (for now, based on the executable path). This tiny program simply establishes the new credentials via calls to setuid(2), and optionally initgroups(3) (calling setgroups(2)) and setgid(2) (if -i was not passed).

The resulting set of groups is either that of the target UID based on the password database, or that before the change in UID (when using -i). The second alternative can be a security hazard in some cases (as the effective GID is not changed either), whereas the first contradicts the threat model above. The current mac_do(4) rules specification indeed only allows to express simple UID transitions towards explicit UIDs from other explicit UIDs or GIDs, without taking into account groups. Consequently, the kernel module currently cannot check the content of setgroups(2) and setgid(2) system calls' parameters, relying completely on mdo(1) passing the right information.

A new version of mac_do(4) has been in the works for approximately a month. Besides fixing concurrency, per-jail settings and MAC policies composition problems, it features a revamp of the rules specification in order to make it possible to finely control which groups are allowed in the resulting credentials. Notably, primary and secondary groups can now be specified independently, and for the latter, GIDs can be tagged as allowed, mandatory or forbidden. A special alias, ., can be used to indicate the current process' UIDs or GIDs depending on the context.

These new features imply that the mac_do(4) module is able to apply credentials change at once, since the allowed final credentials depend on the initial ones through the configured rules. The traditional userland interface (e.g., setuid(2), setuid(2), setgroups(2), etc.) is at odds with this requirement as it necessitates multiple calls to reach the desired final credentials, making the process pass by several successive states that themselves may not be allowed by mac_do(4)'s rules. We overcome this limitation by introducing a new system call, setcred(2), which allows to request arbitrary transitions of credentials at once. Beside its usefulness in conjunction with mac_do(4), it has the benefit of simplifying coding of credentials change in userland. Since it is also extensible, it may have the potential to be adopted later by other systems.

Pre-requisite changes are currently under review (see in particular revisions D46886 to D46889 and D46896 to D46923). The bulk of changes in mac_do(4)/mdo(1) proper will soon be pushed under review as well. An older version of the full series can be seen on GitHub.

Sponsor: The FreeBSD Foundation


Scheduling Priorities: 256-queue Runqueues Sub-Project

Contact: Olivier Certner <olce.freebsd.statusreports@certner.fr>

The goal of the 256-queue runqueues sub-project is to fix FreeBSD’s POSIX compliance in that different priority levels in the SCHED_FIFO or SCHED_RR scheduling classes must lead to immediate preemption by threads having higher priority. It is part of the bigger scheduling priorities revamp project aiming at rationalizing FreeBSD scheduling interfaces, including having consistent rtprio(2) and POSIX interface behaviors (where it makes sense), enhancing POSIX compliance, removing duplicate code and fixing existing bugs, and enhancing the non-standard parts both for better control and security. Expected benefits are increased usage of FreeBSD as a soft real-time platform, e.g., for video and audio processing in casual desktop uses to professional settings. Readers interested in this topic are invited to consult AsiaBSDCon 2024’s paper and EuroBSDCon 2024’s slides for a wider view, and to contact me for questions, feedbacks or discussions.

Currently, priority levels specified either through the prio field of struct rtprio (rtprio(2) interface) or the sched_priority one of struct sched_param, for real-time scheduling classes (RTP_PRIO_FIFO and RTP_PRIO_REALTIME for the former, SCHED_FIFO and SCHED_RR for the latter) as well as idle-time ones (RTP_PRIO_IDLE), are conflated as follows: Each priority level that has the same quotient when divided by 4 is internally treated the same. In particular, threads being in the same such equivalence class but having higher priority will not preempt other threads in the same class, violating POSIX expectations for SCHED_FIFO and SCHED_RR.

To remedy this situation, we have chosen an impacting internal change on the number of queues per runqueue, and defer to the above-mentioned EuroBSDCon 2024’s slides for more details.

The switch to 256-queue runqueues having non-trivial impacts on the ULE scheduler, we have been analyzing it and tuning the scheduler to preserve its previous behavior with respect to anti-starvation and the effect of nice values. With the goal to perform further testing, we have revived Jeff Roberson’s initial ULE’s test tool, called late (currently available on GitHub).

All the modifications made as part of this sub-project are currently under review, starting with Phabricator’s review D45387 (click on the "Stack" tab to see the full series of reviews).

In the course of this project, we have noticed that the effect of nice values is especially weak, and consequently have produced experimental patches to make their effect stronger. However, it is not clear at this point whether we can increase their effect satisfactorily enough in the current ULE setting.

We have also started another scheduler project about adapting ULE to hybrid architectures, which might also trigger more drastic scheduler changes.

Sponsor: The FreeBSD Foundation


Wireless Update

Contact: Bjoern A. Zeeb <bz@FreeBSD.org>
Contact: The FreeBSD wireless mailing list <wireless@FreeBSD.org>

The ongoing wireless efforts are trying to bring more support for recent chipsets as well as newer standards.

With iwlwifi(4) and rtw88(4) being supported we received patches and initial reports for rtw89 and ath10k working for some people. Additionally ath11k, ath12k and various chipsets supported by mt76 are waiting for someone to find the time to finish compat code, test and debug.

Work is ongoing to update drivers to Linux v6.11 using the now bootstrapped vendor branches, which should help maintenance a lot in the future. One particular focus for this update is also to find ways to minimize incompatibilities between wireless compat code versions in order to support multiple Linux versions as needed.

After the native kern_malloc changes got committed, LinuxKPI is seeing ongoing work for memory allocation to play better by the rules set out in Linux which should help with DMA problems seen. There is further work pending to add missing bus_dmamap_sync() calls.

There is work to support rtw88(4) SDIO devices (being tested on an r2s-plus) and ongoing work to stabilize updated USB support which should start landing once the driver updates have finished. Lastly there are more updates in the queue to finish 11n support for LinuxKPI 802.11 compat code as well as improving native net80211 code.

If you have questions or feedback please use the freebsd-wireless mailing list. That way everyone will see, be able to join in, and the answers will be publicly archived.

Sponsor: The FreeBSD Foundation


VirtIO Sockets and AF_VSOCK support

Contact: Danilo Egea Gondolfo <danilo@FreeBSD.org>

The VirtIO Socket device is used to enable communication between guests and host without networking. The AF_VSOCK protocol family enables it to be used through the sockets API.

For the past many months I have been working on a guest driver for the VirtIO Socket device and an implementation of the AF_VSOCK protocol family. Originally, I wanted to get the lxd-agent daemon working on FreeBSD but the communication with the LXD host daemon is done through VSOCKs. LXD is a nice container and virtual machine manager based on Linux/KVM and my end goal is to make FreeBSD a LXD first-class citizen.

At the moment I have it working well enough to enable the lxd-agent to work. I adapted the golang.org/x/sys library and the lxd-agent to support AF_VSOCK on FreeBSD. Features such as command execution, interactive consoles and file transfer are working.

On Linux, AF_VSOCK can be used with VirtIO, HyperV and VMware sockets as transports. I am trying to design my implementation so it will also be possible to use it with different transports in the future.

After getting the current work in a good shape, ideas for future work include integration of AF_VSOCK and HyperV Sockets (which is already supported on FreeBSD through AF_HYPERV), VIRTIO_VSOCK_F_SEQPACKET, VirtIO Socket device for bhyve and the host side of the driver.

I will continue to slowly work on this on my limited free time and hopefully have something more concrete for the next time. There is still a lot of work to be done until it become ready for code review.


Architectures

Updating platform-specific features and bringing in support for new hardware platforms.

Pinephone Pro Support

Contact: Toby Kurien <toby@tobykurien.com>

A new project trying to make FreeBSD usable on the Pinephone Pro has been started during August.

The current FreeBSD RELEASE images already boot on a Pinephone Pro, but no screen output or other devices are supported. The aim is to step by step support additional components so that the device one day might be usable as a highly mobile FreeBSD device.

Over the last few weeks, the groundwork has been implemented like getting used to the device, cross-compiling and booting a 15.0-CURRENT custom kernel as well as toggling the LEDs (red/green/blue in the front). Also, the LCD backlight can be turned on already and the USB-C hub is enabled even though it is not yet functional due to missing power management support.

The next step is to write a driver for the RK818 power management chip. Without it, most of the hardware will not power on like the USB-C port above. This will be done by trying to modify the existing RK808 driver. RK818 support should then make it possible to access a lot more of the devices, e.g. allowing to enable the screen, USB peripherals or WiFi.

Additional feedback and testers are welcome.

Sponsor: Honeyguide Group


SIMD enhancements for aarch64

Contact: Getz Mikalsen <getz@FreeBSD.org>

The porting effort of the SIMD enhanced libc string functions from amd64 to aarch64 has been successfully completed. There are now optimized implementations for 16 libc string functions in addition to those with implementations already available as part of the ARM optimized subroutines library. There is also a presentation regarding the general method for these methods from EuroBSDCon 2024 available on YouTube with a short description in the end of how the porting has been done with regards to the aarch64 architecture.

These enhancements significantly improve performance of string functions for all FreeBSD systems on the aarch64 platform.

The code is currently undergoing acceptance testing in the form of an exp-run building all the ports, once without and once with the patch set applied to see if it has caused any new failures.

Sponsor: Google LLC (GSoC 2024)


Cloud

Updating cloud-specific features and bringing in support for new cloud platforms.

FreeBSD on Microsoft HyperV and Azure

Contact: Microsoft FreeBSD Integration Services Team <bsdic@microsoft.com>
Contact: freebsd-cloud Mailing List
Contact: The FreeBSD Azure Release Engineering Team <releng-azure@FreeBSD.org>
Contact: Wei Hu <whu@FreeBSD.org>
Contact: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Contact: Colin Su <yuas@microsoft.com>
Contact: Li-Wen Hsu <lwhsu@FreeBSD.org>

In this quarter, we have published the 13.4-RELEASE on Azure Marketplace.

Souradeep Chakrabarti from Microsoft has added a feature to use hypercalls for TLB shootdown on Hyper-V and Azure. Micro-benchmark shows 30-40% performance improvement on TLB shootdown. This has been presented at the DevSummit 202409

Wei Hu root-caused an issue on missing CDROM device when booting FreeBSD on the latest Azure v6 VM SKU. V6 type only offers NVMe disks to guest OS. He also continues bug fixing for FreeBSD MANA NIC device.

Work in progress tasks:

Open tasks:

Sponsor: Microsoft for people in Microsoft, and for resources for the rest
Sponsor: The FreeBSD Foundation for everything else


FreeBSD on EC2

Contact: Colin Percival <cperciva@FreeBSD.org>

FreeBSD is available on both amd64 (Intel and AMD) and arm64 (Graviton) EC2 instances.

In the past quarter, a new "small" flavour of EC2 AMI has been added, without debug symbols, tests, 32-bit compatibility libraries, or the LLVM debugger, and without the Amazon SSM Agent pre-installed or the AWS CLI installed by default at first boot.

Build performance tests are now being performed weekly using the snapshot AMIs built by the release engineering team. These tests revealed several performance regressions which have now been fixed; in particular a bug fix to the use of the EFI RNG in the boot loader produced a dramatic speedup on Graviton instances.

Sponsor: Amazon
Sponsor: https://www.patreon.com/cperciva


OpenStack on FreeBSD

Contact: Chih-Hsin Chang <starbops@hey.com>
Contact: Li-Wen Hsu <lwhsu@FreeBSD.org>

The OpenStack on FreeBSD project aims to bring OpenStack cloud infrastructure to the FreeBSD operating system, using FreeBSD’s special features while keeping it compatible with OpenStack.

In the third quarter of 2024, we continued working on several important tasks. Our work on porting OpenStack Ironic is still ongoing, with tests now running on arm64 servers. In this setup, the service node is amd64, and the provisioning node is arm64. This helps us explore more options for running mixed environments in OpenStack on FreeBSD.

In August, we gave a presentation at COSCUP 2024 to share the project’s progress and our experiences. This helped us get more attention and interest from people in the community.

We also updated some of the OpenStack components, like Keystone, Glance, and Placement, from FreeBSD 14.0-STABLE to FreeBSD 15.0-CURRENT. This update helps us keep up with the latest changes in FreeBSD, making the project run better.

Another notable item was testing the bhyve serial console over TCP patch and using it in the OpenStack workflow. This brings us closer to stopping the use of the custom socat-manager solution and moving to a built-in serial console solution.

Although we are still planning to turn the OpenStack manual installation process into FreeBSD ports, there has not been much progress yet. We hope to work more on this in the next few months. Existing work can be found in the openstack repository.

Sponsor: The FreeBSD Foundation


Documentation

Noteworthy changes in the documentation tree, manual pages, or new external books/documents.

Documentation Engineering Team

Contact: FreeBSD Doceng Team <doceng@FreeBSD.org>

The doceng@ team is a body to handle some of the meta-project issues associated with the FreeBSD Documentation Project; for more information, see FreeBSD Doceng Team Charter.

Benedict Reuschling steps down from doceng@. doceng@ would like to thank bcr@ for his service.

Document changes

  • Handbook: Document the automatic creation of XDG directories starting with FreeBSD 14.1. The VNET config example script has been fixed.

  • Architecture Handbook: remove K&R prototypes in MAC chapter.

  • Website: Some improvements regarding the top banner and layout, visually rearrange buttons and more.

  • Documentation repository: fix of all malformed tables warnings. Removal of deprecated attributes to conform to new gohugo releases.

FreeBSD Translations on Weblate

Q3 2024 Status
  • 17 team languages

  • 214 registered users

1 new translator joined Weblate:

  • matthew (id)

Languages
  • Chinese (Simplified) (zh-cn) (progress: 7%)

  • Chinese (Traditional) (zh-tw) (progress: 3%)

  • Dutch (nl) (progress: 1%)

  • French (fr) (progress: 1%)

  • German (de) (progress: 1%)

  • Greek (el) (progress: 1%)

  • Indonesian (id) (progress: 1%)

  • Italian (it) (progress: 5%)

  • Korean (ko) (progress: 32%)

  • Norwegian (nb-no) (progress: 1%)

  • Persian (fa-ir) (progress: 3%)

  • Polish (progress: 2%)

  • Portuguese (progress: 0%)

  • Portuguese (pt-br) (progress: 24%)

  • Spanish (es) (progress: 36%)

  • Turkish (tr) (progress: 2%)

We want to thank everyone that contributed, translating or reviewing documents.

And please, help promote this effort on your local user group, we always need more volunteers.

Packages maintained by DocEng

During this quarter the following work was done in packages maintained by doceng@:

  • textproc/docproj: Bump gohugo dependency to 0.133.1

  • www/gohugo: update to 0.134.3

Open issues

There are 2 Open PRs in bugzilla assigned to doceng@:

  • 276923 www/gohugo link error under poudriere

  • 267274 Please remove the zh-CN Handbook of the current FreeBSD website

During this quarter doceng@ closed 3 PRs:

  • 266107 FreeBSD Handbook and other books: PDF: broken links – crossref

  • 279815 status reports: ERR_TOO_MANY_REDIRECTS

  • 281396 handbook: ERROR: <stdin>: line 149: dropping cells from incomplete row detected


FreeBSD Wiki

Contact: Mark Linimon <linimon@freebsd.org> Contact: Wiki admin <wiki-admin@freebsd.org>

The FreeBSD wiki is a repository of information that does not fit well in the official project documentation because it is too specific, too disparate, or too transient.

Current projects:

Mark Linimon has started attacking various stale pages. The focus has been on pages that we show to new, interested, users. (Recent Foundation newsletters refer to some of these pages directly.) Unfortunately, many of these pages have become stale, to the point where they were actually not good recommendations.

The pages that have received the most work are:

In addition to removing obviously stale entries, all entries have now been datestamped with the time that they were added to the various pages. wiki-admin@ would like to request that we carry forward this tradition into the future.

As well, wiki-admin@ has been sending email to ask committers/contributors to the above pages "should we keep this entry?" This task will continue until the pages have been cleaned up.

(NB: the fact that content in the wiki was stale was mentioned by numerous respondents in the FreeBSD Foundation 2024 Community Survey Report.)

Previous plans that have stalled

Plans are still underway to familiarize our audience on Discord with the wiki (there are too many "silos" in our FreeBSD community). The team has simply not had enough cycles to do this. However, contact Setesh on the FreeBSD Discord for more information.

Preliminary work was being done on updating the wiki software itself. Earlier, we were looking at switching implementations because MoinMoin development seemed to have stalled, leaving us with an unwanted hanging python2 dependency. However, MoinMoin now claims that they are nearing a 2.0 release. We have not yet tried an install of their latest beta version to test compatibility. Testers welcome.


The FreeBSD Russian Documentation Project

Contact: Andrei Zakhvatov <andrey.zakhvatov@gmail.com>

The FreeBSD Russian Documentation Project’s current goal is to provide up-to-date Russian translations of the most important parts of FreeBSD documentation (FAQ, Handbook, Web). It is important to support Russian speakers with high-quality official technical materials and increase acceptance of the operating system around the globe. We hope that this activity will receive some support from the Russian-speaking FreeBSD community and lead to more translated materials.

There is some progress in document translation:

Check the official translation guide if you are willing to help. We always appreciate your help with translation of the following materials:

  • Handbook chapters and sections

  • Articles

  • Web pages


Ports

Changes affecting the Ports Collection, whether sweeping changes that touch most of the tree, or individual ports themselves.

GCC on FreeBSD

Contact: Lorenzo Salvadore <salvadore@FreeBSD.org>

This quarter the main news is about the new GCC releases:

  • lang/gcc11 has been updated to 11.5.0, which is the last GCC 11 planned released;

  • lang/gcc12 has been updated to 12.4.0;

  • lang/gcc13 has been updated to 13.3.0;

  • lang/gcc14 has been updated to 14.2.0.

The exp-run to update GCC default version from 13 to 14 has started. As usual, thanks to everyone involved.

If you maintain any of the affected ports or want to give a hand preparing and testing some patches, please consider trying adding -fpermissive to CFLAGS in affected ports: GCC 14 has transformed some warnings into errors, which is the cause of many of the failed builds. The -fpermissive flag switches those errors back to warnings.


Freepascal and Lazarus on FreeBSD aarch64

Contact: José Alonso Cárdenas Márquez <acm@FreeBSD.org>

Free Pascal is a mature, versatile, open source Pascal compiler. It can target many operating systems and processor architectures: Intel x86 (16 and 32 bit), AMD64/x86-64, PowerPC, PowerPC64, SPARC, SPARC64, ARM, AArch64, MIPS, Motorola 68k, AVR, and the JVM. Additionally, support for RISC-V (32/64), Xtensa, and Z80 architectures, and for the LLVM compiler infrastructure is available in the development version. Also, the Free Pascal team maintains a transpiler for pascal to Javascript called pas2js.

Lazarus is a Delphi compatible cross-platform IDE for Rapid Application Development. It has a variety of components ready for use and a graphical form designer to easily create complex graphical user interfaces.

Three years ago, Mikaël Urankar <mikael@FreeBSD.org> began porting the Free Pascal compiler to FreeBSD aarch64 and it was merged into Free Pascal source code (main branch). Some months ago, I added lang/fpc-devel (3.3.1) and editors/lazarus-devel (3.99) to the ports tree only for i386 and amd64 because aarch64 was not ready yet. The binaries generated on aarch64 did not run because of ELF issues. Finally, some days ago the issues were resolved and support for FreeBSD aarch64 was completed.

lang/fpc-devel and editors/lazarus-devel were updated to 3.3.1.20240913 and 3.99.20240913 with support for aarch64 respectively. It brings to FreeBSD users a new language and platform working on FreeBSD aarch64 for console, graphic, or any kind of apps development.

TODO


Third Party Projects

Many projects build upon FreeBSD or incorporate components of FreeBSD into their project. As these projects may be of interest to the broader FreeBSD community, we sometimes include brief updates submitted by these projects in our quarterly report. The FreeBSD project makes no representation as to the accuracy or veracity of any claims in these submissions.

Containers and FreeBSD: Pot, Potluck and Potman

Contact: Luca Pizzamiglio (Pot) <pizzamig@FreeBSD.org>
Contact: Bretton Vine (Potluck) <bv@honeyguide.eu>
Contact: Michael Gmelin (Potman) <grembo@FreeBSD.org>

Pot is a jail management tool that also supports orchestration through Nomad. Potluck aims to be to FreeBSD and Pot (and potentially one day also Podman) what Dockerhub is to Linux and Docker: a repository of container descriptions and complete container images for usage with Pot and in many cases Nomad.

During this quarter, there were two bugfixes to Pot that will be released soon.

Potluck images saw some updates again. All images have been rebuilt again to include the latest fixes and quarterly packages. Additionally, some images like Loki or Vault have also received additional updates and bugfixes.

Also, we have done some research regarding potential future support of OCI, Buildah and Podman images in Potluck. Two blog posts, one describing a basic Buildah and Podman setup and one describing how to orchestrate Podman containers with Nomad and Consul have been published.

As always, feedback and patches are welcome.

Sponsors: Nikulipe UAB, Honeyguide Group


Last modified on: November 6, 2024 by Lorenzo Salvadore