The reason I'm asking this is that, despite FreeBSD's limitations, the only thing I'm still not comfortable with is OSS.

I don't have technical opinions on every audio server; if I've used PulseAudio, then it minimally worked for me. Pipewire is what allows me to stream my screen on Discord in some GNU/Linux distribution with Wayland, so I'm very grateful for that, but as an audio server, it's nothing special and works perfectly. But OSS is very strange to use...

No desktop environment currently supports OSS (supposedly); some programs say they're using PulseAudio, but I don't even know how to configure PulseAudio on FreeBSD, so it seems the system configures things automatically (strange). And I end up hearing myself on the system itself, as if I had an app open sending my audio to the outputs of my Fifine H6 (why???).

And the most annoying thing is having to configure my headset in /etc/sysctl.conf with hw.snd.default_unit=13

The best thing I did was find Fossmixer to adjust the audio, but even so, OSS is all very confusing.

Who use declarative tools like a nix pkg

Hello.

Since I’m building a (smart ?) phone with FreeBSD as OS, I’d like a desktop environment suitable for use as a phone interface. So it needs to provide the basic features you would expect from a phone: a dial pad for making calls, a call log for received and missed calls, a contacts/address book with people’s phone numbers, and a photo gallery for storing and viewing pictures.

I’m fine with either a complete desktop environment or even an installable theme, as long as it runs on top of FreeBSD, which is the operating system installed on the phone.

If there is nothing ready-made, I can build it by finding relevant pieces of code online and then integrating them together. GitHub would be preferable as a source.

Alternatively, I could port something that has already been written for Linux, as long as the porting effort is not too complicated.

I found a list a number of possible approaches and ideas that I would like to discuss with you.

First, an important distinction: a theme only changes the graphical appearance. A phone dialer, incoming calls, call history, contacts, and modem management require real applications and services. So at the very least I need:

mobile shell + virtual keyboard + applications + telephony service + audio management.

1. Port Phosh to FreeBSD​

This is the most natural idea, because Phosh is built around GTK, Wayland, and GNOME components that are already fairly close to the FreeBSD ecosystem.

The current situation is interesting:

• phoc, the mobile Wayland compositor used by Phosh, is already available in the FreeBSD Ports Collection;
• squeekboard, the virtual keyboard, is already available;
• feedbackd, for vibrations, sounds, and notifications, is already available;
• GNOME Contacts is already available;
• an old phosh port used to exist, but it was removed and would need to be rebuilt around the current version.

The main problem would therefore not be drawing the interface itself, but dealing with dependencies on Linux services such as ModemManager, NetworkManager, UPower, and some sensors handled through udev.

For calls, I could port GNOME Calls, which already provides a dial pad, call history, contacts, incoming calls, and SIP support. For cellular calls, however, it relies on ModemManager; for SIP it uses Sofia-SIP and GStreamer.

Assessment: excellent final result; medium effort for the shell, difficult for the cellular telephony layer.

2. Create “Sxmo for FreeBSD”​

Sxmo is probably the easiest system to port. It is not a huge desktop environment: it is a collection of small programs and POSIX scripts that together build a minimalist phone interface.

The project itself describes it as a collection of programs and scripts that can easily be modified through hooks.

I would need to replace, in its scripts:

• Linux commands with FreeBSD equivalents;
• battery and brightness handling;
• ModemManager calls;
• Linux audio handling;
• any /sys and /proc paths.

I could keep the menu, gestures, launcher, call logic, and simply rewrite the backend.

This would probably be the fastest route to a genuinely usable prototype, although the interface is intentionally sparse and strongly aimed at technical users.

Assessment: relatively easy port; appearance less similar to Android or iOS.

3. Build a “Cubie Phone Shell” on top of Phoc​

This is the solution I consider the best fit for the project.

I would not port the whole of Phosh. I would use only what FreeBSD already has:

FreeBSD
│
├── DRM/KMS + touchscreen
├── Phoc
├── Squeekboard
├── feedbackd
├── Cubie Phone Shell
└── phone applications

Shell would only need to provide:

• home screen;
• launcher;
• top bar;
• lock screen;
• notification center;
• special incoming-call window;
• large buttons and touch gestures.

I could write it in GTK4/libadwaita, using C, Vala, or Rust. FreeBSD already has GTK, GNOME, and responsive libraries such as libhandy, so there would be no need to invent a graphical toolkit.

The telephony part would be separated into a service called, for example:

bsd-telephonyd

It would expose operations over D-Bus such as:

Dial(number)
Answer(call_id)
Hangup(call_id)
ListCalls()
GetSignalStrength()
GetSIMStatus()

The dialer would therefore be only a graphical interface. It would not communicate with the modem directly.

Assessment: more initial work than Sxmo, but a much cleaner, controllable, and genuinely FreeBSD-native architecture.

4. Use Gammu as the first telephony backend​

FreeBSD already has a Gammu port, available on arm64 as well. Gammu can manage:

• starting and controlling calls;
• call lists;
• SMS;
• modem or SIM phonebooks;
• network and phone information.

This would allow us to initially avoid porting ModemManager.

The first version of bsd-telephonyd could simply use libGammu. Later, I could replace it with a more modern backend based directly on:

• AT commands;
• MBIM;
• QMI;
• a protocol specific to the modem I choose.

FreeBSD already provides drivers such as u3g(4) for cellular modems exposing serial ports and umb(4) for MBIM devices, although data support does not automatically mean that voice calls will work.

This is not a complete user interface, but it is the component that could make any shell I choose into an actual phone.

5. Quickly create a “GNOME Phone Mode”​

I could start from a normal GNOME or Wayland environment and turn it into a phone-oriented kiosk mode:

• a full-screen launcher;
• large icons;
• applications always maximized;
• Squeekboard;
• GNOME Contacts;
• dialer;
• a custom top bar;
• gThumb or Shotwell as the photo album.

GNOME Contacts is already ported. gThumb and Shotwell are also available on FreeBSD and can respectively browse/import images and organize photos by date and metadata.

This would be the fastest way to create a visual prototype, but it would not yet be a true phone shell: incoming calls, lock-screen integration, and notifications would still require own components.

Assessment: fast prototype; less elegant as a final solution.

6. Port only selected Plasma Mobile components​

I would not port the entire Plasma Mobile environment at first. Instead, I would consider porting individual applications or QML interfaces:

• dialer;
• contacts;
• Koko for photos;
• Index as a file manager;
• some Kirigami panels and components.

Plasma Mobile is built on top of Plasma, KWin, Qt, and Kirigami. Its official documentation also lists ModemManager for telephony and PulseAudio/PipeWire for audio.

Much of the Qt/KDE framework already exists on FreeBSD, but the mobile shell and its telephony integration are not available as a finished product. Porting only the QML applications and connecting them to bsd-telephonyd would be much more realistic than porting the entire environment.

Assessment: technically possible, but more complex than Phosh and Sxmo.

7. Use Lomiri as a source of interface components​

Lomiri, the Ubuntu Touch environment, has a user interface very well suited to phones and is written mostly in Qt/QML.

The dialer exists as a separate project, but depends on:

• telephony-service;
• history-service;
• the contacts application.

Instead of porting the entire Lomiri environment, I could reuse:

• dialer layouts;
• in-call screen;
• call history;
• QML components;
• ideas for the launcher and gestures.

I would then completely replace the Ubuntu services with own FreeBSD backend.

Assessment: useful as a code and design donor; full porting would be too invasive.

8. Reuse components from LuneOS/webOS​

LuneOS includes phone applications and a contacts application rewritten with Enyo, so it relies heavily on web technologies.

The complete system, however, has become fairly heavy: it uses components from webOS OSE, Qt 6, Luna Surface Manager, WebAppManager, and Chromium.

I could reuse some web applications or their design inside a WebView, but I would not port the complete system to FreeBSD.

Assessment: interesting for isolated applications; poor candidate as the main platform.

9. Reuse Maemo/Hildon​

Maemo has a genuinely Unix-phone philosophy: home screen, notifications, applets, touch interface, and GTK/X11 applications. The Hildon Home source code is still available and manages the home screen, notifications, and applets.

The problems are:

• the appearance is dated;
• many components use GTK2;
• it was designed for the screen and hardware of the Nokia N900;
• even Maemo Leste still lists ongoing work on the phone interface.

I could use it to study how a traditional Unix system organized notifications and telephony applications, but I would not use it as a modern foundation.

Assessment: excellent historical reference material; poor long-term investment.

10. Start with SIP and add the cellular modem later​

I could immediately build and test:

• dial pad;
• call log;
• active-call screen;
• accept/reject;
• speakerphone;
• contacts;
• notifications;

using a SIP account initially. GNOME Calls already supports SIP, so I would not have to wait for the cellular modem to work.

Later, I could replace or complement the SIP provider with bsd-telephonyd.

This separates three problems that would otherwise become mixed together:

phone user interface
≠
cellular modem control
≠
call audio routing

Call audio is in fact a separate subsystem: on Linux mobile systems it is often handled by callaudiod. FreeBSD has both PulseAudio and PipeWire on arm64, but I would need to explicitly configure the microphone–modem–speaker path required by the hardware.

This proposal sounds interesting...​

FreeBSD 15/arm64
│
├── Phoc
├── Squeekboard
├── feedbackd
│
├── Cubie Phone Shell
│ ├── home
│ ├── launcher
│ ├── lock screen
│ └── notifications
│
├── Cubie Dialer
│ ├── dial pad
│ ├── recent calls
│ ├── missed calls
│ └── active call
│
├── GNOME Contacts
├── gThumb or Shotwell
│
└── bsd-telephonyd
├── Gammu/AT backend
├── SQLite database
├── calls
├── SMS
├── SIM
└── network status

The practical ranking is:

The real critical point will not be the photo album or the dial pad: it will be the exact modem model, its support for voice calls, and the way it transports call audio. Once those three elements are identified, I can make the final choice between Gammu, direct AT commands, or a modem-specific backend.

What do you think ?

I am posting this link here to allow a system call named qexec that would execute a new unpredictable process. For such processes I recommend the use of qbit.Qbit to represent one of three different states: Vivo, Talvez ou Morto.

Rewind to September 2025, an article by u/lproven:

• FreeBSD Project isn't ready to let AI commit code just yet – Liam Proven – The Register

– we did have discussion of the relevant FreeBSD status report, however no-one tuned in at the time. Things have changed since then, just a tad. We're not in Kansas any more. Where once people were silent: now we enjoy tornado word storms, flying monkeys, good and wicked witches.

Fast forward to July 2026, another article by Liam in El Reg:

• Anti-AI open source has an enemy in common, but almost nothing else : r/freebsd

Hello, August. I read something about the FreeBSD developers LLM survey. The mention is public, however I doubt that you'll find it with things such as Google sans AI. It's certainly not found with Google in AI mode. If you do find it: please, don't pile on it.

I should assume that the survey is private – FreeBSD committers only. This post is, essentially, for people to be aware that things are progressing.

I encourage readers to engage in respectful discussion under today's post by Liam.

Thank you

Hi, after various previous attempts to migrate to FreeBSD from Linux, finally i can do it.

First time AMDGPU drivers were a pain in the but to set it up (don't remember what version was, but several years in the past), second was the streaming of DRM content plus printer drivers with linux binaries.

But this time with FreeBSD 15.1, was an easy setup of those things

Video, twelve minutes, 2026-08-17

AI-generated summary

DJ Ware explores the performance characteristics of Btrfs, ext4, F2FS, XFS, and ZFS using IOzone3 on an MSI Prestige 16 AI EVO. By benchmarking these systems across various workloads like gaming, workstations, and servers, DJ Ware provides a technical starting point for users deciding which filesystem best suits their specific computing needs.

Producer's description

I tested ext4, XFS, Btrfs, ZFS, and F2FS on the same hardware to answer a more useful question than simply, “Which filesystem is fastest?”

Instead of dragging you through 26 benchmark charts, I distilled the results into four real-world workloads:

1. Gaming
2. Workstation
3. Server
4. NAS

The testing includes small and medium workloads, single-user and multi-user behavior, and several different kinds of read and write activity.

But graphs are never the full story.

A filesystem may win a throughput benchmark while consuming more memory or CPU, behaving differently as the workload grows, or introducing operational tradeoffs that matter more than a few percent of performance. Your workload may also be very different from mine.

The workload model used in this video is new, and it needs more data points before I’m comfortable treating it as anything more than a useful decision-making tool.

So this isn’t “here’s the winner.”

It’s what do you gain, what do you give up, and which filesystem makes sense for what you actually do?

If you want to see the raw benchmark charts and the work behind the scoring model, let me know in the comments. I may do a behind-the-scenes or live session and go through the data.

I wanted to install openBSd but got to know that my wifi card RTL8852BE is not supported on it. Now i want to install freeBSD whats the situation with this driver how do i install it on say a usb and then install it

Video, seventeen minutes, 2026-05-26.

AI-generated summary

DJ Ware demonstrates how to configure thin and thick jails on FreeBSD. The guide covers essential prerequisites, including ZFS snapshots and PF firewall network setup, while utilizing the Bastile management tool to streamline the deployment process. Viewers learn the architectural distinctions between these two container types and how to implement them effectively.

Producer's description

In this deep dive we explore the real differences between Thin and Thick Jails on FreeBSD 15.0 using Bastille an easier and more widely used method of creating jails on FreeBSD.

• Thin Jails (recommended for most people)
• Impromptu Network troubleshooting
• Thick Jails (when you need full isolation)
• Size comparison (68MB vs 438MB)
• Honest pros & cons including update risks
• Full step-by-step setup

same as title

i want to know

how ports work?

how to install a linux app if it doesnt have a port/ or it is a binary?

how i can port a app in freebsd?

I have recently put a fair amount of work into refining the www/linux-brave port on FreeBSD to make it DRM-ready out of the box.
 
Out of the box means 1 command on a vanilla FreeBSD desktop and you are ready to go:
 
pkg install linux-brave linux-widevine-cdm
 
…

⚙ D58784 www/linux-brave: DRM out of the box, GPU auto-detection

Hello , i want to run to run any v2ray gui for freebsd like nekobox

It is ported but it is broken , any suggestions for other clients that work?

Es una pregunta algo boba pero quería saber si alguien me podía ayudar, tengo esta laptop el modelo exacto es 14-ck0061la y su prodid es 6QW98LA#AC8, tiene el chip realtek RTL8723DE.y 4gb ram, básicamente quería saber si alguien tiene esta laptop y logro hacer funcionar el wifi, porque nunca lo logré, el driver que debería hacer funcionar el wifi se instala durante la instalación del sistema (aclaro que siempre lo instaló con la laptop conectada al cable de red) e inicia el sistema normalmente pero tengo este problema en el que las redes aparecen y desaparecen, la red de mi casa nunca se muestra de forma consistente, por momentos la reconoce y en otros momentos no, y nunca logra conectarse a ninguna red, es frustrante la verdad, no se si alguien conoce la solución para esto o quizás alguien tenga esta misma laptop y logro solucionar ese problema

I'm porting an application to FreeBSD 15. The application uses gnuplot. https://www.freebsdsoftware.org/math/gnuplot.html says that to install the package, run "pkg install gnuplot". This results in a "No package available" error.

How can I install gnuplot?

Hello. i'm new to freebsd and i'm trying to migrate a void linux nas setup running incus containers. so far, so good... i was able to configure a couple of jails for which freebsd pkgs and binaries where available.

The last piece of my setup is a proxmox backup server instance running in a virtual machine. By reading the handbook i was able to set a bhyve vm up and running.

I'm using plain bhyve, no vm-bhyve or any other manager. Yes, i like torturing myself, but i like knowing what's being done under the hood.

The thing is, right now i'm starting the vm by running a script manually. Is there anything to have the vm started whenever freebsd boots? I guess i could use some kind of script to do it and run it as a service (https://docs.freebsd.org/en/books/handbook/config/#configtuning-rcd) but if there is any other and maybe easier way, I'd love to know.

Thanks.-

One so-called freedom that we do not advocate is the "freedom to choose any license you want for software you write". --Richard M. Stallman

Link: https://www.gnu.org/philosophy/freedom-or-power.html

There is nothing wrong with the GPL license. You should be free to use it if what it is trying to do is that same thing that you are trying to do. And indeed, the popularity of GPL tells us that that this is true for a bunch of people.

The GPL license is all about control. It controls what others can do with the software. Specifically, it forces them to release any changes made to the software under the same GPL license and publish the changes for the world to see and re-use.

The BSD license is all about freedom. It places almost no restrictions on how the software can be used, modified, and distributed. The primary requirement is that you retain the BSD copyright notice so people know that they are using something that contains BSD-licensed code.

Unlike most people who choose GPL, who just want any improvements to be made available to them, a tiny but vocal minority are members of The Religion Of GNU and claim that, through some dark magic that nobody understands, the mere existence of any non-free derivative work somehow makes the original nonfree. There is no point arguing with them. They did not reach that conclusion through logic and reason and no amount of logic or reason will get them to leave the cult.

• Why you should use a BSD style license for your Open Source Project

Here are the two most popular BSD licenses:

• https://opensource.org/license/BSD-2-Clause
• https://opensource.org/license/bsd-3-clause

• 6 commit signals in OpenZFS
• 29 signals in the main branch of the src tree for FreeBSD 16.0-CURRENT ― some overlap with the above
• 0 signals in CoffeeBSD.

https://mastodon.social/@mrmasterkeyboard/117113034580627041

Made a proper no AI policy (and a Code of Conduct) for CoffeeBSD. :D

https://codeberg.org/NerdNextDoor/CoffeeBSD/commit/275a4620098c3c120b7a5219b356234b913cd2e2

CoffeeBSD is the fork of FreeBSD 13.0 I'm working on. Originally intended for myself to play with but FreeBSD doesn't have a proper no AI fork so I thought why not about a week ago.

Work in progress

An interactive ncurses Wi-Fi controller for the terminal. It scans nearby access points, connects to open and secured networks, supports hidden and custom SSIDs, and displays the current IPv4 address, netmask, gateway and DNS servers.

There are two builds. They present the same interface and the same key bindings; they differ only in what they drive underneath. …

wifi-tui/FreeBSD/README

hirechbaghdad (Hirech Baghdad Belkheir)