Onebase is still a very new distribution – the first version appeared only in July 2003, and Onebase 2004 released in early January 2004 is a major rewrite and enhancement of the original concept. It started out as a source-based system, but with this release it embraced binary packages as well, becoming a hybrid. It is not based on any other major distro or package management system, instead it prides itself on doing things its own way. These are still the early days, but this is also what makes it an interesting distro, and the one to watch.
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.
Upon reboot, I found Onebase follows the trend of hiding boot messages behind a splash screen. Personally I prefer to see what is happening, so as advised I hit F2 for standard display. What I saw was an auto-configuration routine, possibly based on Knoppix, going through its paces. It seemed to detect my hardware correctly but when it was done I found what could be best described as a first approximation rather than a working system. This would be acceptable – after all this is the case with many installations… except for one small problem: this auto-configuration runs on every reboot, and in some cases it is necessary to make the same adjustments all over again. For example, it makes entries in /etc/fstab that I didn’t want – I removed them, but when I reboot, they come back! XF86Config-4 it created was good enough to start XFree without crashing, but not really useable, so I quickly replaced it with my own.
While auto-configuration can be turned off with ol-init, one then has to load all modules and services by hand after each reboot, because Onebase doesn’t seem to use standard tools and locations like /etc/modules for example – it would not be an issue if auto-configuration worked perfectly, on all hardware, every time. But we all know this is not going to happen, so not providing for standard ways of setting up the system seems like an odd design choice. Perhaps I am missing something here… I am also having problems with sound I simply do not understand. I tried to get it going with Alsa and without – the modules load, user belongs to group audio, I fiddled with permissions on devices until I could fiddle no more, yet when starting KDE (both in user and root) I am still greeted by the dreaded message, “/dev/dsp could not be found”! This is disappointing, as I never had this problem with other distros I installed on this machine. Supporting my point about auto-configuration is the fact that I could get sound working when I turned auto-configuration off and loaded everything manually. I am still looking for a solution to this one.
Ol-connect has options for cable internet with Static-IP or Dynamic-IP, for Dial-up connection, for ADSL connection (for pppoe users), and for ISDN connection. Notably lacking is the option of using LAN, with DHCP. Until I find a better solution, I just enter ‘dhcpcd eth0’ after every reboot. It works, and since I don’t reboot that often it is not a major issue, but surely it could be handled better, and there should be some way of making this setting permanent. Reading the forum, I saw a solution involving hacking /etc/ifup and /etc/sysconfig/network-devices/ifconfig.eth0 … well, this is not what I had in mind!
In my opinion, the whole approach to configuration could use rethinking. I am all for auto-configuring as much as possible during installation, but I believe it would be best to stick to standard ways after that.
Olm is the definite highlight. I think it was where most development effort was concentrated, and it works very well. It was no problem at all to compile, for example, Mozilla in one terminal and k3b in another while happily surfing the web in Konqueror at the same time. On the other hand there are some strange bugs affecting other aspects of the system: for example, I found users could not open terminals or use su – could this have something to do with devpts, and lack of its entry in fstab? I sure don’t know, I’ll have to wait for the experts to figure this one out. In the meantime, adding users to group root and modifying permissions on /dev/* fixed this issue.
When installing KDE from source I found a couple of packages would not download, due to the usual glitches: changed locations, versions etc… keeping all details of thousands of packages up to date is a difficult task and occasional discrepancies are inevitable. Nevertheless, I believe installing software should be a routine and dependable process, not a game of russian roulette. One step towards this goal would be to ensure downloads do not fail, by providing alternative locations with a fallback position of distribution’s own archive, and this is one extension of olm architecture I would like to see. In the meantime, current system does have a fallback position of sorts: it was possible to continue installation of KDE by using binary versions of failing packages instead – since binary packages are stored on Onebase’s own servers, they were available. And to their credit, once developers were aware of the problems, they fixed them very quickly.
And at least this time I was able to continue the process without backtracking. Onebase does not archive downloaded sources – once installation finishes, the entire working directory is wiped clean. This was my major complaint about the first version of Onebase: any interruption to the process would result in loss of everything downloaded up to that point. Onebase 2004 addresses this issue, if operation is interrupted for any reason it is declared pending and its working directory is preserved until the process completes or is deleted with olm -w command. This is a huge improvement over the previous versions, but I would like additional option to automatically archive the sources. My bandwidth is limited, and it would be nice to be able to easily preserve downloaded sources as backups, or perhaps for updates of other machines. In fact it is possible: for example working with sources, instead of installing directly with olm -s I can first download with olm -d, then copy downloaded files to a safe location, then continue installation with olm -c. But this is a bit of a kludge – I think it would be nicer to handle this with either a switch, for example olm -s –archive, or through a global setting.
This release shipped with some key components somewhat behind their current versions: kernel 2.4.21, gcc 3.2.3 and Mozilla 1.4. I imagine developers were more concerned about working out the foundations of the system than keeping all components up to date. This is understandable, and probably a wise choice – Onebase is produced by very small team, they had to set their priorities and we should cut them some slack. They did get the foundations right, and now the updates follow: every day there are some additions and updates to the gallery. Olm itself has gone through a couple of revisions already, but keeping it up to date is as simple as command ‘olm -s olm’, and it only takes a couple of seconds. Likewise, the number of available applications was initially quite small, but it is growing and most applications I wanted are now available. There is KDE 3.1.4, Gnome 2.4.1, Fluxbox, Evolution… since I installed my system additions to the gallery included Xfce4, Open Office, Mplayer, Java and Flash. Mozilla is now updated to 1.5. But if the gallery is to grow anywhere near the size of Gentoo’s portage or even Source Mage’s grimoire, it needs more people involved in development and writing .olms for their favourite applications. It is pretty easy, and there is some documentation on that topic available on the website.
While we’re on the subject of the website, browsing through gallery means wading through large number of categories nested two levels deep and I find this more of hindrance than help. I wish there was also a simple alphabetical listing and/or a search function available! But I have to add here the site looks very nice, clean and fast to load. While this is not a feature of the distro as such, it does add to the overall impression, and contributes to user’s experience. As does support available on the forum, and communication between users and developers. On that score I have no complaints – when I asked in the forum about Bitstream Vera fonts, they were added to the gallery just a couple of hours later.
Default kernel is huge, so I used ol-ki command to recompile and trim it down. Ol-ki handles all tasks involved in recompiling existing kernel other than running menuconfig so it simplifies the process somewhat. However be aware it does not create kernel with a new name and its own entry in lilo.conf – it simply overwrites the old one. And compiling another kernel with ol-ki will still require a little bit of work: making a link to the new source first, and making appropriate entry in lilo.conf.
Finally, I also installed Onebase on an old PII/400 with only 128 MB of RAM. I was curious whether base system would compile on a machine with such low specs, and how long it would take: yes it did, and it took over 12 hours. But once the base was in place, I installed binary versions of XFree and KDE and I was rewarded with a system noticeably snappier than Mepis running on identical box. By the way, Onebase binary packages are compiled for i686 architecture.
Most concepts used in Onebase can be found in other distros as well. Sorcerer will compile any number of programs in parallel, Rock Linux will work with either sources or binary packages in similar way, and inevitably someone will drop in to announce Gentoo is best anyway. However systems like Sorcerer and Rock can be somewhat intimidating for those of us who are not professional System Administrators. On the other hand, Onebase truly has the potential of putting the power of source based distro (with additional convenience of using binaries if desired) into the hands of mere mortals, without compromising on features. This release is already eminently useable, but thanks to some bugs and difficulties in configuration it still has some way to go before it is truly ready ‘for the masses’. But I believe the framework is sound, and with a bit of support Onebase will go from strength to strength.
About the author
I am an amateur, but I enjoy dabbling with computers, and after playing with Linux for about 3 years I consider myself an intermediate user. I change my distros quite often, but at the moment beside Onebase I also run Source Mage, College Linux and Arch Linux. I got interested in Open Source when I realized Information Technology is entirely too important to be entrusted solely to corporations and governments.