Jordan Hubbard started FreeBSD in 1993 with two others, and he has now built Daemonarchy with help from OpenAI’s GPT AI model. The name plays on Omarchy, with the BSD daemon taking the place of Arch as the base.
As for Omarchy, it has grown considerably since we initially covered it as a one-command script for Arch. It now installs from an ISO and has managed to pull in massive amounts of funding.
Anyhow, Daemonarchy is only a few weeks old and already has several releases, with v1.3.1 being released a few hours ago.
Why does this exist?
A few people on LinkedIn were pestering Jordan, saying FreeBSD should be as easy to set up and as pretty as Omarchy. That got him wondering, “Why doesn’t that already exist?”
He was testing GPT Astra 6 at the time and used it to put the project together. The first pass took under two hours. That figure leaves out the Poudriere builds used to validate it. GPT also picked the name for the project.
The ports this distro needed went upstream to FreeBSD’s ports tree for review. The same ports also let you install Daemonarchy on top of an existing FreeBSD system.
Jordan also credits the Wayland, Hyprland, and Arch Linux projects for the layers the desktop sits on.
What does it offer?
The installer follows Omarchy’s own, and it asks for the usual basics like keyboard layout, account details, hostname, and timezone.
Daemonarchy can take over a whole disk or settle into a partition or free space you pick, with a minimum of 40 GB of storage required. A whole-disk install wipes the drive, while partition mode overwrites only the partition you select.
Because the installer won’t shrink existing filesystems, anyone dual-booting has to make room from the other OS first. Everything lands on ZFS with rollback support, and encryption is optional.
The desktop is Omarchy itself, ported over with only the changes FreeBSD requires, and it runs on FreeBSD 16.0-CURRENT. Since CURRENT moves daily, each image is pinned to one snapshot.
A compatibility layer maps pacman to pkg, backs the Wi-Fi panel with wpa_supplicant instead of NetworkManager, and uses PipeWire to handle sound. Bluetooth also works for keyboards and mice via FreeBSD’s Bluetooth stack.
Apps come from FreeBSD’s own packages, installed with OctoPkg under Install > Packages or with pkg, and Chromium is preinstalled. Linux-only apps are being held back until specific versions have been tested under the Linuxulator, FreeBSD’s Linux compatibility layer.
Jails give you isolated FreeBSD environments that carry their own packages, and bhyve, the built-in hypervisor, runs virtual machines for guests like Linux and Windows.
And, if you run an upgrade through Omarchy’s update, it applies pkg upgrade to your applications and leaves the FreeBSD base and kernel alone. Daemonarchy’s own packages come from a signed repository and fixes land between ISO releases.
The wallpaper, wordmark, and login theme are the project's own creations.
📥 Get Daemonarchy
The latest 1.3.1 ISO release is a little under 2 GiB. Put it on a USB drive using dd or a live USB tool like Fedora Media Writer, then boot from that.
An internet connection is required during the installation while the installer downloads many packages as it progresses. The source code lives on GitHub.
Before announcing this Linux-based implementation, Amutable had released two open source tools. tine, a Buck2-based build system that composes OS images; available under MPL-2.0, and Quarry, a TUF-based tool that distributes those images to machines; available under Apache-2.0.
What Amutable Foundations brings to the table is a service where Amutable runs the images, update repositories, control plane and vulnerability fixes for organizations and individuals who operate their own systems.
No license has been stated for those company-run parts, and the preview announcement does not say how much of Foundations beyond tine and Quarry will be open source.
The system is immutable, with read-only system volumes protected by dm-verity, signed unified kernel images, and measured boot. Software and configuration both ship as signed images, and a machine boots only what is signed.
Because there is no package manager and no SSH or interactive shell, a change means giving every machine in your fleet a new signed image.
Its images are reproducible, come with an SBOM and are built from pinned inputs of whichever distribution you pick, with tine being able to import packages from Fedora or CentOS Stream.
How machines prove their state
Each machine sends a signed report that records what it booted, from the firmware and boot loader up to the kernel and OS, plus the configuration it runs.
Reports go out at regular intervals and at boot, and the signature is backed by a TPM or a CPU with confidential computing support. Machines without that hardware can fall back to a software key.
Amutable's control plane verifies reports from systemd-report, an experimental command in systemd 260 that the company helped build. It compares each one with the declared state and flags machines that deviate.
A rollout only continues while machines can show they are in a good state. Operators work through a structured interface instead of logging in.
Updates come from per-machine repositories that can link to one another, and downloads are checked against signed metadata for tampering, replay, and rollback attempts.
The same proof is meant to decide access, such as cluster joins and secrets. Amutable's provided example is withholding database credentials from a machine that runs outdated configuration.
Get into the preview
Amutable is looking for teams that manage Linux fleets and need to show what state each machine is in. It expects to start bringing the first 'design partners,' as it calls them, on board over the coming weeks.
Those partners will get early access, a direct line to the developers, and a say in what gets built next. The signup form asks for name, work email, company, role, country, industry, and company size.
Amutable is also targeting Kubernetes next, and if you are eager to learn more about that or Foundations, the team will be present at Booth 347 at this year's KubeCon North America in Salt Lake City.
If you have used Linux for a while, chances are you have used something Mirko Brombin built. He created Bottles, the app that takes a lot of the pain out of running Windows software with Wine. He founded Vanilla OS. And these days, he is building Singularity OS, an operating system with its own desktop and its own approach to immutability.
We last spoke with Mirko back in 2022. A lot has happened since then. He now works full time at fabricators, he is working on getting Microsoft Office running through Bottles, and he has some strong views on AI and on the recent wave of apps cloning Adobe and Microsoft interfaces.
I sent him my questions over email. Here are his answers, exactly as he sent them.
You have full time work at fabricators, Bottles, Sinty OS, and a long list of libraries and tools. How do you decide what gets your time?
I think anyone who's known me for a while knows that I'm not particularly good at sitting still, haha.
I've never really had a proper strategy for deciding what to dedicate my time to. Most of my projects are born from a problem I want to solve, an idea I want to experiment with, or simply the curiosity to find out whether something is possible.
Naturally, working full-time at fabricators and maintaining several open source projects, I've had to learn to set priorities. Not everything can receive the same attention, and not everything necessarily has to become a complete product.
You've written about using AI agents for the mechanical work, so how much has that changed what you can realistically take on?
Artificial intelligence has certainly changed a lot about the way I work, but I think it's important to explain how, because it's a topic I've really spent a lot of time thinking about.
When I wrote my articles about using AI agents in software development, I spent quite a lot of time just trying to find the right words. In open source, it's a particularly delicate subject, especially when you're someone with a fairly public presence and free software isn't just a passion, but also part of your work and your life.
It's very easy to be misunderstood, both by those who consider artificial intelligence the solution to every problem and by those who reject it completely, and honestly... I don't see myself in either position, because I've always had a rather complicated relationship with LLMs. At first I was very skeptical and, frankly, the more I tried to understand how they worked, the harder I found it to fully trust them.
The problem isn't the quality of the code they can produce, but understanding why they produced that particular code, because when I design software, I start from the architecture, I decide how the components should interact, what responsibilities they should have, how to handle errors, which compromises to accept and, logically, which ones to avoid. I document all of this very carefully, because I want to be able to understand every decision even years later, and it's a process I particularly care about and have absolutely no intention of delegating.
I want to give an example. A large part of the applications and infrastructure I develop every day, including for work, is written in Go. Over the years I've built my own set of libraries, defined my own patterns, and developed a fairly precise way of writing software. When I use AI, I don't ask it to invent an architecture, I give it mine, along with the documentation, conventions, and constraints it has to respect. I'm the one who decides how a project is born, how it evolves, and, eventually, when it's time to abandon it.
I still write a great deal of code manually, often because I need to work on particularly delicate components, other times simply because it's faster for me to do it myself. In any case, I review every single line of code written by AI. If it does something badly, it's because I accepted it.
What still doesn't convince me, though, is the very nature of how they work, because a language model can produce a correct answer, it can even explain the steps that seem to have led it to that conclusion, but this is... Well, illogical, at least from my point of view. An LLM can produce reasoning, but it doesn't necessarily possess an explicit, persistent, and causally verifiable representation of the knowledge it uses to express that reasoning. And this bothers me quite a lot.
If an agent decides to use a particular data structure, I want to know whether it did so because my documentation specifies that it's the correct solution, or because that solution is statistically plausible given the context.
To me, these are two very different things, and it's precisely for this reason that, for quite some time now, I've been researching and experimenting with an alternative approach to current language models, a project called Amus, with which I'm exploring a different way of representing knowledge and constructing answers, trying to make the relationships that lead to a conclusion more explicit and verifiable.
I don't want to reveal too much because it's still a research project, but the first results have been really encouraging, and I hope to be able to talk about it publicly in more detail soon.
So, going back to the original question, yes, AI agents have allowed me to take on an amount of work that would have been unthinkable for a single person just a few years ago, but by using them, I've started questioning the very technology they're based on and, well, perhaps that's the best way to describe my relationship with artificial intelligence, haha.
Your site now lists Vanilla OS as community-run. When we spoke in 2022, your goal was to make it sustainable enough to work full-time. What happened along the way, and how did it feel to step back from something you founded?
Not much has changed on this front. Vanilla OS continues to be maintained, it receives updates, especially when it comes to security and stability.
We recently released Vanilla OS 3 Reunion, which involved a huge amount of work to bring ARM support, along with writing the Vanilla OS SDK, which we used to rewrite many of the fundamental components of the operating system, so that everything could share a single common foundation.
Today, the project doesn't depend on my hands alone. There are several team members who make all of this possible, plus fabricators, which maintains its server infrastructure, and let's not forget all the contributors who report problems and provide solutions.
Over time, I've taken on a different role. I certainly still develop, in fact I developed Vanilla OS Continuity, the backup system included in Vanilla OS 3 Reunion, but... My role has started to become more political, both from the perspective of someone who finds ways to keep the project financially alive and from the perspective of making decisions about the architecture the project is built upon.
In short, I'm still holding the reins of everything :D
When you started Bottles in 2017, Wine, PlayOnLinux, and Lutris already existed. What gap did you see that made you build another one?
Well, probably because I wasn't satisfied with any of the three, haha.
Jokes aside, when I started Bottles, Wine was already an extraordinary technology, and PlayOnLinux and Lutris offered very useful tools to simplify its use. Actually, a special shout-out to Mathieu: "Hey look, I'm on It's FOSS, again!" D:
But none of them matched exactly my idea of "simplicity". My goal wasn't simply to create another launcher or a tool to install programs, but rather an environment where I could manage my applications without constantly having to touch the command line or place various DLLs here and there...
I've always found it curious how, in the Linux world, people so easily accepted the idea that technically complex tools necessarily had to be complicated to use as well. I think it's a stereotype, but also a fairly widespread one. The internal complexity of an application shouldn't automatically become the user's problem, and I'm saying this knowing that underneath Bottles there's literally a tangled mess making everything work.
And well, it's the same reason why I'm announcing Raven 😄
Many FOSS folks would say the effort is better spent improving LibreOffice or ONLYOFFIC. Why is getting Microsoft's own suite running worth it to you, given that Microsoft could break it with any update?
Frankly, I don't understand why the two things should be mutually exclusive. LibreOffice, ONLYOFFICE, etc. are fantastic pieces of software that I recommend first and foremost to anyone wanting to move from Windows to Linux.
But I can't be blind either. I see it every day at work. In my office I have the privilege of using whatever I want (mainly Singularity OS with its office suite), but almost all of my clients and partners use Microsoft Office for one reason or another, for support, certification, and all those things that a user less immersed in this kind of working environment might not see.
I'm the first to say that users should have a choice, and I create those choices myself... But that's the ideal world. The real world is that sometimes we simply can't afford to make the choices we'd like to make.
MS Office running on Linux with Soda project
Will this stay a Bottles thing, or do you expect the fixes to go upstream into Wine so that other projects benefit too?
My goal is to contribute as much as possible upstream. We'll have to see whether the Wine developers like my patches though, haha.
Jokes aside, I want this work not to remain something specific to Bottles. I'd like it to be adopted upstream.
First of all, I need to reach a point where Microsoft Office 365 works reliably, then I'll find a way to collaborate upstream. It would be pointless to do it now.
There's also a wave of apps that clone Adobe and Microsoft tools almost one-to-one. Is copying familiar interfaces the right way to win people over, or does Linux need its own ideas? And how do you see their effort of bringing MS Office clone to Linux?
Honestly, this is the recent news I like the least, I have to be honest. I've made some tweets about it, I don't like how the identity of other people's products is being violated.
There's talk of clean room... But objectively, what's the point of talking about clean room if you then unleash a swarm of AI agents on the code, forcing them to keep Microsoft Word and Adobe Photoshop open so they can replicate them down to the very last millimeter?
It's not illegal... The practice itself isn't. But stealing, because that's what this is, the visual identity of that project is, it's called copyright infringement, and in some cases even unfair competition.
And what makes me even angrier is that I really don't see the point. Do we really need another Microsoft Office, identical down to the very last pixel?
If they had created a new suite with exactly the same functionality, using exactly the same approach, that would have been great. I would have been the first to promote it. And yet... This scares me a little, and it says a lot about what the future of open source will probably look like, especially if this is allowed and a precedent is set.
You are also working on Sinty OS. Why build your own desktop environment and kernel platform from scratch instead of reusing GNOME or KDE pieces?
Sinty OS is everything that Vanilla OS cannot be, because of its principles.
With Sinty OS, I wanted the desktop environment to be a unique experience, tailored to my needs (and those of many others, apparently), while in Vanilla OS we use pure GNOME, vanilla, exactly as mother GNOME intended it, and it follows all its principles, its style, everything is libadwaita and consistent with that desktop environment.
On the technical side, the "behind the scenes", Sinty OS is a completely different challenge. I'm trying to build an operating system that stands on the shoulders of Atom Loops, a new immutable technology I'm working on, very different from ABRoot and anything else out there.
Atom Loops manages immutability from the very first second of boot. The bootloader, the initramfs, everything is managed by this component, which follows a strict chain of trust and update validation.
Sinty OS doesn't use partitions for the system root, it uses image files (EROFS for the rootfs and UKI for the kernelcache), which are mounted by Atom Loops during boot, which means that, well, all the disk space (formatted as F2FS) belongs to the user.
Unlike Vanilla OS, I don't use LUKS, but encrypt user files using their own unique key. It's, well, completely different. The init system isn't systemd, but an ultra-minimal solution compatible with systemd units.
Let's say the two operating systems are two very different ways of achieving very similar goals.
When can people expect a stable release of SintyOS?
Haha, Sinty is the face of the project, as well as part of its identity.
Sinty is the shortened form I came up with for Singularity, which refers to the family of software related to Singularity Desktop and Singularity OS. Unfortunately, the term was too generic, so I decided to favor the name "Sinty". Little by little, I'm migrating everything to that name, which, in any case, will continue to mean Singularity.
There will be a lot more about Sinty, very soon. Many more applications and platforms are coming, all connected to Sinty OS.
Anything you'd like It's FOSS readers to know?
I just want to reiterate that people need to experiment more, especially today, when we have the technologies to dream big.
It would be predictable to say that limits are made to be overcome. It's much more exciting to think about how to overcome them.
Thank you for having me in this interview, always a pleasure!
Wrapping up
I would like to thank Mirko for taking the time to answer my questions in such detail.
I like how he refuses to pick a side in the AI debate. He uses agents heavily, yet he reviews every line they write and is researching an alternative to LLMs altogether. Amus and Raven are two things I'll be keeping an eye on, and so should you if you follow his work.
I'd also like to hear what you think about his take on the Adobe and Microsoft clones. Is copying a familiar interface fair game, or does it cross a line? Share your views in the comments.
Real-world ZFS usable space is typically 3–8% lower than this figure due to metadata,
padding, and the pool's built-in reservation. Treat this as an upper bound.
Compare layouts
Same drives, different layouts. This is usually the decision that matters most.
Power, save & share
Copied
RAID terms explained
Here is a brief explanation of the terms used on this online RAID calculator.
Striping
Data is split into chunks and written across several drives at once. It is fast because every drive works in parallel, but nothing is stored twice, so losing one drive loses everything. This is RAID 0.
Mirror
The same data is written to two or more drives. If one dies, another still has a complete copy. Simple and safe, but you only get the space of one drive per mirror. This is RAID 1.
Parity
Extra data calculated from your files, like the answer to a sum. If one number goes missing, you can work it out from the rest. Parity lets the array recreate a failed drive without keeping a full copy, so it costs less space than mirroring.
Single parity
One drive's worth of space holds parity, spread across all drives. The array survives one failed drive. RAID 5 and RAIDZ1 work this way.
Double parity
Two drives' worth of parity, so any two drives can fail. That includes a second drive dying while the first is being replaced, which is when it is most likely. RAID 6 and RAIDZ2 work this way; RAIDZ3 adds a third.
Striped mirrors
Drives are paired into mirrors, then data is striped across the pairs. You get the speed of striping and the quick recovery of mirrors, but only half the raw space. This is RAID 10.
Rebuild (resilver)
After you replace a failed drive, the array recreates its data by reading the other drives. ZFS calls this a resilver. Until it finishes, the array has less protection than usual.
ZFS vs. traditional RAID
Traditional RAID, from a hardware card or Linux's mdadm, only sees blocks of data and cannot tell if a block has gone bad. ZFS is a filesystem and RAID manager in one. It checksums every block, so it spots silent corruption and repairs it from the redundant copy. It only rebuilds the space actually in use, and a read error usually costs one file rather than the whole array. In return, it likes plenty of RAM, and growing a pool is less flexible: adding a single drive to an existing RAIDZ only arrived in OpenZFS 2.3.
URE and drive class
A URE (unrecoverable read error) is a spot on a drive that cannot be read back. Manufacturers rate how often this can happen. Consumer drives are usually rated at 1 error per 10¹⁴ bits read (about 12.5 TB). NAS and enterprise drives are rated at 1 per 10¹⁵ (about 125 TB). A rebuild reads a lot of data, so the calculator uses this rating to estimate the chance of hitting an error mid-rebuild. These are spec-sheet worst cases; real drives often do better.
How is the power draw estimated?
Each drive type uses a typical average draw for a drive that is spinning or active but not under heavy load:
3.5" HDD: 6.5 W
2.5" HDD: 2.5 W
2.5" SATA SSD: 2.0 W
NVMe SSD: 4.0 W
The array total is that figure multiplied by the number of drives. The yearly figure assumes the drives run 24 hours a day, every day: watts × 8,760 hours ÷ 1,000 = kWh.
It counts the drives only. The CPU, motherboard, fans and power supply losses add more, while spinning drives down when idle lowers it. Treat it as a ballpark for comparing layouts.
Frequently Asked Questions
Here are the answers to common questions you might have:
Should I use RAID 5 or RAID 6?
RAID 6 is the safer choice for arrays built with large modern drives (8TB and above). RAID 5 tolerates only one drive failure, and rebuilding after a failure requires reading every surviving drive in full. A single unreadable sector during that window can compromise the rebuild. RAID 6 adds a second parity block, so the array survives a second failure or read error during that window. The cost is one extra drive's worth of capacity. RAID 5 remains reasonable for small arrays of small drives or non-critical data.
Is ZFS RAIDZ better than a ZFS mirror?
Neither is universally better. RAIDZ (especially RAIDZ2) gives you more usable capacity from the same drives, while mirrors give faster resilvers, better random I/O performance, and simpler expansion, since you can grow a pool by adding another mirror pair. For most home NAS builds with 4 to 10 drives where capacity matters, RAIDZ2 is the common recommendation; for performance-sensitive workloads or pools you expect to expand gradually, mirrors are often the better fit.
Is RAID a backup?
No. RAID protects against drive hardware failure and nothing else. Accidental deletion, ransomware, file corruption, controller failure, theft, and fire all affect every drive in the array simultaneously. RAID keeps your system available when a drive dies; a backup lets you recover data you have lost. You need both, and the standard advice is the 3-2-1 rule: three copies of your data, on two different types of media, with one copy off-site.
How much usable space do I get from RAID 5?
RAID 5 gives you the capacity of all drives minus one, based on the smallest drive in the array. Four 4TB drives yield 12TB usable; six 8TB drives yield 40TB usable. Note that your operating system reports capacity in TiB (binary units), so 12TB will appear as roughly 10.9TiB. The space is not missing; it is a difference in units.
Can I mix different drive sizes in RAID?
Yes, but every drive in the array is treated as if it were the size of the smallest drive, and the extra capacity on larger drives sits unused. Mixing a 4TB drive into an array of 8TB drives effectively turns them all into 4TB drives. If you must mix sizes, replacing the smallest drive is usually the cheapest way to reclaim capacity. Some systems (like Unraid or Synology SHR) handle mixed sizes more gracefully than standard RAID.
By now, you must know that mainstream Linux desktop environments, and by extension, distributions, are moving away from X11.
If you don’t know what an X11 session is, it is a desktop session that uses the X Window System, typically through the X.Org Server (Xorg). The server handles graphical output and input communication between applications and the display, while other components manage windows and compositing.
The newer, increasingly favored approach on Linux is a Wayland session.
Wayland is a display protocol, and its compositor acts as the display server, handling graphical output, input, window management, and compositing.
KDE has confirmed that Plasma 6.7 is the last release with a native X11 session, while GNOME has also removed its own X11 session. Of course, X11 applications can still run in Wayland sessions through the Xwayland compatibility layer.
Though not everything is lost for people who prefer X11. Several projects are emerging to keep the experience alive, with some maintaining or forking the existing X.Org Server, while others go as far as rewriting an X11 server from scratch.
This list covers eight of them, spread across desktops, X servers, and a layer that runs X11 apps on a Wayland compositor. Each one is open source and has shown development activity within the past few months.
1. SonicDE
SonicDE is a desktop that branches off KDE Plasma 6 and puts X11 first. It began in 2025 as a patched KWin/X11 called kwin-x11-improved. That grew into sonic-win, a window manager and compositor that keeps KWin/X11 going with code borrowed from KWin/Wayland and its own fixes.
Beyond the window manager, SonicDE is forking the KDE pieces it builds on and stripping out Wayland-only code. A Vulkan backend is in progress, and the developers plan to keep X.Org Server compatibility going while that remains feasible.
There's also conveniences, such as global hotkeys for push-to-talk and OBS recording toggles, and screen recording inside remote desktop apps like TeamViewer. Packages are available for Arch-based distributions, Artix, Manjaro, Gentoo, Void, and Slackware, among others.
Install instructions and links to each distribution’s packages are on the installation page.
Trinity Desktop Environment, or TDE, keeps the KDE 3.5 codebase going as a desktop of its own. The project's goal is to preserve the look and feel of a traditional desktop while being lean and requiring modest hardware to run.
Unlike KDE Plasma and GNOME, TDE continues to offer a traditional X11-based desktop environment rather than moving to Wayland. Its features include a built-in X11 compositor, with the project maintaining the components needed for its classic desktop experience.
The R14.1.6 release, the sixth maintenance update in the R14.1.x series, was announced in April. It fixed window tiling for maximized windows, improved branding, and addressed several transparency problems. It also added a 3D border option for the Kicker panel and a "Go to Desktop" action in Konqueror.
TDE can be installed on various Linux distributions and FreeBSD. You will find the latest packages on the official website.
This is alpha-quality software, and the interval between new releases is long.
Wayback does not replace X11 clients or desktops. It replaces the layer underneath them.
The project is a small Wayland compositor built with wlroots. It carries just the required Wayland functionality to run Xwayland in rootful mode, allowing an entire X11 desktop environment to run inside it.
The aim is to make the traditional Xorg server binary unnecessary while retaining support for existing X11 desktops, particularly in Alpine Linux. The project is still experimental, so compatibility isn't guaranteed.
Ariadne Conill of Alpine Linux started the project. It is MIT-licensed and hosted on freedesktop.org's GitLab instance.
XLibre is a community-maintained fork of X.Org Server that aims to keep X11 viable while continuing to develop the existing codebase. It also carries forward improvements that were never released in X.Org Server, including some features previously available only in Xwayland.
The changes are practical. TearFree modesetting is enabled by default, while atomic modesetting is available as an option. XLibre also introduces Xnamespace, an extension designed to separate X clients, and supports seat management through seatd as an alternative to systemd-logind.
The project also maintains CI builds for Linux, the BSDs, macOS, and Windows, although build coverage does not necessarily imply equal support across all these platforms.
Suggested Read 📖: PeppermintOS is moving from Xorg to XLibre to avoid Wayland.
5. Yserver
0:00
/0:10
📋
The project is quite early in the development cycle and has one main contributor.
yserver is Jos Dehaes' ground-up X server rebuild in Rust, and the code is MIT-licensed.
It does not try to reproduce everything Xorg does. Indirect GLX, the DDX driver interface, non-TrueColor visuals, and clients with swapped byte order are among the things it leaves out.
Clients connect over Unix sockets by default, while TCP transport and XDMCP support are available as optional build features.
Despite its narrower scope, yserver can already run complete MATE, Xfce, and Cinnamon desktop sessions. It has also been tested with window managers such as FVWM3, Window Maker, Openbox, i3, and Enlightenment.
The project runs the X.Org X Test Suite to measure protocol compatibility, but development is ongoing and it is not intended to be a drop-in clone of Xorg.
Unlike the other projects here, XQuartz is not trying to preserve an X11 desktop on Linux or replace the Xorg server with a new implementation. It builds on X.Org's X Window System for macOS, allowing X11 apps to run alongside native Mac apps in the same desktop session.
The latest stable release, 2.8.6, arrived in July 2026. It updated several bundled components to address older security vulnerabilities and fixed rendering issues affecting Apple Silicon Macs.
It supports macOS 10.13 and later, and you can get it from the official website.
Phoenix is an X server built from scratch in Zig, not an Xorg fork, and it is licensed GPL-3.0-only. The idea is to build a simpler server than Xorg by supporting only a subset of the X11 protocol, with a focus on modern applications and graphics hardware.
Most of its planned improvements concern security and graphics.
Protocol messages are meant to be parsed automatically, applications are intended to be isolated from each other by default, and clipboard access is planned to be restricted to focused applications, with an option to restore Xorg-like behavior.
Other goals include tear-free rendering, a built-in compositor, better multi-monitor support with different refresh rates, and HDR. In cases where features such as HDR need more than the existing X11 protocol offers, the project says it may extend the protocol.
For now, Phoenix only runs nested inside an existing X server, where it can render GTK 3, GLX, EGL, and Vulkan applications with hardware acceleration. It remains under development and is not ready for everyday desktop use.
Frame is an X server for x86_64 Linux written entirely in NASM assembly. It skips libc, Xlib, and other typical user-space dependencies, speaking to the X11 protocol directly and communicating with the kernel through DRM/KMS and evdev.
Geir Isene created it for the CHasm desktop with the long-term goal of supporting the desktop alongside ordinary X11 clients. Right now, Frame can serve up to 128 clients at once and supports SHAPE, RANDR, XInput2, and MIT-SHM.
It is released under the Unlicense, and its README credits Claude Code.
If you've followed It's FOSS for a while, you probably have seen our previous coverage of ArmSoM devices. I reviewed the Sige7 a while back and came away impressed (cheeky headline and all). Earlier this year, we also covered the Sige6, the first Sige board to swap Rockchip for Allwinner.
Now the Sige lineup is back on Rockchip with the Sige7s. So, what's changed?
Storage: removable eMMC module (16GB to 128GB) + microSD
Networking: Wi-Fi 6 + Bluetooth 5.0, Gigabit Ethernet with PoE support (add-on module)
2x USB 3.0 + 2x USB 2.0
1x MIPI CSI (up to 5MP camera)
CAN, SPI, PWM, 3x UART, 2x I2C, 6x ADC
RTC battery connector
Headphone out
Power and Maskrom buttons
0°C to 80°C operating temperature
Size: 85 x 56 x 17mm, same footprint as a Raspberry Pi
The Sige7s starts at $153 on ArmSoM's store.
The "s" in the name comes from the chip. The RK3588S is the trimmed-down version of the RK3588 that powers the Sige7. You get the same CPU, the same Mali-G610 MP4 GPU, and the same 6 TOPS NPU. What you lose is peripheral bandwidth. There is no PCIe 3.0, one HDMI output instead of two, no HDMI input, and only one Gigabit Ethernet controller.
In simpler words, the compute is the focus here, the I/O is not. If you want a Rockchip SBC fast NVMe drive or dual networking, this isn't the board for you. If you want RK3588-class power in a smaller package for less money, it is.
There are a few more indirect cost optimizations here for the users. Sige7s accepts a wide 5V to 23V input, so you aren't stuck with a specific USB-C power brick. It also uses a removable eMMC module, which means your precious storage isn't stuck to the board if you want to upgrade or reflash it on another machine.
On the display side, there's HDMI 2.1 up to 8K@60fps, a DisplayPort 1.4 over USB-C, and a 2-lane MIPI DSI connector. The hardware video engine decodes 8K@60fps H.265/VP9 and encodes 8K@30fps, so it can double as a serious media box.
The 40-pin header is Raspberry Pi compatible, and ArmSoM says it works with Pi HATs, the Pi 7-inch display, the IMX219-based Pi camera, and Pi 4 cooling solutions. That's a good thing if you already have Pi accessories in your stock or if you want to expand the board.
Prefer a Compute Module? Meet the CM7s
Alongside the Sige7s, ArmSoM also offers the CM7s, a compute module built around the same RK3588S chip. I checked both spec pages, and the CPU, GPU, NPU, and video engine are identical. It's just a different form factor.
In case you did not know, the compute module contains just the processor, memory, storage, and power management. There are no standard physical input/output ports like USB, HDMI, and Ethernet. Compute modules are more suitable in cases where they need to be embedded.
The CM7s measures 55 x 40mm, pretty much the same size as the Raspberry Pi CM5. Not sure if you can put it into a CM5 carrier board, though.
It's available with up to 32GB LPDDR4/4X RAM and up to 256GB eMMC. Through the 100-pin connectors, it exposes HDMI 2.1, DP 1.4, MIPI CSI/DSI, USB 3.0, PCIe 2.0/SATA, and the usual GPIO buses. ArmSoM has also committed to producing it until at least August 2034, which is reassuring if you're building a product around it.
To get started, there's the CM7s-IO carrier board. It gives you HDMI, USB-C DisplayPort, 4x USB 3.0, Gigabit Ethernet, a 40-pin header, an M.2 M-key slot for NVMe SSDs, microSD, and MIPI camera and display connectors. Unlike the Sige7s, it runs on a 12V DC barrel jack.
Pricing and Availability
Both boards are available now from ArmSoM's official store, with AliExpress and Taobao listings as well.
The Sige7s starts at $153. Wi-Fi antennas are sold separately, so add those to your cart.
If you're in the US, note that ArmSoM collects 25% of the product value as prepaid customs duty at checkout (listed as "sales tax"), so there's no surprise bill on delivery.
If you just want a ready-to-use RK3588S computer, go for the Sige7s. If you're designing your own hardware or want an NVMe slot via the carrier board, the CM7s is the one.
ArmSoM hardware might remind you of Banana Pi boards, that's because the two companies are known to work closely together, and the boards often share the same base.
One more thing worth I have noticed. ArmSoM's documentation has improved considerably since I first tried their boards. That's a positive sign because new SBCs often struggle with the documentation and community.
