Периодична таблица на дистрибуциите на Linux

2. КРИТЕРИИ ЗА КЛАСИФИЦИРАНЕ НА ДИСТРИБУЦИИТЕ

Посочените по-горе числа за броя на дистрибуциите, разбира се, са впечатляващи, но старите потребители на Linux знаят, че ядрото и повечето програми са еднакви при всички дистрибуции, и че техният състав се различава най-вече по номера на версията или компилацията на пакета от конкретният потребител. Освен това, потребителят може да добави към системата си практически всяка необходима му програма, като в краен случай я компилира от изходен код или разработи самостоятелно пакет с нея (при наличие на съответната квалификация, разбира се).

Тъй като броят на дистрибуциите на Linux е много голям, практически да се запознаем с всяка една от тях за да може да направим правилен избор вече не е възможно. Следователно, актуален става проблемът за тяхното класифицирането, както и за избор на съществени характеристики, които да служат за критерии при избор на дистрибуция. На вече споменатия сайт www.distrowatch.com могат да бъдат намерени достатъчно много материали, които дават някакъв, макар и частичен, отговор на поставените въпроси и които са залегнали в основата на тази статия, в която ще бъде направен опит за класифициране на дистрибуциите на Linux по няколко критерия.

Съществуват много признаци, по които могат да се различават отделните дистрибуции, като някои от тях са следните:
• предназначение на дистрибуцията към конкретна област на приложение (например за организация на защитна стена, за работа като маршрутизатор, за създаване на особено защитена система или за използване на домашен компютър от обикновен потребител с акцент върху мултимедийните приложения);
• изисквания към апаратното осигуряване³ (някои дистрибуции са оптимизирани за компютри с процесор Pentium, други могат да се инсталират и на компютри с процесор Intel 80486; например SUSE LiveCD 9.2 не се стартира на компютри, които имат оперативна памет по-малка от 256 MB;
• използваната графична среда – KDE, GNOME или XFce;
• наличието на средства за локализация, осигуряващи поддръжката на нужния ви език (например в някои LiveCD дистрибуции не е предвидена поддръжка на български език, така че се налагат допълнителни усилия за кирилизиране на системата);
• носителят, от който може да се стартира системата – например една или няколко дискети, CD-ROM диск, инсталация върху твърд диск;
• организацията на процедурата за начално зареждане на системата – BSD или System V;
• използваната система за управление на пакети – dpkg или apt-get в Debian, rpm във Fedora Core;
• структурата на директориите на файловата система [виж 5, 6];
• родословието или историята за възникване на дистрибуцията – новите дистрибуции не се създават в повечето случаи на празно място, а на основата на някоя съществуваща такава);
• състава на основното програмно осигуряване⁴, което се инсталира;
• достъпност до допълнителните пакети с програми;
• наличие на комерсиални програми, включени в дистрибуцията;
• процедурата за откриване на различният хадуер;
• предоставените инструменти за управление на операционната система;
• и така нататък …

Нека се опитаме да отделим от този списък тези признаци, които могат да бъдат използвани за основа на някаква класификация на дистрибуциите. Ще започнем с това да отхвърлим някои критерии, нямащи практическо значение.

3. НЕСЪЩЕСТВЕНИ КРИТЕРИИ

Някои от изброените критерии може да изключим без някаква особена аргументация – например достъпността до допълнителни пакети е практически еднаква за всички дистрибуции, тъй като всяка програма може да бъде компилирана от изходен код или да бъде създаден пакет със специфичен за дадената дистрибуция формат. По същите причини може да изключим и критерия за наличие в състава на дистрибуцията на комерсиални програми, тъй като няма начин да ви бъде забранено да купите такива програми и да ги включите във вашата система. Средства за локализация се включват вече във всички дистрибуции без изключение, въпреки че не винаги дистрибуцията съдържа необходимите шрифтове. Този критерии става още по-несъществен в светлината на очаквания преход към Unicode⁵. Нека разгледаме по-подробно още няколко критерия.

И така, от първоначално посоченият списък с признаци за разглеждане останаха само организацията на процедурата за начално зареждане на системата, използваната система за управление на пакетите и областта на приложение на дистрибуцията. Тези три признака за класификация на дистрибуциите трябва да бъдат разгледани по-подробно, с което и ще се заемем малко по-надолу.

4. СРЕДСТВА ЗА УПРАВЛЕНИЕ НА ПАКЕТИТЕ

Както беше казано в посоченото по-горе определение, дистрибуциите се състоят от отделни пакети, всеки от които съдържа някакво приложение, помощна програма или услуга. Отделният пакет може да съдържа например web браузър, библиотека за работа с графични файлове във формат png, набор от шрифтове и така нататък.

Софтуерът, съдържащ се в пакета, се доставя в една от двете форми:
• под формата на двоични файлове, предназначени за непосредствено инсталиране във вашата система без да има нужда от каквато и да е допълнителна обработка (например компилация);
• под формата на изходен текст, които файлове обикновено съдържат текст на някакъв език за програмиране, архивирани във формат tar и опаковани с програмата gzip, а също така и допълнителни файлове, необходими за компилацията на приложението от файловете с изхо­ден код.

Съществуват също така и пакети, които при добро желание могат да бъдат отнесени едновременно и към двата вида. Това са пакетите, които съдържат скриптове и конфигурационни файлове, помощни страници в формат man или info, информация за авторските права или друга документация. От една страна те представляват също „изходен код“, а от друга се инсталират в системата без всякаква допълнителна обработка, също като изпълнимите файлове. Но този тип пакети изпълнява спомагателна роля и за нас не представлява интерес. А количеството и състава на пакетите от първите два типа имат много съществена роля в класификацията на дистрибуциите.

Да си припомним първо, че всичкият софтуер в GNU/Linux е свободен, тоест доставя се заедно с изходният код. И поради това, за всеки бинарен пакет на дисковете на дистрибуцията ще се намери съответният пакет с изходен код. Но обратното твърдение не е вярно, тъй като съществуват дистрибуции, в които броят на двоичните файлове е силно ограничен. Това са така наречените source-based¹¹ дистрибуции, тоест дистрибуции, основани на изходен код. Техните създатели са предположили, че техните потребители ще могат самостоятелно да компилират и инсталират на компютъра всяко необходимо им приложение. Но за да се пусне самият процес на компилиране, трябва операционната система вече да е работоспособна, макар и с някаква минимална конфигурация. Трябва да са били инсталирани програмата за начално зареждане, ядрото, архиваторите tar и gzip (за да може да се разопакова и деархивира пакета с изходният код), компилатор с целият съпътстващ го инструментариум (линкер, асемблер и така нататък), библиотеките на езика C, помощни програми за работа с файлове и текст (find, grep, awk, sed), без които компилирането и инсталирането на програмите е просто невъзможно. Този проблем може да се реши по два начина: или компилацията се извършва на някаква друга система, или необходимият минимум от прекомпилирани пакети се инсталира от дистрибуцията, а останалите пакети се компилират в създадената по този начин среда. Най-яркият пример на реализация на подхода, основан на компилация на цялата система от изходен код е проекта Linux From Scratch, който не е дистрибуция в прекия смисъл на тази дума, а представлява набор от инструкции за създаването на система от набор пакети с изходен код (виж [10]).

Колкото до пакетите с прекомпилиран софтуер, то за тяхното инсталиране както в процеса на инсталация на системата или във вече инсталирана система, се изискват специални средства за управление на пакетите. Работата е в това, че инсталацията софтуер от пакети, обикновено е свързана с разрешаването на така наречените „зависимости“. Например, пакетът, съдържащ компилатора GNU C (gcc) „зависи“ от пакета binutils, който включва в себе си linker¹² и транслатор. Ако потребителят се опита да инсталира gcc без предварително да е инсталирал binutils, най-вероятно процеса на инсталиране на gcc ще завърши със съобщение за грешка. Затова в състава на пакета се включва не само двоичния код на изпълнимата програма, но и допълнителна служебна или мета-информация: името на програмата, данни за разработчика, информация за други пакети, които са необходими за правилната работа на дадената програма (най-често това е необходима на даденото приложение библиотека), контролни суми, информация за това как правилно да бъде конфигуриран пакета и как да бъде правилно деинсталиран, ако нуждата от неговото използване изчезне.

Пакетът обикновено представлява един архивиран файл, в който се намират както самата програма, която ще се инсталира, така и необходимата служебна информация (мета-информация). Понякога тази мета-информация се съдържа не в самия пакет, а във външна база от данни. Но за да се възползваме от нея е необходима още една програма, която да инсталира приложението от пакета в система, използвайки при необходимост мета-информацията от пакета. Очевидно е, че тази програма силно ще зависи от това, каква точно мета-информация се съдържа в пакета и как е организирана тя. По този начин се е получило, че създателите на някои дистрибуции са разработили всеки за себе си своя собствена структура на пакетите и свои специализирани средства за управление на тези пакети, които позволяват инсталация на програмата от пакета с помощта на съдържащата се в него мета-информация.

Системата за управление на пакети е набор от инструменти, предназначени за автоматизация на процесите на инсталиране, обновяване, конфигуриране и отстраняване на пакети на програмно осигуряване от определен формат.

Най-известни системи за управление на пакети са:
• rpm/yum – мениджърът на пакети на Red Hat. В момента абревиатурата RPM обикновено се разшифрова рекурсивно (RPM – RPM Package Manager), но първоначално тя е означавала пакетен мениджър на Red Hat (RedHat Package Manager), тъй като беше разработена за дистрибуцията Red Hat. В настоящият момент, този пакетен мениджър се използва и в много други дистрибуции.
• dpkg/APT – е системата за управление на пакетите *.deb в дистрибуцията Debian, която също е портвана и за други дистрибуции. Самите пакети .deb представляват сами по себе си два tar архива, компресирани с помощта на gzip: в единият се намира управляващата информация, а в другия – самите данни. Стандартно средство за управление на тези пакети е конзолната програма dpkg, допълнена от обвивката APT (Advanced Packaging Tool).
• tgz или tar.gz е стандартен набор от две програми – tar и gzip, понякога допълнен с някои допълнителни управляващи файлове. Използва се в дистрибуцията Slackware и някои други дистрибуции, като не осигурява решаването на зависимости. От source-based дистрибуциите тази система се различава по това, че вътре в tar.gz архивите се намират предварително компилирани програми (а не изходен код на програмите).
• Системата portage на дистрибуцията Gentoo, представляваща набор от файлове ebuild, съдържащи информация за това как да получим (от всеки достъпен източник – мрежа, локален диск etc), компилираме и инсталираме пакет в системата Gentoo, използва конзолната команда emerge. Обикновено пакета в този случай съдържа изходният код на програмата и приложението се компилира директно по време на инсталацията, за сметка на което се оптимизира за конкретната машина. Макар, че по този начин могат да се инсталират и предварително компилирани програми, този вариант се използва само в изключителни случаи, например при инсталация на много бавни машини.
• YaST е приложение, разработено от Novell и използвано в дистрибуцията SuSE.

Компилацията на пакети от изходен код също може да се разглежда като един от вариантите на система за управление на пакетите. От изброените по-горе системи, той се различава само по това, че пакетите в source-based дистрибуциите почти не съдържат в себе си предварително компилирани програми (освен тези, които са абсолютно необходими като ядро и компилатор), така че единственият начин за инсталация на нов пакет е неговата непосредствена компилация от изходен код.

Най-разпространено средство за управление на пакети програмно осигуряване остава програмата rpm. Наистина, тя притежава този недостатък, че разрешаването на зависимостите лежи основно върху потребителя¹³. Програмата само съобщава, че липсва някакъв пакет в системата, а самото намиране и инсталиране остава за потребителя. Затова много основани на rpm дистрибуции използват създадения от Debian инструмент apt, който понякога се появява и под други имена. Дебианският deb и tgz на Slackware (и неговите производни) също са широко разпространени. Освен вече изброените са били изобретени още няколко средства за управление на пакети. Като примери може да използваме slp от дистрибуцията Stampede, който има няколко интересни особености и системата за управление на пакети от дистрибуциятаJBLinux.

Таблица 1, която е взаимствана от сайта Distrowatch.com, показва разпространението на различните системи за управление на пакети. Имайте предвид, че за разлика от аналогичната таблица на сайта, аз не съм си поставял за задача да изброя в най-дясната колона на таблицата всички дистрибуции, използващи една или друга система за управление на пакети, а само съм показал само по няколко примера.

Таблица 1.

Трябва да се каже, че понякога е много трудно да се прокара ясна граница между различните системи за управление на пакетите. Освен това, съществува и програмата Alien, която позволява да се конвертират пакети от един формат в друг. Ако вие искате да използвате пакет от дистрибуция, различна от тази, инсталирана на вашият компютър, вие можете да използвате тази програма за конвертиране на този пакет във формат, който се използва във вашата система, след което ще можете да го инсталирате.

5. СКРИПТОВЕ ЗА НАЧАЛНО ЗАРЕЖДАНЕ¹⁴

Начинът на организиране и разполагане на началните скриптове е вторият съществен признак, по който дистрибуциите на Linux се различават една от друга.

Като начало нека си припомним, че съществуват два различни стила на първоначално зареждане на unix-подобните операционни системи, произхода на които стига до корените на историята на възникване и развитие на UNIX: така нареченият BSD стил (използван също така в такива операционни системи като FreeBSD, NetBSD и OpenBSD) и стилът System V (наричан още стил ATT). Разликата между тях е в организирането и разполагането на началните скриптове, осигуряващи управлението на процеса на първоначално зареждане на системата. В класическите BSD системи, тези файлове се съхраняват в директорията /etc и техните имена започват с представката „rc“. В системите от семейството на System V, тези файлове се намират в директорията /etc/init.d, а връзки към тях са създадени в директориите /etc/rc0.d, /etc/rc1.d и така нататък. Вторият стил на организиране на скриптовете е по-ясен и позволява по-точно да се изпълнява процесът на спиране на системата. Ако искате да научите повече подробности за разликите в двата споменати стила, прочетете глава 2 от книгата [6].

По-голямата част от дистрибуциите на Linux използват стила на System V. Към тях спадат Debian, всички производни на Red Hat, включително Mandrake и руските дистрибуции ASPLinux и ALT Linux. В стил BSD е организирано зареждането на дистрибуцията Slackware и неговите производни. Но и единият и другият стил не се спазват съвсем строго. Например, структурата на директориите, в които се съхраняват инициализиращите скриптове, в основните дистрибуции се различават съществено:

Листинг 1.

• Fedora Core (Red Hat):
  • /etc/init.d/ – символна връзка към /etc/rc.d/init.d/
  • /etc/rc.d/ – скриптове rc, rc.sysinit и rc.local
          |
  •           /init.d/ – множество файлове със скриптове
  •           /rc0.d/ – символни връзки @K*.* и @S*.*
  •           /rc1.d/ – символни връзки @K*.* и @S*.*
    ……….
  •           /rc6.d/ – символни връзки @K*.* и @S*.*
  •           /rcS.d/ – символни връзки @K*.* и @S*.*
• Knoppix (клон Debian):
  • /etc/init.d/ – скриптове rc, rcS, reboot и множество други
  • /etc/rc0.d/ – символни връзки @K*.* и @S*.*
  •     /rc1.d/ – символни връзки @K*.* и @S*.*
    ……….
  •     /rc6.d/ – символни връзки @K*.* и @S*.*
  •     /rcS.d/ – символни връзки @K*.* и @S*.*
• Slackware:
  • /etc/rc.d/ – скриптове rc.0, rc.4, rc.6, rc.K, rc.M, rc.S, rc.local, rc.syslog, rc.nfsd, rc.sysvinit, rc.netdevice, rc.keymap и други скриптове, имената на които имат вид rc.*.
• Gentoo:
  • /etc/init.d/ – скриптове с най-различни имена.
• SuSE:
  • /etc/rc.d/ – символна връзка към /etc/init.d/
  • /etc/init.d/ – множество файлове с различни имена, в частност boot.*
  •                 /boot.d/ – символни връзки @K*.* и @S*.*
  •                 /rc0.d/ – символни връзки @K*.* и @S*.*
  •                 /rc1.d/ – символни връзки @K*.* и @S*.*
    ……….
  •                 /rc6.d/ – символни връзки @K*.* и @S*.*
  •                 /rcS.d/ – символни връзки @K*.* и @S*.*

Както виждате, даже и в Red Hat и Debian, които следват стила на System V, структурата на директориите се различава. А SuSE, макар и произлизаща от Slackware, се движи в посоката на стила System V най-малко в организацията на структурата на директориите. А Red Hat са създали скрипт rc.local, приличащ на едноименния такъв във FreeBSD. В процеса на първоначално зареждане този скрипт се изпълнява последен. Вярно е, че в последните версии на Red Hat и Fedora този скрипт е „празен“, тоест практически не се използва. И авторите на книгата [6] не съветват в него да се добавят собствени команди, препоръчвайки по-добре да се използват средствата на System V.

Но структурата на директориите и имената на инициализиращите скриптове може би не са най-важното. Както е известно, в процеса на начално зареждане на операционната система, в началото се зарежда ядро, което стартира процеса init, имащ винаги идентификатор 0. Този процес изпълнява инструкциите, зададени във файла /etc/inittab. В листинг 2 са показани извадки от него от няколко дистрибуции. Показан е не целият текст на файла, а само 4 групи от най-важните редове, определящи процеса на зареждане. Във всички дистрибуции освен посочените инструкции се определят и действията при натискане на клавишната комбинация Ctrl-Alt-Del и се стартират виртуални терминали (само в дистрибуциите Fedora Core и SuSE за тази цел се извиква процеса mingetty, в Gentoo и Slackware – agetty, а в Knoppix — /bin/bash -login).

Листинг 2.

 id:3:initdefault:

 # System initialization. si::sysinit:/etc/rc.d/rc.sysinit

 l0:0:wait:/etc/rc.d/rc 0

 l1:1:wait:/etc/rc.d/rc 1

 l2:2:wait:/etc/rc.d/rc 2

 l3:3:wait:/etc/rc.d/rc 3

 l4:4:wait:/etc/rc.d/rc 4

 l5:5:wait:/etc/rc.d/rc 5

 l6:6:wait:/etc/rc.d/rc 6

 x:5:respawn:/etc/X11/prefdm -nodaemon

 id:5:initdefault:

 # Boot-time system configuration/initialization script.

 si::sysinit:/etc/init.d/rcS

 # What to do in single-user mode.

 ~~:S:respawn:/bin/bash -login >/dev/tty1 2>&1

 id:3:initdefault:

 # System initialization (runs when system boots).

 si:S:sysinit:/etc/rc.d/rc.S

 su:1S:wait:/etc/rc.d/rc.K

 rc:2345:wait:/etc/rc.d/rc.M

 l0:0:wait:/etc/rc.d/rc.0

 l6:6:wait:/etc/rc.d/rc.6

 # Runlevel 4 used to be for an X window only system

 x1:4:wait:/etc/rc.d/rc.4

 id:3:initdefault:

 # System initialization (runs when system boots). si:S:sysinit:/sbin/rc boot

 ~~:S:wait:/sbin/sulogin

 l0:0:wait:/sbin/rc shutdown

 l1:1:wait:/sbin/rc single

 l2:2:wait:/sbin/rc nonetwork

 l3:3:wait:/sbin/rc default

 l4:4:wait:/sbin/rc default

 l5:5:wait:/sbin/rc default

 l6:6:wait:/sbin/rc reboot

 z6:6:respawn:/sbin/sulogin

 # Used by /etc/init.d/xdm to control DM startup.

 x:a:once:/etc/X11/startDM.sh

 # The default runlevel is defined here
 id:5:initdefault:

 # First script to be executed, if not booting in emergency (-b) mode

 si::bootwait:/etc/init.d/boot

 # /etc/init.d/rc takes care of runlevel handling

 l0:0:wait:/etc/init.d/rc 0

 1:1:wait:/etc/init.d/rc 1

 l2:2:wait:/etc/init.d/rc 2

 l3:3:wait:/etc/init.d/rc 3

 #l4:4:wait:/etc/init.d/rc 4

 l5:5:wait:/etc/init.d/rc 5

 l6:6:wait:/etc/init.d/rc 6

 # what to do in single-user mode

 ls:S:wait:/etc/init.d/rc S

 ~~:S:respawn:/sbin/sulogin

Както се вижда, при всички случаи редът на изпълнение на действията е приблизително един и същ:
• Отначало се задава нивото на изпълнение (runlevel);
• След това се изпълняват действията по началната инициализация на системата, независещи от зададеното ниво. В различните дистрибуции за тази цел се използват различни скриптове:
  • във Fedora Core – /etc/rc.d/rc.sysinit
  • в Knoppix – /etc/init.d/rcS
  • в Slackware – /etc/rc.d/rc.S (тоест скрипт за преход в Single User Mode)
  • в Gentoo – /sbin/rc boot
  • в SuSe – /etc/init.d/boot
• След това се изпълнява скрипт за преход на дадено ниво на изпълнение¹⁵. При това, ако във Fedora Core и Gentoo за всяко ниво на изпълне­ние има отделен ред, то в Slackware за нивата от 2 до 5 се изпълняват едни и същи действия;
• И накрая, във всички дистрибуции, освен в SuSE, на отделен ред се извършва стартирането на графичната среда на системата.

При стила на System V се използва един и същ скрипт за преминаване на дадено ниво на изпълнение, а това какво прави този скрипт, се определя от съдържанието на директорията /etc/rc.d/rcN.d. Тази директория съдържа списък на връзки към стартиращи скриптове за тези системни услуги, които трябва да работят на ниво N. Самите скриптове се намират в директорията /etc/init.d или /etc/rc.d/init.d.

За разлика от стила System V, в BSD стила за всяко ниво на зареждане отговаря отделен скрипт. И отначало винаги се извършва преход на ниво S (еднопотребителски режим), а след това вече се преминава към зададеното ниво за ползване. Стилът BSD в най-чист вид (от разгледаните примери) е реализиран в дистрибуцията Slackware.

Тъй като стилът System V е взет за основа при създаването на стандарта LSB (Linux Standart Base), дистрибуциите, използвали преди BSD стил, в последно време започнаха да се грижат за реализиране на съвместимост със стила System V. Slackware осигуриха такава съвместимост от версия 7.0 на дистрибуцията си. Тази съвместимост се постига с използване на скрипта rc.sysinit, който провежда търсене на всички скриптове в стил System V в директорията /etc/rc/d и ги изпълнява, ако нивото на зареждане отговаря на исканото. Това е полезно, ако вие използвате комерсиален софтуер, който се ориентира по стила на System V. В същото време, вие можете да използвате и BSD скриптове.

6. ОБЛАСТ НА ПРИЛОЖЕНИЕ НА ДИСТРИБУЦИЯТА

За насочеността на дадена дистрибуция в определена област на приложение си струва да поговорим. Област на приложение е доста широко понятие. Както вече беше казано по-горе, под този термин попадат и изискванията към хардуера (дистрибуции за 486 процесори, за компютри без оптично устройство и така нататък), както и дистрибуциите, стартирани от нетрадиционни носители (CD-ROM, flash памет, външни или преносими дискове и др. такива). И броя на градациите или групите, отделени по този признак може да бъде много голям. Аз съставих по материали от Internet таблица 2, в която са показани отделни примери за това към какви области на приложение могат да бъдат ориентирани отделните дистрибуции. Трябва да ви предупредя, че голяма част от обясненията са дадени на основата на намерени в паяжината описания и информацията не е проверена лично, за което моля да не бъда съден строго за допуснати грешки.

Таблица 2.

Ще отбележа, че на сайта на Linux Weekly News има много по-подробна таблица, класифицираща дистрибуциите по тяхното предназначение [3].

7. ОКОНЧАТЕЛНА ТАБЛИЦА И ЗАКЛЮЧЕНИЕ

Обобщавайки гореизложеното, може да направим извода, че съществуват три съществени критерия за класифициране на дистрибуциите на Linux:
• начинът на първоначално зареждане;
• системата за управление на пакети;
• предназначението на дистрибуцията.

И ако сведем всичко в една обща таблица, ще получим „периодичната система“ на дистрибуциите на Linux, представена в Таблица 3.

Таблица 3.

Тази таблица може да бъде допълвана „по вертикала“ чрез добавяне на нови области на приложение на Linux.

За съжаление, аз не съм в състояние да разпределя всички съществуващи към настоящият момент дистрибуции по клетките на таблицата. Поставих само тези дистрибуции, с които съм запознат. Ако вие сте работили с други дистрибуции и можете да ми помогнете в запълването на таблицата, пишете на адрес kos at rus-linux dot net. Аз ще се старая да попълвам тази таблица по хода на пристигащите съобщения.

БИБЛИОГРАФИЯ:

1. DistroWatch
2. Wikipedia
3. The Linux Weekly News comprehensive list of distributions
4. Distribution Reviews
5. А. Федорчук, “Демоны, пингвины и пользователи. Начнем с пингвинов.”
6. А. Федорчук, “О дистрибутивах Linux”²⁰
7. А. Федорчук, “Кое-что об ОС, Unix’ах, Linux’ах и BSD”
8. В. Костромин, „Red Hat Linux 9 Cyrillic Edition с точки зрения пользователя“, часть 1. Инсталляция. 1.2. Минимальная конфигурация. Базовый набор.
9. Э. Немет, Г. Снайдер, С. Сибасс, Т. Хейн, „UNIX: руководство системного администратора“, Киев, БХВ, 1999 г.
10. Джерард Бикманс, Linux From Scratch, версия 5.0, перевод: Виталий Катраев.
11. Sean Russell, RPM Hell. A Perfect Example of Good Software Crippled by Bad Design.