Configuration
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.
In use
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.
Conclusions
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.
- "Onebase review, Page 1"
- "Onebase review, Page 2"
