FOSS for Life

Fedora is a giant among giants, in the shadow of a giant from which it was born. But every giant is born of humble beginnings.

So to understand the giant, you first have to understand from where they came. So let me take you through a short history of Fedora, and show you where it all began, and some of the interesting, if not curious steps that it took to become what it is today.

To start with the very deepest roots, we need to look to the kernel that makes Fedora what it is: The Linux Kernel. That was first introduced in 1991 by a then college student named Linus Torvalds.

A short time later, the first Linux distros began appearing, starting with MCC Interim, which gave rise to SLS, which in turn was the grandparent to Slackware, the parent of numerous other major distros, including Suse Linux, and the uber geek distro of choice by many senior Linux users.

Red Hat, the parent of Fedora, was a little late to the game, as it didn’t get it’s official start until 1994. But just like Slackware, it quickly became the parent of numerous other distributions, including Caldera, Mandrake (later renamed to Mandriva), Red Flag, and even CentOS.

The original beta for Red Hat was released on July 29th, 1994. The official 1.0 release came out in May of 1995, and was interestingly enough, codenamed Mother’s Day. Whether or not it was actually released on Mother’s Day is a subject of fierce debate, but it is still an undeniably memorable achievement. The biggest reason for this is that Red Hat 1.0 actually beat Microsoft’s Windows 95 to market by almost 4 months, which is actually quite an achievement, considering initial development of Red Hat started after that for Windows 95.

After that, development was fast and furious, with four major versions, and a number of sub versions all being released within an amazing two and a half years. After that, the pace of development slowed into a more predictable, and methodical release schedule, with four more versions appearing gradually over the next five and a half years.

It was shortly after this period of relative quiet that the Fedora project was born. In march of 2003, Red Hat released version 9 of their Linux distribution, and shortly after began a move to migrate Red Hat development from an internal closed development (not closed source) system to an open development system. This gave rise to a separation of Red Hat Linux into Fedora Core and Red Hat Enterprise Linux (RHEL).

From mid 2003 to late 2006, Fedora Core continued forward, separate, yet still intimately connected to RHEL, with Fedora becoming more the step child of RHEL and the preferred distribution for SMB’s and home users, and RHEL remaining the undisputed choice for large enterprise. Then in late 2006, early 2007, a decision was made to shorten the name of Fedora Core to just plain old Fedora. Version 7 of Fedora Core released with the new, abbreviated name.

There has been three versions since the new name was adopted (7, 8 and 9), with the latest version having been released in May of 2008. Fedora 10 is already in the pipes and due to be released in 2009, and it will continue for Fedora what is a project that has been over fifteen years in the making.

But, despite it’s longevity, no distro is complete without a good desktop manager to go with it. For the people at Red Hat, and eventually Fedora, the choice was clear: The Gnome desktop would be just what the doctor ordered. Thus they adopted it as their desktop manager of choice. However, this didn’t occur until 1998, and even then was only offered as a choice for installation.

For anyone using Red Hat at the time, you typically had few choices in desktop environments, with KDE leading the way, and few reasons to want to use one, given that most people who used Red Hat didn’t need a graphical desktop. That’s because most users in 1998 were systems admins, and most Red Hat machines were servers.

But that didn’t stop the adoption of Gnome as the default desktop of choice for Red Hat. Fresh off the development presses, and still green around the ears, Gnome was first offered in Red Hat 5.1 as a preview release, but not officially added as a standard element of the distro until 1999 with the release of Red Hat 6.0.

Again, not many people were using Red Hat as a desktop OS at the time, however, the number had increased enough to warrant the inclusion of Gnome into the distribution. So why Gnome, and not the (at that time) more advanced KDE, or even one of the other window managers, such as AfterStep or TWM. The answer to that lies in the polish and feature set of each window manager.

While good, TWM, AfterStep and others were either too spartan, or lacked the polish that came with Gnome and KDE. Sure, they weren’t perfect themselves by any current standards, but they were a lot farther along than most other window managers or desktop environments.

Once the choice was made, Gnome continued to grow, actually gaining a big boost in developers, support, and even acceptance among the Linux world because of this, growing into the giant it is today. And all along the way, Red Hat, and later Fedora, have stayed strong with Gnome, not wavering from their dedication to it all the way through.

One interesting fact though about the relationship between Red Hat and Gnome, is that while Red Hat used and preferred Gnome as the primary desktop environment of choice for their distribution, they also included KDE as well, and offered it as an alternative for those who wanted Red Hat, but didn’t want the Gnome desktop. They still encouraged users to use and stick with the Gnome desktop, however they didn’t want to shut out anyone if possible, and thus included both.

When the Fedora project was born in 2003, Gnome 2.2 was already available and firmly entrenched in Red Hat, and thus has saved the Fedora developers the interesting experience of moving between major versions of a Window manager, even though that will come eventually in the not too distant future.

Overall, I myself prefer the KDE desktop environment, however, I’m also a firm believer in choosing what you want, and tweaking a distribution your way to meet your needs, therefore I’m quite intrigued and pleased to see Red Hat, and now Fedora, so openly supporting choices such as this in their distribution. Because it’s one thing to say you support Open Source, and something else to actually show it through your actions.

Because Open Source is about choice, and freedom, and the Fedora project (and Red Hat) have both done that in both big and small ways. That is why I believe that Fedora is a great distribution with a great future, and is most certainly a hat with a history.

Another interesting tidbit of history that actually spawned from Red Hat is the RPM package system. RPM stands for Red hat Package Manager. Although it’s not called that anymore, that is the source of it’s name. RPM is both a package management system under Red Hat (and later Fedora) as well as a software package format.

Essentially, the RPM file format is somewhat of a cross between an archive file, similar to Zip or Tar, and an installer file, as it contains both multiple files packaged together as a single file (with the extension .rpm), as well as the necessary information required to install and configure the included files.

The RPM package manager is actually a command line tool designed to take RPM files, unpack them, and then follow the included instructions to install everything to it’s proper location. This essentially works in much the same way as other package systems, like deb, ports and others.

But the RPM package manager doesn’t just install software, it can also uninstall, reinstall, verify, query, and update software packages on the system. RPM is also the standard package management system of a wide variety of other operating systems, such as Suse, CentOS, Mandriva, and more, making it a core standard package management system in the Linux world. It’s also part of the Linux Standard Base, making it easy for other distributions to include at will.

But RPM wasn’t always the default package manager for Red Hat, and later Fedora. Back in it’s early days, prior to version 2.0, Red Hat used a system called RPP. It was a command line tool providing simple installation, powerful query features, and and package verification, all necessary tools for the then emerging Red Hat.

But despite all these great features, RPP was doomed to fail from the beginning, because it was too tightly designed around Red Hat, leading to issues which forced Red Hat to release numerous versions of the same package system in each release just to deal with these issues. This relative inflexibility, along with some other issues, eventually killed RPP shortly after version 1.0 of Red Hat.

To solve the problems of RPP, a new package manager called PM was created, taking the best of RPP, PMS (package management system), and several others, and bundled them together. That system failed to produce good results either.

That’s where RPM came in. With the experience of two failed package management systems behind them, Red Hat developers were able to create RPM, which later launched with version 2.0. While not yet perfect, it was a far cry better than RPP, and a welcome change.

But as with any change, good or bad, some standards need to be created to ensure that consistency is maintained throughout the development process, as everything that is done to a package management system affects everyone from those on top, all the way down to the end user, upstream and downstream developers, and distributors.

So to focus the development of RPM in the right directions, the following five goals were adopted:

• Must work on different processor architectures.
• Simplified building of packages
• Install and Uninstall must be easy.
• All work has to start with the original source code
• Easy verification that packages installed correctly.

This simple set of five goals solidified RPM’s development and easily solved Red Hat’s package management woes very quickly. By 1998, RPM was the official package management system for Red Hat Linux.

RPM proved to be an effective package management system for the next several years. But during that time, RPM lost it’s way, along with Red Hat. As employees began to slip away, Red Hat was forced to take a less direct role, and more of a management roll in RPM’s development, allowing the project to drift off in directions they really didn’t want.

It wasn’t until Fedora became reality that they decided to wrest back control of RPM and retake command of it’s core development. But to do this, they had to take several steps back and fork RPM using the then currently available 4.4.2 codebase. While not the best move, as the code was several versions behind the latest work, it gave them a place to start that was as close to their ideal design as possible. It was also the base code used by both Red Hat and Novell at the time.

And forking a project in favor of improving the end product and fixing development woes isn’t all that bad a thing. Take for example the X project. At version 4.4, Xorg split away from Xfree86, the as then primary Xwindows system, and took development in a direction that was not only requested, but needed as well.

Since the Xfree86 developers dug in their heals and refused to move in the directions requested by the community, Xorg took over as the primary Xwindows system, which then saw Xfree86 tossed to the curb. As a result of that inflexibility and refusal to listen to the community, it’s now a dead project, and Xorg is screaming forward as the Xwindowing system of choice.

However, not all splits have to be detrimental to both parties. Take KDE over Gnome. KDE was the parent project of Gnome, and originally was the only true Desktop Environment in the entire FOSS world. But arguments and debates came up that caused some developers to split off and form Gnome, which in the grander scheme of things has been one of the best things to ever happen to either KDE or the FOSS world as a whole.

And sometimes forks don’t always work. Take Compiz for example. It at one time split into Beryl and Compiz over opposing ideologies and developer quarrellings centered around features that should be included in the eyecandy focused window manager. While both did fantastic by themselves, they eventually saw the need to merge, and shortly after doing so, began a fairly rapid downhill spiral towards death.

Sure, they’re still alive today, but unless something happens soon to change their course of progress, especially with KDE4’s Kwin, and eventually Gnome’s own answer to Compiz coming in the next version, they might soon find themselves as a footnote in history.

But so far, only good things have come of this fork in Red Hat’s RPM system. Not only did they regain control of it, but they’ve offered some much needed improvements in RPM that I, and many others like me, saw were needed. During the years when Red Hat didn’t have control over it (or at least direct control), I saw RPM going downhill as a package management system, so much so that it drove me from having anything to do with Red Hat at all.

And I know I wasn’t the only one. I even retreated to other distributions with old tried and true systems like source building, ports, debian and others partially because of that. There were other reasons, but that was one of the primary reasons. This is mostly because RPM became difficult to work with, unreliable, unpredictable at times, and downright painful to mess with.

However, if handed a system with RPM in it today, I’d have absolutely no issues work with it. RPM has really improved a lot since Red Hat forked it, and should continue to improve over time.

Another big change over time is the number and types of diagnostic tools. During the early days of Red Hat, performance was everything, and squeezing every ounce of processing power out of the limited number of processor cycles available at the time was key to success.

But as time went along, and resources got more plentiful, you began to see the number of actively running resource monitors slowly dropping off. The pictures in this article will show you the gradual decline of these on the desktop in any form of prominence. Eventually, by the time you get to the Fedora days, process and resource monitoring has been shoved to the fringes where it’s used only by those wishing to still squeeze every last ounce of performance out of their machines.

Another gradual, but intriguing change has been in the area of applications. When Red Hat first started out, a lot of applications were console based, including common productivity tools such as word processors and web browsers.

But not everything was text only. Some things, like audio players such as SteelWav, dominated the desktop. These provided the end user with a reasonable user experience without requiring them to become a geek master of the command line.

Same with Mozilla (the original Mozilla, not the modern version) for web browsing. These were great tools in their time, but even they weren’t impervious to the march of progress, as they were later replaced with XMMS and Netscape respectively.

Visual themes were also fairly spartan at first, relying on the older blocky style layouts and designs for buttons, windows and more. Over time however, they evolved into more and more advanced designs, throwing away the old blocky window designs for smoother, more elegant designs.

And Red Hat did not shy away from including these eye candy improvements in their various versions as they became available. This is likely because, a user is most comfortable in an environment that is eye pleasing. As such it reduces fatigue and thus makes the experience more enjoyable for the user. This in turn translates into increased loyalty and productivity.

But the thing is, despite all the amazing things Red Hat has put into their distribution, and later into Fedora, it’s all still about choice, and as such, you can choose to either stick with the designs given to you by default in Fedora (and RHEL) or you can change them to something more pleasing. That’s the joy of Open Source, as it’s about choice.

Say you don’t like something, then change it! We’ve seen lots of change in Red Hat and Fedora over the years, in terms of visual looks, feature sets, support and more, as the community has spoken and Red Hat has listened.

That is why I believe that Fedora is a great distribution with a great future, and is most certainly a hat with a history.

(Authors Note: This was originally written for Linux+ magazine, for their february issue, in celebration of Fedora.)