The RULE default should be one package for each specific task (be it a server or desktop one) according to the following guidelines:
- It must be actively developed, compiled with modern, secure libraries, as few as known security holes as possible
- The most recent stable version must be used, without any specific patches
Remember that we want to make it easier for our users to find support. This means that, as long as it is possible, they have to present themselves on mailing lists with “plain”, well known versions of each tool. This accounts also for the previous criterion.
- Choose applications that achieve greater functionality by linking or smart configuration right after install, not with tons of extra code
(in the scripting sense of the word, i.e. in the rc file or via shell scripts). The toolbox approach rules! It is important to note that all the custom configuration must be done after the packages are installed, as the very last step of the process, and, at least for the desktop ones, only modifying the personal rc files of each normal user whose account was just created. Of course, when it comes to system services like iptables or the SMTP server this cannot work. In these cases, the post install script(s) will copy the original rc file with some other name, and put in its place another one optimized for our scenario. For iptables in the desktop case, this means allowing just client connections to the outside world via ppp0, and unlimited traffic on local LAN (eth0 interface) if present. All this avoids the need of doubling existing RPMs, but still enhances the functionality and user friendliness of the system enormously
- (if not yet availble in rpm format) Integration in Red Hat must be as simple as possible
Avoid programs that do need any library not compatible with Red Hat, or that rely heavily on some not compatible file system structure (you can still nag the developer to change that, of course…)
- When it improves performances greatly, static /prelinked recompilation should be considered In some cases, it may make sense to not rely on already existing rpm packages, and build one by ourselves either statically and/or with prelink, available at [ftp://people.redhat.com/jakub/->ftp://people.redhat.com/jakub/]
The rationale behind this is that on our target desktops it will be very unlikely to have all the possible applications running simultaneously. In such a context, sharing RAM/ libraries among applications is not going to give any significant advantage, so we should investigate, on a per application basis, when prelinking or building one static binary will give us maybe some more RAM consumption, but less disk space and/or startup time. Again, this is something that should be done only when it really makes a difference: it shouldn’t conflict with already existing RPM packages, and most probably be limited to big desktop applications, like for example konq-e.
- External dependencies must be minimal
If package X only takes 200 KB.. after you have installed 30 MB of libraries and similar stuff, it’s probably not a good candidate for RULE. Especially if it is the only package that needs all the others.
- Avoid applications tightly integrated in KDE or Gnome, to limit the amount of needed libraries, see above. The Mini-KDE project here at RULE may partly reduce the impact here. – Avoid applications unnecessarily requiring GTK/QT. With the word “unnecessarily” I refer to those programs which have a GTK/QT toolkit not because they are intrinsically graphical (= Gimp) but because they are front end to tasks that can be performed inside a console.
- In general, whenever possible, character based applications must be preferred. This is not yet another edition of the “console vs GUI” holy war. It is simply that, on the kind of hardware we are targeting, even in X (especially in X) the applications must be as light as possible. Let’s fight swapping on a 2000 rpm hard disk as much as we can, shall we? – Later upgrades to a full blown Red Hat, or adding standard rpm packages with maybe several dependencies must be as smooth as possible