Pynix.org: Whitepaper

Pynix - A Generic Linux Distribution

Why Another Distribution?

There is a joke that there are at least as many different Linux distributions as there are Linux users. While this may be exaggerated, the number of Linux distributions is indeed impressive.

However, if you take a closer look, you will notice that actually there are not so many distributions that are truly different. A close examination reveals that most of them are actually familiar. These distributions are derived from one of the few original distributions, i.e. they use another distribution as the basis for customizations.

The Focus of a Distribution

Derived Linux distributions usually have a specific focus. For example, Adamantix is a Debian-based distribution focusing on security, and LTSP is a RedHat variant focusing on X terminals.

Ultimately, the most popular distributions (RedHat, SuSE, Debian) also have a specific focus: the easy installation on individual desktop machines or servers.

Pynix also has a specific focus: the deployment in appliances. Contrary to what it seems to be at first glance, an appliance is more than merely a preinstalled server. In contrast to an individually installed server, the objective is to equip many servers with the same software and maintain them over the entire system life.

Many providers of appliance solutions use one of the known distributions as a basis for their system. The following paragraphs show why this is actually not a good idea.

What Is a Linux Distribution?

A distribution is not merely a collection of software packages. Rather, a distribution defines a framework in which individual packages are installed and run. This framework is outlined by the standard libraries, the compilers, and other utilities provided by the specific version of the respective distribution.

Of course, there is much room for variety, e.g. the way how the file system is organized or how the initialization process works. FHS (Filesystem Hierarchy Standard and LSB (Linux Standard Base) are just some of the efforts made to standardize the environments.

Generic Distributions

Usually, the framework defined by a specific distribution is quite rigid, especially if compatibility with the standard distribution is desired. This is exactly the reason why there are so many derived distributions: sooner or later, developers came to a point where they had to leave the confines of the base distribution.

In generic distributions, the framework defined by the distribution is not quite as rigid. Though the distribution still determines utilities such as the package management or the initialization sequence of the system, it does not define which packages and which package versions are used.

To enable this, it must be possible to create the distribution from scratch. This is the case with Gentoo Linux, OpenBSD, FreeBSD - and Pynix.

The system used for building packages is an important component of a generic distribution. "Normal" distributions do not have this feature, at least not in the depth needed for a generic distribution.

For example, dpkg or rpm can build binary packages from source packages, but this only works with individual packages, using the libraries and tools of the build system.

Unlike Gentoo¹ or OpenBSD/Free-BSD, which mainly compile and install software for the own system, the build process of Pynix can also deliver binary packages intended for installation on other systems.

Another feature of Pynix² is that the source packages are kept in a CVS repository. Thus, all package versions are available, not only the latest version. This is an important aspect for an appliance product. For example, a certain product may require a very specific library version, because an external product (whose sources may not be available) requires precisely this version.

A pleasant side effect of the approach of a generic distribution is that the individual packages use consistent features ³ and versions of libraries. A "normal" distribution does not have this capability, which is most likely the reason for the large number of distributions derived from a standard distribution.

Who Needs Generic Distributions?

Generic distributions are only needed for special utilization purposes. Standard distributions are fully adequate for typical (end) users. The distributor makes sure that individual software packages, especially security patches and the like, are kept up to date.

For an individual installation, generic distributions are usually too unwieldy, as the packages must first be compiled for the own environment.

The situation is different for providers of special solutions - the appliance sector. For many purposes, common distributions are simply not flexible enough. Thus, Pynix enables the compilation and maintenance of a Linux distribution especially adapted to a specific product.

The (Un-)Necessity of Distribution Versions

The version of a distribution also defines which program and library versions are contained. In a specific version, packages of a certain version are usually not replaced by newer versions, as the behavior or configuration of a newer program version may be different from that of the previous version.

Unfortunately, the authors (or maintainers) of a package usually offer security patches for the latest version only. For providers of standard distributions, this generates a considerable workload, as these patches must be specifically adapted for every distribution version that is (still) supported.

The main reason for the maintenance of distribution versions (some of which are several years old) is that the standard distribution does not have a mechanism for configuring the individual software modules. The implementation of such mechanisms if very time-consuming and virtually impossible to handle in view of the large numbers of packages.

The availability of a mechanism for the system configuration is a key characteristic of an appliance. Thus, the configuration mechanism can easily conceal or compensate for differences in the type of configuration of behavior of an individual program ⁴. For this reason, an appliance does not require strict version compatibility of the individual packages, as long as the overall consistency of the product is guaranteed, i.e. the packages and configuration mechanism.

The End of the Packaging Craze

Compared to other distributions, Pynix has relatively few packages. For one, this is because of its alignment for server operation, but also because no alternative packages are provided for a certain function.

Thus, Pynix delivers only one SMTP daemon (Postfix), only one IMAP server (Cyrus), and only one FTP server (Proftpd). Of course, the selection of these packages is partly a matter of taste, but is often determined by the intended utilization purpose.

The main objective is not primarily to achieve an absolute minimum of packages, but to include as few packages as possible while providing maximum functionality, stability, standards compliance, flexibility, and security.

For example, you could set up a web server using one of the many "miniature" HTTP servers, or you could use an e-mail program that can only send e-mail. However, you would quickly realize that the respective program is rather limited in some respects. As such "miniature" servers are not very flexible, they are not part of the basic Pynix system.

On the other hand, special packages can easily be integrated in the system. Additional software or software for special purposes can be managed in a separate CVS tree⁵.

Special Features

The build system of Pynix is CVS-based. The packages are compiled in a "chroot" environment; thus, interferences with the software on the build host are virtually impossible.

The result of a build is an "Apt tree" with the new (and possibly old) packages as well as an installation image for the target system.

Kinship

Though Pynix is built from scratch, it makes use of a number of components or ideas from other distributions:

The package management and the basic system structure (initialization, etc.) come from Debian.
The mechanisms for starting and stopping background processes come from SuSE.
Patches for various programs come from several distributions.
Pynix has many concepts in common with Gentoo.
LFS (Linux From Scratch) provided a lot of hints about how to get everything started.

SuSE Debian Gentoo Pynix

Binary packages Yes Yes No Yes

From scratch No No Yes Yes
Suitability for appliances - - +⁶ ++

Image mechanism No No No Yes

Mechanism for binary package update No APT No APT

Mechanism for source package update No APT Rsync CVS/CVSup

Build system No No "emerge" Yes

Product-versioning support No No No Yes

Focus End users, server/desktop End users, server/desktop Experienced users, server/desktop Experts, server appliances

Notes

1. There are also some other distributions of this kind, but Gentoo has become the best known. (back)

2. BSD systems use the same principle. However, Gentoo uses "rsync" to distribute the sources. Therefore, one could speak of a specific Gentoo version (more correctly: a specific time). In contrast, there are no specific Pynix versions. Rather, there are products containing a certain collection of Pynix packages - the product has a specific version, Pynix itself does not. (back)

3. The enabling and disabling of certain features is much more distinctive in Gentoo than in Pynix. (back)

4. This feature is used extensively in BenHur II, the most important Pynix-based product. If possible, the current version of a package is used instead of patching an older version. (back)

5. For example, there is a subtree containing X11, Gnome, KDE, and various other desktop applications, mostly things the Pynix developers need for their daily work. (back)

6. Binary packages missing. (back)