Ech, jak ja kocham takie podejście – coś mi nie pasuje, ale i tak będę tego używał, bo to jest „ideologicznie słuszne”… A ideologię to lepiej zostawmy politykom, czy też GNU/Stalin^H^Hlmanowi, nie mieszajmy do technologii.

Zrezygnowałam po przeczytaniu wstępu. ;)

Co do niespójności… Windows też jest niespójny, bo przecież nie ma jednego odtwarzacza wideo dla windy, nie ma jednej przeglądarki internetowej… Totalna niespójność!
A poważnie – nie nazwałbym możliwości wyboru „niespójnością”.

Co do RPM/DEB... też nie wiem w czym Ci to przeszkadza. Potraktuj to tak: własna kompilacja to jak instalowanie przez setup.exe w Windowsie (chyba podobna trudność), a RPM/DEB/cokolwiek jest o niebo lepsze, bo daje dostęp do repozytoriów. Więc to taki „dodatkowy ficzer”.

A „niedoróbki”... Każdy tak rozbudowany projekt informatyczny ma niedoróbki. A Windowsie to wszystko tak super działa? Też się pojawiają różne kwiatki… Inna sprawa, czy użytkownik sobie z nimi daje radę czy nie. Jak admin dupa, to co by nie zainstalował, będzie kiepsko działać.

Ze swojego doświadczenia (ArchLinux w domu, Winda w pracy) mogę powiedzieć, że Linux wymaga mniej od użytkownika (użytkownik != administrator), jest bardziej przewidywalny i ma o niebo lepsze środowisko (N pulpitów itp itd.). Windows z kolei lepiej sobie radzi z jakimś egzotycznym sprzętem podłączanym do kompa. Na tym jego przewaga się kończy.

Co do kernela, jest tam opcja pozwalająca ładować moduły z innych wersji. Oczywiście testing itd, ale jest.

Jeszcze jedna sprawa – pomysł, by rozdzielić GUI na serwer, wm, widgety – totalna klapa, która tylko spowalnia system. Jak do tego dorzucimy kolejne xcompmgr czy compiz, czyli dodatkową warstwę – tragedia. Nie wspominając o tym, że nie ma tu (sensownego) odpowiednika GDI, czyli w miarę bezstresowego rysowania po ekranie. Wszystko to musi iść przez kolejne programy, tłumaczące własne konstrukcje na natywne wywołania Xów. Widzieliście xcalc? To już wiadomo, czemu nikt nie używa czystego X ;-P

@Павел: To nie jest takie do końca jak mówisz. Linux mi nie odpowiada o tyle, że jest niespójny i gdzieniegdzie niedorobiony, Windows mi też nie odpowiada, bo mimo swoich wielu zalet IMO nie jest wart swojej ceny. A chyba słuszniejszą ideologią jest używanie alternatywy, niż piracenie?

Choć przyznaję bez bicia, Windowsa kupiłem (w cenie laptopa). Choćby z tego względu, że nigdy nie wiadomo, kiedy będzie mi potrzebny jakiś program działający tylko pod Windowsem, z którym Wine sobie nie poradzi. Więc mógłbyś powiedzieć, że sam w ten sposób zaprzeczyłem swoim argumentom, i pewnie będziesz miał trochę racji nawet.

Ale jednak, mimo wszystko, mimo tych wszystkich żali, które wylałem, wolę Linuksa. Nie wiem dlaczego, ale tak po prostu jest. :)

@Radek: Nie chodzi mi o możliwość wyboru, tylko o brak kompatybilności między dystrybucjami i daleką od idealnej współpracę programów z „różnych światów” (aplikacji z KDE pod GNOME itp.).

Własna kompilacja odpowiednikiem setup.exe? OK. Jak mi pokażesz odpowiednik deinstalatora to może się przychylę do tego zdania.

@puppy: Akurat to rozdzielenie GUI IMO nie jest wielkim problemem. Niby to wszystko spowalnia system, a GNOME z Compizem albo KDE3 i tak ma mniejsze wymagania niż Vista, a gry (te, które mają swoje wersje i na Windę, i na Linuksa) – w końcu najbardziej wymagające programy jeśli chodzi o wydajność grafiki – mają bardzo porównywalną wydajność i tu, i tu.

Co do pakietów to uważam, że powinien być JEDEN (nie trylion jak teraz) wspólny format i tyle w tym temacie :)

Niespójność GUI to zupełnie inna sprawa. Wszystkie aplikacje nigdy nie będą spójne pod względem wizualnym. Np. zobacz jak pod Windows wygląda Winamp lub WMP. Człowiekom jakoś to nie przeszkadza, a czasami nawet wręcz przeciwnie ;)

> Własna kompilacja odpowiednikiem setup.exe? OK. Jak mi pokażesz odpowiednik deinstalatora to może się przychylę do tego zdania.

Zamiast make install, wystarczy checkinstall i już mamy pakiet, którym możemy zarządzać z menedżera pakietów.

A o checkinstall nie słyszałem, a faktycznie, bardzo miły programik :)

@kFYatek, „make uninstall” zamiast „make install”

@jam łasica, używaj jednej dystrybucji, to będziesz miał jeden menadżer pakietów. Zupełnie nie rozumiem tego narzekania, że jest kilka menadżerów. Co z tego? Przecież programiści tych paczek nie robią (chyba, że chcą) – wypuszczają źródło i na tym się ich praca kończy. Kompiluj skoro chcesz mieć taką samą instalację dla każdej dystrybucji.
Nie zabronisz ludziom pisać własne menadżery pakietów ;)

Co do współpracy KDE-Gnome, to nie wiem jak u Was, ale u mnie działa. W KDE mam gtk-qt-engine więc wszystkie GTKowe programy wyglądają jak trzeba. Za to w Windowsie co program to jakaś „skórka” (wspomniany winamp, wszelkie komunikatory, odtwarzacze wideo itp.), więc jest moim zdaniem dużo gorzej.

Nie wiem czy to bylo w komentarzach czy nie ale…

Porównywanie JEDNEGO systemu (win) z KILKOMA (pare distro) i dziwienie sie ze kilka roznych systemow sie… rozni, jest IMO dziwne. Fakt ze distra maja wiele wspolnego, ale niezapominajmy ze kazde z nich to oddzielny system operacyjny. Wiec jak dla mnie porownanie moglo by dotyczyc np Winda vs suseł, winda vs fedora czy vs debian, a nie winda vs linux ;/. Wiele ludzi o tym zapomina niestety…

@Radek: make uninstall… no dobra, tylko kto trzyma katalog ze źródłami po zainstalowaniu programu? A nawet jak trzyma, to wygrzebywanie go… mało to intuicyjne rozwiązanie jak dla mnie. checkinstall o niebo lepszy ;)

@Listva: OK, tyle, że… te wiele systemów (różne distro) mają ze sobą jednak jakby nie patrzeć więcej wspólnego niż różnego. Jak ktoś pisze program na Linuksa, to nie mówi, że to jest program na Debiana czy na Fedorę, tylko że jest to program na Linuksa – bo w 99% przypadków program równie dobrze skompiluje się pod każdą distro, a w jakichś 90% (jeżeli porównujemy distro z podobnego okresu czasowego i na tą samą architekturę) i binarki się uruchomią wszędzie. Więc ta Fedora i ten Debian… no cóż, niby różne systemy, ale aż się prosi, żeby psioczyć na niekompatybilność (różnice w systemie pakietów itp.) między nimi.

kFYatek, ta ale patrząc pod kątem uzytkownikow ktorzy uzywaja jednego wzglednie dwoch distro naraz bardzo martwi ze ich system jest wrzucany ogólnistycznie do jednego wora, bo bardzo lubia byc wyroznieni ;)

A poza tym popatrz jeszcze na zwykłych userów, którzy np. przychodzą do pracy w biurze, gdzie dział IT stwierdził, że zamiast Windowsów poinstaluje Linuksy. Dla takich to po zobaczeniu kilku różnych distro zapewne będzie istniał tylko „Linux z KDE” i „Linux z GNOME”, tylko „nie wiedzieć czemu na różnych komputerach są różne ikonki dla menu Start” ;) No dobra, jeszcze splashscreeny i ekrany logowania mogą zasiać trochę wątpliwości, ale myślę, że łapiesz aluzję ;)

Tak samo pracodawcy przecież nie piszą „zatrudnię programistę/administratora systemu Slackware” tylko „zatrudnię programistę/administratora systemu Linux”.

No ja wiem o co chodzi, mowie tylko ze mi sie to niepodoba ;p. Poza tym Linux to nazwa jadra… ;p

Bardzo fajny tekst, ale IMO za długi — mogłeś go rozbić na 3 kolejne wpisy, tym bardziej że i tak go tematycznie pogrupowałeś.

Faktycznie bardzo bolesny jest brak jednego formatu pakietów z oprogramowaniem i nieprzenośność pakietów nawet pomiędzy kolejnymi wersjami tej samej dystrybucji. Niestety pojęcia nie mam jak to rozwiązać, bo ta słabość jest wpisana w model rozwoju Linuksa i softu mu towarzyszącego.

A co do modułów jądra, to np. Mandriva używa DKMS. Wtedy właściwy moduł łączy się z jądrem przez warstwę pośrednią, i to ona bierze na siebie ciężar zmieniającego się API/ABI jądra. Ale ten problem również istnieje tylko dlatego, że ludzie produkujący jądro nie przywiązują większej wagi do zamrażania API/ABI i w wygodny (dla nich) sposób spychają to na dystrybucje.

No właśnie z DKMS jest podobny problem co z LSB – ktoś się podjął rozwiązania problemu niejednolitości… ale nie zdobyło to wystarczającej popularności. I o ile jak piszesz w Mandrivie jest DKMS defaultowo, o tyle w innych dystrybucjach trzeba to doinstalowywać, ale tak naprawdę nie wiadomo po co, bo np. sterowniki do kart graficznych i tak się nie kwapią żeby z tego korzystać.

I tu wychodzi zaleta centralnego sterowania, które może stosować Microsoft. Użytkownicy Linuksa mają gorzej, bo dystrybucje nigdy nie mogą dojść do porozumienia, często wręcz w ramach jednej dystrybucji dochodzi do tarć i sporów (stąd się wzięło Ubuntu na przykład, a potem Kubuntu i…)

Gorzej! Nawet gdyby zdarzył się cud i wszystkie wielkie dystrybucje ustanowiły sobie jakiś wspólny zestaw reguł, to i tak pewnie zaczęłyby powstawać dystrybucje wyłamujące się z tego schematu, choćby po to by zaspokoić czyjeś potrzeby „płynięcia pod prąd”. Czasem żałuję, że Linux nie należy do jakiejś rynkowej, drapieżnej korporacji która byłaby w stanie wymusić jeden model na dystrybucjach. Może wystarczyłoby nawet „albo załączasz biblioteki w takiej i takiej wersji, albo nie możesz użyć znaku >>Linux<<”. Tak jak Mozilla zrobiła z Firefoksem i Thunderbirdem…

Firefox i Thunderbird to nieco inna bajka, bo tutaj Firefox i Thunderbird jest jeden, a wszelkie projekty pochodne muszą się nazywać inaczej. Zresztą w zasadzie to na dobrą sprawę jest standard w świecie oprogramowania użytkowego, nikt nie nazywa produktu pochodnego tak samo jak oryginału, zawsze przynajmniej jakieś „Mod” do nazwy się dodaje. Zresztą w Linuksach jest tak samo – nie ma dwóch tak samo nazywających się dystrybucji. Tyle że żadna z nich nie zyskała aż tak dużego poważania, żeby być przyjętą za standard. Przez ostatnie kilka lat za najpopularniejszą dystrybucję uchodziło Ubuntu, obecnie z tego co widzę zaczyna być wyprzedzane przez openSUSE, a to przecież distra z zupełnie różnych światów (Ubuntu pochodzi od Debiana, SUSE jak widzę ma swoje korzenie w Slackware, ale np. korzysta z RPMów…).

Jak słusznie zauważyłeś każda dystrybucja ma inną nazwę, ale sam nazwałeś je zbiorczo „linuksami”. Gdy pytam kogoś czego używa na swoim komputerze, to też najpierw powie mi „linuksa”, a dopiero potem doprecyzuje dystrybucję. Linux to silna marka, silniejsza od pojedynczych dystrybucji… możnaby jej pewnie użyć do wymuszania na dystrybucjach pewnych zachowań.

Inna sprawa, że dystrybucje często łatają błędy autorów jądra, więc wymuszanie czegokolwiek na nich byłoby mocno nie fair…

Beznadziejna sytuacja.

BTW. Osobiście odkąd zacząłem używać Linuksa jako swojego podstawowego systemu, przeszedłem następującą drogę: Mandriva -> Fedora -> Kubuntu -> Ubuntu. Ale mam dziwne wrażenie, że znowu będę musiał zmienić distro, bo mam wrażenie, że z kolejnymi edycjami Ubuntu zaczyna coraz bardziej traktować użytkownika jak idiotę, który kliknie akurat ten przycisk, który rozwali system :/

A szkoda, bo to naprawdę dobrze działająca dystrybucja, i to z potężnymi repos…

Tak, Linux to potężna marka, ale przez nikogo nie zarządzana i na dobrą sprawę do nikogo nie należąca. I zmienić tej sytuacji w zasadzie się nie da. I właściwie zauważ, że nawet sami autorzy dystrybucji jej nie eksponują – nie muszą. Kiedy wejdziesz na stronę projektu Ubuntu czy Fedora, przeczytasz, że to „system operacyjny oparty na Linuksie”, a nie „dystrybucja Linuksa”. W dodatku postępuje trend usuwania słowa „Linux” z nazwy dystrybucji. O ile kiedyś wszystko nazywało się „Red Hat Linux”, „SuSE Linux” itp., to teraz mamy „Fedorę”, „Ubuntu”, „openSUSE” – bez „Linuksa” w nazwie. Jak widać, siła marki „Linux” jest tak duża, że nawet unikanie jej przez samych twórców nie zatrzyma jej używania przez użytkowników. I wydaje mi się, że nawet gdyby właściciel marki „Linux” zabronił jej używania w niektórych sytuacjach, to wydaje mi się, że użytkownicy i tak by takie systemy nazywali „Linuksami”.

Chyba, żeby rozkręcić kampanię reklamującą „prawdziwe” (certyfikowane) Linuksy oraz produkty linuksopodobne. Wyrobić w ludziach przeświadczenie, że produkty które nie są „prawdziwym linuksem” są gorsze. Duże pole do popisu dla ironicznych reklam z jajem :)

Inna sprawa, że certyfikowanie dystrybucji byłoby potężnym polem do nadużyć. A jeśli wyrobić w ludziach przeświadczenie, że niecertyfikowane Linuksy są gorsze… wtedy zapewne dużo mniej ludzi decydowałoby się na stworzenie własnego distro, bo przerażałoby ich oczekiwanie na certyfikację wraz z każdym wydaniem, a „bez certyfikatu przecież nikt tego używać nie będzie”. Na arenie pozostałoby kilka największych projektów, co z jednej strony miałoby swoje zalety (większa spójność i jednolitość), ale też i wady (mniejsza konkurencja to wolniejszy rozwój).

Albo też drugi możliwy scenariusz – najbardziej liczące się dystrybucje zbojkotowałyby program certyfikacji jako sprzeczny z ideami Wolnego Oprogramowania, i wtedy, za przeproszeniem, o dupę rozbić takie certyfikaty, bo wydaje mi się, że siła bazy użytkowników Fedory, Ubuntu, Debiana, openSUSE czy innych popularnych dystrybucji wydaje mi się mimo wszystko dużo większa niż siła „ironicznych reklam z jajem”.

To prawda, ale z drugiej strony niektóre dystrybucje (Fedora, SUSE, Mandriva…) występują już teraz w wersjach darmowych i płatnych. Możliwe, że dla dystrybucji certyfikowanie wersji płatnych byłoby sposobem na zwiększenie ich atrakcyjności. A za darmo miałbyś nadal distro bez certyfikatu. Pomysł poparliby też producenci komercyjnego softu…

Widziałeś jakiegoś indywidualnego użytkownika używającego płatnego Linuksa? Płatne Linuksy są dla firm, które chcą mieć porządny support i o nic się nie martwić. Do zastosowań desktopowo-hobbystycznych mało kto jest chętny, żeby za Linuksa płacić.

A jeśli chodzi Ci o to, że np. certyfikat dla płatnego SUSE zwiększyłby popularność darmowego niecertyfikowanego openSUSE… wracamy do pierwszego podanego przeze mnie scenariusza – mniejsze distra przestałyby się w ogóle liczyć i pozostałyby tylko największe projekty (mające zaplecze ze strony dużych korporacji).

Widziałem paru userów płatnej mandrivy. Myślę, że wszystko jest kwestią ceny jaką sobie producent zażyczy…

Tak, małe dystrybucje nie mogłyby marzyć o zdobyciu popularności bez mocnego wsparcia. Ale czy w danej chwili jest inaczej? Bez pieniędzy i niezłej reklamy (jak np. wysyłanie masy płytek jak to Ubuntu robi) chyba nie da się już zaistnieć. Rynek się nasycił.

Ale jest wiele dystrybucji nie aż tak popularnych, ale jednak znajdujących swoją niszę na tyle dużą, żeby być zauważalnymi – jak choćby Arch czy Gentoo.

A poza tym już wracając do samej certyfikacji – jak wyobrażasz sobie np. rozwiązanie problemu pakietów z oprogramowaniem? Kiedy powstawał standard LSB, korzystający z RPMów, obóz Debiana się oburzył, że oni się na RPMy nie przesiądą, bo ich DEBy są lepsze. No i tak się kończą próby ustandaryzowania czegokolwiek w podzielonym świecie Linuksa ;)

Aż cud, że np. twórcy środowisk graficznych porozumieli się w kwestii uwspólnienia katalogów przechowujących np. pulpit, czy integracji schowka.

No ba, bo jest Linux i jest Debian ;).

No, Debiana można od razu skreślić ;)

I to już jest koniec tego projektu, bo prawdopodobnie za Debianem pójdzie Ubuntu, Knoppix i kilka innych naprawdę liczących się distro, a to już jest za duży udział w rynku, żeby projekt się udał ;)

Na Ubuntu bym wbrew pozorom nie liczył, oni nie boją się komercji. Canonical ma nawet strategiczne partnerstwo z Linspire (Linspire dostaje support potrzebny do wypuszczenia Freespire na bazie Ubuntu, a Ubuntu dostaje support potrzebny do zintegrowania zasobów komercyjnego softu z Linspire). Myślę, że mogłoby być ciekawie.

No dobra, ale wyobrażasz sobie, że wszystkie DEBowe dystrybucje oprócz samego Debiana nagle przesiadają się na RPMy? Bo ja nie. Tak samo jak nie wyobrażam sobie, żeby wszystkie RPMowe dystrybucje nagle przesiadły się na DEBy, ani że jedne i drugie przesiądą się na jakiś nowo wymyślony format. Niektóre elementy dystrybucji za bardzo w nie wsiąkły, żeby je zmieniać.

Myślę, że na początek można żyć z różnymi formatami pakietów. To w końcu z grubsza taka różnica, jak między .zip a .tar.gz, można zawsze napisać sprytny konwerter (takiego lepszego aliena). Najważniejsze są wersje bibliotek i inne rzeczy, które zrywają kompatybilność binarek. Gdyby tu uzyskać jakiś standard, to już mielibyśmy znaczący postęp.

Bo ja wiem? Mi się wydaje, że największym problemem jest tutaj brak spójności w rozwiązywaniu zależności między pakietami.

Ale podsunąłeś mi pewien pomysł – gdyby tak napisać menedżera pakietów, który równie dobrze radziłby sobie z RPMami, jak i z DEBami i tworzył dla nich spójną bazę danych zależności, i byłby dostarczany z narzędziami kompatybilnymi pod względem obsługi z linii poleceń z rpm i dpkg, to umożliwiłoby to płynne przejście na nowy standard zarówno dla dystrybucji DEBowych, jak i RPMowych. Tzn. trzebaby jeszcze napisać kompatybilne wersje apta i yuma, ale to nie wydaje mi się jakimś strasznym problemem.

Problemem jest jeszcze to, że różne dystrybucje stosują różny stopień rozdrobnienia pakietów, i nawet pomijając niekompatybilności samych formatów (DEB vs. RPM) trudno stworzyć spójny system rozwiązywania zależności, bo… hm… no trudno mi tutaj podać przykład z życia wzięty, ale załóżmy, że mamy bibliotekę libcośtam, która ma dwa komponenty – libcośtam-a i libcośtam-b. Powiedzmy, że twórcy Fedory zawrą to w jednym libcośtam.rpm, a w Ubuntu rozbiją to na libcośtam-common.deb, libcośtam-a.deb i libcośtam-b.deb. I teraz pakując program korzystający z libcośtam, jaką dać zależność? Że wymaga libcośtam-a i libcośtam-b, czy że wymaga libcośtam?

Z mieszaniem różnych typów pakietów mógłby sobie pewnie poradzić Smart (obsługuje deby, rpm-y, repozytoria różnych dystrybucji…), trzeba tylko rozwiązać nazywanie zależności.

„I teraz pakując program korzystający z libcośtam, jaką dać zależność? Że wymaga libcośtam-a i libcośtam-b, czy że wymaga libcośtam?”

Zostawić to automatowi skanującemu zależności binarki. Wykryje on, że binarki w pakiecie potrzebują „libcośtam.so.2” i wpisze to na listę zależności. Ale to akurat ten konkretny przypadek, nie da się w ten sposób rozwiązać zależności nie wynikających bezpośrednio z linkera i symboli w binarkach. Inna sprawa, że pomijając wyjątki typu Archa (wielkie paczki) czy PLD (masa drobnicy) wszystkie dystrybucje dzielą pakiety według podobnych schematów. Chociaż dobrze byłoby mieć konkretnie opisane standardy.

Na pewno nie wszyscy się do tych standardów dostosują. Ktoś się na pewno wyłamie i stwierdzi, że standardowy model podziału pakietów jest za gruby lub za drobny i zrobi swoją dystrybucję wyłamującą się ze schematu.

Przychodzi mi na myśl jeszcze jedno rozwiązanie – zostawić standardy pakietów wewnątrz dystrybucji jej twórcom, ale stworzyć nowy standard przeznaczony tylko i wyłącznie do dostarczania oprogramowania nie wchodzącego w skład samej dystrybucji. I tam zależności mogłyby być już rozwiązywane według plików (tzn. w paczce mogłyby być informacje o każdym pojedynczym pliku wymaganym przez dany program), a podczas instalacji zapisywane w bazie danych (która oczywiście integrowałaby się z bazą pakietów należących do dystrybucji) z jakich pakietów te wymagane pliki pochodzą, do wgrywania plików np. do /etc/rc?.d mógłby ten menedżer pakietów mieć odpowiednie coś na kształt API (bo przecież w różnych systemach jest to w nieco różnych miejscach), które również dbałoby o spójny wygląd tych skryptów zgodnie z przyjętą w dystrybucji koncepcją.

Ogólnie całość przypominałaby trochę model przyjęty w Windows – inaczej zarządza się tam przecież komponentami systemu, a inaczej resztą oprogramowania. W Linuksie co prawda proporcje między softem uważanym za część dystrybucji systemu a tym określanym jako „third-party” są zgoła inne, ale zasady są dość podobne.

Częściowo jest to załatwione — soft 3rd-party ląduje w /opt, do integrowania się z systemem mógłby być jakiś standardowy program, to nie problem… Wszystko rozbija się ostatecznie i tak o to, że w jednej dystrybucji wrzucili libgmp.so.3, w innej libgmp.so.2, i nijak nie dostosujesz się do obydwu, bo fizycznie możesz tylko z jedną wersją się zlinkować.

Soft 3rd-party ląduje w /opt… teoretycznie, bo jak dotąd z softu lądującego w /opt to widziałem tylko Javę, no i niektóre gry. Tak to wszystkie programy instalowane uznawaną za standardową procedurą ./configure; make; make install – lądują przecież w /usr, albo /usr/local, zlewając się z resztą i utrudniając deinstalację.

A libgmp.so.2 i libgmp.so.3 to, o ile mi wiadomo, po prostu różne wersje biblioteki. I zauważ, że np. w Windows ten sam problem występuje, choćby (bo mi pierwsza na myśl przychodzi) słynna przed laty biblioteka uruchomieniowa Visual Basica – były i VBRUN300.DLL i VBRUN400.DLL, później MSVBVM60.DLL, i wszystko to była zasadniczo ta sama biblioteka w kolejnych wersjach, i też się przecież nie dało zlinkować z każdą z nich jednocześnie. A jednak jakoś to wszystko działało, i mimo pojawiających się gdzieniegdzie w Sieci narzekań, ja tam nigdy z DLLkami pod Windowsem większych kłopotów nie miałem.

Większość komercyjnego softu (bazy danych itp.) trafia do /opt. Tak, .so.2 i so.3 to tylko różne wersje biblioteki, ale to właśnie stanowi 90% problemów z przenośnością pakietów między dystrybucjami.

Linux oczywiście również może przechowywać równocześnie X wersji tej samej biblioteki, tyle że… to nie jest normą. Systemy pakietów z definicji nie pozwalają na zainstalowanie więcej niż 1 wersji pakietu, czasem (naprawdę sporadycznie) developerzy pozwalają na to i robią np. pakiety „gcc” oraz „gcc2”. Ale spróbuj zainstalować równolegle gcc-3.0 i gcc-3.1, w większości dystrybucji będzie to niemożliwe bez ostrego kombinowania. W przypadku aplikacji to akurat „wina” FHS, ale binarki bibliotek nie są problemem — każda wersja ma inną nazwę pliku. Problemem jest model pakietów, który wymusza upgrade wersji zamiast instalacji równoległej. Co wynika z przeświadczenia, że każde distro jest zamkniętym, odizolowanym światem. I koło się zamyka.

Z drugiej strony, całość powoli się klaruje, bo te biblioteki, w których posiadanie kilku wersji zainstalowanych naraz ma sens, mają odpowiednie nazwy pakietów – przykłady: libgtk i libgtk2, libqt3 i libqt4, itp. Głównym problemem jest moim zdaniem brak spójności w nazewnictwie tychże.

Komercyjny soft trafia do /opt… być może. Ale wśród indywidualnych użytkowników dużo częstszy jest scenariusz: ktoś usłyszał o fajnym opensource’owym programie, i chciałby go zainstalować, ale jego twórca jest fanem Fedory, i chciało mu się do niej zrobić RPMa, ale ten użytkownik używa akurat Ubuntu, do którego akurat nikt nie zrobił pakietu z tym programem. W celu jego skompilowania musi ściągać 100 MB pakietów -devel (BTW: w jednych dystrybucjach nazywają się one -devel, w innych -dev…), przy odrobinie szczęścia całość idzie bez błędów kompilacji, a po uruchomieniu okazuje się, że ten program wcale nie jest taki fajny – i jak go teraz skasować?

Użytkownicy komercyjni sobie i tak poradzą, bo mają komercyjny support i/lub rzesze informatyków którzy w opisanej sytuacji stworzą odpowiedniego DEBa tylko na wyłączny użytek wewnętrzny firmy ;) Na dzisiejszym braku standaryzacji Linuksa najbardziej cierpią indywidualni hobbyści… i firmy oferujące ten wyżej wspomniany komercyjny support ;)

„okazuje się, że ten program wcale nie jest taki fajny – i jak go teraz skasować?”

kFYatek, powtórzę się, ale… może make uninstall? ;) A poza tym ten użytkownik, o którym pisałeś, mógł zrobić paczkę a nie instalować ze źródeł – nie dość, że łatwiej by się odinstalowywało, to jeszcze przysłużyłby się swoejmu ulubionemu Ubuntu…

Kolejny, który pisze o tym, co już dawno zostało napisane. Setki razy…