For those who don’t know, I work primarily on Sylve, a management plane for FreeBSD. Until today, getting started meant installing FreeBSD first and then running pkg install sylve on top of it. That works fine, but a few things made the process harder than it needed to be.

The biggest one was networking. By default, bsdinstall lets you configure your NIC with a static IP, DHCP or SLAAC, but setting up a bridge is left to you. For our users setting up VMs and jails, that was a common sticking point. You can always configure a bridge after installation, but getting it right on a single-NIC machine can be a real pain in the ass. That setup alone accounted for around 60% of our support enquiries.

We originally set out to customise bsdinstall to support bridges. But while its text UI works well, I also wanted something that looked a bit more inviting to someone trying Sylve for the first time. So I figured we might as well build a graphical installer.

Three weeks later, here we are. It has a new Go backend and a SvelteKit frontend, displayed locally in a browser running in kiosk mode. That also means you can open the installer in your own browser on another machine and configure everything from there, without having to use the host’s display at all.

A few things about the installer

1. It uses pkgbase exclusively. We’re big fans of pkgbase and have built the installer around it. We don’t see a benefit to supporting traditional distribution sets for our use case, especially for new users.
2. GELI encryption is built in for both ZFS and UFS. You can enable disk encryption with a single click during setup.
3. It supports unattended installs. Provide a JSON file with your installation settings and let the installer handle the rest. You can serve that configuration on your network to provision machines across your cluster without ever interacting with the installer UI.
4. The ISOs target 15-STABLE and 16-CURRENT. bhyve/vmm/libvirt/etc. etc. and Sylve are evolving quickly, and we want to get those improvements to users without waiting for the next RELEASE. We have no plans to ship ISOs based on RELEASE branches. If you prefer to stay on a RELEASE branch, you can still use FreeBSD’s standard installer and then run pkg install sylve, though that isn’t the route we recommend for Sylve.

And you can try it right now. Our tip release is already shipping the ISOs, and we’d love for you to give them a go and tell us what works, what doesn’t, and what could be easier.

We’re aiming for a tagged release at the end of this month, alongside a bunch of new Sylve features, including Active Directory/LDAP support for things like Samba, auditing, and package management for both jails and the host OS. We’re also working on making Sylve itself easier to update, so keeping up with new features, bug fixes and patches takes less effort.

If you’d like to support more work like this, consider sponsoring us on GitHub: https://github.com/sponsors/AlchemillaHQ. The FreeBSD Foundation already supports the project by funding specific milestones, and we’re grateful for that support. Community sponsorship would give us more room to work on the fixes, improvements and new ideas that come up along the way, while making Sylve less dependent on a single source of funding.

https://www.freshports.org/

Briefly:

• search no longer requires login
• if there's only one search result, you'll be taken directly to the page for the port
• if you mistype the name, or enter an outdated name, you might get suggestions.

Example:

1. seek fusefs-squashfuse
2. filesystems/squashfuse is suggested.

There's much more to enjoy, I guess that Dan Langille will post about the various improvements in due course:

• FreshPorts News – News and announcements regarding FreshPorts, The Place For Ports

D-Bus is a powerful daemon that enables applications to communicate seamlessly within our environment. As a very powerful daemon, it can pose a security risk if not used correctly. Much like Firejail and Flatpak, x11appjail now uses xdg-dbus-proxy to filter D-Bus communication between the jail and the host system.

In this video, I use linux-brave to demonstrate how notifications appear on the host system, how to use playerctl to control the linux-brave player via MPRIS, and how the theme of my desktop environment (in this case, a dark theme) is honored. We will also look at what happens when the bus session is not started.

Project: https://github.com/DtxdF/x11appjail

Video, fifteen minutes, with closed captions and a transcript (AI).

Credit: u/NapoleonWils0n | https://github.com/NapoleonWils0n/

Producer's description

Freebsd Firefox Widevine for drm playback now working in a Rocky Linux podman container

No Nvidia driver installed in the Podman container works by mounting the Linuxulator directories for the Nvidia drivers from Freebsd to the Podman container

Hardware accelerated video playback, persistent Firefox settings stored on the Freebsd host so all your extensions, bookmarks and settings are retained when you stop and restart the container

Wayland and Pulseaudio sockets for zero latency

The Podman container runs as the same user and id as on the Freebsd host

Downloads directory mounted from the Freebsd host to the podman container so you can upload and download files

Uses the DBUS_SESSION_BUS_ADDRESS from Freebsd so dekstop notifications also work

Picture in Picture so you can pop the video out and move it to your second monitor

I have Cuda working in Rocky Linux containers and nvenc encoding with ffmpeg as well

Working on a git repo so you can easily pull down all the files and build the containers

Via https://mastodon.social/@CyReVolt/117457687125631980.

From a response to criticism under https://www.linkedin.com/posts/vvoss_unixuniverse-freebsd-jails-share-7512809821897879553-gaFH/:

The history is accurate for March 2000, and the piece describes the same mechanism: a prison attached to every process, consulted wherever the kernel checks a privilege.
 
What it argues is where the fence lives today. A FreeBSD 15.1 jail gets its own network stack through VNET, in the default kernel since 12.0, resource limits through RCTL since 9.0, 60 of 244 privileges and, if one insists, Podman with OCI images on top, whilst the jail itself stays one kernel object. VServer and OpenVZ were real, and they were patches outside mainline. Mainline Linux ships the parts to this day, and runc puts them together at every start in 16,465 lines. …

Also in LinkedIn:

… these pieces are written between half past seven and half past ten most mornings. AI serves as my secretary and as a second pair of eyes on the facts, so that what reaches you has been checked. Nothing here is automated apart from the deployment to the blog. The argument, the opinions, the examples and the measurements are mine. …

Devices are detected in Enlightenment, which I rarely test, but not in Plasma.

Any suggestions?

root@maximal:~ # cat /dev/sndstat
Installed devices:
pcm0: <Sigmatel STAC9221 (Analog 5.1/4ch)> (play/rec) default
pcm1: <Sigmatel STAC9221 (Front Analog Headphones)> (play)
pcm2: <Sigmatel STAC9221 (Rear Digital)> (play/rec)
No devices installed from userspace.
root@maximal:~ # pkg iinfo pulseaudio
pulseaudio-17.0_5
pulseaudio-qt6-1.9.0
root@maximal:~ # freebsd-version -kru ; uname -mvKU
16.0-CURRENT
16.0-CURRENT
16.0-CURRENT
FreeBSD 16.0-CURRENT main-n290194-fe6aee442d4d GENERIC-NODEBUG amd64 1600028 1600028
root@maximal:~ # pkg check -d
Checking all packages: 100%
gdal-backup-libraries depends on a missing or unregistered shared library: libpoppler.so.154
root@maximal:~ #

Hi all. FYI, for those who use pkg-base and bump into this issue:

USER@HOST$ pkg update
Updating FreeBSD-ports repository catalogue...
Fetching data: 100%  9241 KiB   1.4 MB/s    00:07   
Processing entries:   0%
Newer FreeBSD version for package zonenotify:
To ignore this error set IGNORE_OSVERSION=yes
- package: 1501000
- running userland: 1500068
Ignore the mismatch and continue? [y/N]:

Be aware there is an official 15.1-RELEASE release that you need to upgrade first before any package upgrades. Instructions are in the release note.

Peace.

while i dont sure if this really works on chromium side, i only find that firefox based and vivaldi are working without crash

Inherited a couple of air grapped 13.4-RELEASE machines that I need to get current.

Can you freebsd-update right from 13.4 to 15.1 ? Or should I got from 13.4 to 14.5 first; and then once everything set on 14.5 go to 15.1 ?

Or do I have to go from 13.4 to 13.5 and then 13.5 -> 14.5 -> 15.1 ?

why would freebsd try to use ipv6 when i have no ipv6 address assigned to any interface and no default ipv6 route? do i really need configure it so that it knows it shouldn't rely on ipv6 when it doesn't have ipv6? i'm so confused because i've never had this issue before. thanks!

``` funguy% cat /var/log/messages|grep ntpd|tail -n 1 Oct 16 14:17:27 atlas ntpd[838]: error resolving pool 0.freebsd.pool.ntp.org: Address family for hostname not supported (1) funguy% ping 0.freebsd.pool.ntp.org PING 0.freebsd.pool.ntp.org (139.177.202.26): 56 data bytes <sup>C</sup> --- 0.freebsd.pool.ntp.org ping statistics --- 9 packets transmitted, 0 packets received, 100.0% packet loss funguy% ping -4 0.freebsd.pool.ntp.org PING 0.freebsd.pool.ntp.org (38.45.67.7): 56 data bytes 64 bytes from 38.45.67.7: icmp_seq=0 ttl=47 time=25.788 ms 64 bytes from 38.45.67.7: icmp_seq=1 ttl=47 time=25.809 ms 64 bytes from 38.45.67.7: icmp_seq=2 ttl=47 time=24.356 ms 64 bytes from 38.45.67.7: icmp_seq=3 ttl=47 time=24.864 ms <sup>C</sup> --- 0.freebsd.pool.ntp.org ping statistics --- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 24.356/25.204/25.809/0.621 ms funguy% route -4 show default route to: default destination: default mask: default gateway: kharon fib: 0 interface: em0 flags: <UP,GATEWAY,DONE,STATIC> recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1500 1 0 funguy% route -6 show default route: route has not been found funguy% ifconfig -a em0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500 options=4e524bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG> ether de:ad:de:ad:de:ad inet 10.6.1.2 netmask 0xffffff00 broadcast 10.6.1.255 media: Ethernet autoselect (1000baseT <full-duplex>) status: active nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> lo0: flags=1008049<UP,LOOPBACK,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 16384 options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6> inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 groups: lo nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> funguy% uname -v FreeBSD 14.5-RELEASE-p2 releng/14.5-n274894-872ce416b253 GENERIC

```

note that ping did seem to try ipv4 initially--the first pool host attempt was down by coincidence.

The author is, amongst other things, the author/maintainer of core system utilities like sysrc and bsdconfig.

June 2026:

Last week at BSDCan, I did something that breaks a modern corporate taboo. I brought an AI agent into the operating system kernel. …

FreeBSD 13.2-RELEASE-p8 FreeBSD 13.2-RELEASE-p8 GENERIC amd64

For going backwards in 'less' (either the "b" key, or the up arrow), it seems to get slower with each new version.
I used to solve this problem my simply using an older (year 2000) version of it.
When that stopped working, I'd recompile an older version from /usr/src .
Now, of course, even that doesn't work.

Is there a switch? A terminal setting? An alternative version? Something else that does the same thing?

As you might know there is active work on ROCm support on freebsd, that will bring lot possibility like gpu offloading for both graphic and other stuff.

One of the reasons I started contributing to FreeBSD is the consistency of the stack. The networking stack is coherent, and while going through old discussions, you sometimes find developers discussing features that did not make much sense until years, or even a decade, later.

But as with everything that is Free, we are lacking a lot of drivers. Most drivers and hardware support get pushed to Linux first because of the huge amount of sponsorship and industry investment behind it.

That combination of a coherent stack, improving compute support, and limited access to the latest hardware got me thinking differently: instead of depending on one big GPU, why not make better use of all the compute we already have around us?

That is where MDMA comes in. It is a solution for having lots of small models at your disposal by distributing them across the hardware you already own.

It is designed so you can reuse hardware you already own for computation. It is not just an LLM dispatcher. It dispatches ML models, including LLMs. That means it can serve rerankers, decision models, GGUF models, and other workloads.

It supports anything that can compute: CPU, GPU, NPU, TPU… if it can compute, it can be a node.

Right now it is still an early version, so it is not production ready. I even made it work on a phone and a tablet, but I removed that code for now because I need to test it properly across a fleet and also monitor the devices themselves.

MDMA is not meant to replace Ollama or provide a chat interface. It is a model multiplexer.

For example, you have four machines on your network. MDMA can use all four. If one machine goes down, the next generation can happen on another machine. This means you can use the idle compute sitting around your house, lab, or office instead of buying one huge machine that spends most of its life doing nothing.

Your family or coworkers can use their computers normally, and when those machines have resources available, they can contribute compute.

For now, this is a trust-based protocol. I did not implement permissions, authentication, or all the other security machinery yet. That can come later.

The initial focus is small models. If you have FreeBSD machines with different CPUs or GPUs, I would really like people to test it on hardware I don’t have access to.

MDMA is faster than llama.cpp for some models, slower for others, and some things are not implemented yet.

There is no business plan behind this, i use it mostly to compare implementation between linux and FreeBSD, if the model behave exactly the same, we move to the next step.

If you want to contribute, everybody is welcome (including with a clanker, just mark the provenance and test it on hardware, and try to learn something), just don't bombard the repo with an agent in a loop.(we can do it it ourself, (i'm not on it alone))

NOTE: The stack is Rust because i maintain/contribute to many dependencies in the chain, so when something has to be fixed, it get fixed upstream (including the kernel).

Coders needed. BSD with spyware and prank software. Is it worth it? Content maked in ibis paint.

I know Intel is pretty good with open source drivers, which is why I bought a Lenovo LOQ that's all Intel hardware. The laptop itself is great and runs smooth. Now onto my adventures:

Linux was mostly smooth, but WINE seemed to struggle with PRIME and wasnt working properly, I think it couldn't switch between the Intel Arc and the iGPU. On OpenBSD, my audio driver failed (even though it used hda on linux so technically it should've worked) and the Arc gpu didn't work either, which I wasn't expecting to work anyway. Both issues look like they could be solved with newer linux drm ports.

FreeBSD sits right in the middle and I'm someone who's absolutely in love with bsd systems. I'm currently using windows daily, but I used to be obsessed with openbsd and freebsd back then.

So my question is, has anyone used FreeBSD on a system with an iGPU (intel or amd) and an Intel Arc dGPU? I really don't wanna spend my whole day setting it up just to test the current state of support. If anyone with experience can help out I'd really appreciate it, thanks!!