Źródłowe dystrybucje wcale nie takie cacy

W pracy właściwie wszystkie maszyny chodzą na Gentoo. Ostatnio była dyskusja na temat tego, żeby to zamienić na jakieś binarne distro (Fedorę na ten przykład), bo pozwoli to na znacznie łatwiejszą instalację oprogramowania i takie tam.

Ja generalnie byłem przeciwny, ponieważ właściwie wszystkie maszyny po trochu robią za systemy produkcyjne i rozwojowe. W praktyce oznacza to, że przytłaczająca większość z nich ma paczki sprzed co najmniej półtora roku (wydanie Gentoo z początku 2005) i tylko pojedyncze programy były updejtowane (na przykład mysql do 4.1) wedle potrzeb.

Takie coś i owszem jest do osiągnięcia na dystrybucji binarnej, ale wtedy albo trzeba mieć dedykowaną osobę znającą się na budowaniu rpmów (co jest sztuką samą w sobie) i utrzymywaniu dystrybucji w ogóle, albo trzeba wszystkich ludzi odpowiednio przeszkolić, żeby wiedzieli co i jak robić (mało realistyczne imho, bo im starszy system bazowy, tym więcej różnych problemów będzie wychodziło i tym więcej czasu by ci ludzie tracili na rzeczy, które w teorii powinny być proste).

Dlatego też byłem za pozostawieniem Gentoo, a to z prostej przyczyny -- o ile w dystrybucji binarnej musielibyśmy i potrafić budować paczki i potrafić nimi zarządzać, o tyle tutaj jest to zasadniczo rzecz biorąc jedno i to samo. Założeniem Gentoo jest właśnie to, że jeśli chcesz mieć jakąś nową wersję programu, to nie musisz ze względu na zależności upgrejdować połowy systemu, bo ów program się po prostu przebuduje w zastanym środowisku i będzie działał jak trzeba.

A takiego wała. Przez ostatnie trzy dni przeżyłem dosyć brutalne (i frustrujące, bo przeszkadza mi w wykonywaniu pracy za którą mi płacą) zderzenie z rzeczywistością. Jeśli w dystrybucji binarnej chcę zainstalować na przestarzałym systemie jakąś nową paczkę, to zostanę po prostu zasypany listą zależności, których mój system nie spełnia, a bez których paczka działać ni będzie.

Natomiast moje kochane Gentoo zasypuje mnie zazwyczaj nic mi nie mówiącymi błędami sugerującymi, że coś w toolchainie jest nie tak. Co? A to już sobie mogę zgadywać na zdrowie. A najlepiej jakbym po prostu wszystko jak leci updejtnął, to by pewnie zaczęło działać.

O fakcie, że najwyraźniej domyślnie instalowane z systemem oprogramowanie do zarządzania paczkami jest dosyć biedne (w porównaniu z tym, co oferuje choćby vanilla rpm, o jakiś highlevelowych rzeczach typu poldek nawet nie wspominając) i żeby zrobić cokolwiek ciekawego muszę najpierw doinstalować jakieś dodatkowe programy (eix, genloop) nawet nie będę wspominał.

Muszę przyznać, że zalety tej dystrybucji coraz bardziej mi się zamazują.

  1. 1. Polinik

    Przecież w Gentoo do gołego systemu trzeba doinstalować prawie wszystko. Nie przeszkadza Ci, że trzeba doinstalować X-y, jakiegoś WM-a, jeżeli nie używacie trybu graficznego to pewnie konsolowego menagera plików (jak mc), lepszy edytor. Co w tym dziwnego, że dodatkowe (ale w gruncie rzeczy nie niezbędne) narzędzia do portage też trzeba?

    PS. "Rok" jest rodzaju męskiego, nie żeńskiego. "Półtora roku" nie "półtorej roku". To TEN rok, nie TA roka.

  2. 2. mmazur

    Utrudnia to życie osobom nie znającym dystrybucji na wylot. Zasada jest taka, że im lepsze narzędzia dystrybucja udostępnia out of the box, tym wygodniej pracuje się potencjalnym użytkownikom. Jeśli distro domyślnie udostępnia jakiś wydmuszek managera pakietów, no to skutek później jest taki, że przychodzi power user, chce coś zrobić, a tu się okazuje, że się nie da, bo najpierw trzeba znać nazwę jakiegoś third party narzędzia, które robi to, co się chce zrobić.

    Jestem całkiem pewien, że debian domyślnie dostarcza ekwiwalent funkcjonalny rpma (nie mówię o managerze pakietów wyższego poziomu, bo już się pogubiłem, czy u nich jest domyślny apt-get, czy coś lepszego), bez konieczności doinstalowywania czegokolwiek.

  3. 3. Polinik

    Ale przecież takie jest właśnie założenie Gentoo -- żeby "out of box" nie było niczego, co nie jest absolutnie niezbędne. Narzekać na to, że "gołe" Gentoo jest... cóż, gołe, to tak jakby narzekać, że Oplem Vectrą nie da się skosić zboża. W zasadzie to faktycznie się nie da, ale jaki jest sens narzekać na to, skoro nie po to był projektowany?
    Gentoo "out of box" nie ma prawie niczego, bo założenie ma takie, żeby nikomu niczego nie narzucać. Tyczy się to także bardziej zaawansowanych managerów pakietów.

  4. 4. mmazur

    Ja nie narzekam na to, że gołe gentoo jest gołe, bo nie przeszkadza mi fakt, że domyślnie na przykład nie instalują się ixy czy co tam jeszcze.

    Natomiast za bardzo niefortunną uważam decyzję, żeby domyślnie dostarczać wydmuszkę managera pakietów, a wszystkie przydatne funkcje chować po zewnętrznych programach (w ilości co najmniej dwóch, a założę się, że jest jeszcze z kilka alternatywnych). Jak już mówiłem, takie podejście utrudnia życie ludziom, którzy chcą tego systemu używać jako jak najmniej upierdliwego narzędzia.

  5. 5. Polinik

    Mi ta wydmuszka w pełni wystarcza. A skoro gołe Gentoo wygląda tak jak wygląda, to pewnie nie tylko mi.
    Nigdy nie używałem eix, genloop. Jedynym narzędziem, które powinno być w portage, a go nie ma jest revdep-rebuild. Powinno, bo zdarza się, że oficjalne ebuildy zalecają użycie go po aktualizacji niektórych bibliotek.
    Cała reszta to tylko dodatki polepszające funkcjonalność. Dodatki, bez których można się obyć.

  6. 6. rash

    Nie rozumiem dlaczego mówisz 'namiastka managera'. Co takiego emerge nie ma do zarządzania programami w systemie? Funkcji genlopa, który mówi ile co się kompilował? Weź..

    Jeżeli natomiast potrzebujesz programów, które Ci pomogą w bardziej zaawansowanym użytkowaniu systemu to instalujesz jeden dodatkowy pakiet w którym znajdziesz wiele narzędzi.

    IMO władowanie _wszystkiego_jak_leci_ do emerge nie jest dobrym wyjściem.

  7. 7. mmazur

    To nie chodzi o bardziej zaawansowane użytkowanie systemu, tylko o użytkowanie systemu w ogóle. Jeśli dostaję nieznaną sobie dystrybucję i muszę coś z nią zrobić, to w 95% przypadków chodzi o zarządzanie oprogramowaniem, czyli package managera. Im więcej on potrafi i im łatwiej są te funkcje dostępne, tym szybciej uporam się ze swoimi problemami.

    Dwie sytuacje. Pierwsza -- odpalić jakiśtam program. No to najpierw sprawdzam, czy jest zainstalowany w systemie (eix -I z pakietu eix), później sprawdzam gdzie trzyma niektóre pliki ze szczególnym uwzględnieniem konfigów (equery z pakietu gentoolkit), no a jak wszystko wiem, to się zabieram do konfiguracji i odpalania.

    No i druga -- cośtam mi nie działa, muszę zdebugować o co biega. Najpierw -- jakie pliki są zainstalowane w systemie (eix -I z pakietu eix), później -- jakie są dostępne (eix -l), zapuszczam emerga na kilka rzeczy, może pomoże, nie pomogło. No to chcę sprawdzić co się dokładnie zemergowało i czy w międzyczasie współpracownik coś nie grzebał (genlop -I --date datadzisiejsza z pakietu genlop) no i dłubię dalej.

    Jak już wspominałem, zdecydowanie preferowałbym, żeby *cała* funkcjonalność związana z odpytywaniem bazy package managera była dostępna z poziomu jednego programu, albo chociaż jednego zestawu programów. Traciłbym wtedy zdecydowanie mniejsze ilości czasu.

    (Ciekawym co będzie, jeśli jeszcze zacznę się interesować flagami z jakimi poszczególne paczki były kompilowane. Mam nadzieję, że obecny zestawik programów mi do tego wystarczy.)

  8. 8. rash

    Przypadek pierwszy:
    1) emerge -s <app>
    2) cat /var/db/pkg/kategoria/pakiet/CONTENTS

    Nie da się? Jest trudniej? Hm.. Niezbyt. Fakt, wygodniejsze używanie jest eixa i gentoolkita. Ale to do usera pozostaje wybór czego używać - filozofia Gentoo.

    Przypadek drugi:
    1) patrz wyżej
    2) jeszcze raz
    3) cat /var/log/emerge.log |grep (...)

    Poza tym, większość użytkowników używa gentoolkit oraz eix. Nie ma ich by-default? To nie jest _żaden_ problem dla usera Gentoo.

  9. 9. mmazur

    Ooo, widzisz, bezpośrednie grzebanie w tych danych mi się przyda, nie będę musiał szukać w programach (ewentualnie będę miał alternatywę, jeśli program będzie wypluwał te dane nie tak, jak chcę). Mogłem wcześniej pomyśleć, żeby sprawdzić czy te dane są w jakiejś zjadliwej formie na dysku.

    Zaś ten emerge -s jednak z założenia robi co innego i jest przy okazji raczej powolny i niewygodny.

    Co do eixa i gentoolkita -- skoro większość osób ich używa, to powinny być domyślnie i to jako jeden program, ewentualnie jedna paczka. I tyle na ten temat. Co jest, a co nie jest problemem dla użytkowników Gentoo (oraz co jest, a co nie jest zgodne z założeniami tejże dystrybucji) mnie nie interesuje, gdyż, co chyba jasno powiedziałem, takowym nie jestem i Gentoo interesuje mnie li tylko jako narzędzie, od którego oczekuję, że będzie mi jak najbardziej ułatwiało życie. A tutaj ewidentnie jest miejsce na poprawę.

  10. 10. arsen

    ale tu chodzi o to by user sam sobie wybrał co lubi, ja wole narzędzia z app-portage/portage-utils niż eix itd. po instalacji w konsoli q i wyświetli się nam masa super narzędzi bez których mojego gentoo sobie nie wyobrażam.

  11. 11. mmazur

    Nie wnikałem w wewnętrzne policy Gentoo i ich rationale, po prostu stwierdziłem, że zastosowane rozwiązanie nie jest optymalne z punktu widzenia osoby takiej jak ja, czyli power usera niespecjalnie zainteresowanego wgryzaniem się we wnętrzności dystrybucji, a chcącego w jak najszybszy sposób osiągnąć zamierzony cel.

  12. 12. rash

    Xorgów też większość osób używa - czy są w Gentoo domyślnie? Nie. To nie wyjaśnienie ;-)

    Poza tym, jeżeli nie pasuje Ci polityka Gentoo używasz innego systemu, problem z głowy.

  13. 13. Polinik

    mmazur: najwyraźniej nie jesteś targetem Gentoo. Skoro Gentoo nie pasuje do zadań, które musisz wykonywać to używaj takiej dystrybucji, która pasuje.
    Nie kopie się rowów widelcem.

  14. 14. mmazur

    Jeśli żaden z was nie zauważył, nie pisałem o gentoo w kontekście postawienia sobie desktopu, tylko w kontekście kilkudziesięciu maszyn, które już na tym gentoo w pracy chodzą (to odnośnie argumentu 'to nie używaj').

    To raz.

    Dwa -- stwierdzenie, że nie jestem targetem też jest oczywiście wzięte z kosmosu. Jeśli przez target rozumiecie "nie śmie kwestionować jakiegokolwiek punktu policy", to rzeczywiście, nie jestem, acz takiej definicji z oczywistych względów nie przyjmę.

    Po pierwsze dlatego, że policy się zmieniają. Muszą, bo wszystko dookoła się zmienia.

    Druga kwestia jest taka, że o ile ktoś mi nie da linka do dyskusji pomiędzy *deweloperami* (odpowiedzialnymi za te kawałki dystrybucji) na ten temat, z której jasno wynika, że takie zmiany nie zostaną wprowadzone, bo jest to sprzeczne z policy, o tyle wasze stwierdzenia w tej kwestii będę traktował jako średnio wiarygodne. Z mojego punktu równie dobrze może być tak, że nikt z core deweloperów się w sumie nigdy nad tym zagadnieniem z tej strony nie zastanawiał (co dziwnym by nie było, bo deweloperzy z definicji wiedzą co nieco o kluczowych częściach systemu i nie widzą tego tak, jak ja to widzę) i gdyby im zwrócić uwagę, to mogliby coś z tym zrobić. A nawet jeśli nikt im uwagi nie zwróci, to niewykluczone, że jutro, za tydzień, albo za rok, takie narzędzie się pojawi i zacznie być domyślnie instalowane w Gentoo z dowolnego powodu.

  15. 15. arsen

    Widzę że szukasz dziury w całym, przecież znasz te narzędzia co nie są instalowane standardowo (wspomniany eix czy gentoolkit) więc argumenty które tu przedstawiasz jakoś mi tu nie pasują.

  16. 16. mmazur

    Źle widzisz.

    Teraz już znam te narzędzia, dlatego niespecjalnie zależy mi, czy gentoo jako dystrybucja coś z tym zrobi, czy też nie, natomiast gdyby z jakiegoś powodu zależało mi na rozwoju i zwiększonej adopcji tej dystrybucji, to zapewne postarałbym się coś z tym zrobić.

  17. 17. arsen

    Zawsze można http://bugs.gentoo.org i naświetlić ów problem, jak zauważyłeś może developerzy nie zdają sobie sprawy z problemu. Z tym że nawet jak będzie to wbudowane standardowo to nowy użytkownik nie będzie nawet wiedział o istnieniu takich narzędzi. Znacznie lepszym pomysłem by było uzupełnienie oficjalnej dokumentacji o dodatki dla pracy z portage.

  18. 18. mmazur

    Jak już mówiłem, mi nie zależy, więc nie zamierzam na to poświęcać czasu, natomiast ciekawiłaby mnie reakcja core deweloperów (czy kogośtam odpowiedzialnego za portage i opłotki) na argument, że scentralizowany *kompletny* system zarządzania pakietami ułatwia zaawansowanym użytkownikom innych dystrybucji szybką migrację.

  19. 19. Jajcuś

    Rozpieściło Cię to PLD i tyle. Ja w pracy mam ileś debianów... I wkurza mnie to dpkg, apt-get, apt-cache... miejscami strasznie nieintuicyjne i mało użyteczne (w porównaniu do rpm+poldek)... ale przyjmuję, że tak ma być, że jest w tym jakiś sens (znany tylko debianowcom) i nawet nie próbuję z tym walczyć... Na paru z tych debianów PLD chodzi (w chroot lub Xen) i jest dobrze ;-)

  20. 20. DeeJay1

    Jajcus: no mi się też zawsze debianowe maszynki przytrafiają do zrobienia i słychać później krzyki typu "jezu, dajcie mi tu PLD" (mimo swoich wad IMHO paskudnie dobrze się nim zarządza).
    Co do scentralizowanych systemów zarządzania pakietami to zgoda, przecież nikt nie jest w stanie znać wszystkich możliwych dystrybucji a nie wiadomo gdzie szef za chwilę rzuci pracownika. Może się okazać, że nagle trafimy do serwerowni zapchanej dziwacznymi jakimiś dystrybucjami i mamy tylko parę godzin by coś z tym zrobić, wszystkich FAQ nie da się przewertować by znaleźć dwa potrzebne narzędzia by się jakoś w nowym systemie odnaleźć...

  21. 21. ukasbadu

    Wszystkiego po prostu trzeba umiec uzywac. A jak sie przyzwyczailo do pewnych rozwiazan to sie narzeka na rozwiazania inne niz te do ktorych sie przyzwyczailo. Za arsenem: chyba szukasz dziury w calym.

  22. 22. mmazur

    Cały widz właśnie w tym, żeby nie trzeba było umieć.

  23. 23. Hoppke

    Dopiszę się też do wątku, chociaż po czasie pewnie. Mi też marzy się jakaś unifikacja narzędzi "okołomanagerowych" w Gentoo (używam tego na domowym desktopie). Rozumiem, że wolność wyboru, pluralizm etc., ale spora część dystrybucji ma jakiś jeden wiodący program do zarządzania pakietami (np. poldek czy smart) i to zdaje się działać... W Gentoo brakuje mi jakiegoś pojedynczego, kompleksowego narzędzia które będzie umiało w szybki sposób przeszukiwać bazę dostępnych pakietów, zainstalowanych, sprawdzało poprawność pakietów, pokazywało zestaw flag itp.

    Ale jednym z podstawowych ograniczeń jest chyba, przynajmniej na mój chłopski rozum, drzewo portage trzymane jako multum pliczków i katalogów. Gdyby drzewo ebuildów i drzewo informacji o zainstalowanych pakietach siedziało w jakiejś bazie danych, to o wiele łatwiej by było zrobić potem do tego jakiś sensowny front-end... Decyzja o plaintekstowym magazynowaniu takich ilości danych jest IMO wrodzonym defektem Gentoo i okropnie ogranicza pole popisu autorom narzędzi.

  24. 24. Jajcuś

    Hoppke: system plików i pliki tekstowe to też bazy danych. W wielu przypadkach najlepsze do konkretnego zastosowania. Nie jest problemem brak bazy dany. Problemem jest raczej brak odpowiednich indeksów (te mogłyby być już w postaci "bazy danych" np. Berkeley DB czy sqlite) w tej bazie danych. Znaczy się, tak mi się wydaje, bo Gentoo nie znam...

  25. 25. Hoppke

    Oj no, to był skrót myślowy i semantyczne nadużycie z mojej strony ;) Chodziło mi o typową relacyjną bazę danych, najlepiej rozumiejącą jakiś SQL. W Gentoo problemem jest to, że informacji jest o wiele za dużo jak na taką formę przechowywania.

    Wyszukiwanie danych rozsianych po setkach katalogów naprawdę długo trwa, dodatkowo traci się sporo MB ze względu na alokację bloków danych masy malutkich plików. Dlatego właśnie powstaje takie eix, czyli wyszukiwarka która tworzy własną, binarną kopię wycinka zestawu danych z portage, żeby zapytania nie zajmowały po kilkanaście sekund nawet na mocnym sprzęcie.

    Zwykłe "emerge foo" też żeby wyszukać jakiś pakiet ryje ostro po dysku, a żeby sobie przyspieszyć pracę i tak robi jakiś specjalny cache danych z portage. Koniec końców wygląda to tak, że jest sobie kobylaste drzewko portage zajmujące ładnych kilkaset MB (np. mam tu pod ręką maszynkę gentoo na której dane portage mają realną objętość koło 100MB, ale po umieszczeniu ich na ext3 robi się z tego już 300MB), a jakiekolwiek narzędzie operujące na tym i tak robi kopie potrzebnych danych w jakiejś zoptymalizowanej postaci z szybszym dostępem do danych. Takie ustawiczne "hacking on bad design". Portage to kilkaset MB plików tekstowych do grepowania, sedowania i awkowania za każdym razem gdy trzeba coś zrobić przy pakietach (np. by sprawdzić, czy w dystrybucji jest pakiet o danej nazwie i jakie ma zależności). To co się sprawdzało od biedy w Slacku tutaj jest już nie na miejscu...

    Pewnie dałoby się uzdrowić system wprowadzając tylko indeksy w binarnej bazie (jako dodatek, nie wiem czy ten eix tak właśnie nie robi), choć IMO to i tak półśrodek.

  26. 26. rash

    Duże portage - zainteresuj się portage@squashfs

    Zastępca portage - poczytaj o paludisie.

Adde commentarium: (textile lite)