About Komodo

Komodo is a next-generation Linux-based operating system that spawns from the question 'what if we had no compatibility needs and no conventional limitations on design?' Komodo primarily inherits it's behaviour and architecture from OpenStep and Mac OS X, but it borrows and improves upon ideas from other sources (even Microsoft Windows XP). Komodo tries to please everyone by being very friendly to new desktop users, providing a wide range of available applications for artists, developers and business- people, and provide the flexibility and configurability of power users. Whether it does this depends on your opinion, but if you disagree with us, we'd love to know about it so we can improve your experience.

Komodo is unlike anything other distributions have attempted, although in many ways one could say it is similiar to GoboLinux with regards to Komodo's default filesystem heirarchy. Yes, default. Komodo's filesystem heirarchy is completely abstract. The Core Services and all Komodo applications utilize the file /.System/Layout.xml to determine the locations of filesystem components like '/System' and '/Software'. Not only does this allow us to change the heirarchy later, but also let's power users define where their stuff is, just the way he/she likes it. Users who miss the traditional GNU/Linux directories (i.e., /etc, /bin, /usr and the likes) may set up Layout.xml to make Komodo applications use those directories by default. Another advantage (key to the design) is to allow other distributors of Komodo to choose how the filesystem is organized, and to help ease the work of people creating Komodo Runtimes, which allow applications to run on other pre-existing platforms without source code changes or even recompilation.


Komodo uses a package system resembling that of GoboLinux or OpenStep/Mac OS X. The packages are called Bundles in honor of OpenStep, and are placed in one of several defined places. These default places are (by default searched in this order), '~/Software', '/Network/Shared/Software', '/Software', and '/System/Software'. Bundles contain Resources of different types in folders below the package directory, such as 'Apps' for applications, 'Libs' for shared libraries, 'Images', 'Sounds, 'Manuals', 'Docs', 'Headers', and more. These resources are linked into the Shared directory, which is by default '/Software/Shared'. Applications can access these resources with the Emotion environment.


Emotion is Komodo's next-generation application platform. Emotion provides the magical glue between Komodo applications and the underlying platform. Because Emotion is 99% plugin-based, platform developers need only create a set of core plugins which allow Komodo applications to interact with the native operating system. Komodo provides it's own set of plugins for Emotion which interact with the rest of the Komodo platform and the underlying GNU/Linux base.

Emotion is a full-featured application environment; as such it has many components. Some of the important components include Jazz--a vectorized resolution-independent drawing kit, Dagon--which builds upon Jazz to create a powerful modern widget set, Dxl--a language for defining user-interface elements using XML syntax, and Shoe--Komodo's boot system.

Emotion centers around the Bundle as the core object for creating applications. A basic Emotion application could look like the following:

using System;
using System.IO;

using Komodo;
using Komodo.Utils;

namespace MyCompany.MyProject {
	public class MyApplication: Application {
		public override void Run(string[] args)
			Console.WriteLine("hello world!");

Core Services

Komodo features several core applications that perform detection and organization of various things for the operating system. These Emotion applications are grouped as the 'Core Services', and provide functionality required for the operating system to run.


It should be a no-brainer that with a package system like Komodo uses that the PATH environment variables would be very long on the console. Well in fact they were at first, with Komodo's 'import' script. Import is part of the old PkgTools scripts, which provided tools for runtime access of packages. It finally became evident that 'import' was not the right way to go when I had to suddenly remove one folder from the search path after importing several packages. Not to mention it was clumsy to have to import every bundle for the apps you needed on the command line. So instead I followed the path of GoboLinux and created a script to manage symbolic links to the Shared directory, /Software/Shared (referred to as $SHARED in discussions and documentation).


Media.Detect communicates with the traditional UNIX 'fdisk', the Sys FS filesystem (devfs on non-2.5+ kernels) and other resources to locate all media devices attached to the computer. It then creates a mount point for them and generates an /etc/fstab. The mount points are all located in /System/Mounts (by default), named in respect to the type, logical address, and filesystem type of the media device. For example, traditional /dev/hda1 would be /System/Mounts/IDE:Disc-0:Part-1:FSType.

Media.Detect doesn't create very attractive names for the user, so to provide a usable interface to media devices for the user, we have Media.Org. Media.Org takes the links in /System/Mounts and determines labels and other information for them, then creates attractive links in the /Media directory. Names typically will include either a type or label ('Hard Drive' or 'Western Digital 1234E' or 'Main hard drive') and a drive letter (A:, C: etc). The drive letters are unused in Komodo. They are only provided to remind former Windows users where their data is and can be disabled easily via user preferences. The names of the devices in /Media are editable by Admin users, and can be renamed just as any other file. It is perfectly safe because Media.Org looks at what the symbolic links point to instead of what name they are when relinking the directory.

Ok, wrap it up!!

This article is getting far too long, so I will end it now. If you have any questions, ideas, or other feedback, you can find out how to contact the Komodo project here. I will be posting more articles about Komodo and about Komodo looking ahead into the future. Later...

2004 William Lahti, Brian Reynolds