The Dæmon Desktop.


Dæmon Desktop
(The High-Integrity Desktop for Serious Workstations)
This is a tentative to conceptualize a hypothetical ‘FreeBSD Workstation’, just in case of some entity eventually get interested on to design and implement it some day.

The main inspiration for this brainstorm is the aiming to conceptualize a “Desktop to Rule They All” desktop. Also, with the possibility to retain the same UI/UX logic between all «variations».
In other words, a software collection that can scale from scriptable CLI-only tools to a full featured GUI desktop.

  • Audience${FreeBSD}.
  • Configuration – on-the-fly + buildsheets (see Ravenports) - basically a file with the specifications.
  • Language – Pure Ada/SPARK (alternatively OCaml).
  • Portability – Not a goal. Deep integration with the FreeBSD Base is the goal.
  • Supported architectures – All supported by the FreeBSD and the GNAT compiler.
  • Widget Toolkit – Lightweight but professional, custom designed.
  • Window manager – Tilling-automatic, tilling-manual, stacking - modes or separated.
  • Requeriments IBM Design Language IPC NO Freedesktop OCaml plugins bhyve gui capsicum centralized color setup color management dark mode hot code loading multi-monitor network mirroring framework privacy push notifications scalable UI: cli, curses, graphic scriptable separation standalone hotkey daemon strong encryption vcs integration
The basic idea is to have most of the software features written into libraries (lets say, inspired in unikernels like MirageOS) with separated front-ends styles created around them. Several applications could yet be written as daemons, and the front-ends actually just being its clients. Also, why not get some inspiration from Qubes and Muen separation kernels and have all involved parts fully isolated, communicating with each other by an IPC, according to a given security police? Eventually, maybe optionally, using bhyve for isolation (perhaps too much of overhead?) instead of sandboxes.

A 'networking mirroring framework' intended to allow mirroring (and keep mirrored) the desktop configurations between several machines. With the scalable UI/UX design it should also allow to keep it even between the different variations (CLI, Curses, and GUI) the collection. To accomplish that, the software collection would need to have the ability to compile itself, or to talk with the system builder.

The idea behind of the centralized color setup would be to use something similar to .Xresources colors but affecting all themes (CLI, Curses, and GUI), to avoid color mismatch between themes and applications. So, themes colors would to be set exclusively using the 'desktop color codes' instead of HEX codes or something else. Also,
IBM Design Language and Carbon Design System are the perfect references for design UI/UX in general.

Inspired in some design tools, it could have a built-in algorithm for color scheme creation. In practice, the user could set just the initial 16 colors (or ever just one) and the algorithm would automagically create all others missing colors (16M) to create a perfectly matching palette, following the good graphics design rules.

Using buildsheets as configuration files would make the user set configurations build time too. Those buildsheets could also be used for configuration backup, and would make that easier to move them from one machine to another by either distributing a pre-built package with all desired configurations or the buildsheets. The eventual ability to dump a single buildsheet for the entire desktop collection configurations would make the things even more "magical".

One of the goals is to integrate with the FreeBSD Base as deeper as possible, always trying to not depend on third party software, writing all necessary libraries in house.


Some noteworthy software to have its features, user interface, and design investigated:

Also, common UNIX utilities like BusyBox, Toybox and such.


Other noteworthy to have SPARK written alternatives:

ipfw(8) (but with Pf-like syntax, please)
ipsec(4) + security/openiked

security/kerberos and relevant related software (gssapi, sasl, etc.)
security/openssl | security/libressl
security/sudo | security/doas
dns/ironsides: this is already SPARK (2012), but not enough feature rich to compete with Unbound/NSD or Bind.

Secure Mail Solution: complete e-mail solution, end-to-end encryption capable à la I believe it could indeed have some serious commercial appeal.


Keep on watch: NeoGFX

Who is using Ada?
Awesome Ada


Last edited:
My perfect desktop is fvwm2 with three viewable desktop panes and right-click mouse menus to access my application tree. Anything more is clutter.
I'd be happier with the most current version of pf and a few other security enhancements, but am about as happy as I can get with the one I'm using now:


That gives me everything I need to work with and from, while listening to music. I usually run with the file manager and top terminal scrolled but when I work that's how I like it.

I am concerned with the dependencies a program is burdened with, but can live with what it takes to run the ones I use without appreciable performance degradation or personal bias against things like GTK.
Did you check mail/claws-mail for an email client? And deadbeef is a lightweight media player.

I've used mail/claws-mail in the past, but currently (since I changed from KDE to tilling-wms) I am one of those person who prefer everything to be a daemon and have a devel/ncurses client. Same for audio/deadbeef. I use audio/musicpd + audio/ncmpcpp.

Please, don't get me wrong, my current setup work great but lack the integration that only exists when the involved software are developed all together.

For instance I cannot use security/keepassxc to direct unlock deskutils/notes. Also, for instance, I run databases/postgresql10 used by www/davical but I can't use that with deskutils/note because it does not support databases/postgresql10, same for audio/beets.

Those small things that make a lot of difference on the workflow. While I never used anything from Apple, let's call it "Apple Experience".

I would like to try fvwm2 - is there a simple guide for novices like me? Preferably with sample configurations to try before diving into documentations. Right now my favorite is XFCE - will I miss anything from it when using fvwm2?
I miss anything from it when using fvwm2?
No, with FVWM it is possible to create any function, and to customize it anyhow,
your FVWM configuration can be much more powerful than Xfce, Mate, etc
All that is available in Xfce is available in FVWM (BTW Xfce WM is based on FVWM).
Try my config, it is commented very well, all keybindings and functions.
Last edited by a moderator:
Now I see myself messing around to learn about microkernels ... while toying with my tentative to conceptualize a desktop. :rolleyes:
The Ada ports are currently poorly maintained. I've been updating a few from time to time but some seems to need more complicated patches and I didn't had time to work on those.

Btw, the compiler need to be updated too, apparently already has some software coming up with the Ada2020 syntax, just supported by newer GNAT for now.
  • Thanks
Reactions: Joe
Just a side-note: the Dæmon Desktop idea clearly involve a lot of complexity, and I do feel several folks would naturally dislike this due to state of the current casual complex software. Difficult to develop and maintain, full of bugs, inclusive desktops like KDE.

That said, this complexity (if sane designed) is a non-issue for Ada/SPARK, nor for development nor for maintenance. The language was and is designed (and is indeed an ISO standard) to develop and maintain with ease extreme large and complex safety-critical systems, including systems often involving thousands of developers working separated on dozens of millions of lines of code, to just later integrate everything.

So, Ada has all the necessary facilities to match those requirements, like Packages (that can be compiled independently of the rest of the code), Tasks, and so on.
Last edited:
As usual, I have completely misunderstood the topic of this thread and gone off on a tangent. Sorry rigoletto, I misunderstood your goal. :)
The Ada ports are currently poorly maintained. I've been updating a few from time to time but some seems to need more complicated patches and I didn't had time to work on those.

Btw, the compiler need to be updated too, apparently already has some software coming up with the Ada2020 syntax, just supported by newer GNAT for now.

nice idea with the Daemon Desktop, I also described one of the possible FreeBSD Desktop configurations - - here :)

Just curious, why use ADA when RUST is faster and uses less memory - and has similar goals as ADA?


Your desktop article is bookmarked in here already, I am just waiting to have some time to read it carefully.

An actual discussion about Rust vs. Ada would need a specific topic and IDK enough about Rust, but for starters Java was practically the exactly same requirements of Ada and it is hard to relate them. :)

I know Rust can be very fast, I am using x11/alacritty indeed, but beyond the fact those benchmarks are just artificial we don't know if who did the tests actually know how to implement Ada and/or Rust correctly, but if you take a look on Ravenports you will see Ada Tasks (threading) correctly implemented (Marino), and that is able to index thousands of ports in 2ms (4ms in an old and overused 5400RPM disk I had) - fast enough for me.

That said, in short, IDK why anyone would trade a language properly specified, designed, written, and maintained by extreme specialized scientists, heavily tested and officially approved for safety-critical software certification worldwide to something supported by Mozilla, and written by some people without an actual design project, to have some possible minimal performance increase.

This is the upcoming Ada2020 reference manual.

To be fair Rust brought the memory ownership feature which is great, and that was the only actual technical advantage of Rust over Ada (IMO), but Ada2020 added memory ownership (but a different implementation, and also paralellism, also HERE HERE) and this is already present in the last AdaCore-GNAT.

Also, a long time FreeBSD user (`dstolfa` IRC, also HERE) is working on a theory to improve the SPARK reasoning beyond the current check,prove mechanism. He is just waiting to get it `sound` to talk with AdaCore.

This is a interesting and funny video btw:



For the record my second option for that would be OCaml, what ofc would imply a completely different implementation. :)


And Ada do support almost all relevant processor architectures.