Początek historii Linuxa datuje się na rok 1991. Początkowo Linus Torvalds, student Uniwersytetu Helsińskiego jako hobby bawić systemem Minix (bardzo prosty system typu Unix), ale jego twórca Andrew Tanenbaum nie zgodził się na jego rozszerzanie przez innych. Zmusiło to Torvaldsa do napisania zamiennika dla Minixa. Tym sposobem narodziło się jądro Linuxa. Linux wystartował jako terminal (tty) napisany w assemblerze IA-32 oraz C, który został skompilowany do postaci binarnej i ładowany z dyskietki. Dzięki temu uruchamiał się poza jakimkolwiek systemem operacyjnym. Terminal ten miał dwa wątki: jeden do wysyłania, jeden do odbierania znaków z portu szeregowego. Potem Linus dopisał obsługę systemu plików co w końcu przerodziło się w jądro systemu operacyjnego.

Pierwsza wersja jądra - 0.01 - powstała 17 września 1991 roku, a druga wkrótce potem bo już w październiku. Od tamtego czasu tysiące programistów z całego świata uczestniczy w projekcie.

Poniżej treść najsłynniejszego chyba postu z grup dyskusyjnych, w którym Linus Torvalds prezentuje światu swoje dzieło:

From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.minix
Subject: What would you like to see most in minix?
Summary: small poll for my new operating system
Message-ID: <1991Aug25.205708.9541@klaava.Helsinki.FI>
Date: 25 Aug 91 20:57:08 GMT
Organization: University of Helsinki

Hello everybody out there using minix -

I'm doing a (free) operating system (just a hobby, won't be big and
professional like gnu) for 386(486) AT clones. This has been brewing
since april, and is starting to get ready. I'd like any feedback on
things people like/dislike in minix, as my OS resembles it somewhat
(same physical layout of the file-system (due to practical reasons)
among other things).

I've currently ported bash(1.08) and gcc(1.40), and things seem to work.
This implies that I'll get something practical within a few months, and
I'd like to know what features most people would want. Any suggestions
are welcome, but I won't promise I'll implement them :-)

Linus (torvalds@kruuna.helsinki.fi)

PS. Yes - it's free of any minix code, and it has a multi-threaded fs.
It is NOT protable (uses 386 task switching etc), and it probably never
will support anything other than AT-harddisks, as that's all I have :-(.

Nie samym jądrem Linux żyje. Aby z systemu można było w sposób rozsądny korzystać niezbędne jest oprogramowanie. Jak podaje Wikipedia: „dystrybucja (…) systemu operacyjnego Linux to zestaw programów rozpowszechnianych łącznie i dający po zainstalowaniu gotowy do użycia system”.

Chcąc być do końca poprawnym należy mówić o systemie Linux w formie GNU/Linux. Zestaw narzędzi GNU był rozwijany na długo przed pojawieniem się słynnego postu Linus Torwaldsa na grupach dyskusyjnych. Cytując za gnu.org.

Rzeczywiście, istnieje coś, co nazywamy "Linux", i są ludzie, którzy z niego korzystają, ale nie jest to system operacyjny.
Linux jest jądrem — tym programem w systemie, który przydziela zasoby komputera innym, uruchamianym przez nas programom. 
Jądro jest istotną częścią systemu operacyjnego, ale samo jest bezużyteczne — może działać tylko w obrębie pełnego systemu 
operacyjnego. Linux jest zwykle używany w połączeniu z systemem operacyjnym GNU: cały system to zasadniczo GNU, z Linuksem 
funkcjonującym jako jądro.

Przed powstaniem pierwszej dystrybucji, przyszły użytkownik Linuxa musiał być unixowym ekspertem, nie tylko wiedząc jakie aplikacje i biblioteki są niezbędne do prawidłowego załadowania i uruchomienia systemu, ale także znając bardzo dobrze rozmieszczenie plików w systemie oraz konfigurację owych aplikacji.

Pierwsze dystrybucje powstały niedługo po tym jak Linuxa zaczęli używać ludzie, którzy nie byli jego twórcami. Twórcy byli bardziej zainteresowani rozwojem systemu niż rozwojem aplikacji, interfejsem użytkownika czy prostotą instalacji.

• MCC Interim Linux - stworzona na Uniwersytecie w Manchesterze w lutym 1992 roku
• MJ - wydana w lipcu 1992 przez Martina Juniusa
• TAMU - stworzona w na uniwersytecie TAMU w Teksasie (lipiec 1992)
• SLS (Softlanding Linux System) - stworzona przez Petera MacDonalda w sierpniu 1992 roku

Dystrybucje te zawierały proste programy instalacyjne, które jednak nie obejmowały całego procesu instalacji. Zarówno w MMC Interim Linux oraz SLS, użytkownik samodzielnie musiał wykonać partycjonowanie dysku (przy użyciu wcale nie prostego narzędzia fdisk). Po skopiowaniu plików duża część opcji musiała być skonfigurowana przez użytkownika ręcznie (przez edycję odpowiednich plików) lub pół-automatycznie (instalator zadawał szereg dość szczegółowych pytań, na które trzeba było poprawnie odpowiedzieć).

Ostatnia z wymienionych dystrybucji była najbliższa dzisiejszym dystrybucjom. Zawierała ona zbiór skompilowanych pakietów, które można było instalować wedle uznania. Składały się na nią dyskietki z głównym systemem operacyjnym, dodatkami (np. dokumentacja man, emacs), kompilatorem gcc, X-Window, program Tex oraz kodem źródłowym. Zdobyła ona naprawdę dużą popularność - była zainstalowana na większości komputerów z systemem Linux.

Jednak żadna z powyższych dystrybucji nie była porządnie utrzymywana więc Patrick Volkerding stworzył na bazie SLS dystrybucję, którą nazwał Slackware. Jest to najstarsza ciągle rozwijana dystrybucja. Inne znane dzisiaj dystrybucje powstawały w różny sposób. Przykładowo Debiana stworzono na bazie SLS a jego powstanie zostało ogłoszone na grupie comp.os.linux.development w 1993 roku. Stworzony w 1994 roku RedHat był natomiast od początku przedsięwzięciem komercyjnym.

Linki:

• http://linux.ka.nu/ - stąd można ściągnąć niektóre starsze dystrybucje (między innymi MCC Interim Linux oraz SLS)
• http://hedera.linuxnews.pl/_news/2003/11/28/_long/2339.shtml - trocę informacji o początkach dystrybucji Linuxa

Typowa dystrybucja Linuxa składa się z jądra systemu, oprogramowania, dokumentacji oraz multimediów (takich jak fonty, tapety pulpitu, dźwięki systemowe itp.). Większość dołączonego oprogramowania jest darmowa (najczęściej typu open-source). Twórcy rozprowadzają je najczęściej zarówno w formie prekompilowanych plików binarnych jak i kodu źródłowego, co umożliwia użytkownikom modyfikowanie aplikacji. Część oprogramowania zawarta w niektórych dystrybucjach może być pozbawiona kodu źródłowego - przykładowo Macromedia Flash jest takim oprogramowaniem.

Dystrybucje Linuxa prawie zawsze zawierają skompilowane wersję jądra (najbardziej znany wyjątek – Gentoo), biblioteki systemowe GNU oraz różnego rodzaju programy składające się na resztę systemu operacyjnego. Wiele z nich dostarcza program lub procedurę instalacyjną przypominające te z innych systemów (np. Microsoft Windows). Dystrybucje typu self-hosting (np. Gentoo) dostarczają kod źródłowy całego oprogramowania a pliki binarne jedynie dla podstawowych narzędzi do kompilacji (kompilator, narzędzie make itp.). Instalor kompiluje wtedy całe oprogramowanie dla architektury komputera użytkownika.

Dystrybucje są najczęściej podzielone na pakiety. Każdy pakiet zawiera pewną aplikację lub usługę: jeden pakiet może zawierać bibliotekę umożliwiającą wyświetlanie plików PNG, inny może zawierać fonty a trzeci dostarcza przeglądarkę WWW. Wiele dystrybucji razem z podzielonymi na pakiety, skompilowanymi aplikacjami dostarcza wyspecjalizowane narzędzia do instalowania/usuwania tychże pakietów. Takie oprogramowanie nazywa się Oprogramowaniem (Systemem) Zarządzającym Pakietami i szczegółowo traktuje o tym rozdział Zarządzenie pakietami.

Większość dystrybucji instaluje pakiety włączając w to jądro oraz kluczowe komponenty systemu w ustalonej z góry konfiguracji. Sprawia to że instalacja jest prostsza i mniej zniechęcająca, co jest szczególnie ważne dla mniej doświadczonych użytkowników. Nie zawsze jednak jest to dobre rozwiązanie. Większość oprogramowania musi być starannie skonfigurowana aby spełnić specyficzne wymagania, współpracować z innymi aplikacjami albo by być bezpieczna. Administratorzy muszą często spędzić dużo czasu testując i zmieniając konfigurację oprogramowania.

Twórcy niektórych dystrybucji starają się przystosować dołączane oprogramowanie do pracy z tą dystrybucją (poprzez określenie położenia plików itp.). Część dystrybucji dostarcza narzędzia konfiguracyjne, które pomagają w tym procesie, ale znowu nie wszystkie. Niektóre wymagania są specyficzne dla komputera lub sieci i prekonfigurowanie oprogramowania tak aby spełniało te wymagania jest niemożliwe nawet dla projektanta dystrybucji. Tak samo jak z innymi systemami operacyjnymi, Linux i jego dystrybucją nakładają obowiązek administrowania sobą na swoich użytkowników/operatorów/administratorów. Twórcy dystrybucji Linuxa w przeciwieństwie do większości sprzedawców systemów operacyjnych, nie twierdzą że „administracja nie jest wymagana”. Poprzez zastępowanie różnych rzeczy dostarczonych przez dystrybucję, administrator może dojść do miejsca, w którym nic nie zostało z pierwotnej dystrybucji. Wszystko zostało pobrane, skompilowane, skonfigurowane i zainstalowane lokalnie. Możliwe jest również zbudowanie takiego systemu od podstaw całkowicie pomijając istniejące dystrybucje, jednakże trzeba skądś mieć pierwsze pliki binarne dopóki system nie będzie w pełni samodzielny (tzn. nie będzie posiadał działającego jądra oraz skompilowanych narzędzi do kompilacji). Może to zostać osiągnięte przez kompilacje krzyżową (cross-compilation – czyli kompilowanie źródeł na jednej maszynie tak aby działały na innej) na innym systemie. Przykładem może być projekt Linux From Scratch.

Aby system mógł wystartować po uruchomieniu komputera bootsector partycji i/lub całego dysku musi być odpowiednio zmodyfikowany. Minimalna dystrybucja musi na pewno zawierać skompilowane i działające jądro Linuxa. Proces bootowania systemu można podzielić na dwie fazy:

• fazę inicjalizacji jądra
• fazę uruchamiania programów

Po zakończeniu pierwszej fazy, jądro uruchamia pierwszy proces systemu – init, który jest przodkiem wszystkich innych procesów. W poszukiwaniu procesu init, jądro sprawdza czy istnieją następujące pliki /sbin/init, /bin/init, /etc/init. Jeśli żaden z wymienionych nie istnieje uruchamia program /bin/sh. Można więc powiedzieć że minimalna dystrybucja Linuxa wymaga jedynie jądra oraz dowolnego programu, który będzie wywołany jako init (może to być nawet program /bin/ls aczkolwiek taki system wypisze jedynie zawartość głównego katalogu i się zawiesi). Wszystko pozostałe jest teoretycznie zbędne.

Instalując dowolną dystrybucję Linuxa oczekujemy pewnego zestawu programów, które umożliwiają pracę z system. Przykładowo chcemy aby po załadowaniu systemu uruchomiła się powłoka systemu, co umożliwi nam wpisywanie poleceń. Poniżej opisanych jest kilka bardzo popularnych pakietów, które znajdują się niemal w każdej dystrybucji.

Zdecydowana większość dystrybucji (jeśli nie wszystkie) używa pakietu SysVinit, który zawiera program init oraz skrypty wykonujące między innymi szereg czynności przygotowujących system do pracy (np. uruchamianie sieci, demonów logujących itp.). Sposób działania tych skryptów jest zgodny ze sposobem inicjalizacji systemu opisanym przez standard Linux Standard Base.
Konfiguracja programu init znajduje się w pliku /etc/inittab. Jej opis można znaleźć na stronie, której adres jest podany niżej.

Pakiet Bash zawiera Bourne-Again SHell, czyli bardzo rozbudowaną powłokę oferującą ogromne możliwości.

Pakiet Bzip2 zawiera programy do kompresji i dekompresji plików. Kompresując pliki przy użyciu programu bzip2 uzyskuje się znacznie lepszy stopień kompresji niż przy użyciu tradycyjnego programu gzip.

Pakiet Coreutils zawiera narzędzia do podstawowej konfiguracji systemu.

Narzędzia wchodzące wskad pakietu: basename, cat, chgrp, chmod, chown, chroot, cksum, comm, cp, csplit, cut, date, dd, df, dir, dircolors, dirname, du, echo, env, expand, expr, factor, false, fmt, fold, groups, head, hostid, hostname, id, install, join, link, ln, logname, ls, md5sum, mkdir, mkfifo, mknod, mv, nice, nl, nohup, od, paste, pathchk, pinky, pr, printenv, printf, ptx, pwd, readlink, rm, rmdir, seq, sha1sum, shred, sleep, sort, split, stat, stty, sum, sync, tac, tail, tee, test, touch, tr, true, tsort, tty, uname, unexpand, uniq, unlink, users, vdir, wc, who, whoami, yes.

Pakiet Diffutils zawiera programy porównujące pliki i katalogi.

Pakiet Findutils zawiera programy do wyszukiwania plików. Programy te umożliwiają rekurencyjne przeszukiwanie drzewa katalogów oraz tworzenie, utrzymywanie i wyszukiwanie bazy danych (co często daje szybsze rezultaty niż wyszukiwanie rekurencyjne, ale wymaga częstego aktualizowania bazy danych).

Pakiet Gawk zawiera programy do przetwarzania plików tekstowych.

Pakiet Grep zawiera programy do wyszukiwania w plikach.

Pakiet Gzip zawiera programy do kompresji i dekompresji plików.

Pakiet Ncurses zawiera biblioteki oferujące niezależne od terminala sterowanie ekranem znakowym.

Pakiet Patch zawiera program do modyfikowania i tworzenia plików poprzez aplikowanie tzw. plików-łatek stworzonych przy użyciu programu diff.

Pakiet Sed zawiera edytor strumieniowy.

Pakiet Tar zawiera program archiwizujący.

Pakiet Util-linux zawiera różne programy narzędziowe. Wśród nich są narzędzia do związane z systemem plików, konsolą, partycjami oraz wiadomościami systemowymi.

Narzędzia wchodzące wskład pakietu: agetty, arch, blockdev, cal, cfdisk, chkdupexe, col, colcrt, colrm, column, ctrlaltdel, cytune, ddate, dmesg, elvtune, fdformat, fdisk, fsck.cramfs, fsck.minix, getopt, hexdump, hwclock, ipcrm, ipcs, isosize, line, logger, look, losetup, mcookie, mkfs, mkfs.bfs, mkfs.cramfs, mkfs.minix, mkswap, more, mount, namei, pg, pivot_root, ramsize (link do rdev), raw, rdev, readprofile, rename, renice, rev, rootflags (link do rdev), script, setfdprm, setsid, setterm, sfdisk, swapdev, swapoff (link do swapon), swapon, tunelp, ul, umount, vidmode (link do rdev), whereis, write.

Pakiet Vim zawiera potężny edytor tekstowy.

• Strona domowa projektu Linux From Scratch - http://www.linuxfromscratch.org/
• Aktualna instrukcja, jak stworzyć system od zera - http://www.linuxfromscratch.org/lfs/view/stable/
• Opis pliku konfiguracyjnego /etc/inittab - http://www.debianusers.pl/article.php?aid=25#2

Już od wersji 0.01 Linux na tyle wspierał wywołania systemowe (system calls) opisane w POSIX, że można było uruchomić powłokę GNU Bash. Ogólnie po co są standardy i co jest ustandaryzowane.

To wspólna nazwa dla zestawu standardów zaproponowanych przez IEEE, określających wzorcowe API dla aplikacji które miały działać na różnych wersjach systemu UNIX. Cały projekt wystartował gdzieś w okolicach 1985 roku jako przedśięwzięcie mające na celu opracowanie standardu IEEE 1003. Richard Stallman zaproponował później nazwę POSIX, która to została rozwinięta do Portable Operating System Interface.

Ponieważ IEEE pobierało bardzo wysokie opłaty za dokumentację POSIX, i nie zezwalało na jej publikację w Internecie, powstał standard Single UNIX Specification. Jest on otwarty, uwzględnia uwagi od każdego i jest wolnodostępny w Internecie. Obecnie kosztowne są procedury standaryzacyjne i związane z nimi testy PCTS (ang. Posix Conformance Test Suite - Zestaw Testów Zgodności z Posiksem). Implementacja która przejdzie testy może uzyskać certyfikat “zgodności z Posiksem”.

POSIX był opracowywany z myślą o systemach unixkowych. Dzisiaj więc nie dziwi, że większość systemów mających swoje korzenie w takiej czy innej wersji unixa jest w pełni lub dużej części zgodnych z tym standardem. Pochodzenie od UNIXa nie jest jednak wymagana, np. systemy rodziny Windows NT są zgodne ze znaczącymi częściami standardu. Do tego istnieją środowiska dodatkowo tę zgodność rozszerzające jak Cygwin.

POSIX specyfikuje interfejs programowy systemu operacyjnego w około 15 dokumentach. Zawiera to między innymi opis działania powłoki i linii komend, działanie programów użytkowych awk, ehco czy ed i innych. Opisuje sposób programowego dostępu do zasobów (plików, terminali, sieci itd.). POSIX standaryzuje również API biblioteki wątkującej zawartej w wielu nowych systemach operacyjnych.

Nie wszystko było jednak tworzone od razu, POSIX miał kolejne wersje i rozszerzenia:

• POSIX.1, System bazowy
  • Tworzenie i zarządzanie procesami
  • Sygnały
  • Wyjątki operacji zmiennopozycyjnych
  • Naruszenie segmentacji
  • Niepoprawne instrukcje
  • Błędy magistrali
  • Czasomierze
  • Operacje na plikach i katalogach
  • Potoki
  • Standardowa biblioteka C
  • Interfejsy We/Wy i ich zarządzanie

• POSIX.1b, System czasu rzeczywistego
  • Szeregowanie z priorytetami
  • Sygnały czasu rzeczywistego
  • Zegary i czasomierze
  • Semafory
  • Wymiana komunikatów
  • Pamięć dzielona
  • Synchroniczne i asynchroniczne We/Wy
  • Blokady pamięci

• POSIX.1c, Wątkowanie
  • Tworzenie, zarządzanie i usuwanie wątków
  • Szeregowanie wątków
  • Synchronizacja wątków
  • Obsługa sygnaów

• P1003.1d, P1003.1e, P1003.1f, P1003.1g, P1003.1h, P1003.2, P1003.2b, P1003.2c, P1003.2d, P1003.3, P1003.5, P1387, P1003.9, P1003.10, P1003.11, P1003.13, P1003.14, P1003.16, P1224.2, POSIX.18, POSIX.19, POSIX.20, POSIX.21, POSIX.0

• http://www.opengroup.org/onlinepubs/007908799/
• http://www.unix.org/version3/

Na przestrzeni lat projekt opracowania otwartego standardu dla systemów UNIX nazywano różnie: Common API Specification → Spec 1170 → Single UNIX Specification. Tak czy inaczej głównym celem było udostępnienie dostępniejszego zamiennika abstrakcyjnie drogiego standardu POSIX.

Common API Specification został powołany do życia przez Sun Microsystems, IBM, Hewlett-Packard, Novell/USL i OSF. Które połączyły siły aby opracować jedną, wspólny specyfikację dla systemu UNIX. Dzięki zgodności z jednym standardem przenoszenie aplikacji użytkowych między różnymi implementacjami systemu byłoby natychmiastowe. Głównym celem było opracowanie niezbędnych interfejsów używanych przez aplikacji.

SUS jest kolekcją dokumentów które są częścią X/Open Common Applications Environment (CAE).

• Definicje Interfejsu Systemowego (System Interface Definitions, Issue 4, Version 2 (XBD))

Dokument XPD tłumaczy podstawowe pojęcia używane w XSH i XCU, zawiera informacje dotyczące lokalizacji i gramatyki wyrażeń regularnych oraz sporych rozmaiarów słownik.

• Interfejsy Systemowe i Nagłówki (System Interfaces and Headers, Issue 4, Version 2 (XSH))

Opisuje wszystkie nagłówki interfejsów dostępnych w SUS (za wyjątkiem interfejsów sieciowych i terminali opisanych w osobnych dokumentach). Obejmuje to podstawowe zasady użycia, wymogi zgodności, numery błedów, typy danych, strumienie itd.

• Polecenia i Narzędzia (Commands and Utilities, Issue 4, Version 2 (XCU))

Definiuje wszystkie polecenia i narzędzia dostępne w SUS. Zawiera to opis składni i możliwości powłoki systemowej (bardzo dokładne) oraz składnię i działanie dostarczanych narzędzi.

• Usługi Sieciowe (Networking Services, Issue 4)

Defniuje trzy zestawy usług sieciowych: X/Open Transport Interface, Gniazda XPG4 oraz protokół IP.

• X/Open Curses, Issue 4 Version 2

Linux Standard Base (LSB) jest wspólnym projektem kilku dystrybucji Linuxa realizowanym w ramach The Free Standard Group. Celem projektu jest opracowanie wspólnego standardu wewnętrznej struktury systemów operacyjnych opartych na Linuxie. LSB jest oparte na specyfikacjach POSIX, Single UNIX Specification oraz kilku innych otwartych standardach, ale rozszerza je w pewnych obszarach. Projekt ten jest wspierany przez takie firmy jak Novell, RedHat (mające własne dystrybucje Linuxa) a także Adobe czy Intel.

Jak sami podają:

Celem LSB jest rozwijanie oraz promowanie zbioru standardów, które zwiększą kompatybilność pomiędzy dystrybucjami Linuxa oraz sprawią, że aplikacje będą chodzić na każdym zgodnym ze standardem systemem. Dodatkowo LSB będzie koordynować wysiłki mające na celu zachęcić firmy do pisania produktów dla Linuxa.

Zgodność produktu z LSB może zostać potwierdzona przez procedurę certyfikacyjną. Certyfikacja jest przeprowadzana przez The Open Group we współpracy z The Free Standard Group.

LSB specyfikuje na przykład: standardowe biblioteki, wiele komend i narzędzi, które rozszerzają standard POSIX, hierarchię systemu plików, poziomy uruchamiania (run levels) i kilka dodatków do systemu X-Window.

Executable and Linking Format (ELF) definiuje format dla skompilowanych aplikacji. Specyfikacja LSB uzupełnia informacje z dokumentu System V ABI Update i w założeniu ma dokumentować zmiany poczynione od publikacji tego dokumentu.

Dystrybucja zgodna z LSB powinna zawierać następujące podstawowe biblioteki, które dostarczają interfejsu do korzystania z systemu operacyjnego, procesora i innego sprzętu w systemie.

• libc
• libm
• libgcc_s
• libdl
• librt
• libcrypt
• libpam

Dystrybucja zgodna z LSB powinna również zawierać następujące biblioteki narzędziowe, które są zbudowane na interfejsach dostarczanych przez biblioteki podstawowe. Te biblioteki implementują często używane funkcje i ukrywają niektóre zależne od systemu informacje takie jak formaty plików czy nazwy urządzeń.

• libz
• libcurses
• libutil

Dystrybucja zgodna z LSB powinna dostarczać niżej wymienione polecenia i narzędzia. Standard definiuje sposób zachowania się zdecydowanej większości z nich albo odsyła do standardu ISO POSIX (2003).

Dystrybucja zgodna z LSB powinna dostarczać następujące wbudowane w powłokę narzędzia. Zachowanie poszczególnych narzędzi opisuje standard ISO POSIX (2003).

• cd
• getopts
• read
• umask
• wait

Dystrybucja zgodna z LSB powinna być również zgodna ze obowiązkową częścią standardu FSH. Dodatkowo standard wprowadza kilka własnych wymagań (np. dodatkowe pliki w /dev).

Aplikacje nie powinny zakładać iż mają prawa zapisu do jakiegoś katalogu, chyba że jest to /tmp, /var/tmp lub katalog domowy użytkownika wywołującego aplikację. W tych katalogach aplikacja powinna móc pracować w prawem do zapisu ograniczonym przez bit S_ISVTXT implementujący ograniczone prawa do kasowania opisane w ISO POSIX (2003).

Aplikacja nie powinna zakładać że ma prawo zapisu do jakiegokolwiek pliku, którego sama nie utworzyła.

Aplikacja nie powinna zakładać, że ma prawo do odczytu każdego pliku lub katalogu.

Aplikacja nie powinna polegać na prawach określonych przez bity S_ISUID oraz S_ISGID dla pliku nie zawierającego się w pakiecie aplikacji. Zamiast tego dystrybucja odpowiada za to aby wszystkie polecenia systemowe miały wymagane prawa i pracowały poprawnie. Generalnie aplikacje nie powinny polegać na tym, iż są uruchamiane jako użytkownik uprzywilejowany. W uzasadnionych przypadkach, potrzeba bycia uruchomionym z odpowiednimi prawami powinna być dokładnie omówiona w dokumentacji aplikacji.

Aplikacja nie powinna zmieniać praw użytkowników do plików i katalogów, które nie należą do jej pakietu. Jeśli aplikacja ma jakieś wymagania co do tego, musi to być omówione w dokumentacji a instalacja może się powieść jeśli prawa są niewłaściwe Aplikacje uruchamiane z nośników wyjmowanych nie mogą zakładać, iż uruchamiane są w środowisku uprzywilejowanym.

Standard LSB opisuje dokładnie sposób działania skrytpów inicjalizacyjnych, akcje przez nie wykonywane, sposób instalacji oraz usuwania skryptów przez aplikacje a nawet konwencje dotyczące komentarzy w tych skryptach.

Skrypty te operują na runlevelach. W skrócie runlevel to tryb, w którym są uruchamiane i/lub zatrzymywane określone programy. Poniżej lista najczęściej stosowanych trybów:

Zmiana runlevelu odbywa się przez uruchomienie init z odpowiednim parametrem. Przykładowo wywołanie init 0 spowoduje zamknięcie systemu.

W katalogu /etc/rc.d znajdują się podkatalogi w rodzaju rc?.d (gdzie ? to właśnie runlevel) oraz rc.sysinit.d zawierające wiele linków symbolicznych. Część z nich zaczyna się na literę K, część na S a wszystkie mają dwucyfrową liczbę poprzedzającą właściwą nazwę. K oznacza, że zatrzymanie usługi, S jej start. Numer określa kolejność wykonywania skryptu od 00 do 99. Kiedy init przełącza się na inny runlevel określone usługi są uruchamiane lub zatrzymywane w zależności od wybranego runlevelu. Rzeczywiste skrypty znajdują się w katalogu /etc/rc.d/init.d. Wykonują one rzeczywistą pracę a linki symboliczne na nie wskazują. Linki zatrzymujące i uruchamiające usługę wskazują na ten sam skrypt w /etc/rc.d/init.d. Jest tak dlatego, że skrypt może być wykonywany z różnymi parametrami, takimi jak stop, start, restart, reload i status. W przypadku linku zaczynającego się na K odpowiedni skrypt jest wywoływany z parametrem stop, w przypadku S z parametrem start.

Opis poczególnych parametrów:

Standard LSB opisuje również sposób w jaki aplikacje powinny dodawać zdarzenia do deamona cron.

Format baz danych z użytkownikami i grupami nie jest wyspecyfikowany. Programy mogą jedynie przeglądać oraz modyfikować te bazy używając dostarczonego API. Poniższa tabela przedstawia wymagane nazwy grup oraz użytkowników w systemie. Standard nie przypisuje grupom i użytkownikom konkretnych numerów ID z wyjątkiem grupy i użytkownika root, którego UID i GID powinno być równe 0.

Poniższa tabela przedstawia opcjonalne nazwy użytkowników i grup (znowu nie przypisując im konkretnych numerów ID). Jeśli dany użytkownik istnieje w systemie to powinien należeć do odpowiadającej mu grupy. Poniższe nazwy użytkowników i grup są dla użytku dystrybucji a nie aplikacji.

Aplikacje nie mogą zakładać żadnego ustawienia domyślnej maski przy tworzeniu plików (umask) albo domyślnych praw dostępu do katalogów jakie posiada użytkownik. Aplikacje mogą jedynie zakładać prawo dostępu użytkownika do jego prywatnych plików takich jak mailboxy. Położenie katalogów domowych użytkowników również nie jest definiowane inaczej niż w Filesystem Hierarchy Standard. W celu uzyskania potrzebnych informacji aplikacje powinny używać funkcji getpwnam(), getpwnam_r(), getpwent(), getpwuid() oraz getpwuid_r().

Aplikacje powinny być dostarczane w pakietach w formacie RPM jak to jest zdefiniowane w specyfikacji LSB albo dostarczać instalator zgodny z LSB (np. wywołuje polecenia i narzędzia opisane w LSB).

Standard zachęca jednak do używania formatu RPM, gdyż dzięki temu łatwiej jest zarządzać systemem. Specyfikacja nie wymaga aby dystrybucja używała RPM jako swojego menedżera pakietów – specyfikuje ona jedynie format pakietu z oprogramowaniem.

Zaleca się również aby deinstalacja aplikacji była czysta (czyli żaden plik wchodzący w jej skład nie pozostał w systemie).

Dystrybucje powinny zapewnić możliwość instalacji aplikacji w tym formacie, ale same mogą używać innego formatu dla własnych aplikacji i mogą oczywiście używać dowolnego mechanizmu do instalacji pakietów zgodnych z LSB.

LSB jest krytykowane za to, iż nie uwzględnia rezultatów projektów spoza firm członkowskich, głównie z projektu Debian. Przykładowo LSB specyfikuje, że pakiety z oprogramowaniem powinny być dostarczane w formacie RPM (wymyślonym w Red Hat), który powstał znacznie później niż format deb (używany w Debianie) i programiści Debiana (i nie tylko) nie chcą zmieniać formatu, który uważają za lepszy. Standard nie narzuca jaki standard powinien używać system operacyjny dla swoich własnych pakietów a jedynie jaki format pakietów musi być obsługiwany aby użytkownik mógł zainstalować oprogramowanie innych producentów. Ostatnio jednak Debian zawiera opcjonalne wsparcie dla LSB – użytkownik używa specjalnego programu, który zamienia pakiety RPM na deb a potem je instaluje).

LSB jest również krytykowane za błędnie napisane testy, co może powodować niekompatybilność pomiędzy dystrybucjami zgodnymi z LSB, kiedy jedne dystrybucje implementują niepoprawne działanie aby wadliwe testy przeszły, podczas gdy inne uzyskują zwolnienie od zgodności z danym testem. Potępiany jest również brak testów aplikacji, gdyż testowanie jedynie dystrybucji nigdy nie rozwiąże problemu aplikacji polegających na konkretnej implementacji.

W pozostałych dziedzinach prace LSB są mniej kontrowersyjne i spotykają się z dużą wdzięcznością.

• http://www.linuxbase.org/
• http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/book1.html

Standard FSH zawiera wymogi i wskazówki dotyczące umiejscowienia plików i katalogów w unixopodobnych systemach operacyjnych. W założeniu wskazówki te mają zapewnić współdziałanie aplikacji, narzędzi administracyjnych, narzędzi programistycznych oraz skryptów w systemach zgodnych z tym standardem a także jednolitość dokumentacji tych systemów.

Proces standaryzowania systemu plików rozpoczął się w 1993 roku. Początkowo objął on jedynie hierarchię systemu plików w Linuxie. W 1994 roku powstała pierwsza wersja FSSTND (Linux Filesystem Structure Standard) a niedługo potem kolejne wersje. Jednak na początku 1995 roku wspólnie ze społecznością programistów BSD postawiono sobie za cel utworzenie bardziej kompletnego standardu, który obejmowałby nie tylko Linuxa, ale także inne unixopodobne systemy. W rezultacie poczyniono znaczące wysiłki aby skupić się na kwestiach wspólnych dla wszystkich systemów unixopodobnych. Ze względu na zwiększony obszar zastosowania standardu, nazwa została przemianowana na Filesystem Hierarchy Standard (Standard Hierarchii Systemu Plików) albo w skrócie FHS.

Standard ten umożliwia oprogramowaniu oraz użytkownikom przewidzieć położenie zainstalowanych plików oraz katalogów. Osiągnięte to zostało przez:

• wyspecyfikowanie zasad tworzenia dla każdego obszaru systemu plików
• podanie minimalnego zbioru wymaganych plików i katalogów
• wymienienie wyjątków od zasad
• wymienienie szczególnych przypadków, gdzie występuje konflikt ze względu na zaszłości historyczne

Standard ma ograniczony zasięg:

• lokalne położenie lokalnych plików to sprawa lokalna - FHS nie ma zamiaru niczego narzucać administratorom systemów
• FHS wskazuje sytuacje, w których położenie plików musi być skoordynowane pomiędzy wieloma stronami jak lokalne sieci, dystrybucje, aplikacje, dokumentacja itp.

Standard zakłada, że system operacyjny bazujący na FSH obsługuje podstawowe zasady bezpieczeństwa, które można znaleźć w większości systemów UNIX-owych.

Z punktu widzenia FSH możliwe są dwa niezależne podziały plików:

• na współdzielone i niewspółdzielone - pliki współdzielone to takie, które mogą być przechowywane na jednym hoście i używane na innych (np. pliki z katalogu domowego użytkownika)
• na statyczne i dynamiczne (zmienne) - pliki statyczne to wszelkiego rodzaju pliki binarne, biblioteki, dokumentacja i inne pliki, które się nie zmieniają bez interwencji administratora systemu

Pliki, które różnią się ze względu na dowolne z powyższych kryteriów powinny być przechowywane w różnych katalogach. Rozdzielenie plików współdzielonych od nie współdzielonych ułatwi dostęp do tych plików na innym komputerze – wystarczy podmountować odpowiedni katalog. Pliki statyczne z kolei w przeciwieństwie do dynamicznych mogą być umieszczone na systemie plików tylko do odczytu i nie muszą być tak często backupowane jak pliki dynamiczne.

Przykładowa (niepełna) tabelka zgodnego z FSH systemu:

Zgodnie ze standardem FSH, zawartość głównego systemu plików musi pozwalać na:

• uruchomienie systemu – odpowiednie narzędzia, pliki konfiguracyjne bootloadera oraz pozostałe rzeczy niezbędne do wystartowania systemu oraz zamontowania innych systemów plików (gdyż np. /usr, /opt oraz /var mogą być na innych partycjach)
• naprawienie systemu – narzędzia potrzebne użytkownikowi do naprawienia uszkodzonego systemu muszą znajdować się w głównym systemie plików
• przywrócenie systemu – narzędzia pozwalające na przywrócenie systemu ze wcześniej stworzonych kopii zapasowych muszą być umieszczone w głównym systemie plików

Standard zaleca aby główny system plików był (w granicach rozsądku) jak najmniejszy. Podawane powody wymienione są poniżej:

• Czasami główny system plików znajduje się na nośniku o małej pojemności.
• Główny system plików zawiera wiele specyficznych dla systemu plików konfiguracyjnych (np. z nazwą hosta). Oznacza to że główny system plików zazwyczaj nie jest współdzielony w sieci. Utrzymywanie go małym powoduje że będzie więcej miejsca dla współdzielonych plików.
• Błędy dyskowe, które uszkadzają dane są bardzo niebezpieczne w przypadku głównego systemu plików. Mniejszy główny system plików to mniejsza podatność na uszkodzenia w wyniku awarii systemu.

Aplikacje nigdy nie mogą tworzyć ani wymagać do poprawnego działania specjalnych plików ani katalogów w katalogu głównym. Pozostałe miejsca w hierarchii FHS są aż nadto elastyczne dla każdej aplikacji.

Lista wymaganych katalogów w /:

• bin – pliki wykonywalne podstawowych komend
• boot – statyczne pliki bootloadera
• dev – pliki urządzeń
• etc – pliki konfiguracyjne specyficzne dla hosta
• lib – główne współdzielone biblioteki i moduły jądra
• media – punkt montowania dysków wyjmowalnych
• mnt – tymczasowy punkt montowania dla systemów plików
• opt – dodatkowe aplikacje
• sbin – podstawowe z punktu widzenia systemu pliki binarne
• srv – dane dla usług dostarczanych przez system (np. WWW, FTP)
• tmp – pliki tymczasowe
• usr – drugi oprócz głównego najważniejszy system plików
• var – dynamiczne (zmieniające się) dane

Zawiera pliki binarne podstawowych komendy używanych przez wszystkich użytkowników.

Następujące programu muszą się znaleźć w katalogu bin:

Komendy [ oraz test muszą być umieszczone razem w /bin albo w /usr/bin (wymaga tego również standard POSIX.2).

Katalog ten zawiera wszystko co jest potrzebne do załadowania systemu (głównie statyczne pliki bootloadera) poza plikami konfiguracyjnymi niepotrzebnymi podczas wczesnej fazy ładowania. Innymi słowy /boot zawiera dane, które są używane zanim jądro zacznie wykonywać programy w trybie użytkownika.

Katalog /etc zawiera pliki konfiguracyjne. Plik konfiguracyjny to lokalny plik używany do kontrolowania wykonywania się programu. Musi być statyczny i nie może być wykonywalnym plikiem binarnym.

W katalogu /etc nie mogą się znajdować pliki binarne.

Następujące katalogi (lub linki symboliczne) muszą się znajdować w /etc:

Specyficzne dla hosta pliki konfiguracyjne dla dodatkowych aplikacji muszą być zainstalowane w katalogu /etc/opt/<podkatalog>, gdzie podkatalog to nazwa podkatalogu w /opt w którym znajdują się statyczne pliki tej aplikacji.

Katalog jest opcjonalny i zawiera katalogi domowe użytkowników.

/home jest powszechnie stosowanym rozwiązaniem, ale administrator może dowolnie decydować o jego strukturze. Tak więc żaden program nie powinien niczego zakładać o tej lokacji.

Katalog /lib zawiera moduły jądra oraz współdzielone biblioteki, które są niezbędne do uruchomienia systemu i wykonywania poleceń na głównym systemie plików (np. przez pliki binarne z /bin i /sbin).

Zestaw plików z conajmniej jednego z poniższych wzorców jest wymagany (mogą to być pliki albo linki symboliczne):

Jeśli jądro obsługuje moduły ładowalne, to muszą się one znajdować w katalogu /lib/modules.

Ten katalog powinien zawierać podkatalogi, które są używane jako punkty montowania dla dysków wyjmowanych (np. dyskietka, CD-ROM). Kiedyś najczęściej punktem montowania dla wyjmowanych urządzeń był /mnt, ale kłóciło się to ze starszą tradycją wedle której /mnt był używany jedynie jako tymczasowy punkt montowania.

Następujące podkatalogi (albo linki symboliczne) muszą się znajdować w /media jeśli w komputerze znajduje się dane urządzenie:

Kiedy mamy więcej niż jeden czytnik CD-ROM, katalogi powinny zawierać dodatkowo numer urządzenia począwszy od 0 (np. cdrom0, cdrom1), ale katalog cdrom także musi istnieć.

Katalog ten jest przeznaczony dla administratora systemu, aby tymczasowo mógł montować systemy plików. Zawartość tego katalogu jest zależna od administratora i żaden program nie powinien czynić jakichkolwiek założeń co do jego struktury.

Ten katalog nie może być także używany przez programy instalacyjne jako katalog tymczasowy.

/opt jest zarezerwowany jako miejsce gdzie zainstalowane są pakiety dodatkowych aplikacji.

Katalogi /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib i /opt/man są zarezerwowane dla użytku administratora. Aplikacje mogą zawierać pliki, które powinny być do nich skopiowane (lub zlinkowane), ale muszą pracować normalnie w przypadku braku powyższych katalogów.

Programy, które będą uruchamiane przez użytkowników muszą być umieszczone w katalogu /opt/<package>/bin albo w hierarchii /opt/<provider>. Jeżeli pakiet z oprogramowaniem zawiera strony manuala, muszą one być umieszczone w /opt/<package>/share/man lub w hierarchii /opt/<provide> i musi być użyta taka sama struktura jak w przypadku /usr/share/man.

Pliki dynamiczne muszą być zainstalowane w /var/opt.

Pliki konfiguracyjne muszą być zainstalowane w /etc/opt.

Żadne pliki takiej aplikacji nie mogą się znajdować poza katalogami /opt, /var/opt i /etc/opt z wyjątkiem plików specjalnych takich jak urządzenia, czy pliki blokad (lock files).

Katalog jest opcjonalny i jest on katalogiem domowym administratora systemu.

Katalog domowy administratora może być określony przez programistę tworzącego system albo samego administratora, ale zaleca się aby umieścić go w domyślnej lokacji.

W katalogach /sbin, /usr/sbin, /usr/local/sbin znajdować się powinny narzędzia używane do administacji systemem i inne programy dostępne tylko dla roota.

/sbin powinien zawierać programy niezbędne do uruchomienia, naprawienia i przywrócenia systemu, oprócz tych które są w /bin.

Programy uruchamiane po zamontowaniu /usr powinny być umiejscowione w /usr/sbin. Lokalnie zainstalowane narzędzia administracyjne powinny się znaleźć w /usr/local/bin.

Następujące pliki muszą się znaleźć w /sbin

Katalog /srv zawiera dane związane z usługami oferowanymi przez hosta (np. CVS, WWW). Dzięki wyodrębnieniu tego katalogu, użytkownicy będą mogli znaleźć pliki z danymi dotyczącymi poszczególnych usług zainstalowanych w systemie. Jest to również jedyne rozsądne miejsce gdzie można trzymać dane powiązane z usługami. Dane dotyczące tylko jednego użytkownika powinny być trzymane w katalogu domowym tego użytkownika.

Hierarchia katalogu /srv nie jest opisana, gdyż nie ma w tej sprawie porozumienia. Można stworzyć strukturę odpowiadającą protokołom (np. /srv/ftp, /srv/www). Jednak w dużych systemach raczej sprawdza się struktura oparta na podziale administracyjnym (np. /srv/mimuw/www, /srv/biol/ftp). Tak więc programy nie powinny działać poprawnie niezależnie od przyjętej struktury.

Katalog /tmp zawiera pliki tymczasowe.

Katalog tmp musi być dostępny dla programów, które chcą tworzyć pliki tymczasowe.

Programy nie mogą zakładać że jakiekolwiek pliki czy katalogi stworzone w tmp przetrwają czas pomiędzy dwoma wywołaniami programu. Założenia powyższe nakłada również standard POSIX.2.

Zalecane jest czyszczenie katalogu /tmp podczas każdego ładowania systemu.

Katalog /usr jest drugą główną częścią systemu plików. Zawiera on dane współdzielone tylko do odczytu. To znaczy że /usr może i powinien być współdzielony pomiędzy zgodnymi z FHS hostami i nikt nie może do niego pisać. Wszelkie dane specyficzne dla hosta albo zmienne muszą być trzymane gdzie indziej.

Duże pakiety z oprogramowaniem nie mogą używać bezpośredniego podkatalogu w hierarchii /usr.

Następujące katalogi albo linki symboliczne są wymagane w /usr:

W katalogu /usr/local powinny być aplikacje instalowane lokalnie. Nie powinien być on brany pod uwagę podczas aktualizowania oprogramowania zainstalowanego na komputerze.

Następujące katalogi (lub linki symboliczne) muszą się znajdować w /usr/local:

Żadne inne katalogi poza wymienonymi powyżej nie powinny się znajdować w /usr/local po zainstalowaniu systemu zgodnego z FHS.

Katalog /usr/share jest przeznaczony dla niezależnych od architektury plików tylko do odczytu.

W założeniu katalog ten ma być współdzielony pomiędzy wszystkimi architekturami danego systemu operacyjnego (np. sieć w której są komputery i386, Alpha oraz PPC mogą utrzymywać jeden centralny katalog /usr/share). Jednakże różne wydania tego samego systemu a tym bardziej różne systemy mogą mieć różną hierarchię /usr/share.

Każdy program albo pakiet, który przechowuje albo wymaga danych, które nie muszą być modyfikowane, powinien trzymać te dane w /usr/share (albo w /usr/local/share jeśli jest zainstalowany lokalnie).

Następujące katalogi albo symboliczne linki muszą się znajdować w /usr/share:

Katalog /usr/share/man zawiera strony manuali dla programów i danych znajdujących się w systemie plików / oraz /usr. Głównym katalogiem ze stronami manuala <mandir> w systemie powinien być /usr/share/man.

Strony manuala są trzymane w <mandir>/<język>/man<sekcja>/<architektura>.

Opis poszczególnych sekcji:

• man1: Strony manuali, które opisują programy dostępne każdemu użytkownikowi. Większość dokumentacji, którą potrzebuje użytkownik znajdzie się tutaj.
• man2: Ta sekcja opisuje wywołania systemowe.
• man3: Opisane są funkcje biblioteczne, które nie są wywołaniami systemowymi. Sekcje 2 i 3 są głównie dla programistów.
• man4: Sekcja opisuje pliki specjalne, funkcje sterowników oraz wsparcie dla sieci dostępne w systemie. Najczęściej obejmuje to pliki urządzeń znalezione w /dev i interfejs jądra dla protokołów sieciowych.
• man5: Strony manuali opisujące formaty plików (np. plików systemowych, plików wynikowych różnych aplikacji).
• man6: Ten rozdział opisuje gry, dema i inne mniej ważne rzeczy.
• man7: Wszystko czego nie dało się sklasyfikować ląduje tutaj.
• man8: Tutaj opisane są programy do administrowania systemem.

/var zawiera pliki dynamiczne, czyli logi, przejściowe i tymczasowe pliki, pliki blokad (lock files) oraz pliki lub katalogi zawierające informacje o tym co trzeba będzie zrobić w przyszłości (spool). /var istnieje po to aby móc zamontować /usr w trybie tylko do odczytu.

Część katalogów i plików z /var nie jest współdzielona pomiędzy systemami (np. /var/log, /var/lock czy /var/run). Inne natomiast są współdzielone: /var/mail, /var/cache/man, /var/cache/fonts czy /var/spool/news.

Aplikacje raczej nie powinny dodawać katalogów na najwyższym poziomie w hierarchi /var.

Następujące katalogi albo linki symboliczne są wymagane w /var:

Poza ogólnymi wskazówkami dla każdego systemu operacyjnego FSH zawiera również wymagania i wskazówki specyficzne dla Linuxa. Poniżej najważniejsze z nich.

Następujące urządzenia muszą istnieć w katalogu /dev:

Wirtualny system plików dostarczający informacji o jądrze i procesach.

System plików proc jest de-facto w Linuxie standardową metodą odczytywania informacji o procesach i systemie (w przeciwieństwie do /dev/kmem lub innych podobnych). FHS bardzo zaleca zamontowanie tego systemu plików w celu przechowywania i odczytywania informacji o procesach a także innych danych o jądrze czy pamięci.

Jedyny kod źródłowy, który powinien być umiejscowiony w konkretnym katalogu to źródła jądra Linuxa. Powinny się one znajdować w /usr/src/linux.

Wiele dystrybucji (wśród nich: Fedora, SUSE, Debian, Ubuntu) stara się być zgodna z FHS 2.3 i w dużym stopniu jest. Ze znanych dystrybucji np. Knoppix jeszcze nie jest.

• Specyfikacja standardu FHS - http://www.pathname.com/fhs/

Wcześniej dystrybucja ta nosiła nazwę Mandrake Linux (zmiana nazwy wywołana została przez połączenie firm Mandrakesoft i Conectiva, oraz w związku z procesem o prawo do nazwy Mandrake). W Polsce często nazywana jest ona “mandarynką”. Mandrake, a poźniej Mandriva praktycznie od początku istnienia cieszą się sławą najłatwiejszej w obsłudze dystrybucji Linuxa, pomimo tego, że od niedawna o to miano rywalizują także inne “przyjazne” dystrybucje. I właśnie prostota instalacji, a poźniej obsługi jest największą zaletą tej dystrybucji. Inną zaletą jest jej popularność, w związku z czym nie powinno być problemów ze znalezieniem pakietów przygotowanych z myślą o tej dystrybucji. Kolejną zaletą jest to, że w dystrybucji tej zwykle dość szybko pojawiają się “nowinki” ze świata Linuxa. Jedną z jej głównych wad jest nie do końca dopracowana wersja darmowa. Brak w niej przede wszystkim kontrowersyjnych prawnie pakietów, takich jak: biblioteka DeCSS służąca do odtwarzania zabezpieczonych przed nielegalnym kopiowaniem płyt DVD, programy do których nie ma udostępnionych kodów źródłowych takich jak: wtyczka Macromedia Flash do przeglądarki internetowej, kodeków (Windows Media, RealMedia, i inne), oraz udostępnianych przez producentów tylko w wersji binarnej sterowników urządzeń, przede wszystkim kart graficznych firm Nvidia i Ati (nie oznacza to, że system będzie niezdolny wyświetlać cokolwiek na systemach z tymi kartami graficznymi, ale nie będzie w stanie wykorzystać ich do sprzętowej akceleracji wyświetlania grafiki 3D). Niedopracowanie to objawia się również w sporadycznie występujących błędach - zwykle niegroźnych, ale jednak nieco utrudniających pracę z tym systemem.

Podobnie jak Mandriva jest to dystrybucja oparta na KDE (choć są plany, aby w następnych wydaniach podnieść rangę GNOME do równoważnego środowiska), w której również dość spory nacisk położono na prostotę użytkowania. Tym co dystrybucję tą wyróżnia spośród innych to bardzo starannie dopracowana wersja KDE dołączona do tej dystrybucji, dopracowana zarówno pod względem wizualnym, jak i użytkowym. Oprogramowanie dołączone do SuSE jest wprawdzie bardzo bogate (dystrybucja liczy 5 krążkół CD!), jednak znów brakuje “kontrowersyjnych” pakietów. W przypadku SuSE jest to posunięte jeszcze o krok dalej niż w Mandrivie, ponieważ za kontrowersyjny uznano format MP3 - i żaden program dołączony do SuSE nie posiada zdolności odtwarzania plików tego rodzaju. Mimo popularności SuSE rzadko się zdarza, by jakiś projekt udostępniał pakiety przygotowane dla tej dystrybucji - jednak do większości celów oprogramowanie dołączone na płytach w zupełności wystarcza.

Te dwie bliźniacze dystrybucje są kolejnymi przykładami dystrybucji adresowanych do niezaawansowanego użytkownika. Oparte są na bazie słynącej ze stabilności dystrybucji Debian, i mają z nim wspólny system zarządzania pakietami i część repozytoriów pakietów. Dystrybucje te w domyślnie ustawionych repozytoriach zawierają bardzo niewiele pakietów dostępnych bez kodów źródłowych (tylko kluczowe, takie jak binarne sterowniki pewnych urządzeń, głównie kart graficznych). Istnieje jednak możliwość dodania zewnętrznych repozytoriów pakietów, które zawierają potrzebne oprogramowanie. Obie te dystrybucje są tworzone w ścisłej współpracy, częściowo przez tę samą grupę osób, tym co je odróżnia jest domyślne środowisko graficzne: KDE w przypadku Kubuntu, GNOME w przypadku Ubuntu.

Dystrybucja ta, będąca darmowym odpowiednikiem dystrybucji RedHat, pomimo tego, że bardzo dobrze nadaje się również na komputer desktopowy, jest przeznaczona raczej na komputery, które oprócz funkcji normalnego desktopu będą także służyły jako serwer. Systemem zarządzania pakietami jest RPM, wśród pakietów dołączonych do dystrybucji znów jednak brakuje tych “kontrowersyjnych”, w tym także kodeków MP3. Domyślnym środowiskiem graficznym jest GNOME. Do dystrybucji jest również dołączone KDE, jednak zdaniem wielu użytkowników którzy mieli okazję używać KDE na Fedorze - bardzo dużo wysiłku twórcy tej dystrybucji włożyli w takie skonfigurowanie KDE, żeby swym zachowaniem i wyglądem jak najbardziej przypominało GNOME - co oczywiście zwykle jest źle przyjmowane przez tych użytkowników, którzy postrzegają to jako zmienienie KDE w kopię GNOME.

Ta dystrybucja jest zdecydowanie przeznaczona dla zaawansowanych użytkowików Linuxa. Brak jest graficznego instalatora, praktycznie całą instalację przeprowadza się ręcznie, korzystając jedynie z unixowych narzędzi takich jak fstab, oraz z pochodzącego z Gentoo systemu zarządzania pakietami Portage. I właśnie ten system zarządzania pakietami jest tym, co wyróżnia tę dystrybucję spośród pozostałych, ponieważ działa on według innej filozofii niż pozostałe - zamiast dostarczać użytkownikowi prekompilowane, gotowe do uruchomienia pakiety, Potrage dostarcza zbiór reguł jak należy dany pakiet na własnym komputerze skompilować, oraz narzędzia służące do automatycznego wykonywania tych reguł. System instaluje się “od podstaw” samemu dobierając według własnego uznania żądane pakiety, oraz ustawiając reguły kompilacji, co pozwala na niemal idealne dopasowanie systemu do własnych potrzeb.

To jest odmienna dystrybucja od pozostałych - charakteryzuje się tym, że uruchamia się bezpośrednio z płyty CD, dzięki czemu znajduje wiele zastosowań niedostępnych dla pozostałych - w szczególności często jest używana w charakterze “płyty ratunkowej” - dostępne na niej narzędzia często pozwalają przywrócić do działania zainstalowany na dysku system, który odmówił posłuszeństwa, a w przypadku gdyby to się nie udało - za pomocą tego systemu wykonać jakąś pilną pracę, korzystając z bogatej gamy aplikacji, która dzięki zastosowaniu kompresji udało się zmieścić na płycie - miedzy innymi OpenOffice. Należy wspomnieć, że KNOPPIX zawiera pełne środowisko KDE, wraz z pochodzącymi z niego aplikacjami. Kolejną zaletą KNOPPIXa jest możliwość “doinstalowania” brakującego oprogramowania do pamięci RAM - dzięki temu nie jesteśmy ograniczeni jedynie do używania programów dołączonych na płycie.

Ze względu na modularną budowę systemu GNU/Linux i ideę tworzenia małych, wyspecjalizowanych narzędzi wywodzącą się jeszcze z czasów UNIX’a, programy użytkowe na tej platformie rzadko są autonomiczne. Najczęściej do działania bardziej skomplikowanych aplikacji potrzebujemy np. odpowiedniego interpretera skryptów (jak Perl czy Python) czy zewnętrznych bibliotek (np GTK). Póki GNU/Linux był małym systemem utrzymanie porządku w zainstalowanych składnikach można było pozostawić administratorowi. Jednak gwałtowny rozrost dystrybucji wymusił stworzenie rozwiązań upraszczajacych to zadanie.

System zarządzania pakietami składa się z programów słuzących do automatyzacji procesu instalacji, uaktualniania, konfiguracji i usuwania pakietów oprogramowania z komputera. Najczęściej jest używany w odniesieniu do systemów unixowych ze względu na wspomnianą modularność, lecz nic nie ogranicza stosowania filozofii pakietów w innych systemach operacytjnych (patrz Windows Installer).

Pakiety są najczęściej rozpowszechniane jako pojedyncze pliki z wbudowanymi dodatkowymi informacjami takimi jak pełna nazwa, wersja, dostawca, suma kontrolna, _lista zależności_ niezbędnych do poprawnego uruchomienia aplikacji dostarczanej przez pakiet.

System zarządania pakietów jest odpowiedzialny za zarządanie i organizację całości oprogramowania instalowanego w systemie oraz dbanie o ich użyteczność i poprawne działanie. Aby zapewnić poprawne wykonywanie tej funkcji najczęściej implementuje się w nim kilka lub wszystkie z wymienionych poniżej ułatwień.

• Sprawdzanie sumy kontrolnej pakietu aby zapewnić brak różnić między lokalną a oficjalną wersją. W pewnym stopniu uoadparnia to system na błędy transmisji i celowe działanie na szkodę systemu.
• Możliwość prostej1) instalacji, uaktualnienia i usunięcia pakietu.
• Śledzenie zależności w celu dostarczenia kompletnego, działającego oprogramowania
• Automatyczne lub półautomatyczne uaktualnianie zainstalowanych pakietów w celu prostego wprowadzania poprawek użytkowych (bug fixes) i poprawek bezpieczeństwa (security updates)
• Grupowanie pakietów w grupy w celu łatwiejszego ogarnięcia ich przez użytkownika.

dpkg to podstawowy systemem zarządzania pakietami dystrybucji systemu operacyjnego GNU/Linux Debian. Zaprojektował i stworzył go Ian Jackson w 1993 roku. dpkg jest narzędziem niskiego poziomu co oznacza, że służy wykonywaniu podstawowych operacji na pakietach instalacyjnych. Bardziej skomplikowane czynności takie jak _określanie źródeł pakietów_ czy też _automatyczne rozwiązywanie zależności_ i konfliktów pomiędzy pakietami, wykonuje narzędzie wyższego poziomu jakim jest APT.

Pakiet Debiana “dpkg” dostarcza programu dpkg oraz kilku innych programów koniecznych do działania systemu pakietów, w tym dpkg-statoverride, dpkg-divert oraz update-alternatives. Dostarcza także programów takich jak start-stop-daemon, install-info oraz md5sum, przy czym dwa ostanie są rozprowadzane w tym pakiecie dla zachowania kompatybilności (obecnie są rozwijane i dystrybuowane osobno). Pakiet Debiana “dpkg-dev” zawiera narzędzia służące do budowania pakietów Debiana wymienione poniżej.

Debian oferuje serję narzędzi które są wykorzystywane podczas procesu budowania pakietu. Są to:

• dpkg-source pakuje i rozpakowuje pliki źródłowe pakietu,
• dpkg-deb pakuje i rozpakowuje pakiety binarne,
• dpkg-gencontrol generuje na podstawie informacji zawartych w plikach źródłowych pakietu plik control dla pakietu binarnego,
• dpkg-shlibdeps obliczają zależności od bibliotek,
• dpkg-genchanges czyta drzewo katalogów źródłowych po zbudowaniu pakietu i generuje na tej podstawie plik kontrolny (.changes),
• dpkg-buildpackage to skrypt pozwalający na automatyczne zbudowanie pakietu,
• dpkg-distaddfile dodaje plik do debian/files,
• dpkg-parsechangelog czyta plik z zapisem zmian (changelog) rozpakowanego pakietu źródłowego i tworzy opis zmian.

APT (czyli ‘Advanced Packaging Tool‘) jest systemem zarządzania pakietami, używanym przez system Debian. APT został zaprojektowany do współpracy z plikami .deb jedynie na systemie Debian, ale jego zmodyfikowane wersje działają również z pakietami RPM i uruchamiają się na innych systemach operacyjnych, takich jak Mac OS X.

APT znakomicie upraszcza proces instalacji i usuwania oprogramowania na systemach Uniksowych poprzez automatyczne ściąganie pakietu (z Internetu, sieci lokalnej lub płyty CD-ROM, konfigurację, ewentualną kompilację i instalację. Apt-get jest uważany za jedną z najlepszych cech Debiana i daje mu reputację systemu trudnego w instalacji, ale łatwego do używania.

APT nie jest programem samym w sobie. Jest biblioteką języka C++ używaną przez oddzielne programy (sterowane z linii poleceń) do zarządzania pakietami. Najczęściej używane z nich to apt-get i apt-cache. Przykładowo, polecenie pełnej instalacji pakietu php4 wygląda tak:

apt-get install php4

Apt przeszukuje listy pakietów i ich zależności i automatycznie je ściąga, konfiguruje i instaluje. Aby zaktualizować listę pakietów wystarczy wydać polecenie apt-get update. Polecenie apt-get upgrade pozwala na pełną aktualizację całego systemu do jego najnowszej wersji.

Projekt Debian posiada w swoim centralnym repozytorium ponad 13000 pakietów gotowych do ściągnięcia i instalacji. Dodatkowo, dowolna liczba innych repozytoriów może być wpisana do /etc/apt/sources.list.

Repozytorium pakietów nie koniecznie musi być umieszczone w Internecie. Może być nagrane na płyty CD-ROM. To umożliwia aktualizowanie komputerów nie podłączonych do sieci. Istnieją też programy oferujące przyjaźniejszy interfejs użytkownika. Najczęściej bazują one na apt-get. Są to między innymi aptitude (oparte na ncurses) i Synaptic (na GTK+).

Ideą APT jest to, żeby pakiet został zainstalowany bez podawania specyficznej lokacji, gdzie się znajduje. APT dodatkowo automatycznie zajmuje się zależnościami danej instalacji.

APT automatycznie wykrywa brakujące pakiety i sam je instaluje. Pokazuje rekomendowane i sugerowane programy i biblioteki. Podsumowuje także jakie nowe pakiety zostaną zainstalowane i jak dużo miejsca zajmą na dysku twardym.

FreeBSD znane jest z tzw. systemu portów. To stale rozwijane rozwiązanie pozwala na wygodną instalację i zarządzanie oprogramowaniem spoza systemu z wykorzystaniem źródeł, tj. w tradycyjny dla systemów uniksowych sposób - z uwzględnieniem zależności pomiędzy poszczególnymi programami.

Procedura instalacji programu składa się z następujących kroków:

1. wybór opcji instalacyjnych przez użytkownika (może być dokonany ręcznie lub automatycznie)
2. sprowadzenie źródeł z Internetu (jeśli są niedostępne lokalnie),
3. sprawdzenie ich integralności,
4. wprowadzenie niezbędnych poprawek wymaganych przez FreeBSD patch,
5. konfiguracja i zapis preferencji użytkownika,
   • ewentualna instalacja innych portów niezbędnych do działania danego programu<br>(rekursywne wykonanie procedury),
6. kompilacja,
7. instalacja w systemie,
8. rejestracja plików należących do programu z ich sumami kontrolnymi,
9. przypisanie do portu bibliotek i innych programów, które są niezbędne do jego działania,
10. usunięcie plików roboczych zbędnych po instalacji.

Porty tworzą hierarchiczną strukturę podzieloną na funkcjonalne kategorie. Szkielet portu powstaje na bazie pliku Makefile zgodnego z BSD make. W założeniu każdy port posiada swego opiekuna, którym mogą być zarówno pojedynczy programiści jak i całe zespoły odpowiedzialne w ramach FreeBSD za nadzór np. dużych środowisk GNOME i KDE.

Na bazie portów projekt udostępnia prekompilowane pakiety z domyślnymi opcjami dla wszystkich aktualnie wspieranych wersji i architektur FreeBSD. Pakiety rozprowadzane są poprzez Internet oraz na nośnikach optycznych, ich funkcjonalność jest identyczna do tych znanych w dystrybucji linuksowych. Programy instalowane przy pomocy portów i pakietów przechowywane są w przestrzeni odseparowanej od właściwego systemu, co pozwala na zachowanie integralności obu warstw oprogramowania.

Porty FreeBSD stały się bazą lub zainspirowały rozwój zbliżonych rozwiązań wykorzystywanych w systemach OpenBSD, NetBSD (pkgsrc) oraz Linux Gentoo.

Portage to system zarządzania pakietami wzorowany na portach FreeBSD. Został napisany w języku Python i jest głównym narzędziem odróżniającym Gentoo od innych dystrybucji. Z portage korzysta się przy pomocy komendy emerge.

Ebuild to alternatywa dla typowych w innych dystrybucjach prekompilowanych paczek oprogramowania. Jest to plik tekstowy opisujący jak pobrać, skonfigurować, skompilować źródła programu w sposób zoptymalizowany dla danej maszyny oraz jak zainstalować to oprogramowanie w systemie. Oficjalne ebuildy znajdują się na serwerach lustrzanych Gentoo. Nowe ebuildy można uzyskać przez zsynchronizowanie lokalnego drzewa Portage z repozytorium. Służy do tego komenda emerge –sync.

Flagi te wykorzystywane są przez system Portage do określenia, jakie opcje oprogramowania mają być uaktywnione w trakcie jego kompilacji. Umożliwia to dostosowanie oprogramowania do własnych potrzeb. Dla przykładu, jeśli ktoś nie używa środowiska graficznego GNOME tylko KDE, może ustawić odpowiednie flagi USE by oprogramowanie było kompilowane jedynie z obsługą tego drugiego. Flagi USE wpływają na zależności między pakietami oraz na to, jakie opcje będą przekazane przy kompilacji oprogramowania.

Dzięki maskowaniu pakietów w Gentoo można określić, które z pakietów mogą być instalowane w danym systemie. Umożliwia to określenie na jakich architekturach sprzętowych dany pakiet może działać. Wyróżnia się dwa rodzaje maskowania pakietów - twarde i przez słowa kluczowe (ang. keywords). Dla każdej architektury jest przypisane słowo kluczowe, jeśli jest ono poprzedzone znakiem tyldy oznacza wersję testową danego pakietu. Na przykład dla architektur x86 słowo kluczowe x86 oznacza pakiety stabilne i przetestowane, ~x86 oznacza natomiast pakiety wymagające testów. Używane słowa kluczowe są ustalane dla wszystkich pakietów przez zmienną ACCEPT_KEYWORDS w głównym pliku konfiguracyjnym (/etc/make.conf) lub oddzielnie dla każdego pakietu w pliku /etc/portage/package.keywords. Maskowanie twarde jest używane w stosunku do pakietów niebezpiecznych i niezalecanych do instalacji w związku z problemami, które mogą one powodować. Aby odmaskować twarde maskowanie należy dodać odpowiedni wpis do pliku /etc/portage/package.unmask.

W Gentoo istnieje możliwość stworzenia prekompilowanych pakietów oprogramowania. Mają one rozszerzenie .tbz2 i zawierają wszystkie pliki kopiowane przez Portage podczas zwykłej instalacji wraz z metadanymi umożliwiającymi zainstalowanie ich przez emerge. Pakiety takie mogą być wykorzystane do szybkiej instalacji na podobnych maszynach lub do szybkiej naprawy systemu po awarii.

RPM (RPM Package Manager, dawniej Red Hat Package Manager) to program służacy do instalacji i zarządzania pakietami zawierającymi oprogramowanie, oraz nazwa tych pakietów (ponieważ mają one rozszerzenie .rpm). Pakiety RPM zawierają skompresowane (we wczesnych wersjach gzipem, w nowszych bzipem2) archiwum tar zawierające oprogramowanie. Zawierają także (w specjalnym pliku .spec) informacje na temat zawartości, m.in. tzw. zależności (ang. dependencies) - czyli spis programów lub pakietów, które są wymagane do zainstalowania i poprawnej pracy pakietu (działa to także w druga stronę - pakiety później zainstalowane wymagające danego pakietu, uniemożliwiają jego odinstalowanie).

Program ten powstał na potrzeby dystrybucji Red Hat Linux, aktualnie jest używany również w innych dystrybucjach (np. SuSE, Mandrake, PLD).

RPM wprowadził ujednolicone nazwy plików. Przykładowy pakiet z GNU Gadu posiada nazwę gg2-2.0.2-1.athlon.rpm. Nazwa ta składa się z czterech członów w formacie plik-wersja-wersja_pakietu.architektura.rpm:

• gg2 - nazwa programu
• 2.0.2 - wersja programu
• 1 - wersja pakietu (może istnieć kilka wersji pakietu dla jednej wersji programu)
• athlon - architektura (typ procesora) dla której pakiet jest przeznaczony (np. i386, Athlon, Alpha, PPC)

urpmi jest to system zarządzania pakietami stworzony na potrzeby dystrybucji linuksa Mandrake Linux (przemianowanej później na Mandrakelinux, a obecnie Mandriva), a stworzony przez firmę MandrakeSoft. System urpmi wykorzystuje pakiety RPM (Red Hat Package Manager). W skład narzędzi urpmi wchodzą:

• urpme - deinstaluje wybrane pakiety wraz z zależnościami
• urpmf - wyszukuje pakiety o zadanej zawartości
• urpmi - instaluje wybrane pakiety
• urpmq - pozwala na wyświetlenie zawartości bazy pakietów
• urpmi.{addmedia,removemedia} - pozwala dodawać/usuwać źródła pakietów
• urpmi.update - aktualizuje wybrane pakiety

Yellow Dog Updater, Modified, w skrócie yum, jest systemem zarządzania pakietami dla dystrybucji używających pakietów RPM. Yum powstał dla dystrubycji Yellow Dog Linux.

Jego główną przewagą nad zmodyfikowaną wersją apta działającą z pakietami RPM jest mniejszy kod zródłowy (napisany w Pythonie). Jego główna wadą jest znacznie wolniejsze działanie i większe obciążenie sieci, ze względu na odmiennie rozwiązaną kwestię pobierania informacji o pakietach i ich zależnościach2). Brak również oficjalnego GUI, chociaż kilka nieoficjalnych już istnieje. Aktualnie toczą się prace nad oficjalnym GUI dla Fedory Core o nazwie PUP, połączonym z nowym narzędziem do instalacji pakietów. Yum jest standardowym narzędziem służącym do aktualizowania dystrybucji Fedora Core.

poldek jest instalatorem/aktualizatorem pakietów rpm. Napisał go Paweł Gajda jako część instalatora PLD. W codziennym użytkowaniu bardzo przypomina apta. Obsługuje różne źródła pakietów: dysk, ftp, http, rsync. Przetwarza zależności z plików rpm i samodzielnie doinstalowuje niezbędne pakiety. Zlecając poldkowi instalację jakiegoś programu, nie musimy martwić się o nie spełnione zależności, poldek robi wszystko za nas.

Zalety

• Analogicznie do apta poldek nie jest przywiązany na sztwyno do jednego repozytorium lecz pozwala swobodnie definiować ich wiele w pliku konfiguracyjnym /etc/poldek/sources.conf (dawniej /etc/poldek.conf).
• W przeciwieństwie do yum’a poldek pozwala łatwo decydować kiedy i _skąd_ mają być pobierane listy dostępnych pakietów. Nie obciąża to niepotrzebnie połączenia internetowego oraz _przyśpiesza proces instalowania wielu pakietów_.
• poldek pozwala w prosty sposób ukrywać pakiety którę mają nie być instalowane/uaktualniane.
• poldek nie jest również przywiązany do konkretnych sposobów pobierania pakietów, np. nic nie stoi na przeszkodzie aby do ściągania plików zamiast wget’a używać własnoręcznie napisanego programu.
• poldek działa w dwóch trybach
  • wsadowym - polecenia przekazuje się w opcjach linii komend
  • interaktywnym - poldek uruchamia własną “powłokę” w której otrzymujemy m.in. takie udogodnienia jak proste wyszukiwanie (z wyrażeniami regularnymi) czy uzupełnianie nazw pakietów do instalacji (klawiszem Tab).

Obie metody doskonale się uzupełniają i wydajnie korzystanie z poldka jest nawet prostsze do korzystania z apta.

Wady poldek jest niestety mało znany poza środowiskiem PLD.

Slackware przedstawia bardzo minimalistyczne podejście do zarządzania pakietami. Instalowanie, uaktualnianie i usuwanie pakietów jest tak samo proste jak w innych dystrybucjach, jednak Slack nie stara się w żaden sposób śledzić i zapewniać spełnienie zależności. Jeżeli zależności nie są spełnione, istnieje bardzo duża szansa, że nie dowiemy się o tym aż do próby uruchomienia programu.

Standardowe pakiety Sklackware’a to spakowane gzipem archiwa tara. Dla odróżnienia od zwykłych plików .tar.gz powszechnie nadaje się im rozszerzenie .tgz. Archiwa są skonstruowane w ten sposób, że gdy zostaną rozpakowane w głównym katatalogu /, odpowiednie pliki znajdą się tam gdzie powinny. Takie podejście pozwala zainstalować pakiet bez ingerencji zewnętrznych aplikacji a jedynie przy pomocy programów tar i gzip oraz może uruchomienia skryptu doinst.sh który może ale nie musi być załączony w archiwum.

Jakkolwiek sam Slackware nie zapewnie zarządzania zależnościami, istnieją pewne narzędzie które mniej lub bardziej ułatwiają to zadanie.

Część z tych narzędzi działa na zasadzie analizowania zależności wymaganych przez zainstalowane pakiety poprzez sprawdzenie jakich bibliotek wymagają i sprawdzanie jakie pakiety mogą tych bibliotek dostaarczyć. Ten automatyczny proces może być bardzo czasochłonny ale w większości przypadków otrzymane rezultaty są zadowalające.

Nie dostarcza on co prawda zarządzania pakietami w połączeniu ze standardowymi pakietami. Zamiast tego pozwala rozszerzać informację w pakietach w taki sposób aby można było te zależności łatwo wykrywać. Jest to rozwiązanie przenoszące do archiwów .tgz rozwiązania stosowane w .apt czy .rpm. Mimo to nieliczne repozytoria korzystają z tej funkcjonalności.

swaret to skrypt który pozwala ułatwić instalację oprogramowania. Jako jedyny z wymienionych tu programów pozwala rozwiązywać problemy z zaleznościami w standardowych pakietach .tgz.

Podczas standardowego instalowania pakietu swaret zapamiętuje pliki binarne które są kopiowane na lokalny komputer. Po zakończeniu instalacji uruchamiany jest ldd na każdym z tych plików pbinarnych. Jeśli pojawi się błąd Not Found, nazwa brakującej biblioteki i nazwa pliku którego dotyczył błąd są zrzucane do pliku.

Jeżeli okaże się, że jakieś biblioteki są potrzebne swaret próbuje ściągnąć plik libraries-VERSION ze strony swaret.sourceforge.net zawierający listę bibliotek i pakietów je zawierających. Lista brakujących bibliotek jest przetwarzana z wykorzystaniem ściągniętych własnie informacji a uzytkonik otrzymuje listę pakietów po których zainstalowaniu zależności będą spełnione.

Również nie zapełnia sprawdzania zależności. W zamian pozwala w łątwy sposób używać narzędzia rsync do sciągania gałęzi -current na lokalny dysk twardy.

Rozszerzenie standardowego zarządzania pakietami poprzez rozbudowany skrypt bash’a. Pozwala automatycznie instalować bądz uaktualniac pakiety z wykorzystaniem internetu i/lub sieci lokalnej.

• http://eedok.voidofmind.com/linux/chooser.html
• http://jakilinux.org/jaki-linux/quiz
• http://www.zegeniestudios.net/ldc/index.php?firsttime=true