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.