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!
Installation
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.
Heresy!
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/etc.new 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.
Services
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 X.org 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.
Conclusions
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.
nice article to read, and to see that someone thinks the LSB is wrong about how stuff should appear on the system.
Gobonese and rubyxers I totally agree with you.
But I’d have loved to have more deep info on how the init system works.
It sounds interesting, but I just could’nt get it from its short paragraph.
Well, Unununium guys implemented their whole OS in Python. Or at least, a major part of it. That’s a modern trend I guess. The next version of Windows should be a big VB script badly put together.
I might be a BSD hacker, but that is neat. I have wondered what a system that has ruby for everything would be like.
You included ruby in the base. Now the users are stuck with that version forever. Do you have the ruby you use another name? If you include Ruby in the base the users have to depend on that version, and it’s hard to upgrade ruby without breaking scripts. For instance, in FreeBSD 4.x there is Perl. That version had to stay the same forever because of incompatibilities on including such an important program in base. Does this distro/or will it ever suffer from the stale effect? Upgrading the ruby in base is no answer, it will break many programs and administrators scripts.
A++ on accomplishments of the OS though
The project seems pretty interesting but I don’t know how useful it is. Other than a different directory structure it really offers nothing else over gentoo. It also seems to have less prebuilt ebuilds and nothing beats gentoo’s support forums.
Rubyx indeed seems like a very interesting project; too bad I don’t have any Linux installations to start off with.
As for the author: we got the message that you never used Windows.
The problem with the said project is the fragmentation of the current linux base causing confusion.
Just my thoughts…
matty
…sounds quite like Gentoo to me? Or I suppose Gentoo with a more Gobo-like filesystem.
Good to see they’re not worried about convienience – having to download & compile their p2p client in order to download the install files is quite… interesting. But if that’s the way they want it done…
Oh yeah, nice article indeed! If I could only read the mind of my poor harddrive, tormented with at least 5 OS’es this month…I know he knows me…shivers by the thought of his boss sitting at his desk with a huge smile and an upcoming holiday….there goes my free time..*sigh*
verbat: But I’d have loved to have more deep info on how the init system works.
I second, I recently learned that init system is written in Ruby when I visited to its website. I wish, there have more doc about init system.
David Ross: You included ruby in the base. Now the users are stuck with that version forever. Do you have the ruby you use another name? If you include Ruby in the base the users have to depend on that version, and it’s hard to upgrade ruby without breaking scripts. For instance, in FreeBSD 4.x there is Perl. That version had to stay the same forever because of incompatibilities on including such an important program in base. Does this distro/or will it ever suffer from the stale effect? Upgrading the ruby in base is no answer, it will break many programs and administrators scripts.
It is something that I am wondering about it too. I hope, itself ruby can be upgrade by package system or whatever. Push any high level language in the base system is one thing that I always dislike unless itself is a package that will be installed by default.
I find it hilarious that people will go to all the trouble to write a script to handle complex system tasks such as dependancy handling but will not write a script todo trival tasks such as partition and then setting up /etc/fstab. This is not DIY this is just lazyness.
Seems like a fun project for someone who likes ruby.Other than thatI can’t see the value of a system like this. Its not like companies are going to run out and run all their mission critical Application on Rubyx. Ubuntu, Rubyx, etc.. = YALD
Sounds like an interesting project at its early stage, but I think is quite similar to Gentoo, and the latter has momentum on its side. Gentoo docs re really nice and the forums are among the best I’ve ever seen. And yes, Portage has almost every package that one might need
I could use it.
And about Ubuntu, whatever… I hope the day system administration will be automatic comes as soon as possible. Some companies that don’t make money out of the complexity of the systems should provide the needed distros and tools.
That is a simple case of “an itch that doesn’t itch a developer doesn’t get scratched.”
When someone starting a fresh distro writes some scripts, the last thing on his mind (unless it’s the goal of the distro) is to worry about the install. He’s much more interested in writing the system config and scripts for running the machine.
I find it hilarious that people will go to all the trouble to write a script to handle complex system tasks such as dependancy handling but will not write a script todo trival tasks such as partition and then setting up /etc/fstab. This is not DIY this is just lazyness.
What’s the point of a script to setup the /etc/fstab? Setting up the fstab is something you do once, and then you might update again every few months. Whereas installing software you do all the time. So yes, give a higher priority on automating frequent tasks even if they are complex. Dependancy handling is half the reason we use distributions in the first place.
I’m somewhat tempted by this since I’m a ruby fan. Though I don’t really understand how the ebuilds could be written in ruby, with Gentoo they’re written in a python shell script hybrid. But yea, one of the reasons I use Gentoo is its wide selection of ebuilds.
The P2P system sounds kinda cool, though it would make sense to use Gentoo’s system of source mirrors as well (Gentoo is non-profit, sure they wouldn’t mind). Is there a system to prevent P2P poisoning? Gentoo is currently work on this due to some concievable problems with MD5, they’ll probably switch to a trusted key system fairly soon.
Also, I don’t understand how you would login in single user mode given its weird init.d setup as described.
Blixel was just wondering if the author commonly talks about himself in the third person.
the really interesting thing is also the init system, you just skimmed over it, but it seems *way* better than what is usually seen on linux.
Other feature I just discovered: parallel builds/makes/distcc seems something cool, and pkges are installable from *any* user without security/functionality problems.
Does it has a meaning to it?
> Blixel was just wondering if the author commonly talks about himself in the third person.
Sometimes he does, though he much prefers the royal “We”
About the init system – I kind of skimmed over it because honestly I don’t feel qualified to talk about it in more detail. I’m just a user… I hope the creator of Rubyx will chime in with better explanation.
as for package installation, it is handled by a non-root user; in fact the system creates a user for each package it installs. Yes, it means you end up with a lot of users.
At first I thought it was the Japanese katakana character “ka” that is used only for phonetics. But I found it is the word “chikara” that means force or strength. The two symbols looks the same.
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/84470
What a disgusting way to manage a system, with symbolic links all over the place. Gah, I hope I never have to administrate something like this. I get annoyed with sparse files everywhere as much as the next guy, but thankfully good install scripts/package managers can make it easy to find things.
But config files REALLY need to be in one spot. I love how RH dumps so much into /etc/sysconfig. Wanna know why this helps?
tar -cvjf etc-data-hostname.tar.bz2 /etc
That command can save 90% of my configuration time should my hard disk die. I’m sure they link it all well, but the thought of all those links scares me.
I would like to see non-library apps become localized in their directories, but libs should throw files every which-way. Then just throw a symlink in /usr/bin/ to their exe.
It’d also be cool if everyone added something like this to makescripts:
echo “Just type ‘program_command’ to execute”
If you check out man tar, I’m sure tarring up the files the symbolic links point to is trivial. Symbolic links aren’t that big of a deal or that messy really.
And give that (made-up statistic) 95% of users don’t compile anything themselves, adding information at the end of Makefiles would be a bad habit for developers to get into. All that should be in the README.
“I find it hilarious that people will go to all the trouble to write a script to handle complex system tasks such as dependancy handling but will not write a script todo trival tasks such as partition and then setting up /etc/fstab. This is not DIY this is just lazyness”
How exactly would you suggest this script works? It has to set up your partitions (and hence fstab) given that the user may wish for one / partition, or that and /usr, or that and /home, or a few other combinations. They may also have partitions on the hdd already; there may be more than one hdd involved; or quite a few other scenarios I can’t think of now.
Ultimately this script would ask so many questions it’s not much easier than doing it manually. And given that users have to download and compile a p2p client in order to install this distro, I doubt it’s really a problem for them.
I believe it’s for the reasons David Ross mentioned that DragonFlyBSD is IIRC trying to remove all dependency from Perl and rewrite eveyhting in pure /bin/sh. Could be wrong.
Gobo always intrigued me, but I’m not a big fan of all the symlinks, it seems like a hack to me. I’m sure it’s the easiest option, though. Together with the init system I think I’ll have to give this a try.
Does anyone know if it’s fairly doable with dialup? I don’t mind the wait, but I couldn’t deal with Gentoo’s behavior. That is downloading package one and compiling it before it goes on to compile package two instead of downloading package two while package one compiles. Maybe this isn’t the case anymore, I haven’t tried since… I think 1.4
Michael, I can’t say I ever tried it, but I suspect White Water would not work over dial-up, just like you can’t really use bittorrent on dial-up. So Rubyx might not be the best option for you. However you could try Gobo – their live CD can be downloaded over ftp; it will take whatever it takes, but at the end you’ll have a pretty complete system on the CD. As to what you said about Gentoo – yes, I think it still behaves this way. But you could try distros from the Sorcerer family: Sorcerer, Lunar and Source Mage. They all have enough smarts to continue downloading other packages while compiling the first one.
As said Perl –> Shell was done in FreeBSD not DragonFlyBSD, I remember it because at the time FreeBSD developers said repetively that they were rewriting in shell not because they don’t like Perl, but to allow the user the freedom to choose its own version.
Still, I think the problem could be reduced by putting the Perl/Ruby interpreter in a different location that the package use for downloading new user version, and put the path of the “system” interpretor in the system scripts (#!/system/ruby).
This will prevent a boot problem whatever the user download, but I think that if they invoke a system script for their user Ruby/Perl interpretor there could be problems as it would be the user interpretor which would be used..
Still it is better that not booting, well unless the user modified a system script and tested it with the user interpretor..
I can see what he is trying to accomplish with that layout change. However as would most certainly be the case, he will always be fighting an up hill battle. He will have to repackage every package upon every update.
The way I see it he notices what I have thought for some time now … ever since I was introduced to the Plan9 archival file server concept present in Venti. The idea of having a write-once, never-have-to-replace base system I imagine would make life a lot easier when dealing with installed out dated programs that reference depreciated libraries or multiple versions a program.
For those who may not be familiar with it, “In this system, a unique hash of a block’s contents acts as the block identifier for read and write operations. This approach enforces a write-once policy, preventing accidental or malicious destruction of data. In addition, duplicate copies of a block can be coalesced, reducing the consumption of storage and simplifying the implementation of clients.”
What this means is that with a rather limited amount of additional space you could have multiple versions of the same file, much like the way snapshots work except on a block level there would be absolutely no duplicate data, thus being highly space efficient.
One thing to be considered is that there would then be no need to use symbolic links, instead programs would link to the file they wanted and be able to get the version they need. The Plan9 binding approach comes to mind, where all relevant bin directories are bound to a single location.
There would need to be some thought put into how this would be implemented. But not much change as I can see rather simple approaches to take. If successfully implemented there would not need to be any fragmentation of the LSB since developers could continue using the standard locations. No packages would ever have to break given the fact that their required version can always be accessed.
That’s where I think Gobo and Rubyx are trying to go, they just dont know it yet …
From the Gentoo Handbook (that thing you read before you install Gentoo
[quote]
If you want emerge to download the sources before you continue (for instance because you don’t want the internet connection to be left open while you are building all packages) you can use the –fetchonly option of emerge which will fetch all sources for you.
[/quote]
Wondering how you could miss this and still install Gentoo
Hi,
I’m a Rubyx fanatic since my first install of it. I’m running it on all computers at home, and having tested for a while, I’m now sure that it is stable enough to put on my clients’ servers as well.
As the author of the article points out, this distro is not for the newbie or users that likes to rely on GUI utilities, but power users concerned about the system integrity will find a really nice system in Rubyx.
Many of the comments mentions that it sounds just like Gentoo with much fewer packages, but a Gentoo and Rubyx system differs _a lot_. They have in common building from source and dependency handling, but that’s mostly all. Even do I haven’t got much experience using Gentoo, I have noticed that Gentoo packages usually tends to patch and change things quite a lot. Rubyx packages is as much unchanged as possible from the default source installation, only applying additional patches and non-standard configurations when absolutely necessary (example: xv is patched to allow viewing png files among others).
Many of the packages currently not in Rubyx are developed by the users, and waiting for review in order to make sure that everything works as it should, providing a painless user experience. Many packages not officially added can be found in the mailinglist, make sure to check it out.
As for the lack of runlevels, I think that most users would have the need for mostly two, single user mode and full mode. Rubx doesn’t have a builtin single user mode (I think
, but one can always supply init=/bin/bash to the kernel at bootup, and that provides a much more failsafe mode than runlevel 1 in most distributions.
>>Even do I haven’t got much experience using Gentoo, I have noticed that Gentoo packages usually tends to patch and change things quite a lot.<<
Is this a negative thing about Gentoo? I would call this actvitiy or work in progress
Wondering how you could miss this and still install Gentoo
Like I said, it’s been quite some time. I’m fairly sure that wasn’t in the handbook when I installed it. But then, I’m not perfect, maybe I did miss it.
>>Even do I haven’t got much experience using Gentoo, I have noticed that Gentoo packages usually tends to patch and change things quite a lot.<<
Is this a negative thing about Gentoo? I would call this actvitiy or work in progress
Everyone’s needs are different, why can’t they both be advantages? Personally I prefer unpatched packages, since it both seems easier to find solutions to problems, and I feel less hesitant to submit bug reports or ask developers questions.
But then, I see the advantages of heavily patching applications too: fixing distribution specific bugs and fitting everything together more cohesively, though I don’t know how much of the former you’ll have without the latter.
This is just one of the many reasons there’s such a wide variety of distributions.
>> Is this a negative thing about Gentoo? I would call this actvitiy or work in progress <<
I’d say that “work in progress” would be fitting, as the Gentoo systems I’ve seen has been quite broken with all patches that hasn’t been thoroughly tested with all other software that also doesn’t behave as expected from time to time. It is also very hard to use a Gentoo system when coming from much every other distribution, as the “standard” applications often behave very differently.
Mind that I do separate the distribution software itself and the applications. The Rubyx distribution software is quite different from “regular” distributions
This system seems to have the same problem that gentoo has: One god tool to handle everything related to the system.
The unix filosofy of having small ‘perfect’ tools is not that bad. Why must pepople break it all the time?
Buy creating god tools like this you just create restrictions.
What the OSS world needs is interfaces between the components, not reimplementation of them in every god damn distribution.
How does this compare with the other source based distros (Gentoo, Slackware, LFS, etc), as I didn’t really see any mention of them in the article…this does seem like an interesting distro and I’ll maybe check it out?!
Michael
http://phantasyrpg.com/main.php?view=9898
Um, Slackware is not a source-based distribution. It for a long time has used binary packages identical to gzipped tarballs of binaries with a simple script to set up symlinks.
Michael Salivar
Does anyone know if it’s fairly doable with dialup? I don’t mind the wait, but I couldn’t deal with Gentoo’s behavior. That is downloading package one and compiling it before it goes on to compile package two instead of downloading package two while package one compiles. Maybe this isn’t the case anymore, I haven’t tried since… I think 1.4
CHK this Link 😉
http://sourceforge.net/projects/appear/
<u>A frontend written in sh which makes Portage (the Gentoo Linux package manager) much more efficient by backgrounding downloads and allowing for automatic prelinking of packages.</u>