Fedora Myths
There are many myths about Fedora floating around. Some of them started out as facts that have changed long ago, others start out as rumors or misunderstandings. Some are just FUD spread by people who don't like Fedora. Here, we attempt to address some of the myths we have heard.
Contents:
MYTH - Fedora is unstable and unreliable, just a testbed for bleeding-edge software
FACT - This misconception comes from two things:
- RHEL is derived from Fedora every few releases.
- Fedora has rapid releases, a short life-cycle, and a lot of new code.
As for the first item, this means that Red Hat uses Fedora as a platform to promote the development of new technology, some of which might end up in Red Hat Enterprise Linux, derivative distributions of Fedora and other Linux distributions. This does not mean that Fedora is untested, it simply means that Fedora is a rapidly progressing platform.
For the second item, this does mean that Fedora is often running in uncharted innovative territory, but not that it is using too-new code. The programs in Fedora are generally stable releases or well-tested pre-release versions. There are guidelines behind the inclusion of pre-release software, and thorough testing is always done prior to Fedora releases. Refer to http://fedoraproject.org/wiki/QA for our extensive quality testing practices.
Each version of Fedora receives updates from the Fedora development community for a time period of two subsequent releases plus one month--approximately one year.
We do everything we can to make sure that the final products released to the general public are stable and reliable. Fedora has proven that it can be a stable, reliable, and secure platform. Many businesses and organizations rely upon Fedora for both day-to-day tasks and, in some cases, critical infrastructure. Additionally, our well-managed packaging and review process adds an extra layer of safety not found in some other distributions. You can count on Fedora.
MYTH - Fedora isn't true to Free and open-source philosophy, or isn't really community-driven
FACT - Red Hat is the primary sponsor of the Fedora Project, and does control many aspects of the project. This leads to the view that Fedora isn't really community-driven. This simply is not the case. Red Hat's position with Fedora only aids to provide stronger management and direction than many other Open Source projects enjoy. Red Hat's interests are the interests of the community, and the community is given a great deal of power over what happens with Fedora. As an example, Fedora has thousands of packages maintained by hundreds of volunteers from the Fedora community.
Red Hat has always contributed a huge amount of development directly back to the community. Much of this work has become part of Fedora, and is evidence of the dedication of all of the contributors to the principles of Free and Open Source. Refer to http://fedoraproject.org/wiki/RedHatContributions for more details.
Fedora itself is a completely Free and Open Source project. Fedora has a publicly-available CVS repository, and the source code for every package is readily available. All code must be covered by an Free and Open Source license for inclusion in Fedora, guaranteeing your rights to modify and redistribute the software. The only things that are controlled are the Fedora trademarks. These protections are in place to ensure the integrity of the Fedora name, nothing more.
MYTH - Fedora doesn't include software that it could
FACT - One of the primary aims of the Fedora Project is to provide an open operating system that can be freely distributed and modified by anyone, wherever they are in the world. We encourage anyone who wishes to see a Free and Open Source software product included in Fedora to join the Fedora Package Collection project, but the Project cannot accept packages that include features with potential legal liabilities. The ForbiddenItems page describes some of the legally problematic packages, and lists the Open Source alternatives that we provide.
For example, Fedora includes several media players which support a wide range of free and open formats, but does not include any proprietary technologies. Supporting these audio and video formats allow us to ship a multimedia-capable desktop that anyone, anywhere, can use and modify. The Fedora Project realizes that some users need to use the proprietary formats that we are not free to ship, and so we provide media players that are extensible via plugins. This allows third parties that are able to legally distribute codecs for these formats to make them available as plugin packages that work with our media players.
In general, the restrictions described on the ForbiddenItems page are intended to protect global distribution and use of our software. Laws vary between jurisdictions, and lawyers may have differing interpretations, requiring the Project to adhere to more restrictive rules than others might choose to apply.
MYTH - Installing software is difficult, and RPM is the problem
FACT - Fedora provides the yum utility for managing software. Like apt, Red Carpet, and other Linux software management systems, yum uses repositories of packages to automatically locate, download and install the latest versions of software.
The yum utility is actively developed, and is closely integrated with Fedora. Since Fedora Core 4, yum is configured to use the Core and ["Extras"] repositories by default. With Fedora 7 the Core and Extras packages have been merged into a single Fedora repository. Fedora developers are currently writing graphical management tools based on yum for inclusion in future releases. Users who would like a graphical interface to yum for current Fedora releases may install Yum Extender.
RPM itself is simply a file format for software packages that supports specialized features, such as digital signatures for verifying the authenticity of the packages. The supplied rpm utility enables you to perform various tasks relating to RPM packages, including installing individual software packages, but it is not the recommended method for installing software on Fedora systems.
For more details, read the documentation on our Website:
Fedora Documentation: Managing Software with Yum
MYTH - Fedora lacks good management tools
FACT - Fedora developers follow a clear set of usability principles:
- The system should not require the user to do anything that the system can automatically do itself
- If a management tool is required, it should perform just one particular task, and do it well
- Management tools should have as many features as are required, but no unnecessary functions
- Management tools should not require exclusive control of configuration files - administrators must be able to safely manually edit configuration files if they wish
Significant effort has been invested in developing automatic hardware detection, and more recently in automatic network configuration with the NetworkManager system. Since Fedora Core 4, many USB devices will work as soon as they are plugged in, requiring no manual configuration at all.
Fedora supports common administrative tasks by providing a set of graphical utilities, collectively known as the system-config tools. These enable administrators to configure key aspects of the system, as well as popular network services. The Sabayon desktop management tool is developed on Fedora by Red Hat engineers, and follows the same design principles as the system-config tools.
Fedora also has arguably the most elegant and sophisticated installation software of any operating system. The anaconda installer supports a wide range of methods from CD to network boot and installation over the Web. The kickstart facility makes creating and using templates for automating installation a simple task. Engineers constantly work on refining anaconda. Amongst the new features in development for Fedora 5 are support for installing Xen virtual machines, and facilities to create custom bootable systems that run from discs (known as LiveCDs).
MYTH - Fedora should use an alternative default filesystem
FACT - Fedora supports ext3 as the default filesystem because it is robust, and provides excellent performance for the normal range of systems and workloads.
Some alternative filesystems are designed to provide specialized management features and optimized performance for large-scale systems, but these do not provide greater performance than ext3 on standard PC hardware. The xfs, reiserfs, and jfs filesystems are available as experimental installation options for those users and developers with advanced requirements. We welcome participation by interested developers to improve support for these filesystems.
The Reiser4 filesystem is still in development by Namesys, and does not currently fully support several key features required by Fedora users, including SELinux, ACLs (Access Control Lists), and NFS (Network File System).
Namesys continues to maintain version 3 of the Reiser filesystem, but development is now focused on version 4. Version 3 of the Reiser filesystem also lacks robust support for ACLs and SELinux.
MYTH - Fedora is not optimized for performance, because many packages are for i386
FACT - Fedora includes processor-specific packages for the software that may be optimized for particular types of processor. All other packages are compiled with options that make use of modern processors without sacrificing compatibility.
As mentioned in the release notes, Fedora is already compiled to take advantage of the newer processors without losing compatibility with many brands like VIA which retain the older instruction sets.
Only a small number of software components on a modern Linux system benefit significantly from being compiled for the specific type of processor used by the computer, such as the kernel itself, and the glibc library of common software routines. Fedora provides multiple packages for each version of these components. The installer and the software management utilities automatically select the optimal package depending on the processor in your system.
Several optimization features may actually reduce the performance of software if applied incorrectly. For this reason, read the developer documentation for the product before compiling a version from source code with optimization options.