Jednak podobnie jak POSIX z podobnych względów standard ten nie może zapobiec fragmentacji dystrybucji linuxowych.
Ostatnimi laty Linux przeżywa burzliwy rozwój na rynku systemów operacyjnych. Nowoczesne dystrybucje coraz bardziej dorównują możliwościami konkurencji (w szczególności produktom firmy Microsoft). Wydawałoby się, że rozwojowi Linuksa nic nie przeszkadza - jest przecież darmowy, każdy może go rozszerzać; doskonale sprawdza się w rozwiązaniach serwerowych. Zagrożenie, które czyha na dystrybucje Linuxowe, jest w zasadzie tym samym, co doprowadziło do poważnego kryzysu systemy UNIXowe na przełomie lat 80. i 90. i utorowało drogę do sukcesu dla systemu Windows NT. Problemem tym jest brak jednolitego standardu. W przypadku UNIXa problemem była rosnąca niezgodność wersji tego systemu wydawanych przez różnych dostawców. Doprowadziło to do fragmentacji rynku. Użytkownicy skupieni byli wokół pojedyńczych producentów, brak było przenośności kodu. W efekcie systemy UNIXowe traciły na znaczeniu. Czy to samo może grozić dystrybucjom ?
Analizując dzisiejsze dystrybucje również można dostrzec rosnące rozwarstwienie. Mamy kilka istotnie różnych sposobów zarządzania pakietami. Instalowanie z pakietów binarnych oprogramowania często dostarcza frustracji użytkownikom, bo często jest nieskuteczne. Dystrybucje w różny sposób organizują hierarchię katalogów, zarządzanie systemem i inne ważne aspekty. Taki stan rzeczy stanowi barierę dla zdobywania rynku przez system Linux. Brak unifikacji powoduje, że Linux przestanie być rozpoznawany jako jedna platforma, a jako zbiór kilku(nastu) różnych jego realizacji. Nie służy to dobru użytkowników, jak i wytwórców oprogramowania.
POSIX to w skrót od Portable Operating System Interface. Jest to standard odnoszący się ogólnie do systemów operacyjnych. Ostatnia litera "X" symbolizuje wpływ Unixa w powstanie tego standardu. Wiele istotnych elementów specyfikacji tej normy ma swoje źródło w tym właśnie systemie. Nie oznacza to jednak, że standard ten spełniają tylko Unixy. POSIX standaryzuje różne systemy operacyjne, różnych producentów często istotnie od siebie różnych.
POSIX to tak naprawdę nazwa, za którą kryje się zbiór standardów definiujących interfejsy programisty i użytkownika udostępniane przez system operacyjny. Dostęp do tych interfejsów uzyskiwany jest przy pomocy:
Celem stworzenia tego standardu było umożliwienie pisania przenośnego kodu aplikacji, który miał w założeniu działać na wszystkich zgodnych z tym standardem systemach. Związane było to z rozłamem jaki nastąpił wśród producentów systemów Unixowych. Standard ten miał przywrócić popularność rozwiązaniom opartym o system Unix, które traciły rynek na rzecz systemu Windows NT.
Podstawową cechą standardu jest wsparcie dla programowania aplikacji przenośnych. Dzięki definicji tego, co nazywamy UNIXem, teoretycznie, przenośny kod napisany dla UNIXa powinien się kompilować niezależnie od platformy na jakiej zainstalowany mamy system, jak i producenta dostarczającego system operacyjny. Przenośny oznacza tu zgodny ze standardem POSIX, i używający standardowych narzędzi zdefiniowany przez tą normę. Jest to istotne ograniczenie.
POSIX definiuje interfejs, a nie implementację. Oznacza to np. że nie rozróżnia się tu wywołań funkcji bibliotecznych od wywołań funkcji systemowych. Obydwie rzeczy nazywamy tu po prostu funkcjami. Jest tak dlatego, że standard nie narzuca jak ma to być zrobione w systemie, tylko co system zgodny z tą normą ma udostępniać.
Standard nie gwarantuje, że program skompilowany w systemie X zgodnym z POSIX będzie można uruchomić w systemie Y również zgodnym z POSIX. Nawet jeśli będą to dwa systemy na tej samej platformie systemowej. To co zapewnia nam ten standard to jedynie możliwość uruchomienia na systemie Y programu skompilowanego w systemie Y. Oczywiście kod źródłowy programu też musi uwzględniać ograniczenia narzucane przez ten standard.
Interfejs systemowy i pliki nagłówkowe udostępniane w systemie zgodnym z POSIX są zgodne ze standardem ISO C.
Standard POSIX stworzony nie definiuje systemu operacyjnego jako całości. Ze specyfikacji wyłączone są narzędzia umożliwiające administrację systemem operacyjnym. Standard również nie wnika w zagadnienia sprzętowe i utrzymanie systemu.
Zgodnie z historycznym duchem UNIXa, wymagania stawiane systemom przez ten standard zostały tak skonstruowane, by ich ilość była minimalna. Sporo dodatkowych cech zostało sformułowanych jako wymagania opcjonalne.
Twórcom standardu POSIX zależało, by można było go zastosować w możliwie dużej liczbie systemów operacyjnych w szczególności wywodzących się z rodziny UNIX, lecz nie tylko. Do standardu należą również inne systemy, które nie wywodzą się z rodziny UNIX np. Windows NT (razem z Cygwinem) Zgodne z POSIX są też emulatory systemów, które zostały napisane pod inny niekoniecznie zgodny z POSIXem system. Systemy sieciowe i rozproszone również są w stanie spełnić tę normę.
System operacyjny Linux (jądro) zostało zaprojektowane przez Linusa Torvaldsa tak, by jak najbardziej było zbliżone do standardu POSIX.1. Początkowo autor jądra nie posiadał specyfikacji POSIX, a jego decyzje projektowe były podejmowane na podstawie domysłów. Źródłem informacji o standardzie, z którego korzystał Linus były początkowo strony podręczników systemowych (manuali) z innych zgodnych z POSIXem systemów. Formalnie, po dzień dzisiejszy nikt nie jest w stanie stwierdzić, czy Linux jest w 100% zgodny z powyższym standardem. Pytania użytkowników grup dyskusyjnych na ten temat ucinane są odpowiedziami w stylu: jeśli znajdziesz coś co jest niezgodne ze standardem POSIX w Linuxie to daj nam znać. Nie mniej jednak Linux uznawany jest dzisiaj za system, który jest jednym z najbardziej zgodnych z tą normą.
Dystrybucje jako całość dostarczając standardowych narzędzi GNU korzystających z linii poleceń również spełniają większość założeń standardu POSIX.2. Są jednak nadal różnice (narzędzia: split, du, df). Były w przeszłości pewne zawirowania wokół zgodności z POSIX.2 biblioteki glibc, jednak ogólnie można przyznać, że Linux jest jednym z systemów które świetnie realizuje specyfikacje sformułowane w normie. Powstaje jednak inne pytanie:
Linux nie jest w pełni zgodny z normą POSIX.1b, bo nie jest systemem czasu rzeczywistego, choć zapewnia część interfejsu.
Linux posiada częściową implementację wątków (pthreads - POSIX threads) nazywaną LinuxThreads, czyli częściowo spełnia standard POSIX.1c Istnieje kilka różnic semantycznych. Pewnym rozwiązaniem jest biblioteka Next POSIX Threading Library, która jest prawie w pełni zgodna z powyższym standardem. Zastąpiła ona LinuxThreads w jądrach 2.6. Oznacza to, że najnowsze jądra są już prawie zgodne ze standardem POSIX.1c.
Niestety jest to niezbyt wiele w porównaniu do tego czego można by od przyzwoitego standardu oczekiwać. Ponieważ POSIX dotyczy w zasadzie jedynie interfejsu jakim dysponuje programista w danym systemie, to dla dystrybucji oznacza to w zasadzie tylko tyle, że przenośny kod powinien się skompilować pod zgodną ze standardem dystrybucją. Może to być dobra wiadomość jedynie dla dystrybucji źródłowych, instalujących oprogramowanie przez kompilację kodu źródłowego.
Standard nie zapewnia w żadnym stopniu przenośności pakietów binarnych i kodu binarnego pomiędzy dystrybucjami. Powoduje to, że każda dystrybucja traktowana jest jako autonomiczny system operacyjny (inny UNIX), a zgodność dystrybucji ogranicza się do możliwości kompilowania odpowiednio napisanego kodu. Ograniczanie zgodności dystrybucji do tego standardu nie zapobiega rozwarstwieniu, które może powstać jego brak. POSIX jest dobrym standardem dla różnych rodzajów systemów operacyjnych (istotnie różnych), a nie do pewnych modyfikacji tego samego systemu. Potrzeba czegoś, co w większym stopniu dospecyfikuje elementy naszego systemu.
POSIX jest standardem komercyjnym, co oznacza że dostęp do niego jest ograniczony, a także certyfikacja systemu jako zgodnego z POSIX słono kosztuje. W przypadku dystrybucji Linuksa oznacza to że fundusze na autoryzacje wydawać trzeba by było dość często. Spowodowane jest to częstymi aktualizacjami dystrybucji. Na dzień dzisiejszy normą jest, że nowa wersja dystrybucji pojawia się co 3 miesiące. Zresztą wiele dystrybucji Linuxowych tworzonych jest hobbystycznie, więc droga do uzyskania ceryfikatu zgodności z normą POSIX jest raczej zamknięta.
Single UNIX Specification to zbiór otwartych uzgodnionych specyfikacji, które definiują to co nazywamy systemem operacyjnym UNIX. Wywodzi się on ze standardu POSIX - jest jego nadzbiorem. Główną różnicą pomiędzy tymi dwoma standardami polega na tym, że POSIX jest standardem zamkniętym. By mieć dostęp do specyfikacji i certyfikować system jako zgodny z POSIXem należy mieć sporo gotówki. Single UNIX Specification różni się tym, że jest otwartym standardem, z którym zaznajomić może się każdy. Jest to rozwiązanie wybierane ze względu na mniejsze koszta uzystkania certyfikatu zgodności.
Opiekę nad Single UNIX Specification sprawuje The Open Group. Posiada ona prawa do nazwy UNIX.
W zależności od wersji normy, którą spełnia system operacyjny może on być:
Jeśli spełnia standard Single Unix Specification w wersji 2. Standard ten rozszerza standardy POSIX (POSIX.1, POSIX1.b, POSIX1.c, POSIX.2) dodając swoje własne interfejsy do wymagań. Są trzy warianty standardu Unix 98.
Wariant bazowy (Unix 98 base) składa się ze specyfikacji tego właśnie interfejsu.
Unix 98 Workstation dodaje jeszcze wsparcie dla Common Desktop Environment - komercyjnego zarządcy okien. W standardzie tym zakłada się, że korzysta się z komercyjnej biblioteki graficznej Motif.
Unix 98 Server musi dodatkowo (oprócz tego co Unix 98 Base) uwzględniać wsparcie dla Javy, interfejs dla protokołu TCP/IP, SNMP (Simple Networking Management Protocol), protokół HTTP, DNS, telnetu, FTP, NFS, POP3, SMTP i wielu innych.
Kolejna wersja standardu została opracowana przez Open Group na podstawie zmian, które dokonały się w standardach, na których Single Unix Specification bazuje. Dotyczy to w szczególności nowej wersji standardu POSIX IEEE 1003.1-2001 oraz wersji 1999 standardu ISO C. Dokument ma inną strukturę (składa się z 4 części), oraz informacje o sprawdzonych rozwianiach w praktyce. Standard został napisany tak, by minimalnym wysiłkiem system zgodny z Unix 98 mógł przejść testy na zgodność z Unix 03.
Dystrybucje linuxowe, nie są w pełni zgodne z Single Unix Specification w wersji 2 i w wersji 3 (choć są częściowo). Single Unix Specification spełnia podobną rolę dla Linuksa, co standard POSIX. Definiuje API oraz narzędzia, które ma dostarczać system operacyjny. Single Unix Specification dominuje nad POSIXem wielkością wymaganego interfejsu.
Jednak podobnie jak POSIX z podobnych względów standard ten nie może zapobiec fragmentacji dystrybucji linuxowych.
Jest to standard stworzony przez Free Standards Group organizacji non-profit, której celem jest tworzenie otwartych standardów przeznaczonych głównie dla programów open-source. Standard ten, tak jak wszystkie standardy wydawane przez Free Standards Group jest wydany na licencji GNU dla dokumentacji Testy, których zaliczenie jest wymagane uzyskania certyfikatu zgodności, są udostępnione za darmo (na licencji open source).
Linux Standard Base jest projektem standaryzacyjnym, którego celem jest ujednolicenie dystrybucji Linuksa.
Jak wiadomo, dystrybucje Linuksa różnych dostawców działają w istotnie różny sposób. W szczególności różny jest sposób zarządzania pakietami z oprogramowaniem. Jest kilka formatów pakietów np. RPM, DEB, TGZ. Nawet korzystanie z tego samego formatu pakietów nie gwarantuje tego, że pakiet binarny (a nawet czasem źródłowy) zainstaluje się bez problemów na innej niż macierzystej dystrybucji. Stwarza to bardzo duże problemy użytkownikom tych systemów, w których chcą zainstalować oprogramowanie nie dostarczane standardowo z dystrybucją. Często pakiety udostępniane na stronach internetowych projektów (dotyczy to najbardziej pakietów RPM) nie zainstalują się w systemie użytkownika. Użytkownik wówczas musi albo szukać dalej wierząc, że ktoś wygenerował i udostępnił pakiet kompatybilny z jego dystrybucją, albo nauczyć się kompilować program ze źródeł (co dla przeciętnego użytkownika nie jest rozwiązaniem). Ewentualnie może czekać na nowe wydanie swojej ulubionej dystrybucji wierząc, że włączy ona poszukiwany program do swoich pakietów.
Dość znacznie zarysowane różnice w budowie dystrybucji dostarcza też wielu kłopotów twórcom oprogramowania. W szczególności dotyczy to tych, którzy nie godzą się na publikowanie kodu źródłowego. Muszą oni, by ich produkt był szeroko dostępny w systemach opartych na jądrze Linuksa, przygotowywać oddzielne wydania swoich programów dla poszczególnych dystrybucji. Kosztuje to wiele wysiłku; w szczególności testowanie staje się bardziej uciążliwe. Jest to też powód, dla którego wielu producentów komercyjnych programów nie weszło jeszcze na rynek Linuksa.
Linux Standard Base ma na celu utworzenie zunifikowanej warstwy udostępnianej przez każdą zgodną z tą normą dystrybucją. Aplikacje korzystające z tej warstwy (również w postaci binarnej) byłyby całkowicie przenośne pomiędzy dystrybucjami.
Linux Standard Base składa się ze specyfikacji dostępnej za darmo na stronie projektu, przykładowej implementacji dystrybucji oraz testów sprawdzających zgodność dystrybucji ze standardem.
Tym, co najbardziej wyróżnia LSB od dwóch poprzednich standardów jest skupienie się na przenośności binariów pomiędzy dystrybucjami, a nie kodu źródłowego. LSB specyfikuje jak ma wyglądać plik binarny by był przenośny. Nie ma różnicy, na której ze zgodnych z LSB dystrybucji zainstalujemy nasz pakiet. Standard gwarantuje, że odpowiednio przygotowane oprogramowanie zainstaluje się na wszystkich wspierających standard dystrybucjach.
Specyfikacja LSB obejmuje bardzo wiele aspektów dystrybucji:
Jest on w dużej mierze oparty na standardzie POSIX i w zamierzeniu ma być z nim zgodny. Od LSB 2.0 wspiera on też język C++.
Użyty jest format plików ELF. Od wersji 2.0 wspierany jest też format binarny dla programów napisanych w C++.
Stosowany jest tu standard FHS (Filesystem Hierarchy Standard). Oprócz tego wyspecyfikowane są położenia pewnych plików konfiguracyjnych w systemie.
Najnowsza wersja standardu LSB obejmuje również biblioteki graficzne, między innymi libX11. Niestety jest to biblioteka dość niskopoziomowa. W standardzie nie ma jeszcze zdefiniowanych bibliotek dla najczęściej używanych środowisk graficznych (GTK/QT), choć jest to w dalszych planach rozwoju tego standardu.
Jedną z zalet opisu plików binarnych jest fakt, że programy korzystające z dodatkowych bibliotek nie objętych standardem mogą stać się przenośne w sensie LSB. Wystarczy, że te dodatkowe biblioteki zlinkujemy statycznie do naszego kodu wynikowego. Jedyną wadą tego rozwiązania jest większe zużycie pamięci operacyjnej i dyskowej. Było to sporym problemem kilka lat temu, kiedy standard LSB w wersjach 1.x opisywał naprawdę tylko niezbędne biblioteki (i brak było wsparcia dla C++).
Doświadczenie pokazuje, że zgodność specyfikacji dystrybucji z LSB gwarantuje przenośność oprogramowania, poza pewnymi szczególnymi przypadkami. Można zatem powiedzieć, że LSB dotychczas z powodzeniem udaje się utrzymać rozwój dystrybucji w ryzach swojego standardu. Świadczy też o tym fakt, że coraz więcej dużych firm z branży informatycznej wchodzi w skład organizacji FSG (Free Standards Group), by mieć wpływ na rozwój tego standardu.
Założenia, jakie stawia sobie zespół FSG zajmujący się standardem LSB to przede wszystkim:
Debian, Fedora Core, Aurox, SUSE, Ubuntu.