Dystrybucje Linuxa

Marcin Pilipczuk, Piotr Tabor

W tej prezentacji będzie:

• Nieformalna definicja, tak na początek
• Chcemy zrobić dystrybucję - pytania inżynierii oprogramowania; co ludzi motywuje to tworzenia dystrybucji?
• Definicja formalna
• Standardy obowiązujące dystrybucję
  • File Hierarchy Standard
  • POSIX i Single Unix System
  • Linix Standard Base
• Co powinna zawierać dystrybucja - omówienie kolejnych składników
  • Różne programy zawarte często w dystrybucjach
  • Systemy pakietów
  • Systemy rozprowadzania dystrybucji i aktualizacji
  • Systemy aktualizacji; narzędzia do aktualizacji
  • Instalator
  • Boot manager
  • Podstawowy system plików
  • Sposób rozwoju dystrybucji
• Tworzenie własnej dystrybucji - Linux From Scratch
• Przegląd i porównanie kilku najpopularniejszych dystrybucji
  • Mandriva, dawniej Mandrake + Connectiva
  • Fedora Core, dawniej Red Hat
  • Gentoo
  • Debian
  • PLD, czyli nasze wydziałowe laboratorium
  • Slackware
  • Knoppix
  • Red Hat Enterprise Linux
  • Inne specjalistyczne Linuxy

Definicja, tak na początek

Dawno dawno temu, za górami za lasami, na początku lat 90., powstał Linux, a tak naprawdę jego jądro. Linus Torvalds na samym początku rozprowadzał samo jądro Linuxa wraz z kilkoma prostymi prostymi narzędziami GNU. Zainstalowanie sobie Linuxa wymagało wiele pracy i jeszcze więcej wiedzy i zrozumienia - tak naprawdę potrafili to zrobić tylko współdeweloperzy Linuxa. W związku z tym trzeba było wzbogacić Linuxa o coś, by każdy (lub każdy choć trochę zaawansowany w tajnikach komputerów) mógł sobie Linuxa zainstalować i z niego korzystać.

Powstała idea dystrybucji. Dystrybucja, to, w skrócie:

1. Jądro Linuxa, być może z jakimiś zmianiami.
2. Instalator lub jakiś opisany sposób instalacji
3. Zestaw programów i narzędzi dołączanych wraz z jądrem, zazwyczaj na licencji GNU/GPL, ale nie tylko.

Dokładny opis, z czego składają się współczesne dystrybucje, zostanie zamieszczony później.

Skrótem przez historię: pierwszymi dystrybucjami, powstałymi w 1992, były: MCC Interim Linux (University of Manchester), TAMU (Texas A&M University) oraz SLS (Softlanding Linux System). Niestety, wszystkie te dystrybucje szybko przestały być aktualizowane. Wówczas, na podstawie SLSa, Patrick Volkerding stworzył, do dziś aktualizowaną i bardzo popularną, dystrybucję Slackware.

Chcemy zrobić dystrybucję... i co dalej?

Przez pierwszą częśc referatu zajmijmy się następującym problemem: chcemy zrobić dystrybucję. Czy na pewno z sensem jest, abyśmy ją robili? Co musimy w niej zawrzeć? Jakie decyzje przy projektowaniu podjąć? ...

Tak więc teraz stopniowo będziemy sobie zadawali różne pytania. Za pomocą tych pytań będziemy mogli określić, co my tak naprawdę musimy zrobić robiąc dystrybucję. Również zrobimy później od końca, czyli ocenimy, jakie decyzje projektowe podjeli twórcy znanych dystrybucji i dzięki temu porównamy te dystrybucje.

Na poniższy wywód można też patrzeć nie jak Co muszę zrobić by mieć dystrybucję? ale też Co zapewne od dystrybucji mogę oczekiwać?

Pytanie 1: Dlaczego chcemy robić dystrybucję?

Na to pytanie już powinniśmy znać odpowiedź. Tak naprawdę są trzy różne motywacje, które będą miały istotny wpływ na dalszą część projektu:

1. Chcemy zarobić, zakładamy firmę robiącą komercyjną dystrybucję Linuxa.
2. Jesteśmy zapaleńcami i chcemy zrobić nową, fajną, otwartą, darmową dystrybucję Linuxa, z której rzesze ludzi na świecie będą z radością korzystać.
3. Mamy sprecyzowaną potrzebę dla dystrybucji, całkiem prawdopowobne, że zostanie ona zainstalowana tylko na kilku komputerach, np. jesteśmy administratorami laboratorium i potrzebujemy na każdym pracowniczym stanowisku postawić dość specyficznego Linuxa. Albo potrzebujemy Linuxa na maszynie z 16 procesorami do obróbki danych z doświadczeń biologicznych.

Całkiem prawdopodobne, że istnieje już dystrybucja (lub inny system operacyjny), który spełnia nasze wymagania czy wizje dystrybucji. Sprecyzujmy teraz nasze żądania.

Pytanie 2: Dla kogo jest to dystrybucja, kto będzie korzystał?

1. Lokalnie, my, lub kilku naszych znajomych.
2. Wszyscy użytkownicy firmy, większa grupa.
3. Będzie to rozwiązanie biznesowe, na jednym lub kilku serwerach.
4. Będzie to rozwiązanie biznesowe do użycia w wielu miejscach.
5. Będzie to publiczna dystrybucja, bardzo dużo ludzi ją ściągnie i będzie używać.

Pytanie 3: Jaką architekturę ma obsługiwać?

Jeśli jest to dystrybucja dla nas, dla naszych znajomych, lub na określony, niewielki zbiór komputerów, architekturę mamy ściśle określoną. Robiąc dystrybucję dla mas zapewne będziemy chcieli więcej architektur obsługiwać. Dystrybucja np. do obliczeń w biologii pewnie będzie musiała obsługiwać kilka dziwnych architektur, wieloprocesorowych.

Pytanie 4: Co będzie robione na komputerach z naszym Linuxem? Do czego będzie używana dystrybucja?

1. Będzie to dystrybucja biurkowa, z edytorem tekstu, arkuszem kalkulacyjnym, itd.
2. Będzie to dystrybucja dla programistów i developerów.
3. Będzie to serwer.
4. Będzie to komputer, na którym będą wykonywane obliczenia.
5. Będzie to serwer bazy danych.
6. Jakiś inny specjalistyczny cel...
7. Do wszystkiego - studiujemy i próbujemy wszystkiego ;)

Po odpowiedzeniu sobie na poprzednie trzy pytania, tak naprawdę bardzo z grubsza wiemy, jak nasza dystrybucja powinna wyglądać, jakie programy powinna zawierać i w wersji dla jakich architektur. Teraz nadchodzi bardzo ważne pytanie...

Pytanie 5: Na pewno jest potrzeba i sens tworzyć nową dystrybucję? Może już istnieje jakaś, która jest taka, jak my chcemy stworzyć? A może jakiś inny system operacyjny tak dobrze działa, jak nasza planowana dystrybucja?

To pytanie jest ważne dla każdej odpowiedzi na pytanie pierwsze: jeśli istnieje dystrybucja, pokrywająca się z naszą wizją, to albo zaoszczędzono nam dużo pracy (odp. 2 i 3) albo nisza rynkowa jest już wypełniona.

Patrząc tutaj, nie tylko inne Linuxy (których jest bardzo dużo) się liczą. Może, jeśli mamy zamiar postawić biurkową dystrybucję, Windows pokrywa naszę potrzeby? A może któryś Unix będzie bardzo dobry do naszych celów? Ktoś przed nami mógł mieć takie myśli jak my.

Po tych meta-pytaniach, czas zabrać się za bardziej techniczne aspekty dystrybucji Linuxa.

Trzy słowa o BSD

Jednym z prawdopodobnych wyborów może być któraś otwarta odmiana BSD, np. FreeBSD lub OpenBSD. BSD (Berkeley Software Distribution) jest odmianą Unix-a, rozwijaną na Uniwersytecie Kalifornijskim od lat siedemdziesiątych. Dość znane są jego dwie najpopularniejsze otwarte odmiany: FreeBSD i OpenBSD.

• FreeBSD zarówno jest znany z dość wysokiego stopnia przyjazności użytkownikowi, jak i bardzo dobrej efektywności i bezbłędności. Serwery stojące na FreeBSD biją rekordy w długości życia bez przebootowania (tzw. uptime). Jest to kosztem specjalizacji architektur: system ten działa tylko na kilku architekturach, mocno skupiając się na użyciu SMP. Być może jest to dobry wybór na serwer. FreeBSD utrzymuje kompatybilność binariów z Linuxem, dzięki czemu można programy skompilowane pod Linuxem uruchamiać na FreeBSD.
• OpenBSD jest znany jako bardzo bezpieczny system, oraz, przeciwnie do FreeBSD, obsługuje bardzo szeroki wachlarz architektur. OpenBSD, ze względu na bardzo silny nacisk na bezpieczeństwo, jest bardzo dobrym wyborem na serwery otwarte na świat, routery, gateway-e czy serwery pocztowe.

Większość dystrybucji BSD jest opartych na licencji BSD, będącej na pograniczu kompatybilności z GPL.

Wnioski z pytań 1-5.

Na podstawie pytań 1-5 powinniśmy wysnuć kilka wniosków bardziej technicznych na temat naszej dystrybucji:

Pytanie 6.1: Jaki oczekujemy stopień niezawodności?

Oczywiście, fajnie by było jakby nasz system zawsze działał poprawnie, jednak jest to po prostu niemożliwe.

1. Jeśli chcemy naszego Linuxa zastosować do biznesowych rozwiązań, jako serwer, bazę danych, czy do obliczeń, prawdopodobnie zależy nam na bardzo wysokiej niezawodności. Wówczas będziemy wybierać wersje programów raczej starsze, dobrze przetestowane, i będziemy starali się mniej lub bardziej automatycznie aktualizować wszystkie łaty.
2. Jeśli nasz Linux ma być Linuxem biurkowym lub dla programistów, niezawodność, choć ważna, nie jest już tak krytyczna. Tutaj zapewne bardziej postawimy na nowinki programistyczne, nowe wersje programów, które mogą częściej zawierać błędy, ale za to dostarczają więcej funkcjonalności niż starsze, stabilniejsze wersje.

Pytanie 6.2: Jaki oczekujemy stopień bezpieczeństwa?

To pytanie jest tak naprawdę bardzo pokrewne do poprzedniego. Chcielibyśmy, aby nasz system był zawsze bezpieczny, choć dobrze wiemy, że nie jest to możliwe.

1. Podobnie jak poprzednio, starsze, stabilne i dobrze przetestowane wersje programów wraz z każdą wypuszczoną łatką, gwarantują wysoki poziom bezpieczeństwa, jakiego wymagają serwery stojące w sieci.
2. Nowsze wersje programów dostarczają więcej funkcjonalności, nieraz niestety kosztem bezpieczeństwa. Jednak, np. na biurkowych komputerach, stojących w firmie w sieci wewnętrznej za firewallem, zazwyczaj możemy sobie na to pozwolić.

Pytanie 6.3: Jaki oczekujemy stopień bycia user-friendly?

1. Z serwerem, bazą danych, bezpośrednią styczność ma tylko administrator. Choć narzędzia administratorskie są ważne i ułatwiają życie, wystarczą (i zazwyczaj administrator będzie szczęśliwszy ;) ) z narzędziami tekstowymi, często dostępnymi z GNU. Serwer zazwyczaj będzie ręcznie konfigurowalny (bez wyszukanych konfiguratorów), bez Xów i innych programów dla mniej zaawansowanych użytkowników.
2. Jeśli nasz system, choć nie jest to serwer, gdzie dostęp będzie miało kilku administratorów, planujemy dla bardziej zaawansowanych użytkowników, np. programistów, pewnie też nie chcemy dołączać programów dla początkujących, jak np. okienkowych konfiguratorów.
3. System biurkowy i dla początkujących pewnie będzie wymagał całej rzeszy programów automagicznych: auto-konfiguratorów, rozpoznających urządzenia itd., nie wymagających od użytkownika wiedzy.

Pytanie 6.4: Jaki oczekujemy stopień efektywności?

1. Jeśli nasz Linux ma stać na słabych, starszych komputerach, będzie nam zależało na efektywności. Na biurkowym czy programistycznym Linuxie, na starym komputerze, zapewne damy XWindow, a nie KDE. Na browny trzeba dać jądro 2.2. Będziemy omijać wszelkie uprzyjemniacze dla programistów i użytkowników, które powodują powstanie dodatkowej warstwy systemu, czyli czegoś, co będzie powodować narzut na system operacyjny.
2. Na serwerze czy bazie danych, a w szczególności przy maszynie do obliczeń, nawet jak mamy nowszą maszynę, będziemy się starali nie dodawać niepotrzebnych obciążników.
3. Mając specyficzną architekturę, np. maszynę wektorową, będziemy projektowali naszego Linuxa, by maksymalnie wykorzystać własności maszyny.
4. Na nowszych maszynach, szczególnie na maszynie na biurko i dla programisty, nie będziemy się tym przejmowali. Pewnie dodamy jakiegoś dużego X-a, np. KDE czy Gnome, oraz parę innych bajerów uprzyjemniających życie.

Właściwie, to co musimy zrobić?

Po zadaniu sobie powyższych pytań, pora na formalniejszą definicję dystrybucji, czyli co tak naprawdę potrzebujemy zrobić.

Współczesna dystrybucja składa się z:

1. jądra Linuxa
2. instalatora, systemu instalacji
3. systemu pakietów
4. systemu rozprowadzania pakietów oraz mniej lub bardziej automatycznego aktualizatora
5. programów rozprowadzanych wraz z jądrem, głównie na licencji otwartej, ale nie tylko
6. infrastruktury sieciowej, czyli serwerów, skąd można pobrać dystrybucję, aktualizację itd
7. dokumentacji
8. różnych bajerów lokalizacyjnych (fonty lokalne) i nie tylko (tapety, dźwięki)

Teraz, przeanalizujemy składowe dystrybucji, patrząc na dostępne już rozwiązania i zapotrzebowania użytkowników. Wpierw jednak, dowiedzmy się, co musimy zrobić, by można było nazwać naszą dystrybucję Linuxem.

Standardy: POSIX/Single Unix System, Linux Standard Base oraz Filesystem Hierarchy Standard

FHS - Gdzie wgrać ten program by nie zrobić bałaganu?

Filesystem Hierarchy Standard (Standard Hierarchi systemu plików) jest standardem precyzującym logiczne rozmieszczenie poszczególnych rodzajów plików i katalogów dla różnych UNIXowych systemów plików. Aktualnie obowiązujący FHS jest w wersji 2.3 ogłoszonej 29 stycznia 2004.

FHS stawia sobie za cel:

• Programy wiedziały, gdzie się instalować i gdzie szukać innych programów i plików
• Użytkownicy potrafili się zorientować, gdzie znajdują się wszystkie pliki i jakim restrykcją się one poddaję

Dokument ten porusza kwestie:

• Podstawowych cech poszczególnych fragmentów systemu plików
• Plików, które muszą obowiązkowo w systemie wystąpić
• Dopuszczalnych odstępstw od w/w

Istotne cechy plików:

• użyteczność - czemu służą
• statyczność vs. zmienność (static vs variable) - czy pliki, dla prawidłowego działania systemu i aplikacji są potrzebne w trybie "do zapisu", czy "readonly" wystarczy.
  Przykładami gałęzi statycznych jest: /usr, /opt, /boot
  Przykładami gałęzi zmiennych jest: /tmp, /var
  Przykładami gałęzi nieuporządkowanych w tym względzie jest: /etc
  Dlatego też można się spodziewać (raczej w odległej przyszłości) rozdzielenia /etc na /etc oraz /var/etc.
• dające się współdzielić (shareable) vs. nie dające (unshareable) - chodzi o wyrużnienie tych fragmentów systemu, które można udostępnić innym komputerom w sieci (np. poprzez NFS) i nie udostępniać danych całkowicie lokalnych.
  Przykładami gałęzi shareable są: /usr, /opt, /var/mail, /var/spool/news
  Przykładami gałęzi unshareable są: /etc, /boot, /var/run, /var/lock

Główny system plików (root - nie /root)

FHS zaleca by główny system (korzeń) znajdował się na osobnej partycji, możliwie małej, ale żeby zawierał wszystko co jest wymagane aby: bootować, odzystkiwać i reperować system.

Motywuje to następująco:

• Umożliwia to zamontowanie go z małego nośnika
• Mniejsza partycja ma mniejsze prawdopodobieństwo, że zostanie uszkodzona
• Jako developer nie powineneś zakładać, że inni mają główny system plików bardziej rozbudowany niż minimalny

Katalogi obowiązkowe na ścieżce /:

Katalogi opcjonalne:

/bin - pliki wykonywalne poleceń

• cat
• chgrp
• chmod
• chown
• cp
• date
• dd
• df
• dmesg
• echo
• false
• hostname
• kill
• ln
• login
• ls
• mkdir
• more
• mount
• mv
• ps
• pwd
• rm
• rmdir
• sed
• sh
• stty
• su
• sync
• true
• unmount
• uname
• test
• setserial
• [ (To nie pomyłka)

Polecenia te powinny być (choć w większości dystrybucji linuxa niesą) dostępne nawet wtedy gdy ich funkcjonalność jest realizowalna przez powłokę systemową (shell).

Ponadto, jeśli w systemie są zainstalowane odpowiednie aplikacje, to w /bin muszą znajdować się następujące programy: csh, ed, tar, cpio, gzip, gunzip, zcat, netstat,ping

/boot - z czego startujemy

Katalog zawiera wszystkie pliki konieczne do przeprowadzenia procesu bootowania. Tam też znajduje się jądro (choć w wyjątkowych sytuacja dopuszczalne jest by jądro było bezpośrednio w katalogu /).

Pliki konfiguracyjne wymagane w procesie bootowania powinny (menu.lst dla grub'a) powinny być linkowane symbolicznie do /etc (/etc/grub/menu.lst).

/dev - urządzenia

HFS dla Linuxa wymaga dodatkowo istnienienia następujących urządzeń specjalnych:

• /dev/null - wszystkie dane wysyłane na to urządzenie są połykane. Zwraca EOF
• /dev/zero - to urządzenie połyka wszystki i zwraca wyzerowane bajty.
• /dev/tty - to urządzenie jest synonimem aktualnego terminala procesu, który je otworzył.

/etc - konfiguracja

Katalog /etc zawiera pliki konfiguracyjne. Żadnego pliki binarne nie mogą się znajdować w katalogu /etc. Zalecane jest by pliki poszczególnych programów były zapisywane w odpowiednich podkatalogach.

Jeśli system zawiera odpowiednie podsystemy, to obowiązkowo powinien zawierać odpowiednie wpisy w /etc:

Ścieżka	Zawarość
katalog /etc/opt	Pliki programów znajdujących się w /opt. Każdy program w /opt powinien posiadać swój katalog w /etc (o ile posiada jakąkolwiek konfigurację)
katalog /etc/X11	Konfiguracja X windows system.
katalog /etc/xml	Konfiguracja programów XMLowych
katalog /etc/sgml	Konfiguracja programów sGMLowych

oraz pliki:

Plik	Opis
csh.login	Ustawienia o znaczeniu globalny dla C shella
exports	NFS Access Control List - uprawnienia
fstab	Statyczne informacje o montowanych systemach plików
ftpusers	Upawnienia do korzystania z FTP
gateways	Bramy wyjściowe (ciekawostka - moim zdaniem zapisuje się to przy konfiguracji interfejsu)
gettydefs	Ustawienia terminali
group	Grupy użytkowników
host.conf	Konfiguracja zarządzania siecią
hosts	Statycznie przyznane nazwy hostów
hosts.allow	Uprawnienia do dostępu przez TCP/IP
hosts.deny	Zakazy dostęp przez TCP/IP
hosts.equiv	Zaufane hosty dla rlogin, rsh, rcp
hosts.lpd	Zaufane hosty dla lpd
inetd.conf	Konfiguracja demona inetd
inittab	Konfiguracja procesu init
issue	Komunikat przed logowaniem
ld.so.conf	Lista dodatkowych katalogów
motd	Komunikat po logowaniu
mtab	Dynamiczna informacja o zamontowanych systemach plików (ze względów historycznych)
mtools.conf	Konfiguracja mtoolsa
networks	Statyczna informacja o nazwach w sieci
passwd	Plik z użytkownikami i hasłami
printcap	Konfiguracja demona lpd (drukarka)
profile	Domyślne i globalne dla całego systemu opcje startowe bash'a
protocols	Lista protokołów IP i przypisanych portów
resolv.conf	Konfiguracja serwerów DNS
rpc	Lista protokołów RPC
securetty	Ograniczenie dostęp do logowania przez terminale
services	Numery portów dla nazwy serwera
shells	Dostępne shelle (optional)
syslog.conf	Konfiguracja sysloga

/home - w domu najlepiej

Jest to katalog, który zawiera katalogi domowe użytkówników. W tych katalogach powinny być wszystkie pliki specyficzne dla użytkownika, także konfiguracje prywatne użytkowników.

Konfiguracje prywatne poszczególnych aplikacji powinny się znajdować w "ukrytych" plikach i katalogach (rozpoczynających się od .). Jeśli aplikacja posiada katalog ukryty na pliki konfiguracyjne, to pliki w nim nie powinny być ukryte.

/lib - biblioteki kluczowe

Katalog /lib powinein zawierać kluczowe biblioteki, tzn. te wymagane przez kluczowe aplikacja dla działania systemu, czyli przez jądro (moduły), oraz aplikacje z /bin i /sbin.

Moduły jądra powinny się znaleźć w podkatalogu "modules". W katalogu głównym z kolei powinny się znajdować conajmniej następujące pliki:

• libc.so.* - dynamicznie ładowana biblioteka C
• ld* - linker/loader działający podczas wykonania aplikacji

/lib{dodatek} [opcjonalnie]

Biblioteki w alternatywnym formacie. Np. gdy mamy system 32 bitowy i 64 bitowy. To zakładamy katalogi lib32 z bibliotekami skompilowanymi w trybie 32 bitowym oraz lib64 z bibliotekiami trybu 64-bitowego. Następnie lib symlinkujemy do domyślnego z tych dwóch katalogów...

A alternatywne środowisko? Uzyskujemy np. tworząc alternatywny "korzeń" i chroot'ując do niego

/media

Jest to katalog przeznaczony na podkatalogi będące punktami montowania poszczególnych urządzeń wymiennych.

Większość użytkowników linux'a pewnie nie zauważyła tego katalogu, bo większość dystrybucji go domyślnie nie zakłada.

Katalog	Opis
floppy	Stacja dyskietek
cdrom	stacja CD-ROM lub DVD-rom
cdrecorder	nagrywarka CD
zip	stacja Zip

Jeśli jest więcej urządzeń danego typu, to katalogi te należy numerować kolejno od 0. Jednak należy obowiązkowo zostawić symlink do urządzenia domyślnego danego typu (pozbawiany numerka).

Jak widać autorzy standardu 2.3 zapomnieli o urządzeniach klasy pendrive

/mnt - zmontujmy filesystem

Punkt montowania dla tymczasowo montowany katalogów przez administratora. Aplikacje powinny tymczasowo montować dyski w odpowiednim podkatalogu /tmp. Katalog /mnt może być bezpośrednim punktem montowanie (tak właśnie było historycznie i jest to główny powód wyróżnienia katalogu /mount).

/tmp - tymczasem ...

Katalog plików tymczasowych. Żaden program nie powinien zakładać, że jego zawartość się nie zmieni pomiędzy jego wykonaniami. Standard (także POSIX part 2) zaleca, by katalog /tmp był czyszczony w procesie bootowania.

/opt - dodatkowe aplikacje

Katalog na dodatkowe aplikacje. Oplikacje mogą się instalować w katalogach o nazwach programów i w katalogach zarejestorowanych dostawców oprogramowania (LANANA).

Katalogi /opt/bin, /opt/doc, /opt/include, /opt/info,/opt/lib,/opt/man są zastrzeżone dla użytku przez administratora. Pakiety mogą wystawić makiete (front-end) w tych katalogach, przy pomocy linków.

• Konfiguracje powinny być w: /etc/opt/{pakiet}
• Pliki z danymi powinny być w: /var/opt/{pakiet}
• Pliki uruchimieniowe programów powinny być w: /opt/{pakiet}/bin
• Pliki manuali powinny być w:/opt/{pakiet}/share/man

Polecaną przez FHS metodą organizowania opt'a jest używanie najpierw katalogu z nazwą dostawcy programu, a dopiero potem katalog programu. Ma to na celu umożliwienie umieszczania wspólnych plików wykonywalnych i bibliotek bezpośrednio w katalogu dostawny (np. /opt/{dostawca}/bin , /opt/{dostawca}/lib)

/sbin - binaria systemowe

Narzędzia potrzebne administratorowi i tylko administratorowi (root-only) powinny być przetrzymywane w następujących katalogach:

• /sbin
• /usr/sbin
• /usr/local/sbin

Katalog /sbin może zawierać polecenia lub linki posiadające funkcjonalność: bootowania, odzyskiwania oraz reperowania systemu. Programy wykonywane po zamontowaniu /usr powinny znajdować się w /usr/sbin. Programy zainstalowane lokalnie (np. do obsługi sprzętu na lokalnej maszynie) powinny znajdować się w /usr/local/sbin

W katalogu /sbin musi znajdować się (lub lokalny link) do polecenia shutdown - zamykającego system.

Następujące polecenia są zalecane:

Katalog	Opis
fastboot	Uruchom ponowinie system (bez kontroli dysku)
fasthalt	Zatrzymaj system natychmiastowo (bez kontroli dysku)
fdisk	Manipulator tablic partycji
fsck	Ogólne polecenie kontroli systemu plików
fsck.*	Kontrola i naprawa konkretnego systemu plików
getty	The getty program
halt	Zatrzymanie systemu
ifconfig	Konfiguracja interfejsów sieciowych
init	Proces inicjujący pracę systemu
mkfs	Ogólne polecenie zakładania systemu plików
mkfs.*	Tworzy na partycji właściwy (zależny *)system plików
mkswap	Tworzy na partycji znaczniki, że może być ona wykorzystana do swapowania
reboot	Polecenie rebootowania systemu
route	Tablica routingu IP
swapon	Włącza swapowanie na wskazanej partycji
swapoff	Wyłącza swapowanie na wskazanej partycji
update	Demon oczyszczający (zapisujące na dysk) bufory systemowy

/srv - usługi

Jest to katalog przewidziany na dane usług. Jeżeli serwer np. udostępnia archiwum ftp, archiwum svn/cvs lub stronę www, to odpowiedni katalog powinien się znaleźć w /srv.

Jest kilka metodologii tworzenia podkatalogów w /srv. Jedną możliwością jest nazywanie ich w zależności od nazwy protokołu. Inna metoda to najpierw katalogowanie ich w zależności od tematyki, a dopiero później od protokołu (o ile jest tych protokołów kilka).

Oczywiście wszystkie dane "użytkowników" powinny się znaleźć w katalogu domowym użytkownika i być co najwyżej linkowane do /svr.

/usr - drugie, ogólniejsze drzewo systemu

Ogólniejsze, ale w pewien sposób istotnie ograniczone. Poddrzewo /usr musi zawierać pliki, które mogą być współdzielone przez kilka hostów (czyli nie mogą zawierać żadnych informacji charakterystycznych dla hosta). Ponadto katalog ten musi być tylko do odczytu - czyli musi umieć pracować w trybie read-only. Oczywiście zapis do niego jest możliwy - np. podczas instalacji aplikacji, ale możliwość zapisu nie może być potrzebą działających programów. Wszystkie modyfikowalne dane powinny być zapisywane w strukturze /var.

Wymagane katalogi:

Katalog	Opis
/usr/bin	Większość poleceń użytkownika
/usr/include	Pliki nagłówkowe języka C (pochodzące od wszystkich programów). W Linuxach /usr/include/linux powinien wskazywać na pliki nagłówkowe aktualnie używanej wersji jądra systemu
/usr/lib	Biblioteki
/usr/local	Hierarchia lokalna - dystrubucja po instalacji powinna zostawiać ją pustą
/usr/sbin	Narzędzia administracyjne (root-only)
/usr/share	Dane niezależne od architektóry

Katalogi opcjonalne:

Katalog	Opis
/usr/X{11}R{6}	XWindow System, wersja 1 wydanie 6
/usr/games	Gry i programy edukacyjne
/usr/lib<qual>	Biblioteki w alternatywnych formatach
/usr/src	Kody źródłowe. Na linux'ach /usr/src/linux powinien wskazywać na źródła aktualnie używanego jądra systemu

Jak widać jedynym systemem, który posiada swój własny bezpośredni katalog - to XWindows - ze względu na jego popularność i stopień rozbudowania. Co nie zmienia faktu, że inne - nawet bardziej rozbudowane programy nie powinny zakładać katalogów bezpośrednio w katalogu /usr.

Ze względu na wsteczną zgodnośc poniższe katalogi mogą być dostępne w formie linków symbolicznych. Oczywiście do czasu, aż bieżące implementację nauczą się korzystać bezpośrednio z odpowiedniej struktury.

• /usr/spool -> /var/spool
• /usr/tmp -> /var/tmp
• /usr/spool/locks -> /var/lock

Katalog /usr/local zawiera wszystkie aplikację "nie należące" do dystrybucji systemu. Wyróżnienie tego drzewa służy temu, by aplikacje nie zostały nadpisane podczas aktualizacji systemu.

Katalog	Opis
/usr/local/bin	Pliki binarne aplikacji
/usr/local/etc	Specyficzna dla host'a ustawienia (link do /etc/local - w celu ułatwienia backupu)
/usr/local/games	Lokalne gry
/usr/local/include	Lokalne pliki nagłówkowe
/usr/local/lib	Lokalne biblioteki
/usr/local/man	Lokalne strony manuala
/usr/local/sbin	Lokalne polecenia systemowe (dla administratora)
/usr/local/share	Lokalna hierarchia niezależna od architektóry
/usr/local/src	Lokalna struktura plików

Katalog /usr/share jest przeznaczony, dla danych, które mogą być używane przez wiele różnych architektur. Czyli wiele programów (w tych samych wersjach), ale skompilowanych na różnych architektórach może korzystać z tych zasobów.

Katalog	Opis
/usr/share/man	Strony podręcznika systemowego man
/usr/share/misc	Drobne pliki, które nie wymagają oddzielnego podkatalogu (w szczególności: ascii, magic, termcap, termcap.db)

Przykładowe elementy struktuktury niezależnej od architektóry:

Katalog	Opis
/usr/share/dict	Słowniki (zawierające bezpośrednio plik "words" - tradycyjnie Angielski (brytyjski) zbiór słow), a w podkatalogach słowniki narodowe
/usr/share/doc	Dokumentacja
/usr/share/games	Statyczne dane gier (filmy)
/usr/share/info	GNU Info system
/usr/share/locale	Informacje lokalne
/usr/share/nls	Katalogi z tłumaczeniami aplikacji na różne języki
/usr/share/sgml	Dane SGML
/usr/share/terminfo	Katalogi bazy danych terminfo
/usr/share/tmac	makra troff nie dystrybułowane z gruff
/usr/share/xml	dane XML
/usr/share/zoneinfo	Konfiguracja i informacje o strefie czasowej

Inne podsystemy - np. texmf, kbd mogą i powinny tutaj tworzyć katalogi ze swoimi zasobami.

FHS dość dokładnie opisuje system katalogów dla podsystemu man - stron instrukcji obsługi poleceń. Generalnie struktura jest taka .../man/{lokalizacja}/man{section}/{arch}/strony...

• {lokalizacja} - to kombinacja języka, kraju, strony kodowej (na systemach jednojęzykowych ten element nazwy może zostać pominięty)
• man{section} - system man jest pogrupowany tematycznie i numery sekcji wyznaczają te grupy:

  Katalog	Opis
  man1	Programy dla użytkownika
  man2	Wywołania systemowe
  man3	Elementy bibliotek
  man4	Pliki specjalne
  man5	Formaty plików
  man6	Gry
  man7	Pozostałe elementy
  man8	Zagadnienia administracji systemem

/var - to co się zmienia

Katalog /var ma zawierać te dane, które podlegają modyfikacją w trakcie działania różnych programów. Może zawierać dane stałe oraz dane tymczasowe.

Pewne elementy tego drzewa podlegają współdzieleniu między wieloma systemami, ale zdecydowanie nie wszystkie. Przykładami przeważnie podlegających współdzieleniu są następujące poddrzewa:

• /var/mail
• /var/cache/man
• /var/cache/fonts
• /var/spool/news

Z kolej współdzieleniu nie podlegają:

• /var/log
• /var/run
• /var/lock

Oto wymagane podkatalogi:

Katalog	Opis
/var/cache	Cache - wyróżniony aby móc umieścić na oddzielnej partycji z inną polityką dyskową :)
/var/lib	Po prostu stałe dane aplikacji
/var/local	Dane aplikacji z /usr/local
/var/lock	Blokady na urządzeniach i innych zasobach zapisane w formie plików. (Plik ma nazwę LCK..{urządzenie} i zawartość w postaci odpowiednio przesuniętego spacjami numeru pid)
/var/log	Pliki loggera systemowego. Obowiązkowo: lastlog - log kiedy ostatnio się logował każdy użytkownik messages - ostatnie komunikaty legera systemowego wtmp - historia logowań i wylogowywań
/var/opt	Dane aplikacji z /opt
/var/run	Dane bieżące właśnie uruchomionych aplikacji. Katalog czyszczony w procesie bootowania. Tu procesy m.in. umieszcają informacje o swoich pidach (w plikach {nazwa_procesu}.pid).
/var/spool	Miejsce wymiany danych. Głównie dane oczekujące na dalsze przetworzenie... np. kolejki drukarek (lpd), poczty wychodzącej(mqueue), grup dyskusyjnych (news), czy uruchamiacza czasowego dla Linuxów(cron)
/var/tmp	Pliki tymczasowe - zachowywane pomiędzy resetami systemu

Dopuszczalne są także następujące katalogi

Katalog	Opis
/var/account	Dane wyliczeniowe aktualnie działających procesów
/var/crash	Miejsce na zrzuty informacji o błędach (np. core.dump'y)
/var/games	Dane gier (np. save'y)
/var/mail	Skrzynki pocztowa (uwaga: NIE należy używać /var/spool/mail)
/var/yp	Baza danych systemu NIS (Network Information System [System Informacji Sieciowej])

Czego możemy się spodziewać w przyszłości (więc nie polagajmy na):

• Przesunięcia większości /etc do /var/etc
• Zniknięcia /etc/mtab (a na Linuxach do tego czasu powinien być to symlink do /proc/mounts)
• Usunięcie następujących dowiązań symbolicznych:
  • /usr/spool -> /var/spool
  • /usr/tmp -> /var/tmp
  • /usr/spool/locks -> /var/lock

POSIX - by programista pisał raz

POSIX (Portable Operating System Interface (uniX)) jest zbiorem standarów wyspecyfikowanych przez IEEE (Institute of Electrical and Electronics Engineers) i specyfikujących API dla różnych programów uruchamianych na UNIX'ach. Formalna nazwa pierwszej edycji POSIX'a to standard IEEE 1003.

POSIX jest standardem głównie dla programisty, jednak nie stanowi on biblioteki, ale ogranicza się do bardzo dokładnej specyfikacji symantyki poszczególnych operacji, których programista (lub użytkownik) może oczekiwać od systemu operacyjnego

POSIX w szczególności specyfikuje:

• Podsystem wejścia/wyjścia (I/O) z wyszczególnieniem plików, terminali sieci
• Ustandardyzowany system linii poleceń i obsługi języków skryptowych
• API dla obsługi wielowątkowości

Za datę początku tego standardu uznaje się rok 1985.

Standard POSIX doczekał się wielu rozszerzeń i uzupełnień:

• Posix.1, Core Services (włączony też do ANCI C)
  • Tworzenie i kontrola procesów
  • Sygnały
  • Wyjątki przy obliczeniach zmiennoprzecikowych
  • Błędy segmentacji
  • Błędne instrukcje
  • Błędy szyny systemowej
  • Wyzwalacze czasowe
  • Operacje na plikach i katalogach
  • Strumienie (pipes)
  • Biblioteka języka C
  • Kontrola portów Wejścia/Wyjścia
• POSIX.1b, Rozszerzenie - czas rzeczywisty
  • Szeregowania ze względu na priorytety
  • Sygnały czasu rzeczywistego
  • Pomiar czasu
  • Semafory
  • Przekazywanie komunikatów
  • Pamięć współdzielona
  • Synchroniczne i asynchroniczne wejście-wyjście
  • Blokady na pamięci
• POSIX.1c, Rozszerzenie - wątki
  • Tworzenie, kontrola i usuwanie wątków
  • Szeregowanie wątków
  • Synchronizacja wątków
  • Przechwytywanie sygnałów

Przykładami plików nagłówkowych wyspecyfikowanych przez POSIX są:

• aio.h
• arpa/inet.h
• assert.h
• complex.h
• cpio.h
• ctype.h
• dirent.h
• dlfcn.h
• errno.h
• fcntl.h
• fenv.h
• float.h
• fmtmsg.h
• fnmatch.h
• ftw.h
• glob.h
• grp.h
• iconv.h
• inttypes.h
• iso646.h
• langinfo.h
• libgen.h
• limits.h
• locale.h
• math.h
• monetary.h
• mqueue.h
• ndbm.h
• net/if.h
• netdb.h
• netinet/in.h
• netinet/tcp.h
• nl_types.h
• poll.h
• pthread.h
• pwd.h
• regex.h
• sched.h
• search.h
• semaphore.h
• setjmp.h
• signal.h
• spawn.h
• stdarg.h
• stdbool.h
• stddef.h
• stdint.h
• stdio.h
• stdlib.h
• string.h
• strings.h
• stropts.h
• sys/ipc.h
• sys/mman.h
• sys/msg.h
• sys/resource.h
• sys/select.h
• sys/sem.h
• sys/shm.h
• sys/socket.h
• sys/stat.h
• sys/statvfs.h
• sys/time.h
• sys/timeb.h
• sys/times.h
• sys/types.h
• sys/uio.h
• sys/un.h
• sys/utsname.h
• sys/wait.h
• syslog.h
• tar.h
• termios.h
• tgmath.h
• time.h
• trace.h
• ucontext.h
• ulimit.h
• unistd.h
• utime.h
• utmpx.h
• wchar.h
• wctype.h
• wordexp.h

Dostępny jest zbiór testów na zgodność systemu z POSIXem i jest on nazywany PCTS (Posix Conformance Test Suite).

Nawet system Microsoft Windows NT jest częściwo zgodny z POSIX'em, w szczególności w zakresie podsystemu czasu rzeczywistego. Zgodność Windowsa z Posixem wzrasta po zainstalowania Windows Services for Unix lub Cygwina.

Jednak jest problem - standard POSIX jest standardem zamkniętym. IEEE żąda wysokich opłat za udostępnianie dokumentów i nie zgadza się na ich publikację. Wspólnota Free Software nie mogła tego znieść. Dlatego w 1998 roku założyli wspólnotę "Austin Group" (od nazwy miejsca, gdzie odbyło się spotkanie inaugurujące pracę grupy - w siedzibie IBM w Texasie), która wprowadziła standard SUS ("Single UNIX Specification").

Single UNIX Specification - POSIX gratis

Standardowi SUS groziło, że będzie ponownym (po POSIXie) opisem API wymaganego od przyzwoitego UNIXa. Na szczęście udało się porozumieć z IEEE i uzyskać zgodę na wykorzystanie dotychczasowego standardu w rozwijanej dalej dokumentacji. Obecnie obowiązująca jest wersja 3 tego standardu. Składa się on z następujących fragmentów:
• IEEE Std 1003.1-2001 (POSIX)
• ISO/IEC 9945:2002 (parts 1 to 4)
• The Open Group Base Specifications, Issue 6 - która jest główną twórczą częścią SUS
  W szczególności składa się z następujących elementów:
  • Base Definitions, Issue 6 (XBD) - Podstawowe definicje
  • Shell and Utilities, Issue 6 (XCU) - Powłoka i narzędzia
  • System Interfaces, Issue 6 (XSH) - Intefejsy systemowe
  • Rationale (Informative) - Uzasadnienia
• X/Open Curses, Issue 4, Version 2 specification

Przenośny fundament - Linux Standard Base

Jednak FHS i SUS to zamało by przyciągnąć twórców komercyjnego oprogramowania do Linux'a. Oba standardy nie poruszają problemów binarnej zgodności, a jej brak pomiędzy Unixami uniemożliwia dystrybucję oprogramowania w postaci binarnej lub czyni ją drogą i w większości przypadków nieopłacalną.

Dlatego w 1998 roku rozpoczęła działalność grupa Linux Standard Base, która za swój cel podaje: Celem LSB jest tworzenie i promowanie zestawu binarnych standardów, które zwiększą zgodność pomiędzy Linuxami (i systemami podobnymi) i umożliwi uruchamianie aplikacji na zgodnych systemach. Dodatkowo LSB będzie koordynowało działania mające na celu przyciągnąć producentów oprogramowania do pisania i przenoszenia oprogramowania na platformę Linux

W założeniu grupy uczestniczyli Linux Torvalds, przedstawiciele czołowy dystrybucji, członkowie Linux International oraz Jordan Hubbard z projektu FreeBSD.

Specyfikacja ujrzała światło dzienne 29 czerwca 2001. Od tego czasu co około 6 miesięcy jest ogłaszana realizacja standardu. Obecnie obowiązującym jest standard 3.1

Jako, że celem jest binarna zgodność, to standard musi być uzależniony od architektury. Dlatego też składa się z dwóch części, ogólnej oraz specyficznej dla poszczególnych architektur. Aktualnie wspierane są następne systemu:

• IA-32 (Intel Architecture 32 = x86)
• 32 bit PowerPC
• Intel Itanium
• 64-bitowy PowerPC
• 31-bitowy S390
• 64-bit z/Architecture
• amd64

Problemy, które specyfikacja próbuje rozwiązać to:

• Uniknięcie konieczności przygotowania paczek binarnych na poszczególne dystrybucje
• Uniknięcie problemów z działaniem skompilowanych aplikacji po aktualizacji systemu
• Ułatwienie pracy programistów, którzy zyskują możliwość działania w jednorodnym środowisku
• Zwiększenie rynku dla aplikacji

W szczególności LSB opisuje następujące biblioteki:

• libX11
• libXt
• libGL
• libXext
• libICE
• libSM
• libdl
• libcrypt
• libz
• libncurses
• libutil
• libpthread
• libm
• libc

By umożliwić dodawanie funkcjonalności i zachowanie zgodności, biblioteki te stosują "wersjonowanie symboli". Polega to na zakazie modyfikowania nagłówków funkcji i nakazie dodawania kolejnych numerów przy nazwach funkcji których nagłówki lub symantyka ulega zmiania.

Za podstawowy system pakietów został uznany pewien podzbiór funkcjonalności RPM'a w wersji 3. Systemy nie wykorzystujące RPM'a za swój natywny system pakietów, powinny umożliwić - przy pomocy dodatkowych narzędzi - zainstalowanie oprogramowania z RPM'a.

LSB powołuje się na FHS (Filesystem Hierarchy Standard) w kwestii rozmieszczenia danych na dysku.

LSB udostępnia zestaw narzędzi umożliwiających testowanie zgodności systemu oraz aplikacji z LSB. Dostępne są następujące programy:

• lsb-runtime-test - sprawdza, czy system zapewnia wymaganą przez LSB funkcjonalność
• lsblibchk - sprawdza, czy w systemie są dostępne - we właściwych wersjach - biblioteki wymagane przez POSIX
• lsbappchk - sprawdza, czy aplikacja uruchomiona jako parametr - odwołuje się tylko i wyłącznie do zgodnych z LSB bibliotek
• libdev-cc/ - kompilator gcc, który może podczas kompilacji wykorzystywać tylko biblioteki zgodne z LSB
• lsbdev-chroot - ogranicza dostępne w systemie pliki nagłówkowe, biblioteki i urządzenia do zgodnych z LSB i się chroot'uje do tego środowiska. Umożliwia czystą (bezpieczną) kompilację języków innych niż c i c++..

LSB prowadzi odpłatną certyfikację na zgodność ze standardem.

Linki:

• Linux Standard Base (http://www.linuxbase.org)
• Free Standards Group (http://www.freestandards.org)
• Certyfikacja LSB (https://www.opengroup.org/lsb/cert)

---

Programy rozpowadzone z dystrybucją

Podstawową motywacją do tworzenia dystrybucji było dołączenie do jądra wielu programów, dzięki którym Linux stawał się zdatny do użycia do naszych celów. Musimy na początek podjąć decyzję, czy akceptujemy tylko programy na licencji otwartej, czy też jakieś komercyjne lub inne licencje. W przypadku tej drugiej możliwe, że nasza dystrybucja stanie się płatna, gdyż licencja wymusi na nas płacenie twórcy oprogramowania.

Parę słów o licencjach

Różne programy, nawet nazywające się wolnymi, wypuszczane są na różnorodnych licencjach, w których można się pogubić.

Projekt GNU, mający na celu stworzenie otwartego, wolnego systemu operacyjnego (a którego narzędzia wchodzą w skład Linuxów), wraz z FSF (Free Software Foundation) prowadzą klasyfikację licencji (w tym swoich: GPL General Public License, GPL Free Documentation Licence).

Licencja, pierwsze jaki test przechodzi, to czy jest Free Software License. Aby to spełnić musi zapewniać cztery wolności:

• Freedom 0 - wolność uruchamiania programu wszędzie i z jakichkolwiek przyczyn
• Freedom 1 - wolność analizowania, jak program działa, przerabiania go i dostosowywania do własnych potrzeb
• Freedom 2 - wolność rozpowszechniania kopii pogramu
• Freedom 3 - wolność ulepszania i poprawiania programu, oraz udostępniania do wszystkim z poprawkami

Jeśli licencja zapewnia te możliwości jest zaliczaja jako Free Software License. Nie gwarantując tych możliwości, zaliczana jest jako non-free. Np. licencja programu Scilab nie jest FSL, gdyż nie można rozprowadzać płatnie programu z własnymi poprawkami (niejako oczekując opłaty od własnych poprawek).

Jeśli licencja jest Free Software License, może się ubiegać o status GPL-compatible, czyli zgodną z licencją GPL (sztandarową licencją FSF). Zgodność licencji oznacza, że możesz załączać do swojego programu programu i moduły wydane na licencji GPL i dalej rozprowadzać pod swoją licencją.

Jak widać z powyższych rozważań, bez problemu możemy załączać, nawet do komercyjnej dystrybucji, programy objęte licencją zaliczoną jako Free Software License. Z drugiej strony, załączając tylko takie programy, możemy naszą dystrybucję również objąć jakąś podobną licencją. Uzywanie produktów z inną licencją wymaga uwagi.

Klasyczne oprogramowanie w dystrybucjach

Zajmijmy się teraz kilkoma klasycznymi programami (typami programów), które mogą się znaleźć w dystrybucji:

1. podstawowe narzędzie systemowe - interpreter poleceń, GCC, make, ... - tutaj raczej nie ma wyboru, darmowe narzędzia GNU są dobre i wszystkim znane.
2. X-y. W serwerze, klastrze obliczeniowym, bazie danych zapewne nie będzie. Jednak w aplikacjach biurkowych jest to dość istotny element dystrybucji:
   • Możemy zdecydować się na prostszego manadżera okienek, np. WindowMakera. Zaletą jego jest prostota i lekkość, zapewne zainstalujemy go dla bardziej zaawansowanych użytkowników lub też na słabszych maszynach. Wadą jest ubogość (choć niektórzy mówią, że to zaleta).
   • Jednym z ciężśzych, ale rozwiniętych menedżerów okien jest KDE, czyli K Desktop Environment, wolny i darmowy, oparty o biblioteki Qt
   • Alternatywą czy też konkurencją dla KDE jest Gnome, również otwarty menedżer okien. Powstał jako konkurencja do KDE, w oparciu o biblioteki GTK+ (gdyż w roku 1997 biblioteki Qt nie były objęte otwartą licencją). Wybór pomiędzy KDE a Gnome, jako dwoma dość ciężkimi, ale funkcjonalnymi menedżerami okien, zależy zapewne głównie od preferencji użytkowników i wiele dystrybucji załącza wiele menedżerów okien i daje wybór przy instalacji. Wiele menedżerów okien bierze udział w projekcie freedesktop.org, mającym za zadanie ustalenie pewnych standardów menedżerów okien, dzięki którym będzie można pisać aplikacje na wszystkie.
3. Dystrybucja przeznaczona dla programistów będzie zawierać wiele środowisk i narzędzi dla programistów: debuggery, środowiska pracy (np. Eclipse), narzędzia komunikacyjne (organizator, klient pocztowy), narzędzia do tworzenia dokumentacji itd.
4. Dystrybucja biurkowa (oraz zapewne, w części, dla programistów) będzie zawierać narzędzia biurowe: OpenOffice, organizator pracy, klient pocztowy itd.
5. Dystrybucje przeznaczone dla mniej zaawansowanych zapewne będą wymagały załączenia programów ułatwiających konfigurację i robiących wiele rzeczy automagicznie (np. automount).
6. Dystrybucje przeznaczone na serwery mogą zawierać gotowe demony do usług sieciowych, które mamy udostępnić: serwery WWW, DHCP, SSH, czy też systemy zarządzania bazami danych (PostGreSQL, MySQL).
7. Dystrybucja przeznaczona do wszystkiego będzie zawierać zapewne i otwarte serwery, i bazy danych, i środowiska programistyczne.
8. Dystrybucja LiveCD, być może przeznaczona do ratowania komputerów, będzie zawierać narzędzia naprawcze i diagnostyczne.
9. Większość dystrybucji będzie zawierała narzędzia sieciowe, w tym firewall.
10. Właściwie na pewno (chyba że robimy dystrybucję dla siebie lub na kilka komputerów tylko) będziemy potrzebowali zarządcę pakietów oraz program do aktualizacji oprogramowania; nimi zajmiemy się jednak w kolejnym punkcie.
11. Narzędzia do obsługi bardziej nietypowych urządzeń, np. napędu taśmowego. Jakkolwiek jądro powinno sobie poradzić ze sterownikami do prawie wszystkich urządzeń, nieraz będziemy chcieli załączyć bardziej zaawansowane narzędzie do obsługi.
12. Pliki lokalizacyjne: czcionki, układ klawiatury.
13. Bajery: tapety, dźwięki.

Na każdym punkcie powyższej listy powinniśmy, tworząc dystrybucję, wybrać czy załączamy odpowiednie narzędzia i jakie - nieraz jest kilka do wyboru. W przypadku dystrybucji dla wąskiego grona osób, pewnie się pokierujemy ich preferencjami. W dystrybucji dla mas... pewnie tą, co nam się wyda lepsza.

Pakiety, menedżer pakietów

Mnogość programów które załączymy do naszej dystrybucji szybko przyprawią nas o ból głowy i, instalowane tak po prostu szybko zrobią duży śmietnik, który nie będziemy mogli opanować. Opanowaniu tego bałaganu służą pakiety.

Pakiet to po prostu

• jeden program, biblioteka, czy też zestaw dokumentacji,
• zapakowany w specjalny format, by system (czy też dokładnie menedżer pakietów) mógł rozpoznać, co to za pakiet, czy ma już go zainstalowanego itd.

Innymi słowy, wraz z samym programem (biblioteką, dokumentacją) zamieszczamy parę dodatkowych informacji:

1. Jakąś oficjalną, unikatową nazwę pakietu.
2. Numer wersji, by później móc wydać nowszą wersję, i menedżer pakietów się zorientował, że to jest nowa wersja i można ją nadinstalować.
3. Sposób instalacji.
4. Wymagania, czyli jakie pakiety są wymagane, by nasz program dobrze działał, np. pakiet kerncalc-devel wymagał pakietu kerncalc.

Za pomocą mechanizmu wymagań (ang. dependencies) tworzymy sieć zależności, które m.in.:

1. mocno odciążają wielkość systemu: np. wszystkie aplikacje okienkowe pod KDE będą wymagały bibliotek KDE, a nie przynosiły je razem z sobą.
2. ułatwiają tworzenie oprogramowania: możemy, pisząc program, założyć, że pewne inne narzędzia czy biliboteki są dostępne w systemie.

Jedną z decyzji, które też powinniśmy podjąć, jest stopień rozdrobnienia pakietów. Dla przykładu: w dystrybucji PLD przyjęto założenie, że jeśli tylko się da, dzielimy program na podpakiety. Z jednej strony powoduje to, że oszczędzamy na wielkości systemu: zainstalowane na komputerze jest tylko to, co jest aktualnie potrzebne. Z drugiej strony, przy takim rozwiązaniu, urasta znacznie liczba pakietów i komplikuje się sieć zależności. Alternatywą jest łączenie mniejszych pakietów w większe - zmniejsza to liczbę pakietów, ale nieraz będziemy mieli niepotrzebne oprogramowanie zainstalowane na komputerze.

Drugą decyzją jest to, czy preferujemy rozprowadzanie pakietów w formie źródeł czy skompilowanej. Pakiety skompilowane nie wymagają instalacji (przez co się je szybciej instaluje) i są prostsze w instalacji, lecz za to są kompilacja na architekturę docelowego użytkownika na jego maszynie nieraz zwiększa efektywność.

Oprócz samej idei pakietów, oraz po ustaleniu formatu pakietu (który m.in. zawiera, jakie informacje są przechowywane w pakiecie), potrzebujemy jeszcze programu, który będzie rozumiał pakiety, potrafił je zainstalować, informować użytkownika o zależnościach. Taki program to menedżer pakietów.

Dostępnych jest wiele gotowych rozwiązań pakietowych, każdy ma swoje wady i zalety. Zapewne, tworząc dystrybucję, nie będziemy tworzyć nowego systemu pakietów, lecz wesprzemy się którymś z instniejących.

Tworzenie własnego systemu pakietów ma oczywiście parę zalet:

1. Możemy zawrzeć jakieś informacje w pakiecie, które nie zawierają inne systemy pakietów (pewnie to był jeden z powodów, dla których nie wybraliśmy istniejącego systemu pakietów).
2. Będziemy dobrze rozumieli ten system pakietów i będziemy mogli go dobrze dostosować do reszty systemu.

Wad, ze względu też na mnogość różnych systemów pakietów na rynku, jest chyba więcej niż zalet:

1. Będziemy musieli sami tworzyć pakiety z wszystkimi potrzebnymi programami.
2. Czeka nas sporo pracy z implementacją systemu pakietów.

Tak więc pora na przegląd kilku najbardziej popularnych systemów pakietów. Następie omówimy systemy wspomagające wiele systemów pakietów, jak np. autopackage.

RPM, czyli RPM Package Manager RPM Package Manager, dawniej RedHat Package Manager, był pierwotnie rozwijany w dystrybucji RedHat, teraz jest najbardziej popularnym systemem pakietów, uznany przez Linux Standard Base za podstawę. Używany obecnie m.in. w: Fedora Core, SuSe, Auroxa, PLD. Trochę już mieliśmy okazji go poznać przy okazji laboratorium. Podstawowe cechy:

1. Istnieją zarówno paczki binarne jak i z kodami źródłowymi.
2. Format nazwy pliku: [nazwa]-[wersja]-[architektura].rpm dla pakietów binarnych i [nazwa]-[wesja].src.rpm dla pakietów źródłowych.
3. Istnieją automatyczne aktualizatory do pakietów RPM, jak np. YUM.
4. Posiada dość złożoną obsługę zależności.

Z zalet można wymienić:

1. Prostotę i jednolitość instalacji nowych pakietów.
2. Brak interaktywności programów obsługujących, dzięki czemu można ich używać w automatycznych skryptach.
3. Wysoką popularność - bardzo dużo programów jest rozprowadzanych jako RPMy, są wyszukiwarki RPMów, np. rpm.pbone.net.
4. Istnienie paczek z kodami źródłowymi.
5. Możliwość weryfikacji poprawności przez MD5 i GPG.
6. Istnieje DeltaRPM, który jest systemem patchów do RPMów - nie trzeba ściągać całego nowego RPMa, by zrobić aktualizację.
7. Wygodne w użyciu programy aktualizacyjne, zwłaszcza YUM.

Bez wad też się nie obejdzie:

1. Częsta zmiana formatu paczek z wersji RPMa na wersję, bez wstecznej kompatybilności.
2. Stara, nieaktualna, niekompletna dokumentacja.
3. Duży śmietnik w zależnościach, w szczególności w paczkach tworzonych przez różne dystrybucje.
4. Dość skomplikowany i nienajlepiej opisany sposób tworzenia paczek.
5. Nie można rozpakować paczki bez programu RPM (np. .deb można rozpakować z pomocą standardowych narzędzi, jak gunzip czy tar).

Także RPMy są zazwyczaj używane w dystrybucjach zarówno dla mniej jak i bardziej zaawansowanych użytkowników, głównie w dystrybucjach biurkowych i programistycznych (na stacje robocze).

Dpkg, czyli pakiety Debiana

System pakietów Debiana, Dpkg, który również jest używany w kilku innych dystrybucjach, np. Knoppixie, jest bardzo zbliżony ideą do RPMów.

Trochę różni się architektura rozwiązań: program dpkg, i jego pomocnicze skrypty, jest narzędziem dość niskopoziomowym: potrafi rozpakować i zainstalować paczkę, sprawdzić czy zależności się zgadzają, odinstalować paczkę. Jest to program przeznaczony do użycia w bardziej wysokopoziomych narzędziach, jak APT, opisany w rozdziale dotyczącym systemów aktualizacji - sam w sobie jest dość ubogi.

O samym Dpkg można powiedzieć trochę:

1. Prostota użycia powoduje, że można używać go w różnych programach wyższego poziomu.
2. Zarządza zależnościami
3. Jest to dość popularny system, wiele programów jest dostępnych jako paczki .deb.

Jednak podstawową zaletą jest istnienie bardzo dobrego programu APT, który jest uznawany za jedną z podstawowych zalet Debiana i dystrybucji pochodnych. APT jest opisany w rozdziale dotyczącym systemów aktualizacji.

.tgz, czyli Slackware

Slackware w standardowym założeniu nie przejmuje się zależnościami między pakietami. Pakiet to po prostu spakowana paczka .tgz, która może posiadać skrypt doinst.sh, który w razie czego wysypie się, jak nie będzie miał potrzebnych programów czy bibliotek. Proste programy: installpkg, updatepkg, removepkg to instalacja, aktualizacja i usunięcie takiego pakietu.

Paczka Slackware'owa może jednak zawierać pewne informacje o zależnościach w osobnych plikach, potrafią sobie z nim poradzić bardziej wysokopoziomowe narzędzia, jak np. slapt-get. Zostały one opisane w rozdziale o aktualizacjach.

Emerge - właściwie Portage, czyli Gentoo

Mechanizm Portage jest jednym z najbardziej złożonych mechanizmów zarządzania pakietami - ze szczególnym naciskiem na pakiety źródłowe (ale bez ograniczenia możliwości w pracy z pakietami binarnymi i pakietami języków, gdzie pojęcie źródeł się zaciera).

Mechanizm portage realizuje następujące zadania:

• Jedno polecenie do wykorzystywania mechanizmu Portage (o nazwie emerge)
• Automatyczne zarządzanie zależnościami pomiędzy zainstalowanym oprogramowaniem z uwzględnieniem "raz zdefiniowanych preferencji użytkownika" (z możliwością nadpisania tych preferencji)
• Automatyczne ściągania brakującego oprogramowania z któregoś dostępnego serwera
• Automatyczne sprawdzanie sum kontrolnych ściągnietego oprogramowania
• Konfigurowanie flag kompilacji w zależności od "raz zdefiniowanych preferencji użytkownika" (flagi USE), z możliwością nadpisania tych preferencji
• Automatyczne odinstalowanie oprogramowania, które zostało uznane za niesprawne (za zgodą użytkownika oczywiście)
• Działanie w piaskownicy (sandbox'ie)
• Automatyczna aktualizacja całego zainstalowanego oprogramowania (emerge --sync; emerge -u world)
• Możliwość instalacji oprogramowania ręcznie i uwzględnienia go w zależnościach
• Możliwość wyboru profilu oprogramowania
• Obsługuje informacje o pakiecie w danym profilu i na danej architekturze: działa; testowy; zamaskowany (niedziałający)
• Odinstalowywanie oprogramowania
• Obsługę pakietów binarnych
• Obsługę metapakietów - które mają swoimi zależnościami pociągnąć instalacje innych pakietów - np. KDE

Flagi USE to sedno tych "raz zdefiniowanych preferencji użytkownika". Przykład flag USE to:

• gtk - Dodaje wsparcie dla x11-libs/gtk+ (The GIMP Toolkit)
• gtk2 - Używa gtk+-2.0.0 zamiast gtk+-1.2 w przypadku, gdy program wspiera oba formaty.
• gtkhtml - Dodaje wsparcie dla gnome-extra/gtkhtml
• guile - Dodaje wsparcie dla dev-util/guile (Intepreter dla Scheme)
• icc - Używa kompilatora Intel C++ jeżeli pakiet posiada dla niego wsparcie
• icc-pgo - Włącza generację danych PGO lub używa przy icc.
• imap - Dodaje wsparcie dla IMAP

Autopackage

Autopackage jest mechanizmem obsługującym pakietów dostarczonych w pliku o rozszerzeniu ".package".
Zakłada on:

• Instalowanie pakietów na wielu różnych dystrybucjach
• Wiele interfejsów przeprowadzania procesu instalacji: Użytkownicy GUI mają GUI, użytkownicy lini poleceń mają interfejs linii poleceń
• Obsługę wielu języków
• Obsługę zależności - uwzględniającą oprogramowanie zainstalowne inczej niż przez autopackage
• W procesie powstawania: Obsługę instalacji pakietów metodami natywnymi danej dystrybucji

System rozprowadzania, infrastruktura sieciowa

Jeśli nasza dystrybucja jest przeznaczona dla dużej liczby użytkowników na świecie, musimy opracować system rozprowadzania tejże dystrybucji, pakietów oraz aktualizacji do pakietów. W obecnym świecie Linuxowym popularne są następujące metody (lub, od drugiej strony patrząc, są to sposoby otrzymania Linuxa ;) ):

1. Stawiamy nasz serwer FTP, na którym umieszczamy pakiety dystrybucji oraz np. obrazy płyt .iso z wersją instalacyjną naszego systemu. Stąd można pobrać naszą dystrybucję oraz aktualizacje do niej. Następnie umawiamy się z wieloma serwerami na świecie, prowadzącymi mirroring Linuxa, że będą mirrorowały nasz system. Działanie tego jest bardzo proste: tamte serwery co jakiś czas sprawdzają, czy nie pojawiło się u nas coś nowego, i jeśli tak, to ściągają do siebie. W ten sposób użytkownicy z całego świata mogą ściągać naszego Linuxa z serwera położonego blisko nich. Popularnym polskim mirrorem dla linuxów jest serwer ftp.icm.edu.pl.
2. Rozprowadzamy naszą dystrybucję na płytach CD np. z czasopismem komputerowym.

W dodatku, oczywiście, powinniśmy stworzyć dokumentację do naszego Linuxa - opis instalacji, konfiguracji itd.

System aktualizacji

Jak już zostało powiedziane, pakiety z oprogramowaniem zawierają numer wersji, menedżer pakietów potrafi zaktualizowac pakiety. Naszym systemem rozprowadzania, prawdopobodnie za pomocą serwerów FTP, rozprowadzamy aktualizacje do pakietów. Szybko jednak się okaże ręczne instalowanie aktualizacji niewygodne, bo:

1. W momencie jak mamy rozbudowaną dystrybucję z wieloma programami, pewnie będzie kilka aktualizacji do różnych programów dziennie.
2. W momencie instalacji, lub aktualizacji jednego pakietu, możliwe że będzie trzeba 30 innych też zaktualizować, ze względu na zależności. W dodatku, te zależności mogą mieć kilka stopni zagnieżdżenia...

W związku jest potrzeba zrobienia mniej lub bardziej automatycznego programu aktualizującego. Program ten powinien potrafić:

1. Stwierdzić, jakie pakiety są potrzebne do aktualizacji / instalacji
2. Połączyć się z serwerem FTP i wyszukać potrzebne pakiety.
3. Zainstalować pakiety.

Poniżej omówimy kilka istniających programów aktualizujących - być może chcemy któryś z nich wybrać:

1. YUM, YellowDog Update Modifier.

   Działa na pakietach RPM, m.in. w Fedora Core, Red Hat Enterprise Linux, Aurox. Działający z linii poleceń. Rozbudowany mechanizm opcji. Możliwość korzystania z wielu serwerów FTP. Zaawansowana obsługa zależności Istnienie kilku nakładek graficznych. Wadą (z własnego doświadczenia) jest to, że potrafi nieraz rozpoznać, że czegoś nie potrafi zrobić dopiero po ściągnięciu pakietów, co powoduje niepotrzebne ściąganie dużych plików. Drugą wadą jest to, że działa tylko z pakietami RPM.

2. up2date,
   • czyli okienkowy aktualizator,
   • dołączany w Fedora Core i Red Hat Enterprise Linux,
   • prosty,
   • posiada błędy,
   • z zalet: potrafi czytać pliki konfiguracyjne YUMa.
3. APT (Advanced Packaging Tool), czyli
   • program aktualizujący do pakietów Debiana Dpkg.
   • Same narzędzia Dpkg nie są bardzo rozbudowane i ciężar automatyzacji i obsługi złożonych żądań użytkowników został przerzucony na APT.
   • APT jest uznawany za jedną z głównych zalet Debiana i dystrybucji pochodnych.
   • W swoich założeniach jest dość podobny do RPM wraz z YUM:
     • Potrafi ściągać automatycznie aktualizacje, sprawdzać zależności i wybierać pakiety do ściągnięcia.
     • Duża liczba pakietów dostępnych w sieci, wiele programów jest wypuszczanych jako paczki .deb, dostępnych dla APTa
     • Program potrafi ściągać z wielu repozytoriów na raz, w tym zarówno z dystrybucji stable jak i unstable.
     • Potrafi również sciągać paczki z lokalnych repozytoriów, płyt CD itd.
     • APT potrafi zadawać pytania i dawać się konfigurować dość szczegółowo w kwestii, jakie pakiety instalować z nowych aktualizacji itd.
   • APT sam w sobie jest zbiorem bibliotek w C++, wraz z programami, jak np. apt-get.
   • Jest wiele dostępnych interfejsów okienkowych.
4. Mimo, iż standardowe pakiety pod Slackware są to paczku .tgz, niektóre z nich mogą zawierać pliki informujące o zależnościach. Istnieją programy pod Slackware, potrafiące obsługiwać te zależności i przeprowadzać automatyczne aktualizacje. Tymi programami są np. slapt-get, starający się emulować APTa, oraz slackpkg czy swaret. Te programy, poza przeprowadzaniem aktualizacji i próbą rozwiązywania zależności, tworzą również wygodny interfejs użytkownika do Slackware'owego systemu pakietów (programów installpkg, updatepkg itd).
5. Portage, czyli program aktualizujący do pakietów Gentoo. Jedno polecenie "emerge --sync" dokonuje następujących operacji:
   • Połączenie z najmniej obciążonym mirrorem systemy Gentoo
   • Synchronizację informacji o metodach instalacji poszczególnych pakietów - wszystkich
   • Synchronizację informacji o statusie poszczególnych pakietów w poszczególnych profilach na poszczególnych architekturach
   Po tej synchronizacji poleceniem "emerge -pu world" możemy zobaczyć listę zmian, które należy dokonać w systemie, by stał się w pełni aktualnym systemem. Następnie wydajemy polecenie "emerge -u world" i system aktualizuje wszystko.

Instalator

Jeśli robimy Linuxa nie na kilka komputerów tylko, powinniśmy stworzyć system instalacji. Instalacje Linuxów można robić na wiele sposobów:

1. Z bootującego nośnika (CD, DVD, Flash) zawierającego wszystkie pakiety, które użytkownik może chcieć zainstalować, rozbudowany instalator (np. Fedora).
2. Z bootującego nośnika (CD, DVD, Flash, Floppy) zawierającego podstawę linuxa, wraz z informacją, skąd z sieci pobrać dalszą częśc dystrybucji (np. Gentoo).
3. Przez sieć, bootując się z sieci i pobierając co potrzeba.
4. Ręcznie, wg instrukcji.

Wybór ostatni jest oczywiście tylko dla zaawansowanych użytkowników, gdy nasz system będzie na niewielu komputerach (np. system dla klastrów obliczeniowych).

Instalator powinien:

• dać użytkownikowi możliwość wyboru, jakie pakiety chce zainstalować
• wstępnie skonfigurować system (firewalla, opcje lokalizacyjne, hasło roota itd.)
• zapewne powinien zawierać narzędzie do partycjonowania dysku oraz instalację boot-managera.

Narzędzie do partycjonowania dysku służy do utworzenia partycji dla Linuxa (właściwej i swap, być może też innych, jak użytkownik sobie zażyczy) oraz do modyfikacji istniejących partycji (np. Windowsowej). Jeśli nasza dystrybucja jest dla początkujących użytkowników, powinien on tłumaczyć wszystko co robi i nie pozwolić bez wielu ostrzeżeń nic wykasować. Dla zaawansowanych, powinien udostępniać wiele opcji.


Anaconda - instalator Fedory

Boot manager

Boot manager to program, który znajduje się w Master Boot Record na dysku, czyli tam, gdzie komputer sięga, szukając systemu operacyjnego. Boot manager uruchamia sie, czyta swój plik konfiguracyjny, a następnie daje użytkownikowi możliwość wyboru systemu operacyjnego, który będzie uruchamiany. Daje to możliwość współistnienia wielu jąder Linuxa oraz Linuxa i innych systemów operacyjnych, np. Windows. Po wyborze program ładuje boot record wybranego systemu i wykonuje zwykły skok do początku kodu odpowiedniego miejsca w tym kodzie, uruchamiając system. System nie widzi wogóle, że był uruchomiony przez boot-loadera.

Popularnymi boot managerami dostępnymi z Linuxami są LILO oraz Grub.

• Grub jest obecnie najpopularniejszym boot-loaderem, wywodzącym się z narzędzi GNU. Potrafi czytać wiele różnych systemów plików, z nich czytać pliki konfiguracyjne (np. /etc/grub.conf i jądra do załadowania. Przez obsługę wielu systemów plików, jest duży dzięki czemu wymaga dwóch stopni ładowania: stage 1 ładuje, jeśli potrzeba, stage 1.5 która to dopiero ładuje właściwego Grub-a, czyli stage 2. Aktualnie Grub przestał być rozwijany, kosztem postania Grub2.
• LILO jest drugim najpopularniejszym boot-loaderem. Prostszy, mniejszy, nie potrafi czytać systemów plików - wymaga skonfigurowania, gdzie znajdują się na dysku obrazy Master Boot Record systemów operacyjnych do załadowania.

Wybór systemu operacyjnego w LILO

System plików

Dla naszej dystrybucji pewnie będziemy chcieli wybrać standardowy i obsługiwane systemy plików. Systemy plików były już omawiane, więc tu nie będziemy się nad nimi rozwodzić.

Sposób rozwoju

Pytanie, które sobie powinniśmy postawić też, to to, w jaki sposób nasza dystrybucja będzie się rozwijać. Różne dystrybucje Linuxa stosują kilka różnych metod:

1. Wiele dystrybucji jest rozwijanych przez społeczność internetową, tj każdy może popracować, wprowadzić jakieś zmiany, potestować. Są oczywiście ludzie - ale nieraz tez wolontariusze - którzy się opiekują, nadzorują (np. my), ale ogół pracy wykonany jest przez ochotników. (większość dystrybucji - Debian, Fedora, Gentoo, ...)
2. Dystrybucje komercyjne, które zawierają zazwyczaj programy płatne oraz gwarantują obsługę techniczną, utrzymują się rzecz jasna z opłat, zatrudniają pracowników itd. (Red Hat Enterprise Linux, LInspire)
3. Wiele dystrybucji jest wspierana przez firmy, np. SuSe jest wspierana przez Novella. Firma ta zatrudnia pracowników do pracy nad projektem (obok ludźmi pracującymi społecznie nad rozwojem), zazwyczaj są to wtedy opiekuni jakiś części systemu. Firma wówczas uzyskuje porządną, dostosowaną do własnych też potrzeb dystrybucję. (SuSe, Ubuntu, Mandriva)
4. Możemy również poprzestać samemu na rozwoju, wspierając się tylko radami od użytkowników. (po części Slackware)

Tworzenie dystrybucji - to nie jest takie trudne! Linux From Scratch Projekt Linux From Scratch oferuje możliwość zbudowania własnej dystrybucji linuxa od podstaw, z samych źródeł programów dostępnych w sieci. LFS jest de facto książką "jak to zrobić". W wersji "podstawowej" daje nam możliwość zbudowania własnej dystrybucji na świeżej, czystej partycji. Na stronie LFS dostępnę są też "dodatki" do tej książki, umożliwiające m.in.: budowę dystrybucji z ulepszonym bezpieczeństwem (HLFS) ściągnięcie automatycznych skryptów ułatwiających budowę dystrybucji (ALFS) jak zrobić własne LiveCD wiele porad, jak ulepszyć naszą dystrybucję

Tworzenie własnej dystrybucji, poza zaspokojeniem potrzeb wynikających z Pytania 1 i ogólnej motywacji do tworzenia dystrybucji, ponadto pozwala nam (wg autorów LFS):

• na lepsze zrozumienie jak działa Linux i jego komponenty, poznanie Linuxa bardziej od środka (nie jądra Linuxa, a Linuxa jako całego systemu operacyjnego).
• na stworzenie systemu, który będzie zazwyczaj mniejszy i wydajniejszy od zainstalowania dowolnej gotowej dystrybucji.
• tworzenie własnej dystrybucji daje nam pełną swobode wyboru - LFS jest bardzo elastyczny.
• w czasie tworzenia, wszystkiego dotykamy ręcznie, konfigurując - w ten sposób zwiększając bezpieczeństwo systemu, nie przegapimy tyle dziur, a zaaplikujemy wszystkie łatki bezpieczeństwa nie czekając na automatycznego aktualizatora.

Rozpoczynając tworzenie własnej dystrybucji wg. LFS potrzebujemy:

• działającego innego Linuxa
• czystej, wolnej partycji

Robiąc własnego Linuxa, w wielkim skrócie należy dokonać:

1. sformatować nową partycję oraz zamontować ją pod istniejącego Linuxa
2. ściągnąc długą listę potrzebnych pakietów i łatek (lista jest dostępna w książce)
3. tworzymy tymczasowy system do dalszego tworzenia docelowej dystrybucji, tzw. tzw. toolchain, a w tym:
   • zainstalować na nowej partycji podstawowe narzędzia Linuxa, w tym GCC, Make, Bash i inne
   • zainstalować na nowej partycji nagłówki jądra Linuxa
4. zainstalować, już jako docelową dystrybucję, podstawowe narzędzia, przy pomocy toolchain:
   • podmontowywujemy nową partycję pod /
   • tworzymy katalogii i urządzenia
   • tworzymy katalogii o użytkonikach
   • instalujemy podstawowe narzędzia: GCC, Make, Man, Bash i inne
5. tworzymy skrypty uruchamiane przy uruchamianiu (bootscripts)
6. instalujemy jądro Linuxa i czynimy nasz system bootowalnym
7. reboot! i gotowe

Oczywiście dalej nasz system będzie wymagał wiele pracy, zainstalowania potrzebnych narzędzi do pracy itd... ale działa!

Przegląd i porównanie dystrybucji

Mając już za sobą teoretyczną drogę prowadzącą do stworzenia dystrybucji, pora przyjrzeć się paru najbardziej popularnym dystrybucjom, zastanowić się jakie decyzje oni podjeli, dla kogo są one przeznaczone, oraz je porównać.

Jeśli ktoś zastanawia się, jaką dystrybucję wybrać, polecamy Linux Distribution Chooser oraz porównanie dystrybucji Linuxa na Wikipedii.

Mandriva, dawniej MandrakeLinux, zwana w kuluarach Mandaryną

Mandriva Linux Trzy słowa o historii Za Wikipedią: Dystrybucja stworzona w 1998 r. Początkowo był to zbiór pakietów na Red Hat Linux, później usamodzielniła się i rozwinęła. Przez pewien czas firma (wówczas Mandrakesoft) balansowała na krawędzi bankructwa, ale wyszła z tego obronna ręką, w czym duża zasługa modelu biznesowego, konsekwentnie opartego o lojalność wobec społeczności FLOSS. 24 stycznia 2005 r. poinformowano, że Mandrakesoft łączy się z brazylijską firmą Conectiva a 7 kwietnia tego roku o zmianie nazwy z Mandrakesoft na Mandriva i zmianie nazwy dystrybucji na z Mandrakelinux na Mandriva Linux. Zmiana nazwy wiąże się z procesem wytoczonym przez wydawcę komiksu Mandrake the Magician, który zarzuca dystrybutorowi naruszenie praw autorskich przez zapożyczenie nazwy i "magiczne" skojarzenia graficzne.

Odpowiadamy na pytania

Jest to:

• Pytanie 1: dystrybucja, która powtała by być przyjazną początkującemu użytkownikowi. By firma Mandriva zarobiła.
• Pytanie 2: dystrybucja przeznaczona dla początkujących użytkowników:
  • którzy będą wykorzystywali konfiguratory graficze
  • którzy nie będą instalowali innego oprogramowania niż to z RPMów
  • którym przez myśl nie przejdzie przekompilować jądro
  • którzy i tak regularnie psują wszystko - więc bałagan się posprząta przy następnym formatowaniu dysku
• Pytanie 3: pierwotnie przeznaczona na x86, obecnie także na amd64.
• Pytanie 4: dystrybucja przeznaczona jako "pierwsza dystrybucja", do zastosowań biurowych i edukacyjnych

Wnioski

• Maksymalnie rozbudowany instalator - by uprościć proces instalacji
• Środowisko graficzne z wszystkimi bajerami - skaczącymi ikonami itd.
• Możliwość wyłączenia haseł - nawet administratora
• Obsługa i wykrywanie wielu urządzeń na stałe
• Automatyczne montowanie urządzeń
• Interfejs przetłumaczony do języków narodowych
• Menadżer pakietów RPM
• Draki (może teraz Drivy)- konfiguratory graficzne wszystkiego
• Aktualizacja raz na rok - wcześniej dla "płacących" użytkowników
• Odpłatna pomoc techniczna i sprzedaż dystrybucji w pudełku
• PowerPack - odpłatne dodatkowe pakiety

System pakietów

System RPM - ale w dużej mierze niezgodny z RedHatowym RPM'em.
Narzędzie graficzne do zarządzania pakietami - rpmdrake.

---

Fedora Core, następca RedHat Linuxa

Trzy słowa o historii

W roku 2003 Red Hat Inc., firma zajmująca się dystrybucją otwartą i darmową RedHat, zmieniła strategię działania tworząc, w dużej mierze niezależną, dystrybucję otwartą Fedora Core, oraz własną, komercyjną, Red Hat Enterprise Linux. Od tego czasu wydane zostały 4 wydania Fedory, ostatnia wersja została wydana 13 czerwca 2005.

Odpowiadamy na pytania

• Pytanie 1: wolna, otwarta, dobra dystrybucja dla wszystkich.
• Pytanie 2: dystrybucja "do wszystkiego", przeznaczona dla zarówno zaawansowanych jak i początkujących użytkowników.
• Pytanie 3: głównie x86 i AMD, również obecnie PPC
• Pytanie 4: biurko, stacja robocza programisty lub studenta, być może serwer.

Wnioski

W związku z tym dystrybucja spełnia:

• wysoki stopień bezpieczeństwa - tu jest położony mimo wszystko duży nacisk
• niekoniecznie najwyższa efektywność, bardziej ważna bywa nieraz przyjazność użytkownikowi
• przyjazna użytkownikowi, choć nie bez przesady (by nie naruszyć bezpieczeństwa)
• wysoka niezawodność, ale nie za wszelką cenę (przyjazność użytkownikowi - graficzne konfiguratory i narzędzia są jak najbardziej na miejscu).

Dystrybucja nastawiona jest na jak najnowsze pakiety, nie stroni od nowinek, graficznych bajerów, w podstawowej instalacji zajmuje 2-3GB.

Dystrybucja wydawana jest co kilka miesięcy, rozwijana przez społeczność internetową.

System pakietów

Fedora przejęła całego RPMa, z dobrodziejstwem inwentarza, w tym narzędziami YUM i Up2date. Daje to bardzo dużą różnorodność pakietów do instalacji, ale też pewien czasem potrafi powodować śmietnik w zależnościach.

Załączone programy

Fedora posiada, przy instalacji, do wyboru wersję Desktop, Server oraz oczywiście custom. Posiada do instalacji:

1. zazwyczaj najnowsze jądro 2.6.x
2. zarówno KDE jak i GNOME, do wyboru.
3. w wydaniu 4 najnowszego GCC 4
4. wiele narzędzi do tworzenia dokumentów: OpenOffice, TeTeX, ...
5. narzędzia programistyczne: wiele edytorów, Eclipse, ...
6. popularne darmowe serwery i bazy danych: Apache, Bind, PostgreSQL, MySQL, ...
7. wiele narzędzi automagicznie konfigurujących lub okienkowych konfiguratorów, w tym taki "Control Panel"
8. wiele innych...

Oczywiście, wersje Desktop i Server standardowo posiadają odpowiedni, logiczny podzbiór powyższych.

Jak widać owa dystrybucja jest ciężka, przeznaczona do wszystkiego, w tym dla studentów ;).

Z autopsji ;)

Używam fedory od wielu lat... tak z moich obserwacji:

• cenię sobie liczbę dostępnych pakietów, to że wiele jest już na płycie do instalacji
• YUM jest dobrym narzędziem i dobrze współpracuje z Fedorą
• instalator Anaconda sporo umie, ale jeszcze więcej ma bugów, niestety.
• okienkowe konfiguratory, jak ktoś się na tym, co konfiguruje nie zna wogóle, pomagają, w przeciwnym razie przeszkadzają tylko.
• zawsze miałem problem z dźwiękiem
• dobrze działa zarówno z KDE jak i z GNOME
• miałem duże problemy z nią na laptopie.

Inne

• Strona: http://fedora.redhat.com
• Wbrew opinii niektórych, to nie jest tylko dystrybucja na stacje robocze: Wikipedia, kernel.org działają na Fedorze.

Gentoo Trzy słowa o historii Pan Daniel Robbins miał dużo czasu. Dlatego lubił modyfikować i kombinować w wielu dystrybucjach. Początkowo jego ofiarą był Debian, ale po pownym czasie pan Daniel Robbins zaczął uczestniczyć w tworzeniu dystrybucji Stampede Linux w którym tworzył system pakietów. Z niepodanych do publicznej wiadomości powodów opuścił zespół i stwierdził, że zrobi własną dystrybucję. Tak się narodził Enoch. Miał to być bardzo szybki system z całkowicie zautomatyzowanym instalowaniem pakietów. System zaczął się rozwijać, po pewnym czasie było 10 developerów. Jak już przestał przypominać pierwowzór nazwano go Gentoo linux. Na szczęście Daniel kupił sobie nową szybką maszynę, ale błąd chipsetu spowodował, że wieszała się ona permanentnie. Rozwój Gentoo przystanął, a Daniels (niewiadomo na którym komputerze) przestawił się na FreeBSD. Spodobało mu się to co zobaczył - w szczególności system "Portów". Po pewnym czasie powrócił do tworzenia Gentoo i przeprojektował system pakietów i napisał go na nowo - tak powstał Portage.

Odpowiadamy na pytania

Jest to:

• Pytanie 1: dystrybucja, która powstała bo autorowi nie podobały się inne... i pośrednio z zazdrości do portów w FreeBSD
• Pytanie 2: dystrybucja - jak na razie - przeznaczona dla średniozaawansowanego, kto bądź jest na tyle zaawansowany by przebyć proces instalacji, bądź znajdzie osobę, która przeprowadzi ten proces za niego.
  Wynika to z braku instalatora graficznego (jest on w stadium Alfa) jak i graficznych narzędzi konfiguracyjnych. Wszystko się konfiguruje za pomocą dobrze obkomentowanych plików w /etc.
• Pytanie 3: Obsługuje następujące architektury:
  • x86
  • AMD64
  • PowerPC
  • UltraSparc
  • Alpha
  • MIPS
• Pytanie 4: Dystrybucja (tytułuje siebie metadystrybucją) dla (wybrać jedno (góra 2)): bezpiecznego serwera, maszyny developerskiej, profesjonalnego zastosowania biurowego, gier, osadzonych rozwiązań

Wnioski

Jest to system bardzo elastyczny. Pozwala, by system działał optymalnie zarówno przy konfiguracji bardzo precyzyjnej i nastawionej na konkretne zastosowania, oraz jako system utrzymany w stanie "studenckim" (wszystko).

Pozwala utrzymywać zarówno aplikacje w wersji jeszcze "rozwojowej", jak i tylko w wersji "bardzo stabilnej".

By ułatwić konfigurację systemu dostępne są różne profile dla wszystkich architektur, które definiują, które pakiety są zdolne pracować w tej konfiguracji (np. dla x86 istnieją w szczególności profile oparte o jądro systemu 2.4.x jak i jądro 2.6.x)

Zdecydowana większość oprogramowania rozpowszechniana jest w postaci kodów źródłowych, aby umożliwić dokładne dostosowanie oprogramowania do potrzeb (flagi podczas kompilacji). W ten sposób powstaje także dynamiczny system zależności.

Jedyną wadą systemu jest stosunkowo długi czas instalacji pakietów, ze względu na to, że są one w większości kompilowane. Jednak można robić to zbiorczo i bezobsługowo- np. w nocy, co w większości przypadków wystarcza.

Drugą (pomijalnie małą) wadą jest brak instalatora graficznego, który czyni dystrybucję nieosiągalną dla wielu użytkowników - którzy z powodzeniem mogli by z niej korzystać. Trwają nad nim intensywne prace.

System charakteryzują bardzo częste aktualizacje pakietów (około 500 pakietów jest aktualizowanych w ciągu doby). Emerge zawierające najpopularniejsze programy ukazują się niemal równocześnie z wersjami tych programów. Jednocześnie nie istnieje pojęcie "zainstalowania nowszej wersji Gentoo". System jest utrzymywany aktualnym cały czas (wtedy, gdy chce tego użytkownik).

System pakietów

Systemem pakietów jest oczywiście mechanizm Portage. W systemie można dodatkowo zainstalować (zemergować) narzędzia typu RPM, ale jest to zbędne i może doprowadzić do bałaganu w systemie - jednak jest to czasami konieczne (zadanie II).

Załączone programy

Ponad 10000 pakietów w wersjach stabilnych oraz rozwojowych. Prawie wszystko - także programy komercyjne (np. VMware).

Inne uwagi

Powstaje wiele dystrybucji opartych na Gentoo - w tym wiele LiveCD ze względu na stosunkowo prosty mechanizm tworzenia własnego LiveCD opartego na Gentoo.

Debian Trzy słowa o historii Cytuję za wikipedią: Powstanie Debiana ogłosił 16 sierpnia 1993 r. na grupie comp.os.linux.development Ian Murdock, wówczas student uniwersytetu. Napisał on Manifest Debiana, w którym apelował o stworzenie otwartej dystrybucji w duchu Linuksa i GNU. Nazwa "Debian" powstała z połączenia imion Murdocka i jego dziewczyny (obecnie żony) Debry [1] (jest to portmanteau). Dystrybucja ta została zbudowana na podstawie SLS. Wśród założeń Debiana było między innymi to, że będzie zawierał on najbardziej aktualne wersje oprogramowania. Debian powoli rozwijał się i w latach 1994 oraz 1995 - powstały wtedy pierwsze wersje 0.9. Pierwsza wersja 1.x pojawiła się w 1996 roku. Wiosną 1996 roku Bruce Perens zastąpił Iana Murdocka w roli koordynatora projektu. Zainicjował on stworzenie kilku ważnych dokumentów (umowy społecznej wraz z Wytycznymi Dotyczącymi Wolnego Oprogramowania) oraz instytucji prawnej (SPI), a także poprowadził projekt aż do wersji ELF/libc5 (1.1, 1.2, 1.3).

Odpowiadamy na pytania

Jest to:

• Pytanie 1: dystrybucja, która powstała jako manifest wolnego oprogramowania
• Pytanie 2: dystrybucja przeznaczona dla średnio-zaawansowanych użytkowników, którzy radzą sobie z edycją plików konfiguracyjnych.
• Pytanie 3: dystrybucja obsługuje architektury:
  • x86 - podstawowa i najaktywniej rozwijana, dotyczy procesorów x86.
  • Motorola 680x0 - adaptacja dla procesorów Motorola serii 680x0.
  • SPARC - adaptacja dla procesorów SPARC.
  • Alpha - adaptacja dla procesorów Alpha.
  • Motorola/IBM PowerPC - adaptacja dla procesorów PowerPC.
  • ARM - adaptacja dla procesorów ARM.
  • MIPS - adaptacja dla procesorów MIPS.
  • HP PA-RISC - adaptacja dla procesorów Hewlett Packard PA-RISC.
  • IA-64 - adaptacja dla procesorów IA-64.
  • S/390 - adaptacja dla serwerów IBM S/390.
  W trakcie przygotowań do stabilnego wydania wciąż pozostają:
  • AMD64 - adaptacja dla procesorów AMD64.
  • SuperH
• Pytanie 4: dystrybucja przeznaczona głównie na stanowiska robocze dla średno-zaawansowanych użytkowników - programistów

Wnioski

Dość wyważona dystrybucja, obsługująca wiele architektur, początkowo nastawiona na dużą aktualność oprogramowania, ale obecnie wiele osób narzeka na braki aktualizacji.
Pakiety są rozpowszechniane przeważnie w postaci skompilowanej dla konkretnych architektur.

System pakietów

Systemem pakietów debiana są pliki DEB
Obsługują je następujące narzędzia (zarządcy pakietów):

• konsolowe: apt, aptitude, dselect
• graficzne: Synaptic

Podstawowym instalatorem pakietów jest dpkg - instalator niskiego poziomu obsługiwany z linii poleceń, lub jego bardziej zaawansowany odpowiednik - APT, w którym wiele czynności jest zautomatyzowanych (pobieranie pakietów, rozwiązywanie zależności między pakietami). Do wygodniejszego zarządzania pakietami, Debian dysponuje nakładkami na powyższe narzędzia - dselect oraz nowszy - aptitude.

Załączone programy

Twórcy podają, że jest ponad 15490 pakietów oprogramowania dla Debiana.

Inne uwagi

Z dystrybucji wywodzi się wiele innych dystrybucji:

• Corel Linux (obecnie XandrOS)
• Knoppix
• Morphix
• Ubuntu
• MEPIS

Nazwy kolejnych edycji dystrybucji pochodzą od imion postaci z filmu Toy Story:

• buzz - Debian 1.1 - od Buzza Lightyeara - kosmicznego marine,
• rex - Debian 1.2 - od tyranozaura,
• bo - Debian 1.3 - od Bo Peep, pasterki, która opiekowała się owcami;
• hamm - Debian 2.0 - od świnki-skarbonki,
• slink - Debian 2.1 - od zabawkowego, rozciągliwego psa (Slinky Dog),
• potato - Debian 2.2 - od Pana Ziemniaka (Mr. Potato),
• woody - Debian 3.0 - od kowboja,
• sarge - Debian 3.1 - od sierżanta małych, zielonych, plastikowych żołnierzyków;
• etch - od zabawkowej tablicy do rysowania (Etch-a-Sketch),
• sid - od chłopca z sąsiedztwa, który psuł zabawki.

PLD (Polish Linux Distribution) - Polacy nie gęsi

PLD Linux Distribution (skrót rekurencyjny) Trzy słowa o historii za dokumentacją PLD: Wraz ze wzrostem zainteresowania Linuksem w Polsce, rosły naciski na stworzenie polskiej dystrybucji tego systemu. Niemal wszyscy jej chcieli, a niektórzy nawet mówili, że już takową robią. Nic jednak z tego nie wynikało. Wreszcie, w lipcu 1998, zawiązał się projekt mający na celu stworzenie polskiej dystrybucji Linuxa. Projekt PLD, czyli Polish(ed) Linux Distribution, był na tyle dobrze zorganizowany, by przetrwać trudne początki. Nie obeszło się oczywiście bez burzliwych dyskusji na temat kształtu dystrybucji, doboru oprogramowania jak również wersji jądra, na której projekt ma być rozwijany. W efekcie zdecydowano się prowadzić równolegle dwa projekty. Pierwszy został nazwany PLD-devel i był forpocztą dla obecnego PLD-stable. Miała to być pierwsza dystrybucja Linuxa zgodna z nowym, promowanym przez OpenGroup, standardem - Unix98. Równolegle druga grupa pracowała nad podwalinami właściwej PLD-stable. 22 listopada 2002 roku światło dzienne ujrzała pierwsza stabilna wersja dystrybucji PLD Linux Distribution 1.0 (Ra). Jeszcze w czasie jej stabilizacji rozpoczęły się prace nad kolejną wersją. Twórcy projektu zakładali uniwersalność PLD, która pozwalałaby na korzystanie z dystrybucji przez użytkowników z całego świata, jednak pojawiły się obawy, że nazwa Polish(ed) Linux Distribution odstraszy potencjalnych odbiorców z innych krajów. Postanowiono, że zmieniona zostanie nazwa projektu. Pozostawiono charakterystyczny skrót "PLD" w niezmienionej postaci, zmieniono zaś jego rozwinięcie - nazwa "PLD" stała się rekurencyjnym skrótem od PLD Linux Distribution.

Odpowiadamy na pytania

Jest to:

• Pytanie 1: dystrybucja, która powstała jako dystrybucja polskiej i dystrybucja zgodna z standardem Unix98
• Pytanie 2: dystrybucja przeznaczona dla zaawansowanych użytkowników
• Pytanie 3: dystrybucja przeznaczona na x86, PowerPC, sparc(w tym sparc32 jak i sparc64 - programy użytkownika są jednak 32bitowe), Alpha oraz AMD64
• Pytanie 4: dystrybucja przeznaczona głównie na serwery sieciowe

Wnioski

PLD Linux kładzie nacisk na wsparcie nowoczesnych technologii sieciowych (IPv6), bezpieczeństwo (PAM, GSSAPI, TLS/SSL) oraz elastyczne używanie różnych języków naturalnych do komunikacji z użytkownikiem.

System pakietów

PLD wykorzystuje system pakietów RPM. Jest ona przystosowana dodatkowo do łatwego uaktualniania za pomocą narzędzia poldek.

Slackware Trzy słowa o historii Pierwsza do dziś rozwijana dystrybucja, pierwsza wersja w lipcu 1993, wówczas jako obraz dyskietki 3,5 cala. Rozwijana głównie przez 1 człowieka, Patricka Volkerding'a. Obecnie w wersji 10.2, wydanej we wrześniu 2005.

Odpowiadamy na pytania

Jest to:

• Pytanie 1: dystrybucja, która powtała, bo wówczas nie było żadnych innych istniejących dobrych dystrybucji
• Pytanie 2: dystrybucja przeznaczona dla zaawansowanych użytkowników, którzy potrafią zarządzać Linuxem. Głównym założeniem ideologicznym jest zasada KISS, Keep It Simple, Stupid. W tym wypadku simple oznacza prosto dla dewelopera i programisty, nie dla użtkownika.
• Pytanie 3: pierwotnie przeznaczona na x86, obecnie oficjalne porty istnieją na Alphy i Sparc-i, a nieoficjalne na wiele więcej archtektur.
• Pytanie 4: dystrybucja przeznaczona na serwery oraz stanowiska robocze dla zaawansowanych użytkowników - programistów, studentów ;)

Wnioski

W związku z tym ta dystrybucja spełnia:

• bardzo wysoki stopień niezawodności, bezpieczeństwa i efektywności, dzięki założeniu włączania jedynie przetestowanych, starszych, stabilnych i prostych programów i bibliotek, omijanie bajerów i ułatwień dla użytkowników.
• niski stopień przyjazności użytkownika (ale nie bardzo niski) - zasada KISS bardzo ułatwia osiągnięcie poprzednich celów, ale jednocześnie eliminuje wszelkie ułatwienia dla użytkowników. Dystrybucja ta zdecydowanie preferuje narzędzia linii komend nad graficznymi.

System pakietów

Jak już było omówione wcześniej, Slackware nie posiada rozbudowanego systemu pakietów z zależnościami - paczkami są tutaj archiwa .tgz, które ewentualnie mogą zawierać skrypt instalacyjny. Proste narzędzia installpkg, updatepkg i removepkg zapewniają podstawową obsługe paczek; istnieją narzędzia wyższego poziomu, jak np. slapt-get umożliwiające obsługę zależności i automatyczne aktualizacje.

Załączone programy

Dystrybucja ta, stosując zasadę KISS, podchodzi dość minimalistycznie do dostarczonych programów. Programy dzielą się na podstawowe, instalowane zazwyczaj z systemem, oraz dodatki. W wersji najnowszej, tj. 10.2, dla przykładu:

• Oczywiście nie było żadnych okienkowych konfiguratorów (nigdy ich nie było).
• Jądrem podstawowym było 2.4.31 :), zaś w testing było 2.6.13
• Kompilatorem podstawowym było 3.3.6, zaś w testing było 3.4.4
• Środowiskiem graficznym do pracy było KDE (jest to dystrybucja też przeznaczona na stacje robocze)

W powyższych przykładach "numerkowych" widać, że Slackware nastawione jest na starsze, stabilne wersje programów.

Inne uwagi

• Z Slackware'a wywodzi się wiele dystrybucji, jak np. SuSe, SLAX, VectorLinux.
• Strona: www.slackware.com

Knoppix i pochodne

Knoppix Trzy słowa o historii Knoppix to dystrybucja utworzona na bazie Debiana przez niemieckiego inżyniera Klausa Knoppera, który chciał mieć dystrybucję na płycie CD, która będzie działała na większości komputerów - bez konfiguracji. Obecnie istnieje wersja 4.1 dystrybucji na płycie CD (zawierająca 2GB oprogramowania) oraz na płycie DVD (9 GB oprogramowania)

Odpowiadamy na pytania

Jest to:

• Pytanie 1: dystrybucja, która powtała by być możliwie użyteczną dystrybucją Live-CD
• Pytanie 2: dystrybucja przeznaczona dla zaawansowanych i początkujących użytkowników (nie istnieje problem zmian w systemie, bo nie są one utrwalane)
• Pytanie 3: przeznaczona dla architektur x86 i amd64 ze stacją CD, DVD lub gniazdem pen-driva. Może zostać także zainstalowana na dysku.
• Pytanie 4: dystrybucja "osobista", umożliwia natychmiastowe zorganizowanie stacji roboczej z prawie każdego komputera (np. do celów naprawczych). )

Wnioski

• Potrzebny skompresowany system plików, by utrzymać 2GB na 700MB
• Dużo sterowników i system automatycznego wykrywania i konfiguracji urządzeń przy starcie systemu
• UnionFS - jako wirtualny - utrzymywany w pamięci RAM system plików
• Oprogramowania naprawcze, biurowe, narzędzia sieciowe

System pakietów

Nie potrzebny - bo nie instalujemy oprogramowania.

Załączone programy m.in:

• Open Office - Program dla biura w polskiej wersji językowej. Pakiet OpenOffice.org jest kompletnym zestawem narzędzi biurowych.
• Gimp - Program graficzny, linuksowy photoshop.
• Qcad - Jest systemem do projektowania w 2D. Za pomocą Qcad stworzymy rysunki techniczne, plany budowlane, a także części mechaniczne.
• Blender - Program do tworzenia grafiki 3D. Jest zaawansowanym i darmowym edytorem do tworzenia grafiki w trzech wymiarach (3D).
• Quanta Plus - Edytor do tworzenia stron www zgodny ze środowiskiem KDE.
• Kadu - Linuksowa wersja klienta rozmów Gadu-Gadu. Kadu powstało w sierpniu 2001 roku, jako mała wprawka do programowania w KDE. Z czasem program przekształcił się w jeden z najpopularniejszych klientów Gadu-Gadu dla Linuksa.
• Mozilla - Firebird, przeglądarka internetowa.
• Evolution - Organizer i klient pocztowy. Wyróżnia się ciekawym interfejsem i mnogością zintegrowanego oprogramowania do pracy grupowej. W skład wchodzi kalendarz, klient email, menedżer adresów i lista zadań do wykonania.

Inne uwagi

Z Knoppixa wywodzi się wiele innych dystrybucji Live-CD:
• Quantian - jest naukową odmianą Knoppiksa. Zawiera ponad 500 MB oprogramowania naukowego, w tym Scilab, OpenDX czy język obliczeń statystycznych R. W najnowszej wersji Quantian poszerzył się o obsługę protokołu comedi, służącego do współpracy ze sprzętem pomiarowym, system informacji geograficznej GRASS, LyX itd. Ma możliwość pracy w klastrach - co jest niezwykle korzystne przy złożonych obliczeniach matematycznych.
• Mepis - Twórcy MEPIS-a stawiają na prostotę użytkowania
• Monoppix- celem jest upowszechnianie technologii Mono (.NET w wersji GNU)
• Morphix

Linuxy komercyjne, na przykładzie Red Hat Enterprise Linux

Trzy słowa o historii

RedHat jest jedną z najstarszych i bardzo zasłużonych firm w branży Linuxów. Dawniejsza, otwarta i darmowa, dystrybucja Red Hat, miała opcją "komercyjną", dającą możliwość wsparcia technicznego i dostosowania do potrzeb odbiorcy. W roku 2003 firma RedHat zmieniła strategię, tworząc dystrybucję Fedora Core (omówioną wcześniej), otwartą i tworzoną przez społeczność, oraz komercyjną Red Hat Enterprise Linux.

Odpowiadamy na pytania

• Pytanie 1: Chcemy zarobić, sprzedając dystrybucję Linuxową firmom.
• Pytanie 2: Dla odbiorców biznesowych, mniejszych i większych firm.
• Pytanie 3: Im więcej tym lepiej, serwery powinny obsługiwać większe maszyny, stacje robocze niekoniecznie.
• Pytanie 4: Odbiorcom - przedsiębiorcom zależy zarówno na serwerach, większych i mniejszych, jak i na dobrych stacjach roboczych.

Typy RHEL i ich krótkie omówienie

Trudno dalej mówić o RHEL bez opowiedzenia, że występuje on w czterech edycjach:

aspekt	AS duże serwery	ES mniejsze serwery	WS większe stacje robocze	Desktop mniejsze stacje robocze
przeznaczenie	duże serwery o krytycznym znaczeniu (24x7), wielkie bazy danych	mniejsze serwery: WWW, FTP, CUPS, serwer plików	obliczenia, stacja robocza dla zaawansowanych użytkowników	biurkowa i programisty
architektury	wiele: x86, Itanium, różne IBMa itd.	x86, Itanium	x86, Itanium	x86 (bez SMP)

Więc, standardowo, rozwiązania przeznaczone dla serwerów są bezpieczne, wydajne, ale niekoniecznie user-friendly. Dystrybucja WS również stawia nacisk bardziej na wydajność niż przyjazność; dystrybucja Desktop jest typową dystrybucją biurkową.

Ponadto RedHat oferuje, do zakupionych dystrybucji, pakiety pomocowe:

• obsługa techniczna, w trybach 24x7 i 12x5
• aktualizacje z Red Hat Network
• serwis w przypadku awarii
• pomoc w instalacji i uruchomieniu

Ponadto RedHat wypuszcza specjalną, po niskiej cenie, wersję Academic swojego RHEL, w wydaniach Server i Desktop.

Różne specjalistyczne Linuxy

Dystrybucja	Opis
ClusterKnoppix	Klaster od zaraz- bootujesz jeden komputer z płyty. Pozostałe z sieci... i masz działający klaster. Wykorzystuje OpenMotif
Quantian	Quantian jest naukową odmianą Knoppiksa. Zawiera ponad 500 MB oprogramowania naukowego, w tym Scilab, OpenDX czy język obliczeń statystycznych R. W najnowszej wersji Quantian poszerzył się o obsługę protokołu comedi, służącego do współpracy ze sprzętem pomiarowym, system informacji geograficznej GRASS, LyX itd. Ma możliwość pracy w klastrach - co jest niezwykle korzystne przy złożonych obliczeniach matematycznych.
Freesco	Freesco jest dystrybucją Linuksa stworzoną jako darmowa alternatywa dla drogich sprzętowych routerów Cisco (nazwa: freesco = free + cisco). Bootuje się z jednej dyskietki.
Jusix	Jusix to niewielka polska dystrybucja Linuksa uruchamiana z płyty CD. Dystrybucja ukierunkowana na odtwarzanie multimediów. Pliki wideo - avi, mpeg, divx, oraz muzyka - odtwarzanie plików mp3.
Kamix	Kamix to polska minidystrybucja Linuksa mieszcząca się w całości na jednej dyskietce. Zawiera moduły do najpopularniejszych kart sieciowych oraz programy klienckie SSH, Telnet i FTP. Dostępny jest również program ułatwiający skonfigurowanie urządzeń i zapisanie ustawień. Posiada również prosty edytor tekstowy E3 i odtwarzacz płyt AudioCD.
NNW - Nasza Nowa Dystrybucji (druga nazwa: Niestety Nie Działa)	Gotowy router do neostrady i SDI. Zawiera prosty serwer WWW i SSH oraz zaporę sieciową. Obsługuje modemy USB.
Linux-EduCD	Knoppix edukacyjny na potrzeby polskiego szkolnictwa

I wiele wiele innych.

---



Bibliografia

• Definicja dystrybucji Linuxa na Wikipedii i pokrewne strony
• Opis Linux From Scratch i strona Linux From Scratch
• Porównanie dystrybucji na Wikipedii
• Linux Distribution Chooser
• Opisy różnych dystrybucji na Wikipedii
• Strona RedHat
• Binarnie, czy ze źródeł
• The Portable Application Standards Committee
• Single Unix Specification
• Standard Linux Base
• Linux Standard Base (http://www.linuxbase.org)
• Free Standards Group (http://www.freestandards.org)
• Certyfikacja LSB (https://www.opengroup.org/lsb/cert)
• www.userfriendly.pl (komiksy)