Building a customized Linux distribution with packages from early 2002 for my retro PC

In my previous blog post I have explained that between 2001 and 2009 I used to deploy custom Linux distributions based on Linux from Scratch to most of my personal systems. To make this process manageable I have built an automation tool that I recently gave its own name: The Conservative Build Tool (CBT).

I have not been doing any Linux from Scratch deployments in many years, but recently I have found another use case: I wanted to build an idealized Linux system with packages from early 2002 for my retro PC containing hardware components from late 1999, early 2000.

I faced a similar issue as in 2001 -- I could not find a Linux distribution that fully matches my wishes. Slackware 8.0 came close but there were some things that I wanted to be different, such as: KDE 2.2.2 instead of KDE 2.1, sysvinit-style init scripts rather than BSD-style init scripts, and optimized packages (instead of i386 builds, I want packages to be better optimized for a Pentium III CPU).

Moreover, I have also explained in my previous blog post that it is sometimes a challenge to deploy external packages that are not part of a Linux distribution, especially in the early 2000s. These software packages (including all their missing dependencies) need to be built from source code. Although many source packages can be deployed in a straight forward way, you may still face all kinds of complicated technical issues.

Furthermore, I consider it a gift that it is possible to build a system entirely from source code so that it can be studied and modified.

As a result, I have decided to recreate and deploy my own customized 2002 retro Linux distribution based on Linux from Scratch. In this blog post, I will give an overview of its features.

The Desktop Linux experience in the late 90s, early 2000s

You may probably wonder why I want to construct a Linux distribution for this time period. As of today, Linux still did not become a dominant end-user desktop operating system.

Nonetheless, from an end-user perspective there were some interesting Linux and free and open-source software milestones in the same time period that my retro PC was mainstream:

• Mid 1998, KDE 1.0 was released providing a fully featured desktop environment with an experience comparable to Windows 98, the then most dominant PC operating system.
  
  Although the Common Desktop Environment (CDE) already existed before 1998 that became a standard on most commercial UNIX-derivatives (such as Solaris, AIX and HP-UX), its drawback was that it was proprietary software. As a result, it never became popular on Linux.
  
  Before KDE, people typically use the X Window System combined with an external window manager package and random applications.
  
  (As a sidenote: although the KDE's desktop packages were free/open-source the underlying toolkit: Qt 1.0 was not -- it prohibited commercial use).
• In response to KDE's controversial choice of using Qt, the GNOME desktop was developed that only consists of free and open-source components. GNOME uses the GTK+ toolkit that was specifically developed for the GIMP. Version 1.0 was released early 1999.
• KDE 2.0 was released late 2000, improving its desktop experience and fixing the licensing issue with the Qt toolkit -- Qt 2.0 also offered the GPL version 2 as a licensing option. As a result, KDE 2.0 became completely free and open-source.
  
  Although it was good news that the licensing issue was resolved, GNOME's development did not stop. As of today, GNOME and KDE are still the two major desktop environments for Linux systems with their own application eco-systems.
• Microsoft extensively used the dominant position of its Windows operating system to give its own products advantages over its competitors. For example, bundling Internet Explorer with Windows helped Microsoft to push its biggest competitor: Netscape out of the market.
  
  As a result, some of these Microsoft competitors were actively looking at Linux as an alternative. As a result, some well-known commercial products became available on Linux, such as: Netscape, Adobe Acrobat Reader, Real Player and Corel WordPerfect.
• In late 1998, a Linux game company was founded: Loki Games that ported a number of well known commercial Windows games to Linux. Unreal Tournament and Quake 3 arena were amongst my favourite games.
  
  Although Loki Games failed from a commercial perspective and went out of business early 2002, its legacy lives on -- in addition to porting games, they also developed technology to make Linux gaming possible, such as Loki setup tools, SDL, and OpenAL. These packages are still prominently used today.
• Netscape eventually decided to develop the successor of Netscape 4.x from scratch and do the development in the open. They called the open-source foundation of their browser: Mozilla.
  
  Netscape 6.x and 7.x were basically branded versions of the Mozilla Application Suite. Although Netscape could not regain any significant market share with this move, the good thing is that by opening up the code, a fully featured free/open-source browser became available that could rival Internet Explorer that gained 95% market share in 2003. Mozilla 1.0 was released mid 2002.
• The same applies to office suites. In 1999 Sun Microsystems acquired Star Office, a commercial office suite that is comparable in features to Microsoft Office. Star Office was open sourced as OpenOffice.org and Star Office became a branded commercial version of it. OpenOffice.org version 1.0 was released in May 2002.
• There were also plenty of community developed free/open-source end-user applications that worked decently, such as XMMS which was my favourite music player at that time. Its graphical user interface was inspired by WinAmp, a popular music player on Windows.

Naming my custom Linux distribution

In my previous blog post, I have explained that my custom developed build automation tool was originally named after my custom Linux distribution. Since it can also be used on top of any conventional Linux distribution, I have decided to give it its own unique name: the Conservative Build Tool (CBT).

My custom Linux distribution also had various names. In the beginning I gave it the name: UL-Linux.

What does "UL" stand for? I really don't know for sure :-)

The 'L' probably refers to Linux and the 'U' to something ambiguous. It may refer to "Ultimate" because it gives you full control over the components in a Linux system including the underlying source code. It may also refer to "Unusable" because the distribution is very advanced and you could easily get lost in all possible configuration options, including invalid ones. :-)

After UL-Linux I gave my distribution several other names, but I believe these are no longer appropriate. IMO my first name still mostly reflects its strengths and weaknesses, so I have decided to stick with that.

A tour of features

The UL-Linux distribution has a variety of interesting features demonstrating the capabilities of Linux systems in the late 90s, early 2000s.

Based on Linux from Scratch 3.3 with a modified deployment procedure

I have used an old version of Linux from Scratch as basis: version 3.3 to be precise. The main reason why I selected this particular version of the book is the GNU build toolchain that consists of the following components:

• GNU Binutils 2.12
• GCC 2.95.3
• glibc 2.2.5

The above components in the above version ranges were prominently used between late 1999 and early 2002. Quite a few commercial software packages were compatible with it, such as games from Loki games. As a result of having this old tool chain, installing and running these commercial software packages should not be a problem.

Version 3.3 of the LFS book has a number of drawbacks. In addition to using old/outdated packages it has the following issues:

• It uses a bootstrap procedure that relies on statically compiling a number of packages in a single pass for setting up a base system.
  
  The downside of this approach is that the resulting binaries still have a strong connection to the properties of the host system, such as its glibc version. Moreover, the ability to successfully compile these packages heavily relies on the versions of the host system's GNU build toolchain making it hard to guarantee a successful outcome.
  
  To cope with older versions of compilers, the LFS project provides patches to avoid certain compilation problems.
  
  In general, using a single pass approach means that it is hard to ensure that all packages will compile on the host system and that they will behave in the same way when entering the chroot environment.
• It symlinks /etc/mtab to /proc/mounts to keep it consistent, but that choice breaks certain applications

I have created a revised deployment procedure that integrates the ideas of the mtab-pre-lfs-4.1.txt and pure_lfs.txt hints. The former hint corrects the mtab problem by making it a standalone file again, rather than a symlink to /proc/mounts.

The hint also aims to be more FHS-compliant by putting the file in the /var directory that is supposed to be writable, rather than /etc that can also be stored on a read-only file system.

The other hint describes a more robust bootstrap strategy that became a standard practice in LFS version 5.0 and newer. First, the GNU build toolchain is built from source code: GNU Binutils, GCC and then glibc. The first two packages still have a runtime dependency on the host system's glibc.

Then the GNU build toolchain is built again in a second pass by using the tools from the first pass: first GCC, then GNU Binutils. In the second pass, the latter two packages are built in such a way that they have a runtime dependency on our custom built glibc eliminating the dependency on the host system.

The remaining bootstrap packages are built using the GNU toolchain constructed in the second pass to create a minimal system that can be used in a chroot environment.

Finally, we can enter the chroot environment and use our minimal system to build all packages from source code.

Because our desired GNU build toolchain is used early in the process and the dependency on the host system's glibc is eliminated early in the process, the bootstrap is more robust and cleaner.

Slackware package manager

As explained in my previous blog post, the default package manager that my custom Linux distribution uses is the Slackware package manager.

Although this package manager is primitive from a feature perspective, e.g. it does not have a notion of dependencies, the reason why it was selected is because it only relies on a Bourne-compatible shell and some common command-line utilities, such as tar. As a result, we can use it very early in the distribution's deployment process.

Another advantage is that it can be easily used in combination with another tool: checkinstall -- checkinstall records file modifications of an installation process, such as: make install and is capable of automatically creating a package for the host system's package manager so that the package's life-cycle can be managed.

More advanced package managers, such as RPM, have more complex dependencies making the bootstrap of a Linux distribution more complicated.

In addition to the Slackware package manager, the UL-Linux distribution also contains RPM as an optional package that can be used alongside the default package manager.

Display systems

As an end-user, you most likely want to use a graphical desktop environment and use graphics. This distribution includes a number of display systems. Most prominently, it includes XFree86 version 4.2.1, a distribution of the X Window System.

Furthermore, it includes a number of other display backends:

• aalib, which renders graphics as ASCII Art
• svgalib which directly talks to SVGA-compatible hardware
• DirectFB which is an abstraction built over the kernel's framebuffer infrastructure

Some applications and libraries can also use the above display systems in addition to (or as a replacement for) XFree86. SDL supports multiple video backends and has support for all these options. MPlayer (a movie player application) also supports the above outputs.

Window managers

As explained earlier, Linux and many other UNIX-like operating systems, such as FreeBSD, do not have a standardized desktop for various reasons.

Partly, this is caused by the fact that the X Window System is simply just a component in the graphical desktop solution stack, not a full desktop. For example, the responsibility to manage window decorations is delegated to an external program called a window manager. As a result, there are many kinds of window managers available.

There are a number of simple window managers included in the UL-Linux distribution for various reasons:

• TWM (Tab Window Manager) is included as a primitive example window manager with the XFree86 distribution. It lacks some usability properties, such as a close button. It mostly serves as an example to show developers how a window manager can be implemented.
• MWM (LessTif/Motif Window Manager) which is included with Lesstif, a Motif-compatible GUI toolkit implementation. Similar to TWM, it mostly serves as an example to show developers how a window manager can be implemented.
• fvwm95 is included to provide a simple desktop experience. In combination with simple X11 applications, such as xfm, xpaint, xfig and xpdf, you can have a decent desktop experience on low-end (retro-)computers.
• WindowMaker provides a desktop experience comparable to NeXTSTEP. Some simple applications that are developed for WindowMaker are included, such as FSViewer.app (a file manager) and wmtime (a time widget).

Desktop environments

In addition to simple window managers, I have also included the two major desktop environments:

• KDE 2.2.2 which is the latest version in the 2.x series
• GNOME 1.4.1 which is the latest version in the 1.x series. It also includes the Nautilus file manager. Several packages have been updated to make newer versions of certain GNOME applications work properly

I have decided to include both desktops, because both are historically important. Moreover, I have applications that fit in both eco-systems.

Display managers

By default, my Linux installation uses runlevel 3 that provides a textual login. It is also possible to pick a display manager and switch to runlevel 5, that facilitates graphical logins.

There are multiple display managers supported:

• XDM is a display manager included with the XFree86 distribution
• KDM is a display manager included with KDE and primarily developed to start KDE sessions
• GDM is a display manager included with GNOME and primarily developed to start GNOME sessions
• WDM is a display manager using the WINGs GUI toolkit included with WindowMaker and primarily developed to start WindowMaker sessions

XDM is only capable of starting one kind of session type. Although the other display managers are primarily developed for one specific desktop type, they also have the ability to launch multiple kinds of desktop sessions.

In my custom Linux distribution, I have included a tool that makes it possible to configure the display managers in such a way that it becomes possible to launch any kind of window manager and desktop environment that is supported on the system.

As a result of using this tool, it is also possible, for example, to boot into GNOME using KDM, or to conveniently switch from a KDE session to a GNOME or WindowMaker session, which is really useful for experimenting with multiple window managers and desktop environments at the same time.

Applications

My custom distribution contains some historically important applications, such as:

• The GIMP, a popular image manipulation program.
• XMMS, a popular music player with a similar GUI as WinAmp.
• Mozilla 1.0, the first stable release of a fully featured free and open-source browser that originated from Netscape.
• OpenOffice.org 1.0, the first stable release of a fully featured free and open-source office suite that originated from Star Office.

More features

In addition to the mostly visual features shown earlier, my custom distribution has many more features that are hard to visualize:

• In addition to GNU Bash, my custom distribution also contains tcsh as an alternative shell using a C-like syntax. It also includes the Almquist Shell (ash) as a primitive Bourne-compatible for development purposes to test whether shell scripts are POSIX-compliant.
• It contains various kinds of server components, such as OpenSSH, Apache HTTP server, proftpd, Samba and rsync. The reason why I have included these packages is not to encourage people to use a legacy Linux distribution to run a server. As a matter of fact, people should definitely not use them for production purposes because these packages most likely contain security bugs. The main reason is that some of these services are run-time dependencies of existing packages, such as the GNOME and KDE desktops. Furthermore, some services are convenient for file exchange, such as OpenSSH and FTP.
• I have also included many kinds of network clients. Some of them are dependencies of existing packages, others are convenient for file exchange.
• I also included minicom and lrzsz to make terminal connections possible and file transfers using the ZMODEM protocol.
• In addition to the shells and the programming languages supported by GCC (C, C++, Objective C, Fortran), I have also included packages to support the following programming languages: Perl, Python, Guile, librep, Java 1.4, bc, S-Lang, and tcl.
• There are also various kinds of development tools included, such as gdb, DDD, valgrind and strace.
• Another nice but somewhat unconventional feature is that the binfmt_misc kernel module is prominently used. I have developed a plugin system to easily configure it -- if I install the Java Runtime Environment, then I can start Java class files and executable JAR files as ordinary executables. If I install Wine, then I can start Windows executables as ordinary executables.

Conclusion

In this blog post, I have explained my motivation for constructing a historical custom Linux distribution from scratch (from early 2002) and explained the properties of my custom distribution.

It may probably already be obvious, but this is a historical Linux distribution -- it should not be used for production purposes, so you have been warned! I consider this project to be mostly an "interactive historical museum", not the recommended way to do modern work.

Availability

Previously, I have published CBT, the build automation tool that I used a long time ago to roll out custom Linux distributions and packages from source on conventional Linux distributions.

I have now also published my configurations repository for CBT that contains a deployment configuration for my custom Linux distribution and an extra package set with applications that can be installed on top of it.

I have also written an LFS hint that describes my modified LFS-3.3 deployment procedure -- I have contributed the hint to the Linux from Scratch project and it was accepted into their hints repository.

Although I have published my CBT configurations, I did not publish the source tarballs. In the unlikely scenario that you want to deploy this distribution yourself, then you need to obtain the required source tarballs yourself. Although my tool automates the construction of the packages, it unfortunately does not include any download functionality.

Most of the source packages are still available from their original locations or other well-known software repositories -- for example, you can still download old Linux tarballs from the Kernel CDN, and most of the old GNU packages from the GNU download server, although some tarballs have been moved to a different directory. Unfortunately, some packages are really hard to find. I recommend to use the Internet Archive to retrieve these missing packages.

I also know that there is an initiative to archive software: Software Heritage. Unfortunately, it seems that they have not archived most of the old packages that I care about (yet). I am also not sure if there is a way to contribute these missing source packages to them.