Open source infrastructure depends on more than new features. It also depends on the steady, often unseen work of identifying risks, improving processes, and making systems easier to maintain over time.

That is exactly what the Beach Cleaning Project set out to do for FreeBSD.

This project focused on improving the security resilience of the FreeBSD base system by giving the Project better visibility into the third-party software it ships, better tools for evaluating and maintaining that software, and a stronger foundation for future work around software transparency, security, and sustainability.

Why this work mattered

FreeBSD’s base system includes a wide range of third-party components. Over time, keeping track of what is included, who maintains it, how exposed it is, and what action should be taken becomes more difficult. That challenge is not unique to FreeBSD. It is one shared by many mature open source projects.

The Beach Cleaning Project tackled that challenge directly.

The result was not just a review of what exists today. It produced practical tooling, machine-readable data, security assessments, and implementation plans that will continue to support FreeBSD development well beyond the life of the project.

A critical early win: OpenSSL 3.5 for FreeBSD 15.0

The project began with an urgent and high-impact task: updating OpenSSL in FreeBSD’s src repository in time for the FreeBSD 15.0 release cycle. That work ensured FreeBSD could move to OpenSSL 3.5 LTS instead of remaining on OpenSSL 3.0 LTS.

That matters because OpenSSL 3.0 reaches end of life on September 7, 2026, while OpenSSL 3.5 is supported until April 8, 2030. Since FreeBSD 15 is expected to reach end of life in December 2030, moving to OpenSSL 3.5 dramatically reduces the amount of time the FreeBSD community would need to maintain its own unsupported fork, from more than four years to roughly eight months.

Just as important, the work was completed in time for the FreeBSD 15.0 schedule and included build validation across supported architectures, legacy architecture testing, and coordination for broader testing.

Building a clearer picture of the base system

Another major outcome of the project was the creation of a machine-readable inventory of software in the FreeBSD base system.

Using new tooling developed during the project, the team built a YAML-based database that supports reporting on maintainers, components, security review, planning, and Software Bill of Materials generation. By the end of the project, that database included more than 1,000 distinct components, including 73 imported from third-party projects.

This is the kind of work that makes future maintenance easier. Instead of relying on incomplete or outdated lists, FreeBSD now has a stronger foundation for understanding what is in the base system and how those pieces relate to security, ownership, and release engineering.

Turning visibility into action

Inventory alone is not enough. The project also developed a structured way to assess security risk across third-party software in the base system.

Components were evaluated based on factors like impact on build infrastructure, operating system integrity, network exposure, authentication, and user-facing functionality. That helped identify the most critical areas for attention and guided conversations with FreeBSD’s release engineering, security response, and source management teams.

From those conversations came a practical set of priorities, including support for SBOM generation through SPDX tooling, importing pkg into the base system as FreeBSD moves further into pkgbase, and improving tooling around code ownership and maintenance.

Better tooling for a healthier project

One of the strongest outcomes of the Beach Cleaning Project is that it did not stop at analysis. It produced real tooling that can keep delivering value.

The project added support for generating CODEOWNERS-style reports, helping replace stale and incomplete maintainer information with something more useful and machine-readable. It also created tooling to generate SBOM data in SPDX 2 and SPDX 3 formats, report on dependencies, evaluate security exposure, and identify maintainers for different parts of the tree.

Additional automation was developed to track component versions and regenerate deliverables through testing workflows, making the work easier to maintain and extend over time.

Laying groundwork for what comes next

Some of the implementation work advanced significantly during the project, even if it is not yet fully complete.

That includes preparation for importing pkgconf components needed for SBOM generation and ongoing work related to importing pkg into the base system as part of the broader pkgbase transition. In both cases, the project helped move concepts into tested, reviewable work that can continue forward.

That is an important part of work like this. It is not only about producing a final report. It is also about making the next step easier for the Project and for future contributors. In that sense, the Beach Cleaning Project has already had an impact by helping FreeBSD align priorities, improve coordination, and build a stronger path for future security and maintenance work.

Why this matters beyond FreeBSD

Projects across open source are dealing with many of the same questions around security, software composition, traceability, and long-term sustainability.

What makes this work especially valuable is that it offers a practical example of how to approach those challenges: start with visibility, build better data and tooling, identify priorities, and create processes that make long-term maintenance more manageable. The deliverables from this project are part of that larger story.

Thank you to Alpha-Omega

We are thankful to Alpha-Omega for supporting this work. Funding efforts like this help make important maintenance and security work possible, even when it is not the most visible part of open source development.

This project helped lay important groundwork for FreeBSD’s future, and we are excited to see that work continue.

— Contributed By Pierre Pronchery and Anne Dickison

The post Cleaning Up Critical Infrastructure in FreeBSD first appeared on FreeBSD Foundation.

I was fortunate to receive travel sponsorship from the FreeBSD Foundation to attend the AsiaBSDCon 2026 conference and the FreeBSD Developer Summit in Taipei. The event was held over four days at the National Taiwan Normal University from March 19–22, 2026. The first two days were dedicated to the Developer Summit, followed by the main conference on the final two days. My journey from Vientiane, Laos, to Taipei involved a flight with a layover in Bangkok.
On the first day, I missed the conference because my flight was delayed. As a result, I arrived at my hotel in Taiwan around 4 PM on March 19, 2026, although I had originally planned to arrive in Taipei around 10:30 PM on March 18, 2026.
On the second day, I attended a tutorial session titled “IPv6 Tutorial” by Massimiliano Stucchi. From this tutorial, I understood how IPv6 works, how an addressing plan can be built for an enterprise network, and how to configure it on FreeBSD and OpenBSD.
On the third day: In the morning sessions, I attended the Opening Ceremony by Li-Wen Hsu, and then “Rethinking the Forms of OS Functionality Development” by Kenichi Yasukata. From this session, I learned about exploring the question of whether there are other possible forms of OS functionality development that can accelerate development velocity while reducing the burden on these communities. In the afternoon session, I attended “Faster, smolBSD! Boot! Boot!”, “Porting STUNMESH-go to FreeBSD and macOS: Building Peer-to-Peer WireGuard Networks”, “Design and Implementation of Bhyve Management Daemon”, and “Bring Cloud-Native Networking to FreeBSD Jails: Porting Calico from Linux.”
On the fourth day: In the morning sessions, I attended “Run Time Reoptimization for Modern Heterogeneous Systems” by George V. Neville-Neil. In the afternoon session, I attended “Bringing Memory Safety to BSD with CHERI” and “Sleep on FreeBSD: A Bedtime Story About S0ix.”
On the final day, I scheduled time to meet and discuss with Li-Wen Hsu about the LibreOffice community and the FreeBSD community in Laos, as these topics had been put in the developer submit on Day 1, but I could not attend due to my flight delay, as I mentioned previously. Regarding LibreOffice, we discussed the possibility of including FreeBSD in the lifecycle path update stream for LibreOffice. Regarding the FreeBSD community in Laos, I talked to Li-Wen Hsu about our small group of people who are interested in studying Unix-like systems, and we have made a group to study and learn together. In the future, we hope to see more people using FreeBSD in Laos and to be able to host AsiaBSDCon 2028 after AsiaBSDCon 2027 in Singapore.
From this event, I learned many new things about BSD that I have on my PC. This was my first time attending BSDCon, and I made new friends and connections, especially with Li Wen Hsu.
Thank you to the FreeBSD Foundation for sponsoring my attendance at the conference.

The post AsiaBSDCon 2026 Trip Report – Saikeo first appeared on FreeBSD Foundation.

I’m very grateful that the FreeBSD Foundation sponsored my trip to AsiaBSDCon 2026 in Taipei, Taiwan. The conference ran from March 19 through 22, with the first two days dedicated to the FreeBSD Developer Summit and the final two days to the main conference. It was an incredibly productive experience, and I’m glad I had the opportunity to attend.  

The Developer Summit ran for two days, 10 AM to 5 PM each day. Most sessions were short presentations covering topics like FreeBSD on WSL 2 and Ansible on FreeBSD. Between talks, developers worked on patches, followed up on mailing-list threads, and reviewed one another’s work. I found this format extremely valuable as I was able to get useful feedback on my LLVM pull requests during these gaps, which would have taken much longer to sort out over email. I had a productive conversation with Shingyi Hung (aokblast@) about my LLDB kernel debugging pull requests, and his review comments helped me refine my approach going forward.  

The main conference began on Saturday and drew roughly three to four times as many attendees as the DevSummit. Kenichi Yasukata’s talk on a portable userland TCP/IP stack was fascinating — he outlined how separating OS-specific glue from the core stack allows it to remain portable  

while still achieving strong performance. He also discussed techniques for intercepting system calls without relying on LD_PRELOAD, using binary overwriting with architecture-specific hooks. Pierre Pronchery’s demonstration of smolBSD was equally impressive, showing container-oriented NetBSD images that boot in under one second by stripping the kernel and bypassing the traditional UEFI boot path.  

On Sunday, George Neville-Neil gave a thought-provoking talk on runtime reoptimization for modern heterogeneous hardware. His core argument — that Unix-like systems still carry assumptions rooted in the PDP-11 era — resonated with me, and his approach of feeding live profiling data back into LLVM to produce architecture-specific binaries is something I plan to revisit once the recording is available. Brooks Davis presented the CheriBSD upstreaming effort, with a target of FreeBSD 16 in December 2027. The security demonstrations were compelling.  CHERI caught all 13 memory bugs intentionally injected into NGINX, plus two additional ones introduced unintentionally. At lunch, I had the chance to speak with Olivier (olce@) about designing a hybrid scheduler and IntelHFI patch review, which is directly relevant to the hybrid scheduling work I’ve been doing for FreeBSD.  

As helpful as mailing lists and code review platforms can be, they don’t compare to the quality of communication you can have with someone in person. Being able to sit down with Olivier and  Shingyi to discuss my ongoing work face-to-face was far more productive than weeks of asynchronous back-and-forth would have been.  

During the closing session, Li-wen Hsu announced that AsiaBSDCon 2027 will be held in Singapore, and the organizers are actively looking for volunteers and sponsors. I also want to note that I will be presenting a talk on hybrid scheduling at BSDCan 2026.  

Conference schedule: https://2026.asiabsdcon.org/entry/schedule/  

My blog recap: https://minsoo.io/asiabsdcon-2026-recap/  

Thank you again to the Foundation for making this trip possible.  

Respectfully,  

Minsoo Choo

The post AsiaBSDCon 2026 Trip Report – Minsoo Choo   first appeared on FreeBSD Foundation.

2026 is off to a great start for the Laptop Support and Usability Project. We’ve seen lots of exciting updates to major areas such as graphics and Wi-Fi drivers, as well as FreeBSD installer improvements to support the KDE Plasma desktop environment out of the box.

At this stage in the project, as we hinted earlier in the Year One Project Update, we decided to start a rigorous testing program to comprehensively validate all laptop and desktop functionality together. Since January, we have been working behind the scenes to evaluate testing requirements and implement the tooling needed to maintain these test results for the long term.

After trial runs of integration testing on our committed target systems, we are pleased to open up this effort to the FreeBSD community!

How to test

This is the process for testing FreeBSD on your laptop:

1. You run our testing tool that automatically probes your laptop hardware and logs what features work (or don’t work).
2. The tool creates a new directory containing the fully anonymized results.
3. If you wish, you can also add your own commentary to a new file named comments.md inside this directory.
4. You send the results in a Pull Request, making sure to answer the User Stories questionnaire in the template.
5. We will process the report and publish it to the compatibility matrix. No Personally Identifiable Information will ever be published.
6. Success!

To get started, run the following commands as an unprivileged user on your target testing laptop and follow the prompts along the way until you have completed the process. These steps can be done on any FreeBSD installation or live environment such as mfsBSD.

pkg install python hw-probe
git clone https://github.com/FreeBSDFoundation/freebsd-laptop-testing
cd freebsd-laptop-testing
make

The post Call for testing: introducing the Laptop Integration Testing project first appeared on FreeBSD Foundation.

FreeBSD runs on this…

[pi4]
hdmi_safe=0
armstub=armstub8-gic.bin
max_framebuffers=2
hdmi_force_hotplug=1
hdmi_group=1
hdmi_drive=2
hdmi_mode=16

Mar  6 17:04:25 generic kernel: ugen0.4: <ASMedia ASM1156> at usbus0
Mar  6 17:04:25 generic kernel: umass0 on uhub0
Mar  6 17:04:25 generic kernel: umass0: <ASMedia ASM1156, class 0/0, rev 3.20/1.00, addr 3> on usbus0
Mar  6 17:04:25 generic kernel: umass0:  SCSI over Bulk-Only; quirks = 0x0
Mar  6 17:04:25 generic kernel: umass0:0:0: Attached to scbus0
Mar  6 17:04:25 generic kernel: da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
Mar  6 17:04:25 generic kernel: da0: <ASMedia ASM1156 0> Fixed Direct Access SPC-4 SCSI device
Mar  6 17:04:25 generic kernel: da0: Serial Number AAAABBBB0490
Mar  6 17:04:25 generic kernel: da0: 400.000MB/s transfers
Mar  6 17:04:25 generic kernel: da0: 3815447MB (7814037168 512 byte sectors)
Mar  6 17:04:25 generic kernel: da0: quirks=0x2<NO_6_BYTE>
Mar  6 17:04:25 generic kernel: da1 at umass-sim0 bus 0 scbus0 target 0 lun 1
Mar  6 17:04:25 generic kernel: da1: <ASMedia ASM1156 0> Fixed Direct Access SPC-4 SCSI device
Mar  6 17:04:25 generic kernel: da1: Serial Number AAAABBBB0490
Mar  6 17:04:25 generic kernel: da1: 400.000MB/s transfers
Mar  6 17:04:25 generic kernel: da1: 3815447MB (7814037168 512 byte sectors)
Mar  6 17:04:25 generic kernel: da1: quirks=0x2<NO_6_BYTE>

root@generic:~ # zpool create -f store mirror da0 da1
root@generic:~ # zfs list
NAME    USED  AVAIL  REFER  MOUNTPOINT
store   384K  3.51T    96K  /store

root@generic:~ # service zfs enable
zfs enabled in /etc/rc.conf

root@generic:~ # pkg update
The package management tool is not yet installed on your system.
Do you want to fetch and install it now? [y/N]: y
Bootstrapping pkg from pkg+https://pkg.FreeBSD.org/FreeBSD:15:aarch64/quarterly, please wait...

root@generic:~ # pkg install -y samba423
Updating FreeBSD-ports repository catalogue...
FreeBSD-ports repository is up to date.
Updating FreeBSD-ports-kmods repository catalogue...
FreeBSD-ports-kmods repository is up to date.
All repositories are up to date.
Updating database digests format: 100%
The following 82 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
[snip]

[global]
workgroup = FOUNDATION
server string = Pi Samba Version %v
netbios name = RaspberryPi
wins support = Yes
security = user
passdb backend = tdbsam

[store]
path = /store
valid users = freebsd
writable  = yes
browsable = yes
read only = no
guest ok = no
public = no
create mask = 0666
directory mask = 0755

root@generic:~ # testparm
Load smb config files from /usr/local/etc/smb4.conf
Loaded services file OK.
Weak crypto is allowed by GnuTLS (e.g. NTLM as a compatibility fallback)

Server role: ROLE_STANDALONE

Press enter to see a dump of your service definitions

# Global parameters
[global]
        netbios name = RASPBERRYPI
        security = USER
        server string = Pi Samba Version %v
        wins support = Yes
        workgroup = FOUNDATION
        idmap config * : backend = tdb


[store]
        create mask = 0666
        path = /store
        read only = No
        valid users = freebsd

root@generic:~ # pdbedit -a -u freebsd
new password:
retype new password:
Unix username:        freebsd
NT username:
Account Flags:        [U          ]
User SID:             S-1-5-21-2694234615-196936691-1629692636-1000
Primary Group SID:    S-1-5-21-2694234615-196936691-1629692636-513
Full Name:            FreeBSD User
Home Directory:       \\RASPBERRYPI\freebsd

root@generic:~ # service dbus enable && service avahi-daemon enable && service dbus start && service avahi-daemon start
dbus enabled in /etc/rc.conf
avahi_daemon enabled in /etc/rc.conf
Starting dbus.
Starting avahi-daemon.

root@generic:~ # service samba_server enable
samba_server enabled in /etc/rc.conf
root@generic:~ # service samba_server start
Performing sanity check on Samba configuration: OK
Starting nmbd.
Starting smbd.

root@generic:~ # service samba_server stop
Stopping smbd.
Waiting for PIDS: 6629.
Stopping nmbd.
Waiting for PIDS: 6622.
root@generic:~ # zpool export store
root@generic:~ # zpool status
no pools available

root@generic:~ # zpool list
no pools available
root@generic:~ # zpool import store
root@generic:~ # zpool list
NAME    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
store  3.62T   596K  3.62T        -         -     0%     0%  1.00x    ONLINE  -

The post Build a NAS using FreeBSD on a Raspberry Pi first appeared on FreeBSD Foundation.

Please note that the information provided in this document is for informational purposes only and does not constitute legal advice.

The FreeBSD Foundation has launched its Cyber Resilience Act (CRA) Readiness project for 2026 to prepare the Foundation, the FreeBSD Project, and the broader FreeBSD community for the European Union’s landmark cybersecurity legislation. This post provides context for why we are investing in this work now and information about what the project will cover.

The EU is regulating software security

The EU’s CRA (REGULATION (EU) 2024/2847) represents one of the most significant pieces of software security legislation in recent history. It places commercial software into a regulatory framework for security and, if products are found to be non-compliant, it specifies fines of up to 15 million euros or 2.5 % of a company’s total worldwide annual turnover, whichever is higher. 

Manufacturers are required to manage the security risks posed by their supply chain

For manufacturers the CRA mandates essential cybersecurity requirements with which they must comply during the design, development and production of their products. 

These requirements fall into two main categories, each of which has stringent enforcement:

1. Products must be secure by default. 

Manufacturers must actively manage the cybersecurity risk across the full lifecycle of their products. They must document how they are doing this (including providing an SBOM) and make it available to the market surveillance authorities. They must exercise due diligence in their use of 3rd-party components such as open source projects. They must provide a declaration of conformity with the CRA on the basis of having carried out an accepted conformity assessment procedure.

2. Vulnerabilities must be rapidly reported.

Once the product is on the market, manufacturers must act quickly when actively exploited vulnerabilities are discovered. Notifications must be reported on the CRA Single Reporting Platform with deadlines as follows: 24 hours for an early warning notification, and 72 hours for the main notification. Further reporting deadlines also apply within a 14-28 day window.

There is a lot more detail provided in the CRA itself, but these headlines are enough to give a clue to the sorts of activities that manufacturers will soon start doing to meet the CRA requirements.

The CRA is already law, with staged compliance deadlines

The CRA entered into force on 10 December 2024. Its essential cybersecurity requirements (including ‘secure by default’ principles) will start applying from 11 December 2027. Products placed on the market before 11 December 2027 are only subject to these requirements if they undergo substantial modification after that date. 

Reporting obligations come into force on 11 September 2026. Reporting obligations apply to all products with digital elements available in the EU market, including those already on the market before 11 December 2027.

Open source projects have limited CRA responsibilities, but face both opportunities and risks

Open source projects have limited responsibilities

Many in the open source community have been watching this coming down the tracks. The first iteration of the CRA did not mention open source at all. Thanks to feedback from many open source contributors, the CRA now contains robust carve-outs of responsibility for open source projects. 

Happily, individuals who contribute to free and open source projects are exempted from all legal responsibilities, even if they are paid to contribute on a project. 

Organizations that are classified as ‘open source stewards’ have limited responsibilities under the CRA and cannot be fined. The FreeBSD Foundation likely falls under this classification. Individuals cannot be stewards.

The risks to an open source project

Does this mean an open source project has nothing to worry about? For open source projects which are used in downstream commercial software products there are some areas where things might get rough once manufacturers start getting serious about CRA compliance.

One example is a “due diligence denial of service attack”. What happens when many manufacturers aim to carry out a due diligence process on components in their SBOM? A project with a large downstream user base might receive a deluge of requests for information. 

Or, how about when an exploited vulnerability is discovered in your open source project? A manufacturer would have to report it within 24h and your project might receive requests for information, and patch submissions (or demands for fixes!) that come with a lot of pressure attached. Does your project have the processes and staffing for this?

Another, more insidious, possibility is that any open source project that is not prepared for the CRA may simply get swapped out or passed over by manufacturers who see a more-compliant option. This could contribute to putting a project on a downward trajectory.  If you are thinking “my project is too hard to swap out”, consider this –  an unprepared project that cannot be easily swapped out might find that the downstream start making SBOMs just for their fork (this could create all sorts of complexities and upstream queries). 

The opportunities for open source projects

It is not all doom and gloom though. The CRA has the potential to change the power dynamics of the open source landscape. Projects that are proactive in preparing for the CRA will be better positioned to forge new relationships with their downstream users. 

When manufacturers need SBOMs, documentation on security processes, and swift vulnerability management responses to avoid eye-watering fines, they may be more incentivized  to support their upstream open source projects. 

Projects could secure funding agreements, gain dedicated security staffing support, or establish formal partnerships with manufacturers.

Open source projects all over the world are working together to figure this out. After all, it’s what we do. 

The FreeBSD Foundation is committed to helping FreeBSD navigate this important change successfully.

The FreeBSD Foundation’s CRA Readiness project

For FreeBSD, getting prepared now means we can take a proactive approach to CRA readiness and leverage as much benefit as possible while reducing potential harms. 

The high-level project goals are: make sure the Foundation fulfills its legal obligations as an open source steward, protect the Project from disruption as manufacturers work to meet CRA requirements, and ensure that our contributors understand they are not personally exposed to legal liability under this legislation.

What we are working on

The project is organized into six workstreams running through 2026:

Security and vulnerability handling 
This is the core of the effort. Foundation staff will work closely with FreeBSD’s Core team, Security team, and Ports Security team, and downstream vendors to develop a shared understanding of CRA responsibilities and to examine how we collectively respond to CRA-related scenarios. This is a sustained, 12-month effort that takes a holistic view of FreeBSD’s security posture, and will result in updated policies, public positions, and documentation where needed.

SBOM toolchain 
This addresses one of the CRA’s most concrete requirements: Software Bills of Materials. Rather than leaving manufacturers to independently generate their own (potentially inaccurate) SBOMs for FreeBSD-based products, we are building a single, authoritative, open-source SBOM toolchain. This work builds on development started in 2025 under our Infrastructure Modernization project. Over the next four months, we will be adding SBOM information files, identifying and filling licensing gaps, and collaborating with upstream projects to improve SBOM metadata. A shared, accurate SBOM solution is better for everyone.

Public documentation 
This will give manufacturers, maintainers, and contributors clear, FreeBSD-specific information about CRA requirements, including emerging processes and key contacts. The content will evolve as our understanding deepens across the other workstreams.

Community legislative engagement 
This will open up a simple communication channel (most likely a mailing list) so that the FreeBSD community can participate in EU policy development. Bodies like CEN, CENELEC, and ETSI regularly seek input from the open source world, and we want to make sure FreeBSD voices are part of that conversation.

A public-facing project repository 
This will serve as the running record of everything we do. We are committed to transparency: detailed updates, outputs, and decision-making will all be documented here as the project progresses.

Communications 
We will keep the broader community informed through blogs, social media, and other channels as we hit key milestones.

A note on scope
The CRA is new legislation, and real-world guidance on implementation continues to evolve. We have designed this project to adapt as our understanding develops, and though the workstreams above reflect our best current thinking, you should expect the details to shift over time. We will keep you informed as they do.

Learn more

• CRA full text https://eur-lex.europa.eu/eli/reg/2024/2847/oj
• CRA summary https://digital-strategy.ec.europa.eu/en/policies/cra-summary#ecl-inpage-chapter-viii 
• FreeBSD Foundation’s CRA Readiness project repo https://github.com/FreeBSDFoundation/all-projects/tree/main/Cyber%20Resilience%20Act%20Readiness 
• 3rd-party guide to how CRA affects open source maintainers https://cra.orcwg.org/faq/maintainers/ 

The post Getting ready for the Cyber Resilience Act first appeared on FreeBSD Foundation.

Written as part of the FreeBSD Project’s 4th Quarter 2025 Status Report, check out the highlights of what we did to help FreeBSD last quarter:

The post FreeBSD Foundation Q4 2025 Status Update first appeared on FreeBSD Foundation.

We are pleased to announce the October/November/December 2025 issue of the FreeBSD Journal, focused on FreeBSD 15.0, is now available. This online publication provides the FreeBSD community with valuable insights and technical knowledge each quarter.

This quarter’s issue highlights FreeBSD 15.0, featuring articles that explore storage and sound subsystems, system security, developer tooling, and community initiatives. Inside, you’ll find coverage on FreeBSD 15.0 fixes and features, Universal Flash Storage, credential transitions with mdo(1) and mac_do(4), FreeBSD’s participation in Google Summer of Code 2025, and building U-Boot. The issue also includes community staples such as We Get Letters, the 2026 Events Calendar, and a Letter from the Foundation.

Thank you to all the contributors who made this issue possible. The FreeBSD Journal highlights the work and expertise of the FreeBSD community. As always, it is freely available in both HTML and PDF formats.

Read the Q4 2025 Issue Here:
https://freebsdfoundation.org/our-work/journal/browser-based-edition/freebsd-15-0/

Please take a moment to read this issue, share it with your colleagues, and help spread the word that the FreeBSD Journal is a great way to stay up to date on the FreeBSD community.

The post The Q4 2025 Issue of the FreeBSD Journal is Now Available! first appeared on FreeBSD Foundation.

Did you know that your support for the FreeBSD Foundation directly improves the FreeBSD you use every day?

FreeBSD doesn’t just happen. It’s built, tested, maintained, secured, and improved by a global community. Your donation helps make that possible in ways that directly benefit you, including:

• A stronger, more reliable FreeBSD. More than half of the Foundation’s budget goes directly into software development projects, such as advancing laptop and desktop usability and strengthening security.
• Smoother updates and releases you can count on. Your support keeps FreeBSD’s build, testing, and CI infrastructure running, ensuring stable upgrades and dependable releases.
• A community that strengthens the system you rely on. Your donation helps grow contributor participation, expand education and events, and keep the ecosystem healthy for the long term.

When FreeBSD grows stronger, the systems and projects you build on top of it do too. FreeBSD is powered by its community and supported by you.

Please consider donating today! We can’t do it without you. 

Sincerely, 
Deb Goodkin
Executive Director
FreeBSD Foundation

The post Powering the Future of FreeBSD first appeared on FreeBSD Foundation.

As we look back on 2025, it is clear that this has been a year of meaningful progress for the FreeBSD Project and the FreeBSD Foundation. We advanced key development initiatives, strengthened core infrastructure, improved accessibility, and continued supporting enterprise-scale use. 

This work was made possible through the generosity of our donors and the dedication of contributors, partners, and staff. With 62% of our annual budget invested directly in software development, the Foundation remained focused on delivering sustainable, high-impact improvements across the ecosystem. The sections below highlight the technical achievements that shaped 2025.

The post 2025: Software Development and Infrastructure Support. first appeared on FreeBSD Foundation.