Introduction to Rubyx Linux

Rubyx is an advanced, source based distro that stands out from the crowd thanks to some unusual and innovative features. It is also exceptionally lean and mean, and it goes like a rocket! I am a big fan of Rubyx and in this article I will attempt to show you why.

A quick tour of Rubyx

R is for Ruby: rubyx is one large script written in Ruby (programming language comparable to Python). This script manages all aspects of running the system: installation, configuration, booting, managing services, adding and updating software, and even creating isos. The details of installation for all packages – Rubyx ebuilds, if you like – are small Ruby scripts as well.

U is for Unusual: Rubyx is developed from scratch and it goes about its business in its own way. From the distribution and installation, to its file hierarchy and system management, it tends to chose the road less travelled.

B is for Bare Bones: The fat content of Rubyx is very close to zero. In this it is similar to distros such as Arch or Crux, providing just enough tools to keep the system going. The rest is up to the user.

Y is for You: as in, “You do it Yourself!” There are no GUI wizards in Rubyx, and very little auto-configuration. It is up to the user to create partitions, set up the bootloader or configure /etc/fstab, to configure and start any services that might be required and so on. Those who find this appealing will probably be happy with Rubyx. Those just wanting to get a working desktop with a minimum of fuss will probably be better served elsewhere.

X is for eXpert: Rubyx is best suited to advanced users who will appreciate its simple, direct approach. The website claims that “if you have a grasp of partitioning and formatting disks and some understanding of bootloaders, you can install rubyx” and this might be true, but beginners should be warned they will face a nearly vertical learning curve. I consider myself an intermediate user and I find the curve is still a bit steep, but manageable with some patience and help. So how hard is it, really? Well, I think Rubyx is actually a lot simpler to install and keep running than Gentoo for example, it’s just that it can be sometimes hard to figure out because its documentation is rather terse, especially in comparison to the magnificent Gentoo handbook, which I think all developers should be required to study as an example of what user needs.

Getting Rubyx

Stay with me here! I’m not going to bore you with starting ftp client and burning the iso but this subject deserves its own paragraph because this is in fact where the potential user collides head-on with one unique aspect of Rubyx: in order to even get Rubyx it is first neccessary to install White Water, a P2P application similar to Bittorrent but written especially for Rubyx and designed to distribute not only the whole isos but also the individual packages that make up the system. This was a creative solution to a common problem faced by many small projects: one of hosting and distribution. Rubyx was created by just one person, and the cost of hosting and bandwidth consumed by downloads quickly became too high for his pocket, hence this unusual approach. These days Rubyx is distributed solely from its creator’s home ADSL connection, with help of others willing to contribute by running White Water proxies. So far this works quite well, but it does mean that in order to even contemplate getting Rubyx one needs to already run a Linux system that can download and compile White Water, which is only distributed as a source tarball. So Windows users need not apply at this stage, sorry!


Once White Water is ready, there are two options: one is to download the bootable iso (DVD is apparently also available, but I haven’t tried it). This is the easiest way in my opinion and it has the advantage of guaranteeing the environment and sources for the base system that rubyx will need are available. But if the host system has Ruby and a resonably recent version of gcc installed, it is also possible to just download the rubyx script itself and then use it to build a Rubyx system in another partition, with the script downloading the sources from the net (again using White Water) as it goes. It should also be possible to build the system on one machine for another: build it in some directory, then tar it, somehow copy the tarball to the target machine, and untar it there. This script based approach to building the system is uncommon, but not completely unknown – Rock Linux also works this way.

On the other hand, installing from the iso can be compared to installing Gentoo, though it seems simpler somehow. Just like in Gentoo, there is no installer as such, instead the steps go something like this: Create partitions – mount swap – create filesystem on the target partion and mount it – then issue rubyx command that will build the system. For example:

rubyx –root-dir /mnt/rubyx –install Base Net Disk –no-download –make-devices

will install the base set of packages, including the default kernel (getting sources from the iso in this case, hence –no-download) and make some /dev entries. It is possible to add more options, including more package groups, your own kernel config file, optimisations for specific processor type, and options to use distcc. Those with multiprocessor systems can increase the default number of make jobs running in parallel. It is also possible to cross compile a system for another processor type, and I might add Rubyx now also supports AMD64, but I can’t say much about that as I don’t have any AMD64 machines to test it on.
Once the installation process finishes, a number of configuration steps has to be completed – grub has to be set up, fstab created, and it is a good idea to edit the settings for network and the keyboard, which defaults to uk layout. These steps are briefly covered in the documentation on the website and reading it is essential because while not especially difficult, they are not exactly obvious either.


It’s a good thing we don’t burn heretics at the stake any more … wait… just checking! Otherwise developers of Rubyx and Gobo Linux would be the prime candidates, for suggesting that all files belonging to a program should be contained within its own directory instead of spreading out all over the file system as mandated by LSB. Let’s look at the example of how this works: openssh was installed into directory /pkg/openssh.1/ This in turn contains subdirectories such as etc, bin, man, sbin and share, as well as a file openssh-version, which contains the name of the actual source file, as fetched by White Water. Man subdirectory contains the man pages for openssh. Etc contains its configuration files, and so on… The great thing about this is, if openssh package is updated, the new version will just go into /pkg/openssh.2/ and so on. However, the more traditional naming scheme is preserved as well, through symlinks. So for example it is still possible to find /etc/fstab, even though closer examination reveals it is actually a link to /pkg/util-linux.1/etc/fstab. I know this approach is controversial but I must admit that I love it! Perhaps because I came to Linux directly from Classic MacOS (completely bypassing Windows, I might add) I find it both intuitive and eminently sensible, no matter what the standards might say. Those interested in reading more about the justification and logic behind such arrangement, and why it is not necessarily contrary to the spirit of LSB can find some interesting materials on Gobo Linux site because Gobo uses the same approach, in fact takes it even further. For example, look for “I am not clueless” heading in their documentation section.

Package management

Rubyx is source based, but it does not fetch the sources directly from their providers, the way Source Mage, Rock Linux or Onebase do. Instead the source files are stored on Rubyx server and then distributed through White Water and its P2P network. On my LAN I run White Water proxy on one machine, (running Arch Linux) and when I want to install something on Rubyx system, it gets the files it needs from my proxy. If they aren’t in the cache already, the proxy gets them from others out there. This process is pretty transparent, except for having to set up a variable WW_PROXY in /etc/profile, pointing to my proxy server.

As for actual installing, updating and configuring packages or getting some information about them, all of that is done by rubyx script and its various options.

rubyx –install packagename will install package and its dependencies.

rubyx –configure packagename will change options, for example get glibc to use nptl. This is also the way to compile a new custom kernel, although thankfully the default one worked for me this time.

rubyx –clean will delete older versions of packages, in our example, if /pkg/openssh.2/ is current, then pkg/openssh.1/ would now be deleted – and not until now.

rubyx –upgrade … well, guess! But what happens with configuration files then? They are copied to the new version. Sticking with our openssh example, /pkg/openssh.1/etc would be copied to /pkg/openssh.2/etc At the same time, a new directory /pkg/openssh.2/ is also created, with the default settings for this version. I like this better than the alternative, which would be to use new settings by default and preserve the old ones under a different name – the old settings will usually work with the new version, and this way any changes made by the user are preserved and automatically applied, on the assumption they were made for a reason.

rubyx –query-package and –query-group provide rudimentary search functions, but I don’t find them especially useful since they don’t tell me whether package is installed or not, or in what versions.

Speaking of updates, another little peculiarity of Rubyx worth mentioning here is its release scheme, or rather the lack of such. There is no such thing as milestone releases like Rubyx 1.0 or whatever. Instead, all updates to the rubyx script are numbered sequentially, so it currently stands at 82; likewise with White Water, which is currently at version 26. As for the isos, they are just snapshots of the build created by some version of rubyx script – hopefully the current one, but not necessarily so. It is not unheard of for the isos to lag behind the script by many versions.


I have a confession to make: I dislike this whole business of runlevels. I know why they are there and why they can be useful but I don’t really need them, so I see the associated maze of links and scripts as just an unneccessary, headache-inducing nuisance. That’s why I was delighted to find that Rubyx dispenses with the concept of runlevels altogether. Instead it is either Go or No-Go, and that is just fine by me because that is all I ever need. Frankly, I think that is all that 99% of users will ever need! If a service has its ‘enable’ flag set to ‘yes’ in its configuration file which can be found in /pkg/pkgname.version/etc/pkgname/pkgname-enabled, then it will be started by init script, and that’s all there is to it. Services can be also managed at any time with start, stop, restart and reload commands. It doesn’t get any simpler than that, yet it is all that I ever wanted on my boxes… finally, I’m happy.

Practical issues

One would expect a system built from source optimised for the target machine to be fast – and it certainly is. Add to this no services running by default, no runlevels, no fancy splash screens, and you get a system that will boot quickly as well.
One would also expect a system built by one person to have small selection of packages – and this is also true. There is KDE and Gnome, but many supporting applications are missing, or not too fresh: for example Firefox and Thunderbird are both available but behind current versions. The kernel is current though – 2.6.8, and there is instead of XFree. As for other needs, it will be hit and miss, I’m afraid. There is Xine, but no mplayer. There is Apache, PHP and MySQL, but I don’t see Java or PostgreSQL, though I could swear it was contributed by one of the users… I guess the situation will really improve only if there are more developers contributing packages – there’s only so much one person can do. And this also means that as far as development and the mailing list goes, there are bursts of activity, then periods of silence, when the real life takes precedence.


Rubyx is a great tool for those willing to invest some time and effort into the installation and initial configuration. Its “less is more” approach makes a refreshing change from the general trends that seem to favour complexity. It is solid and fast, easy to run and maintain, and I think from the technical standpoint it could be an excellent, reliable system for many users, both on the desktop and as a server. The only shadow of doubt lies in the fact that for now it depends totally on one person, and its distribution model while currently performing well is really untested – there is no way of knowing how White Water is going to scale up without getting more people to actually use it. Also, it depends on the goodwill of the community members prepared to provide bandwidth, and should that community grow, it remains to be seen whether this model is workable. Then again, if it takes off, perhaps Rubyx will be able to afford hosting.

About the system

I installed Rubyx on AthlonXP 2000, Gigabyte motherboard with 512MB of RAM and nVidia GeForce2 MX 440. It takes about 12 hours to run “rubyx –install Kde-all” on this system.

About the author
The author (also known as Ferrix on some forums) lives in Australia. Besides Rubyx, his computers currently run Yoper, Arch and Ubuntu, and one (very old) machine double-boots Syllable and SkyOS. But he has never owned a system running Windows, nor does he ever intend to.

If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.


  1. 2004-10-11 9:31 pm
  2. 2004-10-11 9:35 pm
  3. 2004-10-11 9:36 pm
  4. 2004-10-11 9:40 pm
  5. 2004-10-11 9:43 pm
  6. 2004-10-11 9:49 pm
  7. 2004-10-11 9:51 pm
  8. 2004-10-11 9:55 pm
  9. 2004-10-11 9:55 pm
  10. 2004-10-11 10:14 pm
  11. 2004-10-11 10:16 pm
  12. 2004-10-11 10:17 pm
  13. 2004-10-11 10:26 pm
  14. 2004-10-11 10:34 pm
  15. 2004-10-11 10:35 pm
  16. 2004-10-11 11:00 pm
  17. 2004-10-11 11:01 pm
  18. 2004-10-11 11:16 pm
  19. 2004-10-11 11:19 pm
  20. 2004-10-11 11:28 pm
  21. 2004-10-11 11:56 pm
  22. 2004-10-12 12:32 am
  23. 2004-10-12 1:06 am
  24. 2004-10-12 2:28 am
  25. 2004-10-12 3:06 am
  26. 2004-10-12 3:43 am
  27. 2004-10-12 4:12 am
  28. 2004-10-12 5:04 am
  29. 2004-10-12 7:20 am
  30. 2004-10-12 7:33 am
  31. 2004-10-12 7:44 am
  32. 2004-10-12 8:45 am
  33. 2004-10-12 10:44 am
  34. 2004-10-12 10:58 am
  35. 2004-10-12 11:01 am
  36. 2004-10-12 5:12 pm
  37. 2004-10-12 7:22 pm
  38. 2004-10-13 12:32 am
  39. 2004-10-13 6:08 am