Daemonarchy: FreeBSD Gets an Omarchy-Style Desktop Experience

on

By the end of this piece you will have a clear picture of what Daemonarchy is, how it was built, which architectural choices it makes under the hood, and what the project signals about the convergence of BSD and modern desktop Linux workflows.

The Origin and AI-Assisted Development

Jordan Hubbard, one of the three people who started FreeBSD in 1993, built Daemonarchy with the assistance of GPT Astra 6. The project name is a deliberate play on Omarchy, substituting the BSD daemon for the Arch in the base system. The stated motivation came from repeated requests on LinkedIn asking why FreeBSD could not be as straightforward to install and as visually polished as Omarchy. Hubbard's response was to ask whether something already existed that did this, and to build it.

The first working pass was completed in under two hours of AI-assisted work, though that figure explicitly excludes the Poudriere build cycles used to validate the result. GPT also selected the project name. Daemonarchy is only a few weeks old and has already shipped multiple releases, with v1.3.1 appearing within hours of this article's source being written. For context, Omarchy itself has grown from a one-command script for Arch into a full ISO-based installer that has attracted substantial funding, so the bar it sets for a "flavoured" experience is not trivial.

This is notable not because of the speed itself but because it demonstrates that a foundational BSD figure is comfortable using a large language model as a primary development tool for a system-level project. The distinction between the AI-assisted initial pass and the subsequent Poudriere validation is important: the AI generated the structure, but the FreeBSD build infrastructure still had to verify it. That separation between generation and validation is the pattern that will matter as these tools mature in infrastructure work.

Architectural Decisions That Matter

Daemonarchy runs on FreeBSD 16.0-CURRENT. Because the CURRENT branch moves daily, each release image is pinned to a specific snapshot. This is a practical necessity rather than a design choice, but it has implications: users are not on a stable release branch, and the project must track upstream changes that can break the desktop stack at any time. The pinning mechanism means that a given image is reproducible, but it also means the project cannot simply say "install the latest FreeBSD and you will get the same experience."

The storage layer is ZFS with rollback support and optional encryption. The installer can target an entire disk, a partition, or free space the user selects, with a minimum of 40 GB required. A whole-disk installation wipes the drive; partition mode overwrites only the selected partition. The installer does not shrink existing filesystems, so anyone planning a dual-boot configuration must free up space from the other operating system before running the Daemonarchy installer. ZFS rollback support means that a failed update or a broken package change can be reverted at the filesystem level, which is a meaningful safety net on a CURRENT-based system where breakage is more likely than on a stable release.

The desktop is Omarchy itself, ported with only the changes FreeBSD requires. Hubbard credits the Wayland, Hyprland, and Arch Linux projects for the layers the desktop sits on. This is significant: the visual and interaction layer is not a reimplementation but a direct port, which means the user experience is intentionally identical to Omarchy's. The differentiation is entirely in the base system beneath it.

The Compatibility Layer and Its Implications

The most technically interesting component is the compatibility layer. It maps pacman to pkg, meaning that scripts and workflows written for Arch-based systems that invoke pacman will be redirected to FreeBSD's native package manager. The Wi-Fi panel is backed by wpa_supplicant rather than NetworkManager, and PipeWire handles audio.

The pacman-to-pkg mapping is the most consequential of these three. It means that automation, provisioning scripts, or package management workflows that assume pacman can be run on a Daemonarchy system without modification at the command level. For an admin managing a fleet where some machines run Arch-based systems and others run Daemonarchy, this reduces the branching logic in scripts. It does not mean all Arch packages will resolve identically, but the interface is unified and the mental model is preserved.

The choice of wpa_supplicant over NetworkManager is a deliberate simplification. NetworkManager brings a D-Bus daemon, a plugin architecture, and a configuration model that has historically been a source of friction on BSD systems. wpa_supplicant is a single-purpose daemon with a well-understood configuration format. For a desktop distro that prioritises a clean install experience, this trades some of NetworkManager's flexibility for operational simplicity.

PipeWire for sound is the same choice made on modern Linux desktops, so users coming from Omarchy or any current Arch-based desktop will find no difference in audio behaviour.

What This Means for the Ecosystem

The ports that Daemonarchy required were submitted upstream to FreeBSD's ports tree for review. This is the detail that extends the project's impact beyond its own user base. Once those ports are accepted, any FreeBSD user can install the same desktop stack without running Daemonarchy. The project effectively serves as a demanding consumer of the ports tree, pushing for the packages and dependencies that a modern Wayland/Hyprland desktop requires, and doing so under the scrutiny of the FreeBSD security team.

For system administrators, the practical takeaway is that FreeBSD now has a path to a modern desktop that does not require manually assembling a Wayland compositor, a tiling window manager, and a full set of supporting packages. The 40 GB minimum and ZFS rollback support make it reasonable to evaluate on a test machine without significant risk. The CURRENT-based foundation is the main caveat: this is not a stable-release product, and the project's release cadence is tied to how quickly it can re-pin to a working snapshot.

For developers working on FreeBSD ports, the project demonstrates that the ports tree can support a full modern desktop stack. If the ports are accepted upstream, they become available to every FreeBSD user, not just Daemonarchy installers. That is a broader ecosystem benefit than the distro itself, and it positions FreeBSD as a viable target for the same desktop tooling that the Arch ecosystem has driven forward over the past several years.

Source: feed.itsfoss.com

Read more
Post a Comment
Subscribe to: Posts (Atom)

Popular Posts

Install Ollama and Open WebUI on Ubuntu 24.04 with NVIDIA GPU Acceleration (Step-by-Step)

Overview Running a local large language model (LLM) is easier than ever thanks to Ollama and Open WebUI. Ollama handles model downloads and inference, while Open WebUI gives you a clean, chat-style interface in your browser. In this tutorial, you'll install both on Ubuntu 24.04 (works on 22.04 too), enable NVIDIA GPU acceleration, and deploy them with Docker Compose. The result is a fast, private AI stack you control. What You'll Need - Ubuntu 24.04 or 22.04 (fresh or existing server/desktop). - An NVIDIA GPU with recent drivers (Turing/RTX or newer recommended). - Root or sudo access. - Open ports 3000 (Open WebUI) and 11434 (Ollama) on your firewall if you access remotely. Step 1: Install NVIDIA Drivers and Verify CUDA First, update your system and install the recommended NVIDIA driver. On Ubuntu Desktop you can use Additional Drivers, but the CLI route is reliable: sudo apt update && sudo apt -y upgrade sudo ubuntu-drivers autoinstall sudo reboot After reboo...

Install a Local AI Chatbot on Ubuntu 24.04 with Ollama and Open WebUI (Step-by-Step)

Running a fast, private AI chatbot on your own computer or server is easier than ever. In this guide, you will install Ollama (a lightweight local LLM runtime) and Open WebUI (a modern web interface) on Ubuntu 24.04 . You will be able to chat with models like Llama 3 or Mistral without sending data to the cloud, and with optional GPU acceleration if you have an NVIDIA card. What you will need : an Ubuntu 22.04/24.04 machine (VM, bare metal, or WSL), at least 8 GB RAM (16 GB recommended for larger models), 15–30 GB free disk space for models, Internet access, and optional NVIDIA GPU drivers for acceleration. Why Ollama + Open WebUI? Ollama manages local large language models (LLMs) with simple commands and sensible defaults. Open WebUI gives you a clean, chat-style interface with features like prompt history, file uploads (for some models), and model switching. Together, they are a simple, reliable stack for a self-hosted AI experience. 1) Update Ubuntu and install basics First, ...

Install Ollama + Open WebUI on Ubuntu 24.04 with NVIDIA GPU Acceleration (Step-by-Step)

Overview This guide shows you how to install Ollama and Open WebUI on Ubuntu 24.04 with NVIDIA GPU acceleration. You will get a fast local AI stack that can run modern large language models (LLMs) like Llama 3 on your own hardware, secured and accessible in a web browser. We will cover GPU driver setup, Docker with the NVIDIA Container Toolkit, Ollama installation, Open WebUI deployment, basic security, and troubleshooting. Prerequisites - A machine running Ubuntu 24.04 (fresh or updated). - An NVIDIA GPU with at least 8 GB VRAM recommended for 8B models (more is better). - Internet access and sudo privileges. Step 1: Install the NVIDIA GPU Driver Install the recommended proprietary driver so CUDA becomes available to both Ollama and containers. sudo apt update && sudo apt install -y ubuntu-drivers-common sudo ubuntu-drivers autoinstall sudo reboot After reboot, verify the GPU is recognized: nvidia-smi You should see a driver version and your GPU model. If not, check...

Trending Now

Daemonarchy: FreeBSD Gets an Omarchy-Style Desktop Experience

on
By the end of this piece you will have a clear picture of what Daemonarchy is, how it was built, which architectural choices it makes under the hood, and what the project signals about the convergence of BSD and modern desktop Linux workflows. The Origin and AI-Assisted Development Jordan Hubbard, one of the three people who started FreeBSD in 1993, built Daemonarchy with the assistance of GPT Astra 6. The project name is a deliberate play on Omarchy, substituting the BSD daemon for the Arch in the base system. The stated motivation came from repeated requests on LinkedIn asking why FreeBSD could not be as straightforward to install and as visually polished as Omarchy. Hubbard's response was to ask whether something already existed that did this, and to build it. The first working pass was completed in under two hours of AI-assisted work, though that figure explicitly excludes the Poudriere build cycles used to validate the result. GPT also selected the project name. Daemonar...