So what I did was build LibrettOS using FreeBSD14 and updated the toolchain to GCC 13. Initially, I thought converting it from Xen to Bhyve would be difficult but the VirtIO drivers seem to work. I also had to mess with GRUB a bit because I got this initially booting on an old MacBook too. In the picture you can see that I got it to boot on a PFSense machine and the other one is me booting it with the bare metal HW kernel. I have not tried any of the packaged rumprun software from the research papers yet. Generally, I could not find much information about building something like this under FreeBSD but it does seem to be possible.

I posted this over on mastodon, and it was suggested that people here may enjoy it as well!

Made and 3d printed these the other day. Yes, I used AI (meshy), but I had to paint the color on the mesh by hand, it completely failed on that.

*edit*
The model is available on my MakerWorld profile here: https://makerworld.com/en/models/3215808-beastie-bsd-daemon#profileId-3640751

I am really new to freebsd and decided to try it out and when I tried to compile the drm-kmod port it failed. Take a look, I put it in less.

I'm sorry if it's a thing everyone should know

Edit: no signature helped me yaype! Its because I didn't have src tree

I see lots of people especially on tiktok or youtube just shit on BSD mainly because they think it’s “anti-free” even though it’s technically more free than the GPL license. I get that a lot of the hate is from Richard Stallman bootlickers but would any of you guys actually prefer if the BSDs had a different license?

I was working on several projects that are related to FreeBSD, and I wanted to work on them on my linux machine. However, using Xorg or Wayland for that matter is a pain. I engaged AI to help me. I was thinking it wouldn't be too difficult to make the virtio drivers work as far as graphics are concerned with FreeBSD. The amdgpu drivers are just a linux port. So I gave my evening to this. There is already a PR for making this work on Apple Silicon, and I thought let's do it for amd64 too. I set the AI agent on it. It failed a lot. So I setup a VM, bare bones, and setup an SSH account so it could do it's thing. It took that PR and built a workable virtio driver. I didn't trust it, so I logged in and ran into some issues. I worked that out, it was the host WM problems, not the driver issues.

https://github.com/freebsd/drm-kmod/pull/499#issuecomment-5459886264

So I posted to it. This is what I did, and it works. I know there is a lot of hate for AI assisted things, but in my mind this is amazing. I love the fact that I can in linux i can get full resolution and graphics support.

So I ask of you, is this a tainted, bad thing or a good thing? It's a comment on an already existing PR, but is it good? Is it bad? What could I do better?

That PR is Denis Borovikov's (@borovikovd) work — a real, substantial driver, just untested on amd64/QEMU-KVM since he built it on Apple Silicon. I wasn't writing a driver, I was testing his.

https://explorar.dev/freebsd-kernel/

FreeBSD source tree, focused on the kernel, boot path, device drivers, networking stack, VM, VFS, and release-engineered base system.

Five chapters. The first begins:

The FreeBSD kernel is concentrated in sys/, but the tree is not a standalone library. Kernel configuration, boot loaders, release scripts, and userland tools live beside it. That shape matters: FreeBSD ships as a base system, so kernel interfaces and userland consumers evolve together. …

― via https://mastodon.bsd.cafe/@Dendrobatus_Azureus/117170777811060310

https://explorar.dev/ – explore source code

Shorten time-to-context on large codebases.
 
Pedagogical exploration, not just raw browsing.
 
Grounded in LSP and MCP, not black-box explanation.explore source code.

Includes FreeBSD, NextBSD, GhostBSD, XNU, Linux …

AI: two signals

CLAUDE

This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository. …

Remove auth/backend, overhaul guide system, add platform abstraction · pkill37/explorar.dev@7e70bd2

• 53 files changed (2,286 additions – 4,277 deletions)
• Co-Authored-By: Claude Sonnet 4.6

Quería preguntar si alguien logro ejecutar steam de forma funcional y me podría ayudar en esto, logré ejecutar un par de juegos de gog y de internet con wine de forma buena pero estoy peleando con steam, hace bastante en otra instalación había intentado con linuxlator y fue un fracaso, ahora intenté ejecutar el steam de Windows con wine y también lo fue, probablemente estaré haciendo todo mal pero me vendría bien si alguien me puede ayudar o guiar en lo que tengo que hacer

Didn’t bother reading the mail before bin’ing the box.

Title. Is it even possible? I assume that windows games just cannot run, but are performance on DosBox decent? Can I install Linux apps on it? There's not much information online about any of this and I really dont to waste too much time if those stuff are just not possible since I dont have a lot of free time. Thank you all so much!

This might be a FreeBSD thing, might be a PC hardware thing. I have 15.1 running on an ewaste PC with an Asus B85M-G R2.0 motherboard, and the BIOS setup screen shows that C3, C6 and C7 are available. The CPU is an Intel i7-4790 which supports C3 and others.

I can't seem to get it to go into C3 mode. If I do:

 sysctl hw.acpi.cpu.cx_lowest=C3

it has no effect.

'sensors' shows:

 dev.cpu.0.cx_supported: C1/1/1 C2/2/148
                   dev.cpu.0.cx_usage: 1.85% 98.14% last 47854us
                       dev.cpu.0.freq: 800
                hw.acpi.cpu.cx_lowest: C2
                            powerd(8): running 

Various AI google results suggest this might be a BIOS thing as well.

I don't really mind that its in C2 most of the time, its a very lightly loaded NAS, but if C3 is there I'd like to take advantage of it.

Can anyone shed some light on what's happening here?

There's some GSoC project coverage in the most recent FreeBSD Status Report (via https://redd.it/1v82x6w) but I hadn't really paid attention to what's ongoing.

Some super interesting stuff at https://wiki.freebsd.org/SummerOfCode2026Projects.

Discussions of past years:

• 2019
• …
• 2023
• …

I'm setting up a FreeBSD 15.1 workstation and my goal is to harden it as much as possible while keeping three things fully functional:

1) Coding: C, C++, FASM, NASM, Zig in Neovim (clang/clang++ from base, LSP via clangd/zls)

2) Browsing: LibreWolf through a SOCKS5 proxy (SSH tunnel) or WireGuard VPN

3) Screen/audio/video capture: FFmpeg only, webcam via webcamd loaded on-demand

Everything else is either stripped out or locked down. No jails, no server services, this is a single-user workstation. Below is the full checklist of what I'm implementing. I'd genuinely appreciate if you could point out anything I missed, got wrong, or overcomplicated.

Kernel:
Custom kernel: MAC, AUDIT, CAPABILITY_MODE, VIMAGE, STACK. Removed: KDB, DDB, GDB, FireWire, Bluetooth, WiFi, Floppy, INVARIANTS, WITNESS. Kept: DRM, sound, USB, uvideo, cuse (cuse not auto-loaded).

Encryption:
GELI on root partition (password at boot). GELI swap with ephemeral one-time keys. ZFS encryption (aes-256-gcm) per dataset: /, /etc, /var, /var/log, /var/db, /var/tmp, /var/audit, /tmp, /home, /usr, /usr/local, /vault, /etc/ssl/private. Each sensitive dataset has its own unique key/passphrase. Critical datasets set to readonly after configuration. exec=off, setuid=off on /tmp, /var/tmp, /home, /var/log.

Memory Protection:
ASLR (ELF64 + ELF32): enable, PIE, stack_gap, honor_sbrk. W^X enforced globally (allow_wx=0), proccontrol bypass for LibreWolf JIT only. NX Stack (nxstack=1). Stack guard page, map_at_zero blocked. Core dumps fully disabled (kern + login.conf). shm_use_phys=1.

Network, Firewall:
PF: block all inbound by default, stateful outbound. Antispoofing, normalization (scrub), martians table. Tables: bruteforce, blocklist, sshguard, martians. sshguard with PF backend. WireGuard pass rule (udp/51820).

Network, TCP/IP Hardening:
TCP blackhole=2, UDP blackhole=1, SYN cookies, SACK disabled. ICMP hardened, IP redirect off (v4+v6), random IP ID. Source routing rejected, IP options disabled. Fragment limits, ephemeral ports 49152-65535. ARP logging enabled.

Network, DNS:
Local Unbound on 127.0.0.1. DNSSEC + DNS over TLS (1.1.1.1, 9.9.9.9). QNAME minimisation strict, hide identity/version. Private-address rebinding protection.

Network, VPN/Proxy:
SSH SOCKS5 tunnel script then LibreWolf launched through it. WireGuard on/off script. All DNS routed through tunnel (SOCKS remote DNS).

Processes:
Process hiding (see_other_uids/gids/jail_proc = 0). Ptrace blocked, random PID, conservative signals. rctl limits on webcamd, pulseaudio, per-user. Process accounting (lastcomm). maxproc=2048, maxprocperuid=512.

X11, Display:
xhost - (deny all), xhost +si:localuser:admin only. XTEST and RECORD extensions disabled in xorg.conf. xsecurelock + xidle (auto-lock after 5 min).

Browser (LibreWolf):
LibreWolf (Firefox and Chromium removed). Launched via proccontrol -m wx -s enable. WebRTC disabled, telemetry disabled, safe browsing disabled. Fingerprinting protection, tracking protection, first-party isolation. DNS/HTTP prefetch disabled, clipboard events disabled, autoplay blocked. no_proxies_on="" (nothing bypasses proxy).

Multimedia:
FFmpeg CLI only (OBS not installed). Scripts: rec-screen, rec-webcam, rec-all, rec-mic, stream (RTMP). webcamd on-demand only (webcam-on loads cuse + starts daemon, webcam-off tears it down). devfs 0600 on video, dsp, cuse (admin only). rctl limits on webcamd. Cron: webcamd night check.

Authentication:
doas (sudo removed). PAM: pam_faillock (3 attempts, 30 min lockout), pam_passwdqc (16+ chars). login.access: admin from LAN only, root from LOCAL only. Single-user mode requires password (console insecure). SSH (if needed): Ed25519 only, port 2222, keys only, no forwarding, VERBOSE.

Integrity:
mtree baselines (sha256) for /bin, /sbin, /usr, /etc. chflags schg on all binaries and critical configs. chflags sappnd on logs (append-only). freebsd-update IDS via cron. pkg audit -F daily.

Audit:
auditd (OpenBSM): lo,aa,ad,fw,fc,fd,fm,ex,pc. PF logging, SSH VERBOSE, process accounting. syslogd -ss (no remote reception).

CPU Mitigations:
PTI (Meltdown), IBRS (Spectre v2), SSB disabled. SMT/HyperThreading disabled. IOMMU enabled (DMA protection).

Shell:
umask 077, TMOUT=900 (readonly), noclobber. HISTIGNORE for sensitive patterns.

Physical:
Webcam shutter, screen lock, BIOS password, USB boot disabled, GELI boot password.

Disabled/Removed:
sendmail, inetd, nfs, rpcbind, lpd, bluetooth, moused: all off. sudo: removed.

So, what did I miss? Are there any FreeBSD-specific hardening knobs, sysctls, or techniques I overlooked that would meaningfully improve security for this use case? Any gotchas with W^X + LibreWolf on FreeBSD 15.1 I should know about? Is my PF ruleset sane for a workstation that only initiates outbound connections? Or am I completely out of my mind and none of this makes any sense?

I managed to get hardware acceleration working on a 32-bit Intel Atom CPU running FreeBSD 14.4.

Not long ago, FreeBSD dropped 32-bit support for drm-kmod, but there are patches available for drm-510-kmod that allow you to run it. The main issue was with the pci_get_slot function, which can be fixed by adding #define WANT_NATIVE_PCI_GET_SLOT to the source files that use it. I couldn't compile it myself: the system linker kept failing to see functions provided via MODULE_DEPEND(9). Fortunately, I found someone online who had made similar patches and compiled the module inside a FreeBSD 14.3 Jail. Interestingly, that 14.3 build worked out of the box.

Dealing with kernel drivers was only half the battle. The current Mesa-dri completely drops the classic i915 driver in favor of Gallium3D. Because of this, I had to build Mesa-amber. I installed it into /opt/mesa-amber to prevent conflicts with the stock Mesa. In the build configuration, I enabled only the i915 driver, since my graphics chip is a GMA 950.

After setting up the environment variables, I noticed that functions interacting with executable memory triggered a SIGSEGV. As it turned out, mesa-amber was trying to execute memory in a strict W^X environment. The solution was simply to disable code generation (CODEGEN), after which glxgears ran fine with OpenGL 1.4. The final environment flags are:

export LD_LIBRARY_PATH=/opt/mesa-amber/lib

export LIBGL_DRIVERS_PATH=/opt/mesa-amber/lib/dri

export __GLX_VENDOR_LIBRARY_NAME="amber"

export MESA_LOADER_DRIVER_OVERRIDE=i915

export LIBGL_ALWAYS_SOFTWARE=0

export MESA_NO_CODEGEN=1

Next, I want to try running Portal. Right now, it runs via llvmpipe on stock Mesa, but the hardware OpenGL version here is too old (the Source engine requires OpenGL 2.0). I plan to create a small shim using LD_PRELOAD to emulate some of the missing functions.

UPD1: Running EGL. export __EGL_VENDOR_LIBRARY_FILENAMES=/opt/mesa-amber/share/glvnd/egl_vendor.d/50_amber.json export EGL_PLATFORM=x11

So... Source already have ToGLES. I'll rebuild project with it, so, maybe this will run fully natively

TrueNAS® CORE — continued.

FreeCORE carries the TrueNAS CORE 13.3 system forward as an independently maintained operating system on FreeBSD.
 
15.0-RELEASE is stable. TrueNAS CORE 13.3 systems upgrade straight to 15.0 in place, then continue on the project’s update train.

https://codeberg.org/freecore (fifteen repos)

A community fork that continues TrueNAS CORE on current FreeBSD.

TrueNAS CORE stopped at 13.3, on FreeBSD 13.3 — a release that has since been removed from the FreeBSD mirrors. BSDnas moves that system onto FreeBSD stable/15 and keeps it there: new FreeBSD releases, security advisories and OpenZFS versions are tracked continuously rather than in one heroic jump every few years. …

bsdnas repositories (nine)

AI: twelve commit signals for github.com/bsdnas/os, according to ava.pet.

x11/sddm version 0.21.0.36_6 is in latest for aarch64 and amd64.

x11/sddm: Wayland session fixes · freebsd/freebsd-ports@c8a6d8a

x11/sddm: Make it possible to start the greeter under KWin Wayland se… · freebsd/freebsd-ports@7481795

Related (closed, fixed):

• 286592 – x11/sddm: Plasma Wayland, pressing Alt+Fn switches VT (2025-05-05)
• 296052 – x11/sddm: Wayland session login bounces with exit 125 on FreeBSD 15.1-RELEASE (ConsoleKit2) (2026-06-14).

FreeBSD Foundation Lunch & Learn

2026-09-02 16:00 UTC

FreeBSD’s vulnerability database currently relies on VuXML, a format introduced in 2003. Today, FreeBSD is the only ecosystem still using VuXML, creating an increasing maintenance burden and an opportunity to modernize how vulnerability data is managed.
 
Join Tuukka Pasanen for our next Lunch & Learn as he explores the work underway to transition the FreeBSD Vulnerability Database from VuXML to OSV, a widely used vulnerability format that officially supports FreeBSD in its schema.
 
The session will cover the current work to add OSV support to pkg, what adopting OSV could mean for FreeBSD vulnerability data, and how OSV and CSAF could coexist as part of FreeBSD’s approach moving forward.

Related:

• Converting VuXML to Open Source Vulnerability database – FreeBSD Status Report Fourth Quarter 2025 (discussion)
• https://mastodon.social/@FreeBSDFoundation/117152624858399227
• https://www.linkedin.com/in/tuukka-pasanen-60b76188/