Linux Cookbook [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Linux Cookbook [Electronic resources] - نسخه متنی

Carla Schroder

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
تنظیمات قلم


اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
لیست موضوعات
افزودن یادداشت جدید

2.1. Introduction

Installing a
Linux distribution is quite easy these
days. Pop in a CD-ROM, make a few configuration choices, then go
enjoy a cup of tea while it finishes. Modern Linuxes have excellent
hardware detection, install quickly (typically in 30 minutes or
less), and require no more than a single reboot.

2.1.1 Source-Built Systems: The Olde Way

Maintaining a Linux system has also
evolved tremendously. Packages and intelligent dependency resolvers
mean that keeping a system updated and patched is now easier and less
error-prone. Today's youngsters have it so easy. We
didn't have CD-ROMs in the primitive olden days of
computinginstead of broadband, we had a station wagon full of
floppy disks. To get new programs, us old-timers had to unpack
laboriously downloaded tarballs, or copy them off floppy disks, then
compile the programs from source code. Dependency problems? Why, us
old geeks handled all those things without help from any fancy-pants
dependency resolvers. It went something like this:

# tar -xvf someprogram.tar

# ./configure

# make

The make failed, because of unresolved
So the next step was to download a tarball containing the program
with the required libraries, which took six hours over a 300-baud
modem. You know, the kind with the rubber cup that fits over the
phone. I passed the time by going outside and planting a garden. I
came back inside when the download was finished, unpacked the new
tarball, and tried again:

# ./configure

# make

Boy howdy, another long string of error messages indicating more
unresolved dependencies. Download yet another tarball, do more garden
work. By the time everything was installed and working, I had
tomatoes the size of melons. It's a good thing we
were so smart we hardly even needed computers.

Why was there all this dependency drama? Because Linux uses shared
libraries that are dynamically linked at runtime. Many separate,
unrelated programs can use the same libraries. This makes for a fast,
efficient system. Less memory and storage resources are consumed, and
programs are smaller and easier to distribute. But as Linux evolved
and became more complex, managing source-built systems became more
difficult. So programs were put into

packages .
Packages include compiled binaries, pre- and post-installation
scripts, file indexes, uninstallation scripts, and other goodies.
Each package knows what it needs to resolve its own dependencies.
Package databases track all the installed-from-package files on a

2.1.2 Dependency Resolvers

However, not all was bliss in
Whoville. RPM, the Red Hat Package Manager, is
the most widely used Linux package manager. RPM is quite powerful. It
runs dependency and version checks, and it tracks all installed
packages in the RPM database. But it cannot fetch additional packages
to resolve dependencies, nor can it manage the relationships between
packages. When it gets stuck because of dependency problems, it tells
you what additional packages to install, which means you have to find
these packages and install them. This can lead to more dependency
conflicts, and a simple installation can go haywire in a hurry. This
is known as "RPM

Many dependency resolvers have been developed for RPM-based systems,
including apt-rpm, urpmi,
Yum, and Ximian's Red Carpet. There are excellent
distribution-specific installers/resolvers, such as Red
Hat's up2date and
SuSE's YaST and Maintenance Web. In this chapter
we'll cover RPM basics and Yum, which was developed
natively for RPM systems. For many users, Yum strikes the right
balance of features and ease of use.

/ 435