Zjednoczenie pakietów

O jakie elementy w prozie współpracy z Linuksem większość nowych użytkowników nabija sobie guza? Nieee, niekoniecznie kompilacja i praca w konsoli. Nie jest to też instalacja sterowników, choć łączy się ona z problemem o którym chcę wspomnieć. Otóż…

Usadźcie nowych użytkowników i dajcie im polecenie zainstalowania jakiegoś programu. Dla pikanterii – najlepiej takiego, którego nie ma w repozytorium. Nie będziemy się posuwać do pierwotnego cynizmu i niech ten program występuje w wersji dla Linuksa. I jakie będą reakcje?

Pewnie spora część z nich rozpocznie kontemplować w zadumie własne paznokcie. Część, bardziej wtajemniczonych, wierząc w siłę repozytoriów, będzie tam próbowała rozwiązać ten problem. Inni podążając instynktem wyuczonym w szkole/domu/pracy, udadzą się na stronę programu i tam poszukają sobie instalki. Całkiem nieźle, jak na nowych. Lecz…

Jeżeli twórcy programu zadbali o prekompilowane binarki dla Linuksa (początkujący podnoszą jedną brew), to oprócz paczki ze źródłami (opada dolna warga), na stronie znajdziemy cały wysyp paczek (instalek) .rpm, .deb, .txz. I jeśli twórcy byli zapobiegliwi, każda w wersji i386, i686, amd64, itp. (unosi się druga brew). I teraz zaczynają się dylematy zwykłego użytkownika, który sobie tylko chciał pooglądać strony WWW i przez Skype pogadać. O ile może być świadom istnienia na dysku oprogramowania pt. Linux, o tyle rozróżnienie jaką posiada dystrybucję, architekturę – to po prostu za wiele. W głowie rodzi się bunt ‘w imię czego ja się mam tak mordować w tym luksusie’, a efekt takich przemyśleń jest raczej większości znany.

Dlatego wiodący system został zaakceptowany przez świat (nie ukrywajmy, w większości składający się z laików i ignorantów komputerowych), gdyż umożliwił co najmniej proste i dostępne instalowanie programów. Ludzie podążyli za pomysłem ‘one .exe, one click’ nawet nie tyle z sympatii do wiadomej firmy, co po prostu z wygody, niewiedzy, lenistwa, braku czasu na szukanie trudniejszych rozwiązań, itp.

A teraz minę powyższego użytkownika przeciwstawcie uśmiechniętej buzi, która pobiera jeden, jedyny plik ze strony programu i kliknięciem sobie instaluje (no oczywiście podając uprzednio hasło roota – administratora).

Jak dla mnie, problem istnieje i jest realny. Ludzie naprawdę nie czują potrzebny totalnego zagłębiania się w nazwę dystrybucji, jej wersję, platformę sprzętową, typ paczek przynależnych danej dystrybucji, itp. To tak, jakby robić doktorat z fizyki, na potrzeby wymiany żarówki w lampce.

Połowa światka FOSS już od jakiegoś czasu zastanawia się jak ujednolicić te nieszczęsne pakiety. Druga połowa zastanawia się, jak tym pierwszym obrzydzić to zastanawianie. Niechęć budzi zapewne to, że wtedy sposób dystrybucji programów i ich instalacja stanie się aż nazbyt podobna i zapożyczona z rozwiązań windowsowych. Co za tym idzie, mogą się pojawić zagrożenia w postaci wirusów i innych nieprzydatnych dodatków. Ale czy na pewno nie można nad tym zapanować?

Tu nie chodzi o to, aby likwidować repozytoria i przewracać dotychczasowy porządek do góry nogami. Lecz o to, by developerzy byli w stanie przygotować jedną wersję paczki gotowej do instalacji na wszystkich (większości) dystrybucji. To rzecz jasna nie takie hop siup – począwszy od różnic pomiędzy dystrybucjami w strukturze /etc i nie tylko (spróbuj debianowcu skonfigurować w konsoli sieć na OpenSUSE. Spróbuj użytkowniku OpenSUSE skonfigurować w ten sam sposób sieć na Debianie), przez różne wersje kerneli, bibliotek, itp. Część problemów już się rozwiązuje, jeżeli chodzi o standaryzację ustawień – głównie za sprawą Linux Standard Base. Kwestię bibliotek można rozwiązać za pomocą linkowania statycznego podczas kompilacji. Program dostępny ‘normalnie’ w repozytorium, zachowywał by się podczas instalacji jak dotąd – pobierał zależności, itp, z różnicą taką, że – zainstalowałby się na każdej dystrybucji.

Przypuszczalnie, batalia o wygodę instalacji jest do wygrania. Niestety, kosztem wielkości paczki z programem (po co nam zatem te gigabajty wolnego miejsca na dysku?), zajętością pamięci RAM przez program (a po co nam te gigabajty RAMu?) i kosztem bezpieczeństwa, tudzież stabilności. Ale patrząc na specyfikę Linuksa, czy te ostatnie argumenty nie są zbyt na wyrost? Może obawy są niepotrzebne. A poprawienie jakości komfortu pracy i zlikwidowanie mętliku instalacyjnego na pewno zyskałoby w oczach zwykłych użytkowników.

5 komentarzy

  1. Widzę, że mamy podobne podejście do Open Source. Jeśli chce się stać popularne wśród komputerów typu desktop to musi się zmienić wiele rzeczy. Unifikacja pakietów MUSI być 😉

  2. Użytkownik, jeśli sam instalował linuksa, musiał już dokonać wyboru architektury. Jeśli ktoś mu zainstalował, to i tak wolałby, żeby ktoś inny za niego doinstalował potrzebne programy, tak jak to robi wielu użytkowników windowsa (w tym wielu moich znajomych). A dlacego tak robią? Ponieważ pod windowsem też nie ma unifikacji programów instalacyjnych. Po pierwsze wersje dla W95/98/me i dla 2000/xp/visty (czasami dla visty jest osobna wersja). Do tego dą wersje z instalatorem exe, albo paczki msi, czasami też zdarza się wersja “standalone” w archiwum zip. A co do unifikacji pakietów binarnych dla różnych architektur – zobaczmy: ftp://ftp.icm.edu.pl/packages/OpenOffice/official/stable/3.0.1/
    OpenOffice 3.0.1 Linuxintel – 152257KB
    OpenOffice 3.0.1 LinuxIA64 – 187288 KB
    OpenOffice 3.0.1 LinuxX86-64 – 157237 KB
    Razem prawie 500 MB – niemalże jak MS Office 😉 – kto by chciał tyle ściągać, żeby jedną trzecią od razu wywalić.
    Poza tym wszystkim, niech się lusdziska przyzwyczajają do samodzielnego myślenia, zamiast do tego, że ktoś za nich, biedaczków, myślał będzie, bo ludzkość i tak głupieje coraz bardziej z każdą godzina.

  3. 1. pewnie ze na windows nie ma unifikacji programow instalacyjnych (bo i czemu mialo by to byc?). ale fakt jest taki, ze kazdy jeden obsluguje sie tak podobnie (cegla na enter) i wszystkie sa w gui.
    2. jest pewna roznica pomiedzy posixem (w wydaniu linux), a winapi (to z windows) – to lezy u podstaw, i jest takze duuzym problemem (dla linuxa):
    a. w winapi wiele struktur ma pole okreslajace ich rozmiar (np. pole cb w tym linku: http://msdn.microsoft.com/en-us/library/ms686331(VS.85).aspx). na 1szy rzut oka to troche bez sensu, ale umozliwia to dzialanie kodu na roznych wersjach windows bez rekompilacji,
    b. na linuxie to wyglada tak, ze biore jakas binarke linkowana dynamicznie z przed powiedzmy 5 lat, proboje ja odpalic na jakiejs nowej dystrybucji i widze komunikat ‘symbol glibc2_4 not found’ lub podobny. nie jest to wada posixa – np. solaris nie ma z tym problemu (binarki z 2.8 dzialaja na 2.10 – a to kilka lat roznicy).

    reasumujac: format pakietow to jedno (i to pewnie da sie w miare zorganizowac), ale wiekszym problemem jest to, ze linux jest skrajnie nieprzyjazny dla wszelkiego oprogramowania z zamknietymi zrodlami – a wystaczylo by dzialajace abi.

    i mala rada do stv (odnosnie ostatniego akapitu): troche wiecej pokory – czy naprawde jestes ekspertem w kazdej dziedzinie, z ktora masz stycznosc w zyciu codziennym? czy znasz zasade dzialania srodkow pioracych w proszkach, budowe i strukure plyt pilsniowych (to z mebli), itd, itp…

  4. “biore jakas binarke linkowana dynamicznie z przed powiedzmy 5 lat, proboje ja odpalic na jakiejs nowej dystrybucji i widze komunikat ’symbol glibc2_4 not found’” – Rozpuścił ludzi XP.

  5. Mam takie same odczucia. Porządny system ma Google w instalce do Google Earth (przynajmniej 4.3).
    Jeden plik .run, któremu trzeba nadać status wykonywalności i odpalić jak każdy inny skrypt (./plik.run).
    Jest to tak proste dlatego, że GEarth jest instalowany w /home i nie trzeba się zagłębiać w tajniki struktury katalogów poszczególnych dystrybucji.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Post comment

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.