Showing posts with label FEDORA. Show all posts
Showing posts with label FEDORA. Show all posts

Tuesday, August 23, 2011

Fedora Software Repositories

One of the brilliant features of Fedora is that it only comes on one CD disc. Not every operating system can brag about that. Indeed, many Linux distributions are delivered to users through multiple disks.

Formerly, the strategy in delivering a Linux distribution to your home or office was not very complex: all of the applications a user needed or would ever need in the future would be delivered on one complete set of CDs (or, later, one or two DVDs). The advantage here was that once you downloaded and burned all of those CDs, you would be all set to run that distribution without having to download additional software later. But the average CD image download, discussed. That’s a lot of data, even for today’s broadband connections. Having to do this for three, five, or even seven CDs is a very time-consuming undertaking for most users, unless they are willing to pay to have those same CDs delivered by mail.

Fedora flips the model around a bit. Working with the knowledge that a majority of Internet users now have broadband access, the Fedora Project has decided to send out just the absolutely necessary Fedora applications on one CD and leave the rest online on servers scattered around the world for users to download as needed.

This may seem inefficient, since you must have Internet access of some kind to make this work. But consider that most operating systems update themselves via Internet anyway, so in order to keep Fedora up to date, online access was needed anyway. And only downloading and burning one CD is a lot faster than downloading and burning CDs plural. Delivering a ‘‘core’’ distribution also gives users much greater flexibility in picking and choosing what software applications they want on their system. It also means their hard drives won’t be loaded with stuff they don’t need.

To give you an idea of just how much more software is available, consider these numbers: a standard installation of Fedora has around 1,100 packages. Currently, there are over 12,000 total application packages available.

Fedora, like its sibling Red Hat Enterprise Linux, organizes its software in repositories. There are three primary repositories for Fedora, each holding a specific class of software. Let’s walk through them now.

The three official Fedora repositories are pretty clearly named, but let’s examine them anyway.
» Fedora. This repository holds all of Fedora’s officially supported software. Everything that Fedora must have to actually run is in here, and all of the software is under a free software license. Additional applications in this repository include AbiWord, Evolution, Firefox, Gaim, OpenOffice.org, and Thunderbird.

» Updates. This repository contains any software that has been updated because of a bug or security fix.

» Source. All of the source code packages for Fedora software are found in this repository.


Adding Repositories
These are not the only repositories that Fedora can use. There aremany communityrun repositories on the Internet for Fedora, each holding specialized software that the Fedora Project does not want to host.

There are many software applications out there that can run on Linux, but because their licenses are completely proprietary, some Linux distributions won’t touch them with a 10-foot pole. By virtue of its Linux origins, Fedora’s makers feel obligated to abide by this philosophy, keeping totally commercial packages away from Fedora.

But there is an important distinction here. While the Fedora Project does not release commercial software with Fedora, that does not preclude letting users have access to a commercial repository after they have downloaded and installed

Fedora. A fine distinction, to be sure, but it gives users the advantage of making their own choices about what software they want to use. All of the package managers in Fedora work off a master list of repositories stored on your PC. From this file, known as sources.list, the package managers know which repositories to check for new software and if there are any updates available for software installed on your system. If you want these managers to peruse another repository, you will need to modify sources.list with the new information.

Fedora users in the know are aware of three such third-party repositories that will get you access to the latest in cutting-edge software for Fedora. These are the Dribble, Freshrpms, and rpm.livna.org repositories. Fortunately, you won’t have to add these repositories one at a time. Instead, you can use one command to add RPM Fusion to your sources.list, which will accomplish the same thing.

This operation will be done using a command-line application. Command-line applications are always run in a Terminal window, one of the plainest and most versatile tools found in Fedora. To start Terminal, click on the Applications | System Tools | Terminal menu command

Source of Information : Cengage-Introducing Fedora 2010

Thursday, August 18, 2011

How Fedora Installs Software

In the Windows world, there is usually one way to install software: clicking on an installation application that starts up and runs the whole setup for you from start to finish.

In Fedora, like most Linux distributions, there are three methods of software installation. Admittedly, one way to install sure sounds attractive and less confusing, but the one-size-fits-all installation service comes with a potentially bad price: Windows installation routines can often overwrite important underpinnings in the operating system for the sake of the application that’s currently being installed. This is good for your installed application, but potentially very bad for any pre-existing application on your system that was using that same section of Windows’ code.

In Fedora, all of the three installation methods take great pains to install applications using only what’s already in Fedora. If what the application needs is not installed in Fedora already, it has what is known as a dependency. The installing user (that would be you) will be told about any dependencies and asked how to proceed. A description of the three installation methods is easy to provide:

» Self-Contained Installation Program. This methodology is very much like the method used by Windows. A special installation application is run that automagically handles the application’s setup on your PC. This type of installation is not common on Fedora machines, though some of the larger consumer applications (OpenOffice.org or Firefox) can be installed in this manner. There is one important difference from Windows: no existing software is changed by the installation application. Dependencies are usually handled well, but it’s not foolproof.

» Compiled from Source. Remember how any user can get to the source code of any free software application? Well, once you have that code, you can perform what’s known as a compilation to turn that code (which only humans, at least the smart ones, can read) into something the PC can read and work with. Software compilation isn’t hard, but it is time-consuming at times, and dependencies are not automatically handled.

» Package Management. This method is unique to UNIX-based systems. All of the files and settings needed to install and run an application are included in one package. Fedora uses RPM-based, or .rpm, packages. (Other Linux distributions, such as Debian or Ubuntu, use Debian-based, or .deb, packages.)

As you may have guessed, package management is the preferred method of software installation in Fedora. Package installation is actually performed by an application known as a package manager. It helps keep track of all of the applications that are already installed on your PC and also helps keep track of those dependencies we mentioned. If you install a package that needs some additional software tools to properly operate on your Fedora system, it’s the package manager that will figure out what other packages you need.

In Fedora, there are actually three package managers that will assist you in your installation needs:

» PackageKit. This robust graphical package manager lists every package available for Fedora, which lets you search for software applications from a very big list. Applications are categorized by type, status on your system (installed or not), or origin.

» Software Update. Another graphical tool, this package manager has one job to do: keep your system as up to date as possible. If there’s a new version of any of your installed applications out there, Software Update will know about it and flag it for you to download and install.

» yum. The core package manager for Fedora, this command line application makes getting new packages as easy as typing one line of text and pressing the Enter key.

Each of these three package managers is configured to find all of the packages from Fedora’s package repositories. In the next section, we’ll walk through repositories and how they work.

Source of Information : Cengage-Introducing Fedora 2010

Wednesday, May 25, 2011

Fedore Desktop Environments

It would be a good idea to discuss what is different—specifically, the graphical interfaces that users work with when they work with any kind of Linux.

Most computer users are used to seeing just one graphical interface when they run their PCs. Windows 7 Home Edition users get to use the basic Windows interface, Windows 7 Premium and Ultimate Editions use the fancier Aero interface, and OS X users use Aqua. Graphical interfaces are the technical name for the windows, menus, and icons that so many computer users have grown accustomed to.

In these operating systems, you get the interface that comes with the OS. You can change the colors and the sizes of some items (bigger icons, for instance), but at the end of the day, you're still using the same interface.

In Linux, this is not the case: There are literally dozens of interfaces for you to choose from. This goes back to the whole modular nature of Linux. Unlike Windows 7, the interface applications are separate from the core operating system. So, if something creates a glitch on a Linux interface, known as a desktop environment, the core operating system is not affected.

These desktop environments do more than just look different; they are managed by completely different tools, and each carries its own set of specialized applications. For example, a text editor (like Windows Notepad) called Gedit is available for the GNOME desktop environment, and in the K Desktop Environment (KDE) the same kind of editor is known as Kate. (The first letter of an application is often a clue to the preferred environment for that application.)

Confusing? It shouldn't be. The good news is that applications for one desktop environment usually work in other environments without a hitch. (The author, for instance, prefers to work in KDE but won't part with the Gedit text editor. The two work together quite well.)

Source of Information : Cengage-Introducing Fedora 2010

Monday, May 23, 2011

Yes, There’s More Than One Way to Spin Fedora

You could almost say that Fedora is a victim of its own popularity. Because Fedora is so efficient and easy to use (even among Linux distributions), developers of all persuasions have taken a good thing and recrafted it into something they prefer even more. These variations of Fedora are known as spins, and they follow the same release cycle as the main version (though they might be offset by a few days here and there). Most of the differences between the flavors of Fedora are purely cosmetic: sometimes it’s a different desktop environment, sometimes it’s a different set of installed applications.

It is important to note that these spins are not completely different versions of Fedora; they are just Fedora pre-packaged in different ways. You can, if you wish, download and install all of the software needed to created identical versions of these spins. But having the spins already set up will save you a great deal of time and effort.


Fedora Desktop
The Fedora Desktop is the primary version among the Fedora ‘‘family’’ of spins, the one from which all the others are based. One of Fedora’s main characteristics is that it uses, by default, the GNOME desktop environment. GNOME, along with its predecessor KDE, is one of the most popular desktop environments around for Linux and other UNIX-based operating systems. It’s often regarded as an easier-to-use environment, with fewer controls for users to worry about. Free software purists prefer it for the totally free nature of the code that is used to build GNOME.


Fedora KDE
Fedora KDE is the most popular ‘‘alternate’’ Fedora spin, and as you might have guessed from the name, it features the KDE. The KDE environment came before GNOME, but quite a few people in the Linux community don’t like it because initially it was built with the help of nonfree code. (The Debian Project, for instance, initially would not ship any release with KDE.) The GNOME Project was started as a result of this concern. Today, the code in KDE is more open, and those objections have been rendered moot. Fedora KDE makes exclusive use of KDE and its attendant applications.


Fedora LXDE Spin
LXDE stands for ‘‘Lightweight X11 Desktop Environment,’’ and it is designed to be very fast and light on its electronic feet. While not as popular as GNOME and KDE, the LXDE interface features multi-language support, standard keyboard shortcuts, and tabbed file browsing. LXDE is a good environment for low-power devices such as netbooks, mobile Internet devices, or older machines.


Fedora Xfce Spin
This Fedora spin uses the Xfce environment, a simple and fast environment based on the old UNIX CDE environment. Xfce takes a bit of getting used to, because the graphic interface tools are a bit less intuitive than the more robust GNOME and KDE environments. But using Xfce gives this Fedora spin the added advantage of not being as resource-hungry as other Linux distributions and makes it ideal for running on slower, older PCs.


Fedora Games Spin
Like to get your game on? The Fedora Games spin offers a great collection of games available for Fedora. Not every Fedora game is included with this spin, but the designers have tried to put together a good representation of the different styles of games that you can get for the Fedora distribution.


Fedora Edu Spin
Unlike the other Fedora spins, Fedora Edu is not different because of its look or feel. Rather Fedora Edu’s differences lie in the content and tools it provides to users. Fedora Edu is sometimes referred to as the ‘‘kids’ Fedora,’’ and indeed, the addition of educational and development software certainly matches that description. But the overall goal of the project is to provide an easy-to-use distribution for all ages of students. According to the project’s home page, ‘‘The purpose of this spin is to create a ready-to-go development environment for contributing to educational projects inside, but also outside of the Fedora ecosystem....’’ Edu runs a GNOME desktop, with the differences mostly in the set of educational applications that ships with the distribution. These include various language, science, and development learning tools.


Fedora BrOffice Spin
One of the interesting results of working on the international stage of the Internet is how names can be used for different things in different nations. For instance, the office suite found in Fedora, OpenOffice.org, gets the ‘‘.org’’ in its official name from the fact that OpenOffice is actually a trademarked company name in the Netherlands, as well as a trademark owned by Orange UK, the British telecommunications company. Rather than raise a ruckus, the project’s organizers decided to simply tack on the ‘‘.org’’ to the name. But even that didn’t work, as OpenOffice.org is a trademark held in Brazil. So, OpenOffice.org users in Brazil use BrOffice. BrOffice, as you may have surmised,
is the centerpiece of the Fedora BrOffice spin. But the spin’s creators didn’t stop there. This spin is loaded with language packs and applications that are well suited for Central and South American users, whether they converse in Spanish or Portuguese.


Fedora FEL Spin
Very likely the most specialized Fedora spin is the Fedora Electronic Laboratory (FEL) spin. FEL was put together solely to provide a solid platform for the Electronic Design Automation (EDA) community. These are the people who put together things like microchips, processors, and robots. You know, easy stuff. According to the project’s Web site, FEL ‘‘provides a complete electronic laboratory setup with reliable open source design tools in order to help you keep in pace with the current technological race. It reduces the risk assessment of open source hardware development and enables electronic designers to create their work quickly and efficiently.’’

Source of Information : Cengage-Introducing Fedora 2010

Friday, May 20, 2011

The Fedora Connection

Fedora actually began its existence as a simple collection of software. One of the community outreach projects started by Red Hat as it was working to keep community interest high was the Fedora Linux project, a collection of newer and more experimental software that, when installed on Red Hat Linux, would give users a chance to enhance their computers without introducing risky software to the main Red Hat Linux distribution.

It’s important to note that Fedora Linux was not a stand-alone version of Linux, like other distributions, but was actually what’s known as a repository of software. But it would play a key role in what was to come next.

In September 2003, Red Hat made a stunning announcement: Red Hat Linux would cease to be a product. Instead, users who wanted to have commercial grade support (such as those coveted enterprise customers) would now use and pay for Red Hat Enterprise Linux. Users who wished to continue using Red Hat Linux for free and without support would use Fedora Core, a formal merging of Red Hat Linux and the software from the Fedora Linux project.

The new Fedora Core distribution would be governed not by Red Hat, but by an independent nonprofit organization known as the Fedora Project. At the time, this was considered to be a radical move, but as Linux became more commercially viable, vendors like Red Hat were able to make the jump to a pure commercial distribution.

Initially, reaction was mixed. After all, many people wondered, what about home and small business users who wanted some level of support? In response, in 2004 Red Hat (rather quietly) released Red Hat Professional Workstation, a $100 version of Red Hat Linux that came with direct Red Hat support. It was, unfortunately, a commercial failure.

What happened next would shape the commercial/community distribution model for all future releases—not just for Red Hat, but also for other followers of the model.

Simply put, the Fedora community took care of the support problem itself. By becoming a cohesive, flexible body, members of the Fedora Project began to fill the gaps that were once occupied by Red Hat. Documentation was created; support issues resolved; bugs tracked, identified, and removed. In short, the Fedora Core distribution became as robust and powerful as Red Hat Linux ever was and soon surpassed its parent distribution in terms of ease of use and features.

In fact, the Fedora Project became so strong that eventually Red Hat would drop its efforts for a home/small business desktop product and put time, effort, and resources back into Fedora Core.

Ultimately, this approach worked out very well for both sides. Power users and developers got a complete and robust distribution to experiment with and use, and Red Hat kept its commercial distribution solid and mature. And, as an added benefit, Fedora Core, later named just Fedora, would become a test bed for new technologies and applications, which would later be included in Red Hat Enterprise Linux.

It’s a good example of a win-win situation for users, developers, and commercial vendors alike.

Source of Information : Cengage-Introducing Fedora 2010

Monday, May 16, 2011

The Red Hat Connection with Fedora

Red Hat Linux is one of the earliest created Linux distributions, having been invented by Marc Ewing in 1994. Ewing actually began working on the distribution, then known as Red Hat Software Linux, in December of 1992, soon after he graduated from Carnegie Mellon University.

According to legend—because you can have legends in under 20 years on the Internet—the name ‘‘Red Hat’’ came from Ewing’s habit of wearing a red hat while at CMU. The name stuck, even after Ewing’s company was purchased by entrepreneur Bob Young in 1995.

Red Hat’s initial popularity is attributed to some key technological advantages it had over other Linux distributions of the time. One such advantage was the addition of a graphical configuration system used when installing Red Hat. Primitive by today’s standards, nonetheless this simple series of installation screens was hugely helpful for those early adopters who wanted to try out Linux.

Another advantage Red Hat had was how software applications were distributed for the Red Hat Linux platform. Recall that while open source and free software is always available in its source code form, such a format is not easy to use. What software developers must do is deliver their application in a form that’s easy to install. On Windows, this is done with a self-executing file that users can double-click and have the new program installed.

On Linux, such an approach is not a good idea. Self-executing installs can bring a host of mistakes and potentially malicious changes to a computer, and at the most fundamental level, all Linux systems resist such packages. Instead, applications are installed using packages. A Linux package can contain many of the same files as a Windows installation routine, but the control of the installation lies with the package manager—not the package itself.

Package managers will not only ensure the package is properly and safely put together, but they will also make sure that any other software the application needs will be installed as well.

Red Hat’s advantage here was the introduction of the RPM package management system. RPM packages are one of two major Linux packaging systems (the other being Debian GNU/Linux’s DEB package system).

Over the next nine years, Red Hat Linux would continue to capitalize on these and other advantages, devoting much of its marketing and sales efforts to getting Linux into the workplace; specifically, the enterprises which are organizations with 500 or more computer users. By targeting this market, Red Hat was essentially aiming for the low-hanging fruit; there aren’t a lot of enterprise-level customers out there, but it only takes a few to really build your revenue stream.

But this approach, while commercially successful, gave Red Hat a problem. While Red Hat Linux was becoming increasingly popular in the corporate world, the community-oriented developer and user bases that had helped to bring Red Hat Linux to where it was technologically were feeling increasingly disenfranchised. What good was it to develop cutting-edge software, the community complained, when Red Hat, fearing any software instability for its well-heeled enterprise customers, would only include it after a laborious quality control process?

This issue was serious enough to prompt Red Hat to launch several community outreach programs—because if the community began to vote with their feet and walk away from Red Hat, highly valuable development resources could be lost, and Red Hat’s community reputation would plummet. Some of this outreach helped, but in the end, it took the birth of a new distribution and the death of Red Hat Linux to help save Red Hat.

Red Hat Linux is one of three major branches of Linux distributions that exist today. Many successful distributions, including Fedora, are based on Red Hat Linux, such as Red Flag, a popular Chinese distribution, and Yellow Dog, a flavor of Linux designed to run on Apple's Mac hardware.

Source of Information : Cengage-Introducing Fedora 2010

Thursday, May 12, 2011

Distributions of All Shapes and Sizes

In the very beginning, there was one distribution of Linux, known as MCC Interim Linux. Its singular status didn’t last long. Very soon, there were a handful of distributions. Today, nearly 18 years later, there are upwards of 200 distributions. No one knows the exact number, since new ones are being created every week, and old ones are being allowed to languish into obscurity.

Whatever the exact number, there are a lot of distributions out there, and they all fall into one of two categories: commercial (like RHEL) or noncommercial (like Fedora).

The commercial distributions exist for a pretty self-explanatory reason: someone, either a company or a group of developers, wants to make money. These distributions tend to be the most well-known of the Linux distributions, although they are not necessarily the most influential.

Distributions in this category include RHEL, SUSE Linux Enterprise Server, Mandriva Linux, and Ubuntu Server. Those are the more commercially successful distributions; it is by no means a complete list.

Noncommercial distributions are generally run as not-for-profits, if they are well organized, or even as a hobby for one of a group of developers. The motivation for developers is varied. Some want to create something meaningful. Some do it to earn extra money. (Actually, some nonprofit distributions do receive some funding through voluntary support and donations.) Some want to have fun coding. Whatever the reason, developers have made noncommercial distributions very popular and extremely influential among all Linux developers.

Noncommercial distributions include Debian GNU/Linux, Slackware Linux, Ubuntu, openSUSE, and SimplyMEPIS. Just to give you an idea of how influential noncommercial distributions can be, know that SimplyMEPIS, Freespire, Linspire, and Xandros are among the many Linux distributions (commercial or otherwise) based on what has become the most popular noncommercial distribution today: Debian GNU/Linux.

Source of Information : Cengage-Introducing Fedora 2010

Saturday, August 28, 2010

The Upstart Event-Based init Daemon (FEDORA)

The Upstart Event-Based init Daemon Because the traditional System V init daemon (SysVinit) does not deal well with modern hardware, including hotplug devices, USB hard and flash drives, and network-mounted filesystems, Fedora replaced it with the Upstart init daemon (fedoraproject.org/wiki/Features/Upstart). RHEL still uses xinetd, a successor to the init daemon.

Several other replacements for SysVinit are also available. One of the most prominent, initng (www.initng.org), is available for Debian and runs on Ubuntu. In addition, Solaris uses SMF (Service Management Facility) and MacOS uses launchd. Over time, Upstart will likely incorporate features of each of these systems.

The runlevel-based SysVinit daemon (sysvinit package) uses runlevels (single-user, multiuser, and more) and links from the /etc/rc?.d directories to the init scripts in /etc/init.d to start and stop system services. The event-based Upstart init daemon uses events to start and stop system services. With version 9, Fedora switched to the Upstart init daemon and began the transition from the SysVinit setup to the Upstart setup. This section discusses Upstart and the parts of SysVinit that remain: the /etc/rc?.d and /etc/init.d directories and the concept of runlevels.

The Upstart init daemon is event based and runs specified programs when something on the system changes. These programs, which are frequently scripts, start and stop services. This setup is similar in concept to the links to init scripts that Sys-Vinit calls as a system enters runlevels, except Upstart is more flexible. Instead of starting and stopping services only when the runlevel changes, Upstart can start and stop services upon receiving information that something on the system has changed. Such a change is called an event. For example, Upstart can take action when it learns from udev that a filesystem, printer, or other device has been added or removed from the running system. It can also start and stop services when the system boots, when the system is shut down, or when a job changes state.

Future of Upstart. Changing from SysVinit to Upstart involves many parts of the Linux system. To make the switch smoothly and to introduce as few errors as possible, the Upstart team elected to make this transition over several releases.

Over time, Fedora will move away from the SysVinit setup and toward the cleaner, more flexible Upstart setup. As more system services are put under the control of Upstart, entries in the /etc/event.d directory will replace the contents of the /etc/init.d and /etc/rc?.d directories. Runlevels will no longer be a formal feature of Fedora, although they will be maintained for compatibility with third-party software. Eventually Upstart will also replace crond.

Software package. The Upstart system uses the upstart package, which is installed by default. Some of the files Upstart uses are found in the initscripts package, which is also installed by default.

Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition