Before we proceed to installation, I would like to briefly describe Olm - Onebase Linux Management. Olm and the assorted ol-commands are the heart of Onebase. Together they aim to provide an integrated system for managing many aspects of system administration, initial setup and dealing with packages. These are console tools and there are a number of options and one-letter switches, fortunately the only command one really has to remember is olm, as invoked by itself it will provide a listing of all available options.
Olm can be used to install software either from source or binary packages, depending on switches used. So, 'olm -s packagename' will install source for that package and any dependencies while olm -b will do the same but using binary packages instead. There are corresponding options to just download (-d for sources and -f for binaries), to compile or install already downloaded packages (-d for sources and -i for binaries), or to just list packages that would be installed (-g and -p respectively). Olm -o sets the options used to compile software: processor types, optimization levels and any other compiler flags. What about executing a script that was downloaded through a browser, or just written? Olm -a will do that. It's a fairly complete and rich system, but apart from remembering various switches it is still easy to use.Resources permitting any number of Olm processes can run concurrently, and according to developers any dependency problems that might arise will be automatically resolved.
Gentoo has portage, Source Mage has grimoire - Onebase uses Application Gallery. It's a collection of information required to install packages, in the format packagename.olm. I will call them .olms, not to be confused with the command olm itself. So, each .olm is an equivalent of a spell in Source Mage, or I believe ebuild in Gentoo. These .olms are then grouped into categories and sub-categories. Unlike other source-based systems, Onebase's Application Gallery resides on their server, not in the local cache. This means using Application Gallery requires no updates or synchronization, since the system always uses the current version. However starting with Onebase 2004 it is also possible to create and use a local gallery, using ol-off command. One of the options in ol-off synchronizes local gallery with the main one, and Onebase running in this way is quite similar to those other source-based distros. It is very simple to switch back and forth between main and local galleries with ol-off command.
Main gallery can be accessed not only by olm commands, but also with a web browser. Once the desired application is located, click on its name to download its .olm script, which can then be executed with 'olm -a' . I think this was in fact the original way of installing software in the first version of Onebase. Console browser Links is included in core tools, so web-based representation of gallery is still available even when not running XFree.
When I cast a spell on Source Mage, if there are any optional dependencies it will ask me whether I want to use them. There are no such options in Onebase - dependencies described in .olm will be installed, unless one edits the .olm directly. While extra flexibility is nice, I think this is fine - most users should be happy with the defaults, and experts can do a bit of editing themselves.
The way I think about this, olm itself deals with management of software, while ol-commands handle configuration, though that division is a bit blurry: ol-sys handles updating of all installed packages, and ol-ui removes installed packages. But then there are configuration scripts such as ol-init for managing init services, ol-audio which switches between Alsa and standard drivers, ol-connect for internet connections, and ol-ki for kernel reconfiguration. Ol-help displays help files, simply by opening text files in vi editor. Ol-commands also include several 'enterprise tools'. Unfortunately I was not not able to try them out as I only had one Onebase system available at any given time, but I want to mention them since the developers seem to think they are important, and set Onebase apart: these are ol-link, ol-share, ol-net and ol-manage. As I understand they are meant to simplify managing a number of machines, with tasks such as updating all machines with one command, producing common kernel configurations, or listing packages used on all systems.
My test machine was an Athlon XP1800, Gigabyte 7VRX motherboard with on-board network and audio. 512MB RAM, 80GB disk, and CDROM/burner. Video is provided by a cheap nvidia GeForce4-MX440 card and sound by Soundblaster Live, since I like to play music on my computer and I could never get acceptable quality with on-board sound.
The default installation I used was very simple. Booting from Onbase CD, first come the options to use the disk for installation, or rescue. Choosing installation brings us to cfdisk for partitions (I used only root and swap), then selection of mountpoints and filesystems - available are ext3, reiserfs and XFS. Lilo is installed, either in MBR or /. Next come the settings that will be used for compiling, such as processor type, optimization levels and any additional compiler flags. And then the fun begins: because Onebase is based on sources, the whole base system is now compiled. There is no way to configure kernel at this stage - the default kernel is compiled with default set of options. The whole process took two and half hours on my machine. When it is over, all that is left to do is set up the root password, and reboot into the new system.
- "Onebase review, Page 1"
- "Onebase review, Page 2"