25 lat z Debianem

28 komentarzy

• Comments 28
• Pingbacks 0

1. Ech, gdyby tylko dystrybucje, przynajmniej te debowe, potrafiły się zjednoczyć pod wspólnym logo Debiana ! Ech, gdyby tylko Debian przemyślał sprawę desktopu dla Kowalskiego i wziął gotowe rozwiązania ze swoich klonów ! Wspólne testy i śledzenie błędów, wspólne fora, wspólne repo, komercyjne wsparcie dla jednego standardu… Pomarzyć można, ale jestem optymistą: w Busterze ma pojawić się “współczesny” instalator. Dodadzą jeszcze instalator sterowników z Ubuntu, uproszczą biurokrację w tworzeniu i dodawaniu pakietów, powzorują się na wiki Archa i będzie pozamiatane 😉 100 lat !

2. Debian to kiedyś moje ulubione distro ale zawsze wkurzało mnie to piełko zależności, sciagasz jeden pakiet a ciagnie pół środowiska.

3. Nie na tym polega “piekło zależności” 🙂 Inna sprawa, że w Debianie, akurat zależności to piekło.

4. Nie cwaniakuj.

   Wszędzie tam gdzie do fragmentu kodu jest potrzebny osobny silnik powstaje zależność.

   Mozna by rzec nawet ze już są na etapie kompilowania, bo przy kompilacji czasami mozesz sie pozbyc zbednych wtyczek i zbednych zaleznosci. Osoby ktore instaluja gotowe binarki tego problemu nie widza. Swiat sie wydaje dla nich piekny i idealny.

   Problem jest jeszcze jeden, na przyklad nie da sie czasami skompilowac starego programu z nowym gcc bez poprawek. Widac to bylo na przykladzie FreeCAD ktory sklada sie z dosc starych niewspieranych juz zaleznosci. Te zaleznosci raz skompilowane sa nieruszane albo tworzone sa dla nich poprawki. Niestety nie zawsze da sie trzymac 200 lat w repo skompilowanej binarki jesli jej zaleznosci tez sie zmieniania, bo binarka zacznie sypac bledami.

   Generalnie ta cala nie kompatybilnosc jest dla mnie straszna i czasami menadzery typu Flatpak, Snap jest chyba jedym z bardziej rozsadniejszych rozwiazan, ktore byc moze bylo juz w Linuxie za nim powstaly zaleznosci w celu zmniejszenia miejsca na dysku.

   Zeby bylo jasne. Zaleznosci sa dobre, ale czasami uprzykrzają życie i moze sie myle ale czasami sa bezsensowne. a wynika z problemow programistycznych, a dokladniej jakosci pisania bibliotek i ich uzywania.
   Kiedy programista chce uzyc np. funkcji z biblioteki, zgaduje ze musi on skopiowac cala biblioteke, a czasami caly silnik jesli ma zaleznosci. A moze on chcial tylko fragment tego co ta bibliotego robi?
   Moral jest taki:
   Aplikacje portable powielaja te same biblioteki w systemie.
   A aplikacje z zaleznosciami sciagaja cale zaleznosci, nawet jesli uzyjesz tylko jedna funkcje z biblioteki.

   Wielkosc aplikacji z zaleznosciami zostala troche zminimalizowana dzieki podziałom na binarki i biblioteki i moze cos jeszcze przy pakietowaniu aplikacji. Ale powiedzmy szczerze, to nie jest jeszcze pełna optymalizacja, a jakbys budowal pakiet z 1000 plikami osobno i do nich drzewo zaleznosci to bys sie chlopie juz zajechal przy samym paczkowaniu. Dlatego jest potrzeba unowoczesniania budowania pakietow poprzez zautomatyzowanie niektorych procesow. Miejmy nadzieje ze wspolnymi silami ulepszymy dystrybucje Linuxa.
   I zeby bylo jasne, nie jestem programista, choc probowalem sie uczyc kilka jezykow i troche czytalem jak dziala dany kompilator. I jest czasami jest różnica właśnie w wykorzystaniu biblioteki. I na tym swoja wiedze opieram. Jezeli sie myle to przepraszam.

   Pozdrawiam.

5. Piękna zgoda, ale przeczytaj wpierw tekst, który skomentowałem. Wówczas, oraz wtedy, gdy poużywasz zarówno Debiana przez lat kilka, jak i inaczej skonstruowanych w zakresie zależności dystrybucji, może sam dojdziesz do tego, kto tu “cwaniakuje”.

6. Mam jeszcze Debiana. Ale dla mnie pieklo zaleznosci jest wszedzie o ktorym wspomnialem wyzej, wiec osoby “buba” nie rozumiem. I Debiana bym zostawil w spokoju i jego pieklo. Moze “buba” instalowal offline? Moze mu chodzilo o pakiety sugerowane? Moze mial Xfce tylko i chcial zainstalowac cos z KDE i nagle okazalo sie ze bez qt i czesci kde apka nie zadziala?

   Moge sie zgodzic tylko z “trb” ze Debian jest specyficzna dystrybucja.
   Domyslnie tylko gnu pakiety, nie wspierane pakiety wylatuja z repo – nie wazne ze sprawne, zaczalem narzekac na brak niektorych pakietow i musialem zaczac kompilowac. Debian “kuleje”, jakby brakowalo testerow i developerow. Odeszli? Dlaczego ? Moze przestarzaly “system rozwoju”? A moze sie myle? Widzialem kiedys wpis ze mieli problem z przeportowaniem aplikacji zgodnych z lib na lib64, a moze to byla tylko wymowka? A moze faktycznie to problem, bo jak ktos np. cale zycie tylko paczkowal cos i mu sie zwalily na glowe nie rozwijane skrypty to poszedl na skróty? A to tylko przyklad.

7. Z tym lib chodzilo mi ze mieli problem z przeniesieniem do odpowiednich folderow, bo bali sie ze skrypty sie posypia, ale widac nie mieli “zauffanych” developerow by je sprawdzili i ewentualnie poprawili. Bo inaczej tego nie potrafie wytlumaczyc.

8. Nie wiem jak jest teraz ale kiedys siedzac na gnome jak zachciało sie zainstalować cos z kde to pakiety mialy tak poustawiane zaleznosci ze ciągnęło prawie cale kde. Ps. Wiem o co chodzilo z piekłem zależności ale napisalem tak bo dla mnie to tez byla porażka a i do kolegi co napisał niżej to nie byly sugerowane pakiety tylko wymagane.

9. Jest różnica miedzy pakietami sugerowanymi a wymaganymi. Tu nie trzeba bylo apki tylko jakis glupi lib potradil pobrac 3/4 kde ze pojawiala sie mozliwosc na nie zalogować.

10. Po latach nie mam już złudzeń – Debian nie celuje w desktopowego użytkownika. Nawet jeżeli to – to za dużo biorą na barki.

11. O Debianie to się pisze co? A o Gentoo to się zapomina… A ich wiek jest podobny…

12. Jesli developer menadzera logowania w ten sposob stworzyl biblioteke, to bedzie miala ona takie zaleznosci w kazdej dystrybucji linuxa.
    Moze developer uzywal KDE i dla niego to byla najlepsza opcja i moze nie widzial az takich problemow.
    Developer ktory tylko paczkuje w danej dystrybucji zazwyczaj moze tylko podzielic aplikacje na pakiety.

    Poniewaz nie kazdy uzywa KDE i Gnome, dlatego powstaly rozne menadzery logowan i jedno z nich ma nawet rozne nakladki graficzne (qt / gtk) do wyboru.
    Ale tak naprawde to chyba dyskusje nad tym ze GDM jest stare i coraz ciezsze, zapoczatkowaly stworzenie nowych menadzererow logowan.
    Przyklady menadzerow. W Debianie tez ktores z nich powinny byc.
    https://wiki.manjaro.org/index.php/Install_Display_Managers

13. Nic nie zrozumiałeś tu nie chodzilo o menadżer logowania tylko jakis glupi randomowy lib z kde potrafil pobrac taka ilosc kde ze i menadzer sesji sie caly pobieral jako zależność bo jedna zależność pociagala kolejną.

14. Głupie narzędzie umożliwiające m.in. zmianę kolorystyki (z tego co wiem) tematów w GNOME3 – gnome-tweaks wymaga nautilusa (menedżer plików), gnome-settings-daemon, python-gobject, gnome-settings-daemon ciągnie m.in. gnome-desktop, mnóstwo innych i dodatkowo np. gtk3-print-backends. Siedząc zatem w środowisku innym niż GNOME3 i mając jedną paczkę, która nawet nie musi należeć do “stajni” GNOME3/Gtk3, ale która wykorzystuje jego ustawienia wyglądu, chcąc je zmienić muszę zainstalować praktycznie całe GNOME3.
    Sorry, bo wnerwia mnie hejt (nie mówię tego pod Twoim adresem) na to, że “głupia paczka z KDE” wymaga ściągnięcia połowy środowiska. Tak, to po prostu wygląda. Przy czym w istocie są programy pisane sensownie i takie, które sensownie nie są pisane. Dalibóg – narzędzie do zmiany kolorystyki tematów aplikacji korzystających z Gtk+3 doprawdy nie powinno ciągnąć mi całego środowiska, bo nie jest mi ono ani potrzebne, ani nie chcę z niego korzystać.
    Niektóre spośród owych zależności są “wbite” w sam program. Niektóre są “wbijane” przez opiekunów paczek, którzy m.in. kompilując je z niemal wszystkimi możliwymi zależnościami dają możliwość ich wykorzystywania w różnych DE, choć mogłyby być kompilowane jedynie pod określone. Wówczas jednak musieliby kompilować kilka paczek zamiast jednej (np. vlc-qt, vlc-gtk itp.). Zawsze jest jednak wybór – można sobie skompilować paczkę wg własnych potrzeb (oczywiście, jeśli są źródła).
    W przypadku Debiana dochodzi jeszcze jedna kwestia. Często paczki kompilowane są w taki sposób, że “wbijane” są tam minimalne i maksymalne wersje paczek zależnych. I to powoduje różne kłopoty. Stąd też było moje stwierdzenie, że “w Debianie zależności to piekło”. Tych ustawień dla minimalnych i – przede wszystkim – maksymalnych wersji paczek po prostu często nie musi być. Nie mój jednak system (już) i nie moje pchły.
    BTW – Obecne KDE (czyli Plasma 5) w ogóle nie ma żadnego DM.

15. Tam gdzie ty widzisz wady, ja widzę więcej zalet, Debian mieli wolno, ale jednak prze do przodu. Ani Fedora, ani zachwalany Arch, ani Łubuntu – mimo, że stoją za nimi komercyjni giganci – nie są w stanie (na razie) przełamać “backendowej” popularności Debiana. Jednoczyć nie ma z czego, na razie Debianowi mogą zagrozić co najwyżej schizmy. Są teraz fajnie porobione distra, które w niczym nie ustępują Ubuntu (choćby nasz Sparky). I trzeba jasno dać do zrozumienia, że jak chcesz solidnego, sprawnego komercyjnego wsparcia to wybierasz… komercyjną konkurencje. Linux tak nie działa, tu standardy wykluwają się latami.
    Z perspektywy lat, bardzo doceniam model wydawniczy Debiana, nie jest idealny, ale w świecie, gdzie wypuszcza się wersje beta oprogramowania i podpisuje się jako produkcyjną, ów model jest skuteczny. Panowie z M$ też widzę zaczęli zabawę z eksperymentowaniem w Windowsach powyżej 7 i całkiem możliwe, że jak Google się postara, skończy się to Windowsem tylko dla biznesu. Użytkownik nie lubi nagłych zmian i bycia beta-testerem.
    9 lat pracy na Debianie (stable) – jest to jakaś mała miara sukcesu dla tego systemu, tym bardziej, że jestem tylko ‘zaawansowanym Kowalskim’.

16. Chyba nie o tym pisałem. Jeśli jednak chcesz przejść na to, o czym ja pisałem, to możemy. Pobawmy się w paczkowanie w Debianie i nie w Debianie. Ile paczek w swoim życiu zrobiłeś?

17. Chyba odniosłeś błędne wrażenie, że uważam Debiana za zły system dla wybranych. Według mnie, wystarczy wziąć ubuntu-drivers z graficznymi nakładkami i Debian świetnie zastąpi ogromną większość forków swoich i Ubuntu. Deb już stało się niepisanym standardem (bardziej dzięki Ubuntu), jeśli jakiś komercyjny program ma wsparcie na linuksa to jest to zazwyczaj Ubuntu, a ściśle wersja paczek/wydania na którym było to testowane. Co do jakości oprogramowania to pełna zgoda, dlatego wg mnie najlepsze wyjście to stabilna baza + aktualizacja aplikacji (Debian Stable + backporty + własne repo + jakiś odpowiednik AUR w przyszłości) lub dystrybucja ciągła z paczkami w wersji LTS (np kernel i libreoffice-still w Archu). Dzielić to się można jak jest z czego, do testów potrzebni są ludzie (programiści i użytkownicy), jeśli projekt ma po parę aktywnych osób to jak można coś dobrze przetestować… Więc zamiast tworzyć odłamy, poprawiajmy to co już jest 😉

18. “Co do jakości oprogramowania to pełna zgoda” – Nie to żebym się czepiał, ale jaki wpływ na tę jakość mają deweloperzy Debiana? Z czystej ciekawości pytam i po to, by być przekonanym o ich na tę jakość wpływie.

19. Na jakość rozumianą jako działające oprogramowanie dla użytkownika końcowego, wpływ ma m.in. odpowiednia liczba testów – w tym przypadku wysiłek włożony w przygotowanie Stable. Czasem śledzę krytyczne błędy po zamrożeniu pakietów i naprawdę jest tego sporo – można tu trochę pokombinować patchami, paczkowaniem lub odpowiednią wersją. Oczywiście część błędów przejdzie i nie jest już łatana wcale, aż do następnego wydania 😉 Z Archowej beczki – linux-lts jest dla mnie duuużo bardziej stabilny od aktualnego, chociaż ten drugi też jest oficjalnym, “stabilnym” wydaniem. Może to ze starości, może bardziej się do niego przykładają – nie wiem.

20. No to teraz zerknij na kilka paczek w Debianie Stable i jak one są “patchowane” i – przede wszystkim – czym, oraz skąd (bo to najważniejsze) te patche pochodzą. Sorry, ale paczka w wersji X, do której dodawane są autorskie patche z wersji >X (Y) i doprawdy niewiele własnych, to jest voodoo, a nie wybitne działania deweloperów Debiana. Przynajmniej wg mnie.

21. buba Jesli developer / programista tak stworzyl aplikacje / biblioteki, to wszedzie aplikacja tak bedzie dzialac.

    pavbaranow Dziekuje za wyjasnienia.
    VLC nie kompilowalem, ale nawet nie chodzi o DE. Do programow sa dodawane niektore funkcjonalnosci ktorych nie kazdy uzywa.
    Jesli program zostal sensownie napisany to wtedy inna osoba / paczkujaca moze podzielic pliki np. na paczki vlc-qt , vlc-gtk. Tylko ze to jest troche klopotliwe poniewaz paczkujacy sam musi czesciowo zdecydowac jak podzielic pliki i musi przetestowac jak to dziala.
    Nie jestem pewien czy zaleznosci maksymalne to to samo co pakiety z zaleznosciami sugerowanymi.
    Ale zalecane jest instalowanie zaleznosci sugerowanych / maksymalnych, poniewaz przy instalowaniu minimalnych zaleznosci np. jakas opcja w innym programie moze Ci nie dzialac ktorej nie kazdy uzywa.

    Dlaczego ? Wiekszosc zaleznosci jest wykrywana automatycznie, ale czasami jest to nie mozliwe.
    Np. Program A uzywa komendy jakiegos programu B i programisci zazwyczaj to uwzgledniaja w skryptach np. configure. Ale paczkujacy gdy podzielil recznie program B na B1 i B2 to nie jest wstanie przewidziec w ktorej czesci programu lezy dana komenda ( tego nie pokaze “ldd /lib/biblioteka” ). Jedynym rozwiazaniem jest chyba tylko testowanie programu A czy dziala po zainstalowaniu B1 lub B2.

    Dlatego w Debianie “zaleznosci minimalne” to zaleta, i pozwala zmniejszyc system, ale robisz to na wlasna odpowiedzialnosc.

    KDE uzywalo KDM, natomiast KDE Plasma 5 uzywa SDDM. Sprawdzone na wiki:

    https://en.wikipedia.org/wiki/KDE_Display_Manager

22. “Nie jestem pewien czy zaleznosci maksymalne to to samo co pakiety z zaleznosciami sugerowanymi.”. Nie. Potrafię to odróżnić 🙂 Chodzi o deklarowanie zależności od konkretnej biblioteki, która musi być w wersji minimum X, ale jednocześnie nie wyższej niż w wersji Y. Niezależnie od tego, czy sam program wymaga tego drugiego parametru.
    Jeśli chodzi o “zależności wykrywane automatycznie”. Jest nieco inaczej. Wielu programistów używa pewnych plików, które ułatwiają budowę paczki. Ot, choćby CMakeLists.txt dla cmake. Korzystając z parametrów samego cmake, jak i znając treść CMakeLists.txt jesteś w stanie zbudować program – nazwę to tak – o określonych parametrach. Ingerencję możesz wprowadzić w zasadzie jedynie w zakresie zależności opcjonalnych (czyli np. zbudować paczkę tak, by integrowała się jedynie w jednym środowisku, a w innym już nie; pozwolić sobie na coś takiego mogą jednak te dystrybucje, które są zogniskowane wyłącznie na jednym DE ot, choćby jak KaOS, czy Chakra). Oczywiście można też spróbować zmienić taki CMakeLists.txt, by coś uzyskać. Opiekun paczki nie musi też zastanawiać się nad wynikami działania ldd, albowiem to jak zrobić paczkę, jakie ma zależności, co się osiągnie gdy odpowiednio je zdefiniujemy, użyjemy określonych, zawarte jest najczęściej właśnie w tego typu plikach.

    A jeśli chodzi o KDE – KDM było dawniej częścią jednej z paczek (nie pamiętam już której). Było wraz z nią rozwijane i dostarczane do systemu. Stąd jeśli coś miało w zależności tę paczkę, to i KDM wchodziło w system. Obecnie KDE nie rozwija we własnym zakresie żadnego DM. SDDM nie jest projektem KDE. Plasma może używać dowolnego DM, choć sugerowane jest SDDM. Sprawdzone przed własnym nosem, bo akurat KDE używam od kilkunastu lat. Także budując dla niego paczki.

23. Ale spodziewasz się, że na 300 aktywnych devów będzie aż tak wiele – jak to ująłeś – “własnego” na te 40k paczek? Ja mówię też o dokumentacji, pewnej transparentności w działaniu. Stwierdzam fakt, że ten model działania sprawdza się i tyle.

24. Jakiś niecały miesiąc temu aktualizacja jądra wyłączyła mi dźwięk w wyjściu słuchawkowym, okazało się że było to jakoś związane z nową implementacją sterowników AMD – chociaż na tym komputerze karta to Nvidia 😉 Jakoś tam to później poprawili, ale po zasubskrybowaniu reddita Archa widzę, że bardzo dużo osób ma przez kernel problem z grafiką i to wszystkich producentów, chociaż akurat u mnie samo jajko działa szybciej. Taki jest podatek od nowości, dlatego jak ktoś chce mieć spokój to zostaje LTS.

25. Sorry, ale te 40k paczek to przesada. Jedne źródła tworzą w Debianie 3 paczki.
    Może ten model się sprawdza. Może nie. Kilka lat używałem Debiana. Chcesz sprawdzić? 🙂

26. Tak, czy inaczej – kernel stabilny. Problem leży w innym miejscu.

27. ” Chodzi o deklarowanie zależności od konkretnej biblioteki, która musi
    być w wersji minimum X, ale jednocześnie nie wyższej niż w wersji Y. ”

    Jeśli chodzi Ci np. o ” Zależności: python-gi (>=3.0) ”
    Jeśli coś takiego się stosuje, to tylko aby przekazać paczkującym że z taką wersją python-gi 3.0 lub większą udało się skompilować dany program. Zwykłemu użytkownikowi taka wiedza jest niepotrzebna i nie robi różnicy.

    Kompatybilność wsteczną w dosłownym znaczeniu rzadko się podaje, jeśli nie ma potrzeby.
    Ponieważ:
    – Domyślnie Debian buduje nowe repozytorium dla każdego wydania, więc chyba jest tam tylko 1 wersja biblioteki. Było by też bez sensu kopiować stare pakiety, skoro można skompilować wszystko z nowa biblioteką. Jeśli coś się nie kompiluje z tą wersją to porostu nie istnieje w repozytorium.
    To jest wada tego systemu.

    Inaczej może być w wersji ciągłej, gdzie nie ma czasu na przekomponowywanie ciągle repozytorium z nową biblioteką współdzieloną.
    – Jedyne narzędzie do sprawdzania kompatybilności wstecznej jakie znam to próbna kompilacja i prawie nikt tego nie robi, jeśli nie musi. Mam namyśli od zwykłych developerów aż po paczkujących.

    Wadą takiej dystrybucji ciągłej jest to, że stara aplikacja dzięki nowym zależnościom może przestać działać i trzeba ją prze-kompilować. Na szczęście nie zawsze. Jeśli chodzi o biblioteki, to może tu być , w systemie i repozytorium, kilka wersji tej samej biblioteki i aplikacje sobie użyją jakiej tylko potrzebują.

    Chyba się nie zrozumieliśmy.
    System zazwyczaj automatycznie, ( a jeśli nie, to powinien ) na podstawie pliku ( np. configure lub innego ) , dzięki własnym skryptom, sam wykryć zależności do kompilacji, zainstalować i skompilować program. Dodatkowo po skompilowaniu pliki są automatycznie prześwietlane pod kątem zależności i automatycznie dodawane do pakietów.
    Natomiast ja podałem przykład wcześniej dlaczego to w jednym przypadku nie zadziała.
    Tak jest zazwyczaj w .rpm i .deb

    Mogę Ci napisać jak to wygląda z mojej perspektywy ( innej niż Debian )
    Do zbudowania pakietu rpm tworzę tylko plik .spec
    Muszę wpisać tam, nazwę, wersję , licencję, opis, informację.
    Ponieważ nie mam takiego skryptu jak ma Debian, to muszę ręcznie je zainstalować i podać w pliku spec zależności.
    Jeśli pakiet jest podzielony to każdy pakiet musi mieć własny opis, zależności i pliki.
    Jeśli kompilacja powiedzie się sukcesem, to na tym kończy się moja praca.
    W zależności od dystrybucji Linuxa tworzenie pakietów może wyglądać trochę inaczej z innymi narzędziami.

    Dodam, że istnieje ( niedomyślne, może nieoficjalne ) repozytorium, które może uczynić Debiana dystrybucją ciągłą, ale większość pakietów jest po prostu chyba kopiowana z wydania stabilnego.
    to samo możesz osiągnąć aktualizując Debiana z dystrybucji na dystrybucje.
    Więc szału nie ma.

28. To co powoduje wadę (braki programów), że Debian unika
    różnych wersji bibliotek, ma swoją także zaletę.
    System zajmuje mniej miejsca.

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