Co jest złego w linkowaniu statycznym ? Pod Windows masa programów tego używa i jakoś sobie radzi. W najgorszym przypadku z grą czy aplikacją dostarczane są odpowiednie DLLki, czasami mające w sumie po kilkanaście MB. Dyski naprawde są bardzo tanie – 500GB to koszt ~250zł. Ludzie instalują masę gier i jakoś na nikim nie robi wrażenia 8GB potwór.

Problemem jest masa śmiecia dostarczanego z różnymi dystrybucjami – 10 terminali, 5 kalkulatorów, 20 edytorów tekstu i wiele innych. Gdyby wprowadzić zestaw Jedynie Słusznych (TM) narzędzi (co najwyżej dwa z każdej grupy), to myślę że chodziło by to lepiej. Pod Windowsem jest prosty notatnik i bardziej zaawansowany wordpad – obydwa spełniają swoje zadanie. Pod dowolnym unixem za to mamy emacs, vi, vim, nano, pico, ee, gedit, kwrite i dziesiątki innych, których po instalacji zwykły użytkownik nigdy nie włączy – poza jednym edytorem z danego środowiska graficznego. Czemu nie może być grupy najbardziej potrzebnych narzędzi, a jeśli użytkownik chce to sobie dorzuci inne ? Chcę posłuchać mp3 to instaluję WinAMPa, za to pod linuxem muszę mieć do wyboru 100 różnych odtwarzaczy, które nie mają połowy funkcjonalności winampa. Gdyby dostarczać tylko najpotrzebniejsze aplikacje, nie było by problemem dostarczanie odpowiednich zależności z aplikacjami tworzonymi przez osoby trzecie.

Problem różnych katalogów rozwiązałoby IMO API, które mówi, jak się nazywa standardowy katalog dla danego użytkownika. Np. pod Windowsem mogę sobie pobrać ścieżkę do katalogu Moje Dokumenty czy gdzie w katalogu użytkownika mają być umieszczane prywatne dane aplikacji.

Rozwiazanie od dawna istnieje i sam czesto z niego korzystam. Powiem krotko: alien (http://kitenet.net/~joey/code/alien/)
Niestety, tak jak pisali przedmowcy problem tkwi w balaganie jaki powstal w strukturach katalogow. Na nic sie zdalo FHS (http://www.pathname.com/fhs/) skoro i tak wszyscy (poza debianem) maja go w dupie…

Po przeczytaniu wszystkich wypowiedzi postanowiłem wtrącić swoje 3 grosze (a może nieco więcej).

Uważam, że Linuksowi jest potrzebna pewna standaryzacja. Powody chyba znane. Natomiast moim zdaniem nie ma co wymuszać takiego a takiego typu paczki. Jak napisał Artwi, przygotowanie kilku paczek to kwestia jednego skryptu (w ostateczności można użyć programu alien) zaś ożywiona dyskusja w tym temacie nad wyższością DEB nad RPM i odwrotnie jasno dowodzi, że raczej nikt z typem paczki nie ustąpi. Poziom kompatybilności powinien być więc niżej – w zawartości paczki. Niech każda dystrybucja ma własny typ paczki, ale trzyma się pewnych standardów na niższym szczeblu. Jednak z racji tego, że rozmieszczenie plików nie jest jednakowe (np. wspomniane plug-iny do Firefoxa), dla mnie idealną sytuacją byłoby, gdyby twórca paczki z programem dał do niej opis gdzie jaki plik ma iść (np. libabc -> biblioteki (np. /lib), libqwerty -> biblioteki lokalne (np. /usr/local/lib) itd.). W ten sposób jeśli tylko system przez jakiś plik konfiguracyjny/zmienne środowiskowe lub w inny sposób dostarczy stosowne informacje o specyficznej dla siebie hierarchii plików, będzie wiadomo co gdzie szukać i pewien poziom kompatybilności będzie zachowany. Opcjonalnie brak takowych informacji mógłby świadczyć o strukturze zalecanej np. przez LSB co skutkowałoby instalowaniem w domyślne katalogi.

Jeśli problemem dla dostawców oprogramowania byłoby istnienie 25 rodzajów paczek, zawsze istnieje możliwość zrobienia archiwum tar.gz/tar.bz2 z odpowiednią zawartością.

To odnośnie paczek i rozłożenia plików.

Kwestia różnych wersji programów i bibliotek w różnych dystrybucjach też jest dla mnie do rozwiązania pod warunkiem pewnej zgodności ABI wszystkich programów danej wersji standardu. Pod tym hasłem rozumiem coś podobnego do LSB (albo i samo LSB – nie zagłębiałem się w jego specyfikację) co definiowałoby, że np. wersja 1.3 oznacza system, który ma Glibc w wersji min. 2.7, kernela w wersji min. 2.6.26, X.org w wersji min. 7.2 itd. Taka specyfikacja byłaby w miarę regularnie uaktualniana i, w przeciwieństwie do LSB, dotyczyłaby TYLKO konkretnych programów/bibliotek. Czyli dana dystrybucja byłaby zgodna z taką specyfikacją niezależnie od rozłożenia plików czy rodzaju stosowanych paczek do programów i pozwalałaby się szybko zorientować czy aktualna wersja dystrybucji na naszym dysku pozwala na używanie danego programu czy też trzeba uaktualnić.

Co do niekompatybilności bibliotek i programów wymagających ich różnych wersji do działania, wolałbym mieć działające programy i 3 różne wersje tej samej biblioteki niż niedziałający program czy kompilowany statycznie (choć to pewne wyjście jest pod warunkiem, że dotyczy kilku aplikacji a nie całego systemu). Co do trzymania kilku wersji biblioteki jednocześnie, zainteresowałbym się rozwiązaniem zastosowanym w GoboLinuksie. Tam mamy np. /Programs/Glibc/2.5, /Programs/Glibc/2.7 i link /Programs/Glibc/Current wskazujący na aktualnie używaną wersję (np. 2.7). Jeśli np. program abc nie chce działać z wersją 2.7 a działał z poprzednią, wystarczyłoby go tylko jakoś zmusić do używania innej wersji niż domyślna. A na resztę programów to nie wpłynie. Do stosowania tego podejścia nie trzeba struktury katalogów GoboLinuksa, choć dzięki niej mogłoby być łatwiej.

/* Tak na marginesie, w tym systemie da się instalować programy bez roota bez żadnych Klik'ów */

Jeśli chodzi o wspomniane wcześniej piekło zależności – na dystrybucjach typu Mandriva, Ubuntu czy openSuSE problem praktycznie nie istnieje a jeśli chodzi o dystrybucje pokroju Slackware'a – cóż… wybór ich użytkowników.

Usunięcie pozostałości po odinstalowanym programie dałbym jako domyślnie zaznaczoną opcję do menedżera programów – czasem może zajść potrzeba zachowania tych plików. A co do pozostałości po ręcznie usuniętym programie – menedżer mógłby wykryć zniknięcie programu i zaproponować wyczyszczenie.

Przyznaję, że nie wiem, jak rozwiązać problem instalacji programu z zależnościami bez internetu. Na razie jedyne co wymyśliłem to ładowanie do paczki wszystkich wymaganych zależności a instalowanie tylko tych niezainstalowanych. Opcjonalnie dystrybucje mogłyby tworzyć dwa rodzaje paczek – z minimalną ilością opcji i zależności i maksymalną. Ale czy to ma sens?

Odnośnie Klik'a – jest kilka możliwości na "kliknij i uruchom", jednak chyba wszystkie albo wymagają dostępu do internetu albo obecności pewnych programów w systemie. Zastosowanie wyżej opisanej przeze mnie specyfikacji rozwiązałoby ten problem. Nie licząc metody działania, pozostałby jeszcze jeden: co z programami mającymi kilka plików wykonywalnych (Util-linux na przykład)? Który plik uruchomić? Tak, przykład jest zły (bo to nie "klikalne"), ale znajdzie się pewnie wiele innych programów o podobnym problemie. Rozwiązaniem może być…

…Podział aplikacji na dostarczone z dystrybucją (z repozytoriów) oraz innych dostawców. Wolność dla mnie oznacza nie tylko dostępność źródeł czy możliwość ich zmiany, ale także używanie zamkniętego oprogramowania. Nie wszystko pochodzi od Microsoftu i nie wszystko uważam za złe (a nawet nie wszystkie rozwiązania rodem z tejże firmy uważam za złe). Zapewne wielu Czytelników tego portalu używa Opery, Skype czy Flasha. Zatem można by nieco ułatwić producentom tych programów ich dystrybucję – niech każda dystrybucja stosuje własne rozwiązania i rozwija się zgodnie z własnymi założeniami a na to miejsce niech będą istniały jakieś standardowe metody skorzystania z tego co się w systemie znajduje. Innymi słowy spis gdzie jakie pliki można znaleźć, jakie są w systemie wersje programów i bibliotek (i gdzie one są), jak się co nazywa itd. Do tego jasno określone miejsce na instalację programów z zewnątrz (choć to może być zbędne) i mają łatwiej i dystrybucje i inni.

Summa summarum moim zdaniem standard, choć potrzebny, nie powinien wymagać konkretnych rozwiązań a jedynie wymagać jednoznacznego opisu danej dystrybucji tak, by na bazie tego opisu była kompatybilność między dystrybucjami. Nieważne czy pliki wykonywalne są w /sbin, /System/Links/Executables czy w /usr/local/bin. Dzięki opisowi program "wiedziałby", gdzie się ma odwołać po potrzebne mu dane/pliki (chociażby przez symlinki) a dystrybucje mimo tego samego zróżnicowania byłyby ze sobą kompatybilniejsze.

Ufff… rozpisałem się. Mam nadzieję, że choć 1/10 zdań miała jakiś sens.