THE RULE PROJECT: Run Up2date Linux Everywhere
Home page	Installers	Mailing list	Docs and Wiki	App. DB	FAQ
Site map	Package selection	Package list	Download	News	Tasks/todo

We have to choose 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, with as little as possible known security holes.
• 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. (NEW) 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 frieldnliness 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...) (NEW) 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;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

Avoid applications tightly integrated in KDE or Gnome

Avoid applications unnecessarily requiring GTK/QT

In general, whenever possible, character based applications must be

chosen.

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