The Lumina Desktop Environment is a new, BSD-licensed, graphical system environment which is designed primarily for BSD and UNIX-based operating systems. This focus on BSD systems results in a number of distinct differences in from the current collection of Linux-focused desktop environments, only one of which is independence from all the Linux-based system management frameworks.
This article will explain a bit of the history behind the Lumina desktop, the foundations of its design philosophy, the internal operating system sup- port framework, the current status of the project, and the goals/timeline for the project to achieve an official (non- beta) release.
The Lumina Desktop Environment (“Lumina” for short), was initially started in late 2012 as a small hobby project to just add some functionality/utilities to the Fluxbox win- dow manager. I had grown a bit tired of all the constant issues with running other desktop environments on FreeBSD. I was using Fluxbox quite a bit at that time because I liked the responsiveness of the interface – although I really missed things like automatically generated application lists/ launchers and the ability to have the system remember/ detect which application to use to open a file. After a little over a year of intermittent work on nights/weekends, I had gradually turned Lumina into a very basic Qt4-based graphical overlay for Fluxbox, with a small background utility for launching applications and opening files. Around this time (end of 2013, beginning of 2014) it was still considered barely functional (pre-0.1), but Kris Moore of the PC-BSD project offered to host it on the PC-BSD source repository, tying it into the automated build and distribution systems for users of the PC-BSD operating system to play with. Since we were in the middle of phasing out some old technologies that I maintained as part of my PC-BSD development job, I took him up on the offer and we moved the source tree for Lumina over to the PC-BSD SVN repository so I could work on it a bit more regularly as time availed itself. Over the next couple months, I was able to continue to clean things up and get it to a more usable state (although still very primitive), all while still maintaining a fairly tight level of secrecy on the project (as secret as an open source project on a public source repository can be, at least).
In April of 2014 that all changed: a status update about Lumina was accidentally featured in one of the PC-BSD weekly blog updates after we finally got a port and pre-built packages for it quietly added to the FreeBSD ports tree. This caused PC-BSD users to get all excited, some news sites and slashdot picked up on the story, and then the secret was officially out – the BSD’s were getting their own desktop environment. Since then, a lot has changed in the project: the sources were moved from SVN to the new PC-BSD repository on GitHub in April 2014, then in September 2014, it was moved again to its own sub-repository on GitHub (under the PC-BSD umbrella) and also obtained an independent release engineering schedule. In December of 2014, the entire project was converted to Qt5 and parts of it also started getting converted from the Xlib to XCB libraries (since Qt5 used XCB, whereas Qt4 used Xlib). All the while, more and more of Fluxbox was getting disabled/ replaced/bypassed all the time, so that in May of 2015, we announced that we were starting work on a new Qt-based window manager specifically to integrate with the Lumina desktop on a tighter level and replace Fluxbox. This leads us up to the present time: Lumina is still technically a beta release (since the new window manager has not been finished/implemented yet), is available on many operating systems (BSD and Linux-based), and is continuing to become more popular with every new point release. Why is this so? Perhaps it has to do with the philosophy behind how the desktop is designed and implemented…
The Lumina desktop is designed around three primary goals: minimal system overhead, a modular interface, and a complementary relationship with the underlying operat- ing system. Minimal system overhead is an obvious goal – people use computers to run apps to get things done, not look at a pretty interface. Any system which uses most of its processing power and/or memory just to run the interface is a system which has stopped being a tool and just become another burden. In my experience, the main culprits for this type of system drain are automatically started background daemons that are either rarely accessed or are used to hide the actual impact/requirements of some client application. Lumina takes a very clear-cut approach with regard to system overhead: keep it simple. The entire Lumina desktop can be boiled down to a single library, one binary for the entire desktop session, and one utility for opening files and/or launching applications. The other various applications which Lumina provides (such as the file manager) are simply treated as optional convenience utilities to be used/ignored/removed as desired. Because of this simplicity, there is no need for any communications daemons (such as DBus) or other desktop-monitoring daemons just to keep the desktop working in a semi-unified fashion, allowing Lumina to run incredibly fast and with a tiny amount of system overhead (typically less than 150MB of memory).
The principle of a modular application is something that has been around for quite a while with varying degrees of success. The main way that this has been performed is through detection/use of optional “plugin” libraries (or other similar systems), and while this works well in theory, it also has the effect of also making your application highly sensitive to “bad” plugins (whether malicious or just incompatible). Since the system interface is one thing which should be rock solid and reliable, Lumina is designed around a system of built-in plugins – functionality that is always in sync with the current version of the desktop because it is compiled and included within the desktop binary itself (preventing both version mismatch issues and externally-loadable 3rd-party malware).
Now how does a desktop environment have anything but a complementary relationship with the underlying OS? Very simple. If you look at the Linux development space, you can easily see that there is no such thing as a “Linux” operating system. Instead, what you have is a Linux kernel combined with some userland to create a “distribution” of Linux, such as a GNU/Linux distribution. The Linux- based desktops which are developed in this ecosystem have gradually evolved into providing much of that user- land “glue” to assemble all these various operating systems – effectively becoming an embedded part of the OS and providing many of the basic OS-level standards for application compatibility between different Linux dis- tributions. While this seems to work fine in Linux-space (most of the time), it causes all sorts of issues when you try to run that desktop on a non-Linux system because the BSDs already have a completely functional operating system independent of any desktop environment and its underlying frameworks.
For a quick example, the background system frame- works which the linux-based desktops use many times will not run (or will not run well) on BSD-based systems because they are either trying to duplicate functionality which is already implemented in a different way on a BSD operating system (such as the hald vs devd issues) or they rely on functionality which is not available on a BSD system (at least not in the same way). By writing a desktop to rely on these frameworks then is to effectively limit the portability/functionality of the desktop across various OSs (and don’t forget the extra overhead required for all the intermediate interface layers).
Operating System Integration
The Lumina desktop handles OS-integration in a very efficient, but compartmentalized manner. First, Lumina restricts itself to being a system interface only and does not try to provide utilities for configuring every aspect of the system. The reason for this is quite simple – not all systems are used in the same situations or for the same purpose. For example: a stand-alone service kiosk does not need to have access to all the same configuration utilities that a system developer might need on his worksta- tion. Similarly, an embedded system with a tiny screen (such as a cell phone), will need utilities tailored for touch- screen use while a console television system will needs apps tailored to function with a simple controller. By keeping Lumina as a customizable interface only, it allows the distributor of the system to decide what types of apps need to be installed based on their target audience and system specifications. For an example of how this works, look at the relationship between Lumina and the PC-BSD project. PC-BSD provides a FreeBSD operating system tailored for desktop/laptop users and also provides all the tools and utilities necessary for configuring that system. Lumina just provides an OS-agnostic system interface with the ability to embed support for all those various OS utilities (control panel, package manager, etc.) into the interface so that they are readily accessible by the user.
Second, for controls which an interface needs to have access to but the OS manages, Lumina has a single LuminaOS class contained in its library where all those interactions may be set to directly interact with the native system/ libraries. A couple good examples of this would be controlling screen brightness or audio volume. The OS and/or distributor has usually already decided which audio subsystem will be used (ALSA, OSS, PulseAudio, etc) – Lumina just needs to know how to have basic interactions with it. By the same token, though, all those OS-interactions are also completely optional. In the class, it is very simple to specify when something is not available for an OS, and in that case the interface responds by hiding all references to that functionality – preventing the user from having access to some of the niceties that Lumina provides, but still allow- ing the user to have a fully-functional interface.
Since Lumina is designed around a distribution framework which utilizes a distributor before it reaches the consumer, this opens up all sorts of configuration/implementation pos- sibilities that Lumina is only just starting to expose. First, this opens the door for Lumina to be used on almost any type of device: such as a smartphone, tablet, or console tv system, in additional to the traditional “desktop” market. This is due in part to the compartmentalization of all the interface elements into distinct “plugins” – since this allows the distributor to preconfigure the desktop with an interface suited for their target device (just as PC-BSD is doing for desktop systems right now). Second, this allows the user the ability to suit their workflow and maximize productivity (such as having the distributor set a default interface that caters to the target user). Third, this allows the desk- top to be as heavy/light on resources as desired (either for system performance or user preference), depending on the choice of interface elements and desktop functionality.
Customization options like this always come with a price: complexity and/or confusion. Lumina attempts to alleviate this in a couple different ways. By providing a single settings file on the system which arranges the default user interface and other user-experience options, Lumina makes it extremely simple for distributors and system administrators to customize the out-of-box experience, as well as by providing a convenience utility called lumina-config which gives the end-user an easy way to configure every aspect of the interface as desired (all without touching a terminal or text editor).
Right now, the primary development focus for Lumina is to achieve a comparable level of functionality with other common desktop environments (particularly with regards to traditional desktop systems – mobile/console systems are not a huge focus right now), and finally reach the goal of the first non-development release (1.0). The means that the new Qt-based window manager needs to get finished up (with a current target of December 2015) as well as the continued addition of new interface plugins and features. This new window manager is actually three-fold, it will not only replace Fluxbox for managing windows while the session is active, but it will also provide a replacement for xscreensaver while the session is inactive and also incorporate the session locking/suspend functionality for when the user needs to step away from the system. This utility, when combined with the current desktop interface, will effectively make Lumina a stand-alone system interface with an incredibly small list of system dependencies – opening up all sorts of possibilities for system types and without limiting the user by requiring long lists of package/library dependencies which may conflict with what the user actually needs the system to do. The current goal for reaching version 1.0 of the Lumina desktop is July of 2016 (prior to FreeBSD 11.0-Release), and so far we seem to be on track to meet this goal. In the meantime, the Lumina desktop is a highly fast/stable alternative to other common desktop environments, particularly for BSD-based systems. The only time we expect that a user’s current settings may get changed on an upgrade in the near future is when the new window manager gets activated by default (simply due to the number of configurations/files that this change touches). We are already working on ways to minimize the effect of these changes as much as possible,however, so that Lumina may continue to provide a stable, consistent user experience even across major updates.
About the Author:
Ken Moore is the founder and lead developer of the Lumina desktop environment as well as a developer with the PC-BSD project. He is an avid proponent of keeping it simple, and always focuses on clean, readable code quality as well as interface designs that anyone can understand and use. On the weekends, he likes to spend time with his wife and two kids, playing games, building contraptions, or just having general family time.