Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

GNU/Linux - obalanie mitów: Kompatybilność wsteczna

Po pierwsze, co to jest mit?

Słownik pwn podaje 3 definicje, ja podam tylko tą która odnosi się do tego wpisu a mianowicie:

«fałszywe mniemanie o kimś lub o czymś uznawane bez dowodu»

Rozważmy w takim razie pewne stwierdzenie i rozważmy czy tak rzeczywiście jest i ewentualnie jak jest to rozwiązane w systemie Windows


co do kompatybilności wstecznej to też bzdury piszesz, popatrz na linuksy choćby takie ubuntu paczka z 904 nie odpali na 10,04 czy 10.10 a dzieli je tylko 12 m-cy, a praktycznie wszystko co pisane było pod XP śmiga i na Viście i 7-ce, wiadomo że są jakieś tam problemy ale to drobnica (sokoleokopr)

r   e   k   l   a   m   a

A więc jak jest naprawdę?

Systemy *nixowe używają najczęściej współdzielonych bibliotek budowanych pod konkretną dystrybucję w celu zminimalizowania zużycia pamięci i ułatwionej aktualizacji tychże bibliotek/programów.

Co to oznacza?

Oznacza to że wiele programów korzysta z jednej konkretnej wersji biblioteki efektywnie współdzieląc zasoby (pamięć).

Jakie są z tego korzyści/niekorzyści?

1.Programy zużywają mniej pamięci poprzez współdzielenie jednej biblioteki tzn. system ładuje TYLKO tą bibliotekę z której korzysta WIELE programów.

2.Ewentualna aktualizacja czy to bezpieczeństwa czy naprawiająca błędy jest ułatwiona gdyż tylko ta biblioteka musi być zaktualizowana przez co wszystkie programy korzystające z tej biblioteki są z powrotem bezpieczne/naprawione.

3.Ładowany program nie jest przenośny. Oznacza to że przenosząc program rozruchowy nie mamy pewności że zadziała na innej dystrybucji linuksowej.

4.Dłuższe włączanie programu. Ponieważ przy zimnym starcie program/system musi się upewnić że współdzielone biblioteki istnieją/posiadają wymagane funkcje(proces ten można zminimalizować do minimum za pomocą programu prelink jak i preload).

Czy da się to zrobić inaczej ?

Jak najbardziej!! Programy mogą być kompilowane statycznie (wszystkie zależności znajdują się w pliku rozruchowym) lub wszystkie zależności znajdują się np. w folderze instalacyjnym programu, tracimy korzyści numer 1 i 2 ale zyskujemy przenośność tego programu kosztem zwiekszonego zużycia pamięci i ewentualnych problemów z bezpieczeństwem.

Przykłady:

Przeglądarka internetowa Firefox 4:

Jeden plik ściągnięty ze strony portablelinuxapps.org
*Statycznie zbudowany

Drugi ściągnięty ze strony Mozilli (4.0 b12)
*w większości dynamicznie zbudowany

Porównajmy ich zależności:


Jak widzimy wersja statyczna jest zależna od podstawowych bibliotek występujących w każdej dystrybucji bez wyjątku podczas gdy dynamiczna wersja jest zależna od tylu bibliotek dynamicznie współdzielonych że nie starczy mi monitora na wyświetlenie wszystkiego:)

Porównajmy ich wielkość:


Tutaj znowu widzimy różnicę wielkości wersji statycznej od dynamicznej. Także jak widzimy różnica wielkości jest kolosalna!Oczywiście program dostarczany spoza repozytoriów może nieść ze sobą wszystkie potrzebne zależności i np. program rozruchowy będzie malutki podczas gdy i tak będzie ładował biblioteki "wewnętrzne" w efekcie zwiększając ogólne zużycie pamięci jak.

Drugi przykład:

Jeden plik zbudowany statycznie drugi dynamicznie, ponownie widzimy różnicę zalezności jak i wielkości.

Jak wyglada sytuacja w innych systemach?

Sytuacja jest bardzo podobna. Oprogramowanie może być kompilowane względem bibliotek systemowych lub dostarczane wraz z wymaganymi bibliotekami. Poczynając od wersji Me Microsoft wprowadził folder WinSxs pozwalający na różne wersje tych samych bibliotek aby zapewnić kompatybilność programom, jest to rozwiązanie tzw. piekła dll-ek (również istniało w linuxie, rozwiązane dzięki menadżerom oprogramowania i kompilacji względem bibliotek systemowych lub bibliotekom w folderze programu). Sytuacja pogarsza się gdy musimy dostarczyć oprogramowanie względem bibliotek które nie są dostarczane wraz z systemem aczkolwiek problem ten istnieje i w przypadku GNU/Linux

W takim razie czy sytuacja w Linuxie jest gorsza czy lepsza?

Sytuacja jest trochę lepsza dzięki temu że większość dostarczanego oprogramowania jest otwarta i jest kompilowana względem bibliotek systemowych lub bibliotek dostarczanych za pomocą repozytoriów. Dodatkowo biorąc np. dodatkowe repozytoria z oprogramowaniem (Ubuntu/PPA itp.) programy i tak są w większości kompilowane względem bibliotek systemowych. Sytuację jeszcze bardziej ułatwia LSB czyli Linux Standard Base, certyfikat gwarantujący kompatybilność dla producentów oprogramowania poprzez:

*dodawanie funkcji do bibliotek i usuwanie dopiero po oznaczeniu danej funkcji jako przestarzałej w którym przypadku producent oprogramowania ma około 6 lat na zaktualizowanie aplikacji do nowej funkcji/standardu. Dzięki czemu mamy przewidywalny zestaw funkcji/bibliotek które są dzięki temu wstecznie kompatybilne i nie musimy się bać że program zależy od biblioteki w werji 1.1 a mamy 1.2 gdyż ta biblioteka zawiera wszystko co wersja 1.1 i ewentualnie inne funkcje
*ustalenie pewnych podstawowych bibliotek i funkcji w które producent oprogramowania może sie "wstrzelić"

W takim razie dlaczego użytkownicy tak narzekają na kompatybilność?

Głównie przez brak zrozumienia *nixowej filozofii współdzielonych bibliotek. Dlatego dziwią się że np. przeglądarka opera ma tyle wersji do wyboru (multum dystrybucji i wersji) a nie tylko jedną. Drugim powodem są aktualne dynamiczne zmiany zachodzące w GNU/Linux (podsystem dźwięku - totalny bałagan aczkolwiek pulseaudio staję się coraz bardziej niezawodne), podsystem graficzny miał swoje bolączki przez kompletne przepisanie pewnych części.

Podsumowanie:

W takim razie czy możemy jednoznacznie stwierdzić o obaleniu mitu braku kompatybilności? Według mnie zdecydowanie tak
 

Komentarze