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.
Bundles
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
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.
Software.Org
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
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...