- This topic has 13 odpowiedzi, 2 uczestników, and was last updated 5 years, 11 months temu by
.
- Posty
(…) kolejność jest następująca:
# repozytoria dystrybucji;
# AUR (Arch User Repository);
# rozwiązania kontenerowe (przede wszystkim snap i flatpak – wspierane przez Manjaro);
# cała reszta.# repozytoria
# AppImages lub flatpak
# ewentualnie cała reszta, w tym AUR (rozsądnie!)[/quote]
Z całym szacunkiem, pozwolę sobie nie zgodzić się.
W przypadku Manjaro kolejność jest następująca:
Dlaczego? Wbrew różnym twierdzeniom, jak sama nazwa wskazuje AUR jest „repozytorium” przeznaczonym dla użytkowników Archa, a nie Manjaro. Odmienne twierdzenie jest delikatnie mówiąc niefrasobliwością, zwłaszcza, przy kierowaniu Manjaro do „mniej doświadczonych” użytkowników niż korzystający z Archa. Po mojemu nazywa się to debilizm – oferować coś, co przez przypadek może być, ale wcale nie musi zadziałać w Manjaro. AUR można traktować wyłącznie jako coś co po przeglądnięciu znajdujących się tam PKGBUILDów i ewentualnie innych plików, można – przy doskonałej znajomości tak tworzonej paczki, jak i przede wszystkim systemu (Manjaro) – traktować jako wzór skryptu budującego paczkę dla Manjaro. Zwłaszcza, jeśli bez żadnej refleksji budujemy te paczki jakimś AUR-wrapperem (yaourt, pamac itd.)
AppImages – mogą, ale nie muszą zadziałać (na dowolnym systemie). Niemniej jednak są bezpieczne. Niczego złego w systemie nie zrobią.
Flatpak – jak najbardziej ma oficjalne wsparcie.
Snap? Ze względu na, nazwijmy to, pewną niekompatybilność z Archem (w zasadzie, to z żadną inną dystrybucją niż Ubuntu) wypadł z jego repozytoriów i obecnie jest wyłącznie w AUR (przyznam, że nie wiem, czy w Manjaro utrzymują to w repozytoriach; byłoby to co najmniej dziwne i niefrasobliwe).
Potem w istocie cała reszta, czyli… jeśli znalazłeś interesujące Cię oprogramowanie, którego nie ma ani w repozytorium, ani nawet w AUR, to zrób sam, a jeśli nie potrafisz, to poproś kogoś, by stworzył odpowiedni PKGBUILD dla zbudowania paczki dla pacmana/Manjaro. Jeśli nie chcesz rozwalić sobie jakiejś aktualizacji, czy instalacji czegoś, to nie wprowadzaj do systemu żadnej aplikacji do systemu z pominięciem menedżera pakietów. I to ostatnie dotyczy absolutnie każdej dystrybucji. O tym, że w przypadku wprowadzenia takiej paczki sam zaczynasz dbać o system już nawet prawie nie wspomnę.… nie było moim zamiarem rozpisywanie się – chodziło mi tylko o wypunktowanie tematów. Cieszę się @pavbaranov, że rozwinąłeś temat i … po lekturze Twoich uwag i zastanowieniu się, dochodzę do wniosku, że właściwsza byłaby kolejność:
# repozytoria swojskie;
# kontenery + portable;
# AUR;
# cała reszta.
… nie straszyłbym jednak, aż tak bardzo AUR’em – zakładając, że świadomi jesteśmy faktu ograniczonego zaufania, jakim powinniśmy go darzyć. Nie należę do ludzi beztrosko radosnych i jeżeli decyduję się na instalację jakiegoś oprogramowania, to robię to po odpowiedzi na pytania takie, jak ’po co’, ’dlaczego’, ’czy aby na pewno’ i analizie ryzyka. Takie świadome i racjonalne podejście powoduje, że nie mam problemów z ponad 100 pakietami z AUR. Rzecz jasna, odrobina fartu nie zaszkodzi.Nie zadawaj pytania, jeżeli nie jesteś gotów usłyszeć odpowiedzi
Śpieszę wyjaśnić: to nie kwestia ograniczonego zaufania wobec pakietów z AUR (choć trzeba do nich mieć takie, to – odpukać – tego typu rzeczy jak ostatnio ze snapem jakoś nie kojarzę przez kilka ładnych lat używania wpierw Manjaro, teraz Archa). Chodzi o to, że AUR to są paczki dla Archa, które winny uwzględniać jego rozwiązania, jego aktualne paczki itd. Manjaro ma swoje własne pewne rozwiązania, które niekoniecznie muszą być kompatybilne oraz pewną część własnych paczek, a nadto – czego nie wolno pomijać – jest w stosunku do paczek w Archu opóźnione o pewien czas (stable). AUR – na poziomie PKGBUILDu winien być taki sam dla Archa i dla Manjaro. Niemniej jednak wprowadzać może jakieś patche, które nie są już w przypadku Manjaro właściwe. Oprogramowanie tu reprezentowane – właśnie z uwagi na „różnice” czasowe (to samo zresztą występuje przy nieaktualizowanym Archu) – może być oparte o inne wersje paczek, na których jest budowane bądź ma działać. Zbudowałem setki paczek dla Archa i o ile mogę być pewny, że w Archu winny się one dać zbudować i winny działać prawidłowo, to nie jestem w stanie dać absolutnie żadnej gwarancji ich działania w Manjaro. Po prostu o ile mamy pewne ograniczone zaufanie do paczek z AUR w Archu, to w Manjaro powinniśmy je mieć jeszcze bardziej zmniejszone. Musimy też pamiętać, że w przypadku paczek z AUR (sam masz jakieś pewnie 10% systemu z nich zbudowane) to my bierzemy odpowiedzialność za działanie takiego systemu.
Dam Ci pewien przykład, dlaczego twierdzę, że AUR dla Manjaro (stable) to nieporozumienie. Oczywiście będzie w tym lekkie założenie prawidłowej opieki nad paczką AUR (zdarza się, choć tu loteria niestety). Jak dobrze wiesz oznaczenie paczek dla pacmana to: nazwa_paczki-(ewentualny_strip:)numer_wersji_aplikacji-wersja_paczki. Pomijając nawet strip, to weź pod uwagę, że niektóre aplikacje winny być przebudowywane po dostarczeniu do systemu jakiejś nowej wersji aplikacji (ot, dla przykładu – po wprowadzeniu w Archu Qt5.11, przebudowie wymagały pewne paczki oparte o jego komponenty). W momencie, gdy taka paczka trafia do „normalnego” repozytorium Archa, paczka budowana z AUR, a wymagająca przebudowy winna zostać podbita do nowej swojej wersji (z XY-1, do XY-2). Użytkownicy Manjaro – często i nie wszyscy – bardzo często do aktualizacji systemu używają albo pamac, albo octopi+yaourt, albo samego yaourt. We wszystkich przypadkach z rozszerzeniem o AUR. Wróćmy zatem do powyższej sytuacji – użycie któregokolwiek z programów do aktualizacji systemu w takiej chwili spowoduje przebudowanie paczki z AUR (bo podbita wersja_paczki), ale jednocześnie nowa wersja paczki, która spowodowała to podbicie nie trafia do systemu. W momencie, gdy paczka ta do Manjaro trafi nic nie będzie wskazywać na konieczność przebudowy aplikacji z AUR, która właśnie teraz winna być przebudowana i aplikacja będzie działać wadliwie (oby nie cały system).
Jeśli zatem ktoś z użytkowników Manjaro ma taką wiedzę, by nad tym wszystkim zapanować, by wiedzieć czy i kiedy można z AUR coś zainstalować, bądź przebudować, a kiedy nie jest to konieczne bądź możliwe, to proszę bardzo – najmniejszych przeszkód do korzystania z AUR nie ma. Tyle, że… Czy w takim przypadku nie lepiej jest skorzystać z systemu, dla którego AUR jest przeznaczony, bądź jakiegoś jego forka (możliwości wiele), ale który korzysta bezpośrednio z repozytoriów Archa niż zostać samodzielnym deweloperem własnego systemu?
I z mojej strony to już EOT, bo i tak trochę wątek poszedł nie w stronę. Nic więcej już tu nie dodam, bo wydaje się, że temat wyczerpałem. Przynajmniej tu, bowiem to w istocie na szerszą, spokojną dyskusję.… przyznaję, że używam AUR 'objawowo’ – nie wnikam nadmiarowo w zagadnienia teoretyczne, chyba że uznam, to za konieczne (np. muszę rozwiązać jakiś problem) lub interesujące. Powiększam swoją wiedzę stopniowo, zgodnie z metodologią rozpoznania przez bój. Ten wątek nie powiększył (jak dotychczas) mojej wiedzy na temat AUR, ale spowodował zmianę mojego podejścia do tego repozytorium. Niby wszystko jasne – aż głupio, bo nie ma niczego istotnego, z czym mógłbym się nie zgodzić – niby wiem w czym rzecz i postępuję zgodnie z tą wiedzą, ale dopiero ta drobna wymiana zdań zmusiła mnie do refleksji i zastanowienia się nad problem oraz – to w tym najważniejsze – zmontowania z drobnych opinii i spostrzeżeń jednej, spójnej, obejmującej sposób wykorzystania Arch User Repository na co dzień.
… w szerszej perspektywie wygląda, to następująco:
# W swojej praktyce informatycznej wypracowałem sobie zasady, które wynikają z moich poglądów i ograniczeń nakładanych przez rzeczywistość, w jakiej funkcjonuję; np. taką, która mówi, że należy standaryzować swoje działania, metodologie postępowania. Dopóki używałem Manjaro na własny użytek, to konstruowałem system (instalacja, konfiguracja, etc) na podstawie własnego, dotychczasowego doświadczenia i pod kątem własnych potrzeb. Sytuacja zmieniła się w momencie, gdy wykonałem kilka instalacji 'obcych’. Zmuszony byłem zweryfikować kilka rozwiązań, ponieważ w dotychczasowej formie okazały się mało funkcjonalne w nowych okolicznościach. Dalsza zmiana nastąpiła z chwilą pierwszej instalacji 'zaprzyjaźnionej’, która ma priorytet 1 (0 = moja własna), a więc bardzo wysoki (podejmuję się opieki) – kolejna weryfikacja założeń.
# Jednym z weryfikowanych tematów, jakie przeobrażały się w mojej teorii ManjaroDoskonałego, było wykorzystanie repozytoriów innych niż 'swojskie’. Początkowo używałem AUR dość swobodnie (pomijając nieśmiały okres narzeczeński). Z czasem zacząłem zastanawiać się nad jego charakterem i rolą, jaką uważam za stosowną dla niego. Konkluzja była prosta – używać, acz uważnie i z umiarem. Na własnym systemie mam sporo pakietów z AUR (ok. 6,66% wszystkich zainstalowanych), ponieważ nie ma ich w repozytoriach 'swojskich’ (które mają bezwzględny priorytet), a potrzebuję ich / wydaje mi się, że potrzebuję / chcę mieć konkretne narzędzia pod ręką, gotowe do pracy. Zupełnie inaczej wygląda sytuacja na instalacjach 'obcych’ i 'zaprzyjaźnionych’, na których usilnie staram się pozostać w zakresie repozytoriów manjaro’wych – pakiety z AUR, to precyzyjnie uzasadnione wyjątki.
# Następny etap, to pojawienie się w mojej świadomości, możliwości realnego wykorzystania rozwiązań kontenerowych (wcześniej interesowałem się zagadnieniem teoretycznie, np. kontenery w True OS – chyba porzucili, to rozwiązanie; lub paru innych dystrybucjach). Mimo fizjologicznej wręcz niechęci do sporego zapotrzebowania na powierzchnię dyskową, rozwiązanie podoba mi się – klarowne; skutecznie i prosto rozwiązuje problem piekła zależności na systemach innych niż rolling release; zgrabnie separuje system i aplikacje.
# Skoro mogę instalować pakiety ze snap’a czy flatpak’a i uważam je za 'lepsze rozwiązanie’ (cokolwiek się za tym kryje) niż korzystanie z AUR, to konsekwencją tego jest myśl, aby zastąpić wszystkie pakiety AUR’owe ich odpowiednikami kontenerowymi (nadal, bezwzględne pierwszeństwo mają 'swojskie’ repozytoria). Rozwiązaniem idealnym jest korzystanie, w przygniatającej większości, z oprogramowania dostępnego w repozytoriach natywnych dla danej dystrybucji i uzupełnianie ich / rozszerzanie o pakiety z repozytoriów kontenerowych, plus pojedyncze pakiety z AUR lub portable. W zasadzie, ideałem było by, gdyby wszystko było w repozytorium 'swojskim’, a dopuszczenie innych źródeł, to rozwiązanie realne, kompromisowe.
# Do tego dążę, krok po kroku, temat za tematem. Obecnie jestem na etapie doprecyzowywania szczegółów teoretycznych i rozważań nad różnymi wariantami, dlatego tak spodobał mi się ten 'nieślubny’ wątek – trafił w moje aktualne myśli. Kolejnym krokiem będzie generalny przegląd dostępnych pakietów w rozwiązaniach kontenerowych, tak aby zorientować się w skali zamienności.
… a jak wygląda wykorzystanie zewnętrznego oprogramowania u Was; z jakich repozytoriów korzystacie; jakie są Wasze teoretyczne założenia w tym temacie?
————-
SŁOWNIK:
# priorytety: 0=ja; 1=rodzina,przyjaciele; 2=znajomi,praca; 3=elektorat.
# instalacje: zaprzyjaźnione = prywatne, prawie jak moje; obce = prywatne inne.
# repozytoria: swojskie = repozytoria danej dystrybucji; kontenerowe = w tym kontekście, pakiety programowe zawierające niezbędne zależności, instalowane w wydzielonej strukturze folderów, bez ingerencji w system; portable = kopiujesz, nadajesz execute, uruchamiasz.Nie zadawaj pytania, jeżeli nie jesteś gotów usłyszeć odpowiedzi
Skoro zrobił się luźny (w miarę), choć ważny wg mnie, wątek, to jeszcze wtrącę się.
„Kontenery” – Z tym zabieraniem miejsca dysku to różnie bywa. Osobiście używam ich wyłącznie do próbowania jakichś aplikacji. Od czasu do czasu buduję np. rozwojowe wersje LO. Budowanie ich ze źródeł na moim komputerze, to katorga (trwa to z 10h). Zrezygnowałem już z tego dawno. Do pewnego czasu używałem zmodyfikowanego przez siebie PKGBUILDu dla libreoffice-fresh-rpm, który dokonywał pobrania oryginalnie przygotowanej paczki rpm (ona jest tworzona na CentOSie, ale nie pamiętam której wersji), a następnie przebudowywał to do formatu pacmana i instalował. Tak przygotowana paczka, po jej instalacji zabierała ok 500-600MB. Jakiś czas temu przeszedłem na AppImage, które również jest tworzone przez przebudowanie oryginalnej paczki, ale tym razem akurat deb (nie chciało mi się tego skryptu przerabiać na rpm). Pomijając to, że mogę w ten sposób tworzyć różne paczki poprzez proste dodanie parametrów do skryptu, okazuje się, że AppImage zbudowany w ten sposób to ok. 215MB – 3x mniej! Choć w istocie często zabierają dodatkowe miejsce.
AppImage nie jest jednak uniwersalnym formatem. Posiadanie glibc w wersji niższej, czy wyższej niż ta, na której został zbudowany zwykle powoduje, że aplikacja nie uruchomi się w ogóle. Wszystko też zależy od sposobu jej spakowania.
Obecnie nie korzystam już też z flatpaków, a ze snapów… Raz, że nigdy mi się nie udało (próbowałem, gdy to rozwiązanie się pojawiło dla Archa, potem już w zasadzie nie próbowałem), dwa z przyczyn natury ideologicznej i to podwójnej. Z repozytorium Archa (bo było tutaj), snapd wypadł jakiś czas temu nie bez przyczyny. To rozwiązanie, które oparte jest o… Ubuntu 16.04; nieco zbyt stare jak na Archa AD 2018. Przyczyn było więcej. Druga, poważniejsza kwestia – nie bardzo lubię, gdy w systemie mam uruchomioną jakąś zbędną tak na prawdę w nim usługę, a taką jest snapd uruchamiany przez systemd. W dodatku ma to – o ile wiem – dość wysokie uprawnienia. Może na jakimś kernelu z selinux czy apparmor to się sprawdza, ale ani na swoim, ani na repozytoriowym tego rozwiązania sobie nie życzę u siebie. Z przyczyn bezpieczeństwa. Też podwójnego. Canonical – jak dowiodły tego paczki snap z malwarem – nie panuje nad tym kompletnie.
Z kontenerowych rozwiązań, wg mnie, najsensowniejszym wydaje się być flatpak. W miarę bezpieczne (piaskownica), dzielące swoje zasoby. Gdyby jeszcze poprawie uległo instalowanie (a w zasadzie nie samo instalowanie, a „objawianie się” takiej paczki w menu /obecnie często instalacja dwu wersji: z repozytorium oraz z flatpaka daje taką samą informację w menu/) oraz przede wszystkim odinstalowywanie takich paczek (wraz ze wszystkimi pozostałościami w katalogu lokalnym), a także zwiększona byłaby podaż takich paczek, to byłoby to dobre rozwiązanie, zwłaszcza tam, gdzie nie mogę sam sobie zbudować paczki, bądź jej przebudować).
Pozostaje jeszcze „kompilacja na piechotę” (czyli „starym stylem”: configure/qmake/cmake/itd->make-make install). Tego nikomu nie polecam, albowiem prawdopodobieństwo, że tak zbudowany system rozwali się jest zbyt wysokie. System paczkowania w Archu jest na tyle prosty, że należy sobie w takim przypadku zrobić samemu paczkę (kogoś poprosić o jej przygotowanie).
Natomiast co do jednego – jestem uparty: AUR, jeśli w ogóle czemukolwiek służą w Manjaro, to wyłącznie przez przypadek. To loteria. Nie na darmo nawet jeszcze w czasach, gdy dawało się mieszać repozytoria Chakry i Archa już tworzono niezależny odpowiednik AUR dla Chakry jakim jest CCR. Podobnie we wszystkich dystrybucjach, które teoretycznie mogą korzystać z AUR, ale które nie korzystają z repozytoriów Archa bezpośrednio. Znając meandry paczkowania dla Archa twierdzę, że w ogóle dopuszczenie możliwości użytkowania paczek z AUR w Manjaro to duża niefrasobliwość ze strony twórców tej dystrybucji. Niemniej jednak to bardzo proste – robić dystrybucję w ogromnej mierze cudzymi rękami i zrzucić odpowiedzialność za nią na innych. Co ciekawe, to we wcześniejszej swojej dystrybucji Phil właśnie zapewnił alternatywę dla AUR :)
Generalnie – dobra rada: nie kombinować i dopóki to nie jest absolutnie konieczne nie korzystać z rozwiązań innych niż systemowe. Jeśli już jest to konieczne – zapisać sobie gdzieś te paczki, zapisać czy nie wymagają przebudowy po aktualizacji jakichś paczek i… jeśli to paczki z AUR, to szczególnie w Manjaro należy je budować lokalnie, z ominięciem wszelkich ułatwiaczy (yaourt itp.). Tylko takie rozwiązanie (+ jak to mówisz „cache podczaszkowe”) daje dość wysoką gwarancję poprawnego działania tak skonstruowanego systemu.
Czego wszystkim życzę.… AUR jest rozszerzeniem/uzupełnieniem repozytoriów Arch’a, a więc i dziedziczy jego cechy, m.in. wymóg stawiany użytkownikom: świadomość działania. Nie jest dobrym pomysłem dla nieznających jego podstaw, czy niedoświadczonych użytkowników – to nie jest jego target. Nie jest również rozwiązaniem oczywistym, czy pozbawionym kontrowersji, dla dystrybucji będących pochodnymi Arch’a, np. Manjaro.
… mogę jednak założyć koło od motoru do roweru (nikt mi tego skutecznie nie zabroni) – może, to być fajne, może być sensowne nawet; pod warunkiem, że wiem co robię, a jeżeli nie wiem, to potrafię szybko uczyć się, wyciągać wnioski z własnych doświadczeń i weryfikować pierwotne założenia. Najważniejsza, moim zdaniem, jest w tym przypadku zasada (pozwolę sobie na parafrazę): przede wszystkim świadomość, głupcze.
… mam pewien dystans do snap’a ze względów ideologicznych – życie nauczyło mnie, że produkt korporacyjny, to nie jest, to za czym tęsknią tygrysy. Również techniczne aspekty korporacyjności odgrywają w moim uprzedzeniu znaczną rolę. Potwierdzeniem tych ostatnich obaw, są doniesienia o wspomnianych przez Ciebie problemach Ubuntu Snap Store – Canonical dołączył do 'exkluzywnego’ grona dostawców shit’owego oprogramowania.
… konteneryzacja aplikacji, to obecnie trend, którego nie można ignorować i należy mu kibicować, bo pomysł, w swoich podstawowych założeniach, jest genialnie prosty, a skuteczność – teoretycznie – wysoka. Problem w tym, aby wyjść z okresu dziecięcego i dopracować się dojrzałego rozwiązania, a najlepiej kilku. Dlatego cieszę się, że istnieją i rozwijają się takie systemy jak Flatpak, Snappy, AppImage, Docker, NixOS, GoboLinux. Im większe będzie zainteresowanie takimi rozwiązaniami, tym większa szansa na sensowny rozwój, który może przełożyć się zarówno na systemy operacyjne wykorzystujące wyłącznie kontenery, jak i całą resztę, dla której jest, to ciekawe rozszerzenie funkcjonalności.Nie zadawaj pytania, jeżeli nie jesteś gotów usłyszeć odpowiedzi
No to jeszcze co do AUR :) i raz jeszcze. Dokładnie rzecz biorąc AUR to zbiór przepisów na zbudowanie paczki dla Archa. Nic więcej! Każdy taki przepis m.in. dwa „pola”: depends i makedepends. Z punktu widzenia tzw. dystrybucji pochodnych, istotne jest głównie pierwsze. To pole deklaruje jakie zależności są wymagane do uruchomienia i działania paczki zbudowanej w oparciu o taki „przepis”. Z pewnych względów leżących po stronie sposobu budowania paczek dla Archa zasadniczo nie deklaruje się tutaj wersji oprogramowania. „Przepis” ma uwzględniać aktualną wersję paczki, która jest przez nią wymagana, a która znajduje się w repozytorium Archa (ewentualnie w innej paczce w AUR, która też musi być zbudowana na powyższej zasadzie). Arch jednocześnie zakłada pewien idealizm – system jest zawsze aktualny (stąd też moje wieczne boje, by każdą instalację przeprowadzać z opcjami -Syu dla pacmana, a nie -S jedynie). Tak skonstruowana paczka ma działać, czyli uwzględniać to co w Archu jest.
Spośród dystrybucji, które opierają się na paczkach Archa, praktycznie wyłącznie gałąź stable (oraz w pewnej mierze testing) Manjaro jest jedyną, która w danym momencie czasowym nie oferuje (bądź może nie oferować) tych samych wersji paczek „depends” dla „przepisów” w AUR. Jedna jedyna – innej nie ma. Nie istnieje jak dotychczas taka dystrybucja. Chakra uniezależniła się na tyle, że mieszanie repozytoriów Archa i Chakry jest praktycznie niemożliwe. Wszystkie inne dystrybucje pochodne, korzystające z tych samych rozwiązań (np. systemd), jak np. Antergos, Namib, Obarun, Revenge itd. korzystają bezpośrednio z repozytoriów Archa. Antergos zaktualizowany na 28.05.2018, 17:43 ma te same paczki, jakie ma Arch. W przypadku Manjaro tak może być, ale niekoniecznie.
Dodatkowo dochodzi konieczne podbijanie wersji paczek, które opisałem wyżej.
Korzystanie z AUR we wszystkich tych bezpośrednio pochodnych, czyli oferujących w tym samym momencie te same paczki, dystrybucji jest takie samo w przypadku Archa, jak w nich. W przypadku Manjaro tak nie jest.
I teraz – wykaż mi proszę, że AUR jest w ogóle repozytorium dla Manjaro. Jedynie osoby korzystające z Manjaro Testing, przy zachowaniu pewnej roztropności mogą korzystać. Zwróć przy tym uwagę, że Manjaro – zgodnie z deklaracjami twórców – jest adresowane także do mniej obeznanych użytkowników.
Oczywiście możemy doprowadzać dyskusję do absurdu i dyskutować o tym, że nikt nikomu niczego nie zabroni. To idźmy na całość. Nie istnieje żadna, ale to absolutnie żadna przeszkoda, by instalować w Manjaro i to bezpośrednio paczki rpm, czy deb. Wszak oba narzędzia umożliwiające to znajdują się w repozytorium.… trudno się z Tobą nie zgodzić, raz jeszcze mówię, to wyraźnie – to nie może działać, masz rację, ale … No właśnie, problem z tym nieszczęsnym 'ale’, a dokładniej rzecz biorąc z dysonansem poznawczym jakiego doświadczam podczas użytkowania pakietów z AUR. Z jednej strony, przyznaję Ci rację, że nie należy (’nie należy’, a nie 'nie wolno’) tego używać, bo to obca tkanka stanowiąca zagrożenie; a z drugiej, praktyka pokazuje, że nie wiąże się to z takimi problemami, jakich teoretycznie należało by spodziewać się. Być może dlatego, że nie instaluję niczego bezrefleksyjnie, bez analizy; być może dlatego, że gdy napotkam jakieś problemy, to najczęściej rezygnuję, dochodząc do wniosku, że może to być zapowiedzią kolejnych kłopotów – staram się znaleźć kompromis pomiędzy stabilnością systemu (powiedzmy, ok.60%), a jego funkcjonalnością (ok.40%). Fakt, w swoich dotychczasowych wypowiedziach na ten temat, niezbyt raźno wyrażałem pogląd (oczywisty dla mnie, dlatego pewnie słabo go artykułowałem), że koń, to zwierzę generalnie przyjazne człowiekowi, ale należy zachować kilka zasad bezpieczeństwa i ogólny zdrowy rozsądek, aby nie zejść gwałtownie, wskutek niezamierzonego uderzenia kopytem w czaszkę. Porównanie przydługie, ale staram się opisać swój sposób myślenia, bo jako liberał z natury nie podpiszę się pod żadnym zdecydowanym zakazem, chyba że zagrożone, są fundamentalne prawa jednostki lub istotne wartości społeczne. Dlatego, moim zdaniem, trzeba ostrzec i pozostawić wolność decyzji.
… Manjaro tak, to robi. Na swojej wiki ostrzega, że nie wspiera AUR; wyjaśnia dlaczego tego nie robi; informuje, że jest, to repozytorium dla użytkowników Arch’a; ostrzega o potencjalnych niebezpieczeństwach; pozostawia wolność decyzji, informując o sposobach instalacji pakietów z AUR. Mogli pójść drogą Microsof’tu, który wyraźnie dryfuje w kierunku systemu jako usługi z ograniczoną ilością oprogramowania, dostępnego tylko ze sklepu firmowego (przynajmniej w bazowej wersji systemu). Nawet ’Don’tBeEvil’ Google pozwala instalować oprogramowanie z obcych repozytoriów.
… tak, raz jeszcze biję się w pierś i przyznaję, że powinienem wyraźnie – choć bez zbędnych emocji – zaznaczać, że AUR jest potencjalnie niebezpieczne; w zasadzie dla bardziej doświadczonych użytkowników; i cokolwiek z nim robisz, robisz, to na własną odpowiedzialność. Ale przez palce nie przejdzie mi faszystowska myśl (spoko, to tylko figura retoryczna), że mogę napisać komuś, że 'nie może’, albo choćby – nie znając osoby – że 'nie powinien’. Jednoznaczna, krótka informacja z ostrzeżeniem w natywnym języku i prawo do podjęcia własnej decyzji – nawet jeżeli będzie głupia. Widziały gały, na co klikały. Mam pewne doświadczenie w szkoleniu user’ów z obsługi oprogramowania i zawsze kierowałem się zasadą, że należy użytkownikowi wytłumaczyć reguły działania, podnieść poziom świadomości, tak aby wiedział co się dzieje i mógł podjąć własną decyzję, a nie działał mechanicznie (czytaj: bezmyślnie) na podstawie wykutego schematu. Dopłynie, albo utonie – nauczy się, albo zadzwoni o czwartej nad ranem :D Poza kilkoma beznadziejnymi przypadkami – zawsze działało.
… co do sposobu instalacji (-Syu), to zgoda całkowita. U mnie wygląda, to trochę bardziej skomplikowanie, bo stosuję metodę mieszaną – graficzno-text’ową – ale sprowadza się, to do prostej reguły: nie ma instalacji, bez aktualizacji. Zarówno w przypadku pakietów ze 'swojskich’ repozytoriów, jak i AUR – każda aktualizacja jest aktualizacją całego systemu, a każda nowa instalacja poprzedzona jest sprawdzeniem, czy nie ma czegoś do zaktualizowania.Nie zadawaj pytania, jeżeli nie jesteś gotów usłyszeć odpowiedzi
Cóż.. Ze stosunkiem Manjaro do AUR to różnie bywało, a byłem jedną z pierwszych osób (na pewno w Polsce), które zainstalowały tę dystrybucję. Pamiętam też co było napisane na byłym już, nieistniejącym forum Manjaro. W PRowych tekstach pochodzących od jego twórców pojawiały się wówczas informacje o tym, że Manjaro „daje łatwe wsparcie instalacji z AUR” (yaourt instalowany OTB). Pewnie t rudno mi będzie to teraz udowodnić, albowiem strony te przepadły, ale nie czuję się w ogóle do tego zobowiązany. To nie moja obecnie dystrybucja i w istocie można sobie przyjąć radosne stwierdzenie: róbta co chceta.
Odnosząc się do Twoich słów – otóż właśnie Manjaro „tak nie robi”. W swoim wiki nt. AUR w części przenosi tekst z wiki Archa na ten temat, w części pisze bzdury. Natomiast ani jednym słowem nie zająknął się tam nikt, że to nie pakiety z AUR mogą być za stare (to jest drugi z wymienianych powodów, jakie problemy mogą być z paczkami budowanymi z AUR), ale że to… Manjaro (stable) jest często za stare. Nikt nie zająknął się też na temat tego, że paczka z AUR może zostać przebudowana za wcześnie w stosunku do Manjaro. Problem nie leży w tym, że to są „paczki potencjalnie niebezpieczne”, albowiem nikt jeszcze nie wykazał ich niebezpieczeństwa, pomimo że istnieją już kilka ładnych lat, ale w tym, że to nie są pakiety przeznaczone dla Manjaro. Zamiast tego wprowadza się dodatkowo jeszcze kompletnie nieuprawnione i nieprawdziwe stwierdzenia, jak to, że Manjaro jest w 100% kompatybilne z Archem. Nie jest i nigdy nie będzie. Fakt, że paczki w Manjaro w znakomitej większości są – bardzo często bezrefleksyjnie – przenoszone do Manjaro, fakt, że są tak samo budowane nie uprawnia do tego typu twierdzenia. 100% kompatybilność to m.in. możliwość dołączenia do repozytoriów Manjaro stable podstawowych repozytoriów Archa (oczywiście damy je na niższej pozycji w pacman.conf) i możliwość bezkolizyjnego zainstalowania paczek oraz ich w pełni sprawnego działania. Powtarzam: to może się udać, ale to jest przypadek (a sam miałem coś, co można było nazwać ManjArch – właśnie mieszane repozytoria, ale nie o tym).
Jeśli uważasz, że używanie paczek z AUR jest prawidłowe (nie „możliwe”, a „prawidłowe”) to udowodnij proszę tę tezę odnosząc się nie do praktyki („bo mi to działa”), ale uzasadnij teoretyczne aspekty tej tezy. Inaczej pozostanę faszystą, skoro już byłeś mnie do nich przyrównać i będę twierdzić: AUR nie jest przeznaczone dla użytkowników Manjaro, niezależnie od tego co oni sobie o tym wyobrażają. IMO – nic nie przeszkadza korzystać z PKGBUILDów z AUR w Manjaro, ale aby to działało prawidłowo, to Manjaro winno mieć swoją bazę – nazwijmy ją MUR – gdzie będzie miało owe PKGBUILDy dostosowane do stabilnej wersji swego systemu (ta wersja jest przeznaczona dla ZU, a nie testing, czy unstable, gdzie potencjalne kłopoty mogą być mniejsze lub nie będą występować wcale).I popatrz jeszcze raz. Z Twojego wpisu wynika, że zawsze dokonujesz aktualizacji całego systemu, także z AUR. No to raz jeszcze zobacz (to akurat przykład mojej paczki, która absolutnie nie jest dla Manjaro). Jestem opiekunem m.in. plasma-frameworks, która oferuje bugfiksy (głównie) z nadchodzących wydań. Commit, który wskazuję był akurat powiązany z testing Archa, ale wkrótce – po przetestowaniu bodaj przez z górą miesiąc wydań beta i RC Qt5.11, oraz krótkim okresie testowym w testing – ta wersja trafiła do „zwykłego” repozytorium Archa. U mnie pojawiło się podbicie tej paczki ze względu na konieczność przebudowania z uwagi na jej pewną zależność tego wymagającą (to nie jest reguła; nie wszystkie zależności wymagają przebudowania paczki). Załóżmy teraz, że to jest w AUR i że korzystasz z tej paczki. Dokonując „graficzno-tekstowej” aktualizacji systemu, także w stosunku do tego co w AUR (nie wiem z czego korzystasz, ale to nie jest istotne kompletnie), jeśli korzystasz z jakiegoś AUR-helpera/wrappera otrzymasz informację, że plasma-frameworks (której przecież używać jest nieakualna i wymaga budowy). Co zrobi 99% użytkowników (tak Manjaro, jak i Archa, ale w tym drugim przypadku nie jest to wrażliwe)? Prawdopodobnie dokona budowy nowej wersji paczki (zwróć uwagę, że w przypadku mojego PKGBUILDu masz wersję paczki z „.” -> X.Y, gdzie X zawsze odpowiada wersji w repozytorium, Y zaś jest kolejną wersją tej właśnie paczki; gdy pojawia się nowa paczka w Archu, czyli będzie to coś co jest >X.Y, to zostanie w systemie zainstalowana właśnie ona – cały system będzie działać, a ktoś, kto używa mojej paczki jedynie zostanie ewentualnie przez pewien czas pozbawiony jakiejś funkcjonalności, bugfiksu; w przypadku paczek z AUR najczęściej tak to nie wygląda). Kilka dni temu dowiedziałbyś się zatem o istnieniu nowej wersji plasma-frameworks i najprawdopodobniej dokonasz jej zbudowania (ile osób czyta changelogi?). Dokonasz tego zupełnie zbędnie, albowiem do dzisiaj w stable, a nawet w testing Manjaro nie istnieje paczka, ze względu na którą konieczne jest dokonanie przebudowy plasma-frameworks. Tu jeszcze nic się złego nie dzieje – przebudujesz po prostu bez sensu, ale system będzie działać prawidłowo. Kiedy jednak do stable (czy nawet testing) trafi już paczka, ze względu na którą wymagane jest przebudowanie, to już w żaden sposób nie zostaniesz poinformowany o takiej potrzebie (wszak użytkownicy Archa zostali poinformowani wcześniej, a nikt kto tworzy paczki dla AUR nie tworzy ich z myślą o Manjaro, ba sam uczestniczyłem w ich usuwaniu :)). Dokonując zatem aktualizacji systemu dokonasz aktualizacji systemu z repozytoriów (prawidłowo), nie dokonasz natomiast koniecznej aktualizacji (czy jak w tym przypadku choćby przebudowania) paczek z AUR i… system po reboocie może nie wystartować wcale.
Oczywiście z tym samym problemem spotykają się użytkownicy Archa, ale tam to jest ewentualne zaniedbanie użytkownika – w przypadku Manjaro to błąd systemowy.
Opisany powyżej przykład to jedynie jedna z postaci błędu, jakiego doświadcza nieświadomy mniej lub bardziej, czy nawet świadomy użytkownik Manjaro korzystający z AUR (teraz mówię sprawdzam: jesteś doświadczonym użytkownikiem paczek z AUR, powiedz mi proszę, które z nich wymagają przebudowania po dostarczeniu nowej wersji zależności do repozytorium, które nie wymagają przebudowania pomimo, że dostały nową wersję?). Dodatkowo dochodzą pewne rozwiązania, które nie są kompatybilne ze sobą. AUR nie uwzględnia istnienia czegoś jak mhwd (i jego pochodne, bo zostało to już sforkowane do kilku innych dystrybucji), a z drugiej strony rozwiązania Manjaro nie uwzględniają tego co w AUR itd. Paczka z AUR w Manjaro jest równie wadliwa w nim jak paczka z dowolnego innego systemu.
Niemniej jednak, jeśli wykażesz mi, że pomimo tego wszystkiego AUR jest składnicą, z której w sposób bezpieczny dla siebie mogą korzystać ZU (przypominam główną tezę Manjaro: Manjaro is a user-friendly Linux), przy czym nawet w podstawowej informacji o Manjaro, jego twórcy chwalą się, że dystrybucja ta zapewnia dostęp do AUR: (Access to the Arch User Repository (AUR), czyli tam gdzie PR – zapewniamy AUR, tam, gdzie szczegóły do których stosunkowo mało kto sięgnie, z uwagi na to, że AUR w Manjaro działa OTB – to jednak obecnie – umywamy ręce), to zrobię uszy po sobie. Jak na razie nie widzę nigdzie żadnego merytorycznego argumentu, który od bodaj 6 lat używania Manjaro i Archa uzasadniłby tę tezę.… no tak, wiedziałem, że nie darujesz sobie tego faszysty, choć wyraźnie napisałem, że to nic osobistego – tylko forma retoryczna. Never mind.
… Manjaro zapewne zmieniało swoje podejście do AUR – sam pamiętam (dokładniej, coś mota się po zamglonej pamięci) jakąś informację o 'powrocie’ AUR do Manjaro. Trudno wyrobić sobie zdanie na ten temat, nie znając szczegółów, przede wszystkim motywacji tych zmian. Spekulując, oficjalna obecność AUR, mimo oficjalnego braku wsparcia, bierze się z chęci rozszerzenia oferty oprogramowania – zapewne. Albo z przekonania (mnie taka myśl przyszła do głowy, więc i chłopakom z Manjaro mogła), że ludzie i tak będą używać AUR, więc może lepiej dać jakieś 'nieoficjalne wsparcie’, tak aby zmniejszyć potencjalne problemy. Spekulacje, same spekulacje.
… pakiety z AUR, są potencjalnie niebezpieczne – w Manjaro. Nie z powodu ich niebezpiecznej natury, tylko z powodu braku synchronizacji w rozwoju obu rozwiązań. Ja natomiast nie jestem doświadczonym użytkownikiem AUR, o czym już wcześniej pisałem – znam jednak zasady funkcjonowania tego mechanizmu; na tyle, że wystarcza mi, to na obecnym etapie rozwoju.
… trudno mi się z Tobą polemizuje, bo czytając Twój text mruczę 'no’, 'tak’, 'jasne’, 'oczywiście’. Z większością Twoich głównych argumentów zgadzam się. Motamy się w drobiazgach technicznych (może te informacje będą dla kogoś przydatne, nie deprecjonuję ich), np. w rozważaniach o tym co jest bardziej spóźnione, tracąc z oczu istotę sprawy. Istota, moim zdaniem, zawiera się w odpowiedziach na dwa pytania:
1) Czy AUR jest dla Manjaro? Obaj zgadzamy się, że nie (choć odnoszę wrażenie, że starasz się przekonać mnie o tym, że mam inny pogląd na tą sprawę). Wielokrotnie pisałem, że nie, napiszę raz jeszcze – AUR nie jest dla Manjaro.
2) Czy można używać pakietów z AUR w Manjaro? Tutaj różnimy się. Ty uważasz, jak sądzę, że zdecydowanie nie można, nie należy, herezja. Ja z kolei, że można, po spełnieniu paru warunków. Inaczej: Ty jesteś zdecydowanym przeciwnikiem alkoholu, bo to dla niego trucizna; ja natomiast uważam, że zachowując zdrowy rozsądek można go użyć – bez szkody dla innych, z pożytkiem dla siebie.
… zgadzamy się co do założeń teoretycznych. Różnimy się co do opinii nt. praktycznych implementacji. I dobrze. Cywilizacja trwa i rozwija się dzięki różnicom i tarciom z nich wynikających :-)Nie zadawaj pytania, jeżeli nie jesteś gotów usłyszeć odpowiedzi
@azja – Bardziej staram się wytłumaczyć jakie problemy rodzi korzystanie z AUR w Manjaro (pominąłem jeszcze jeden oczywisty, choć go gdzieś zaznaczyłem – dodać do nich należy „zwykłe” problemy z AUR w Archu), bowiem to nie jest nigdzie napisane.
Manjaro jest dystrybucją adresowaną m.in. do ZU. Tu nie ma „ostrzeżenia”, jak w przypadku Archa, że to dystrybucja dla co najmniej średnio zaawansowanych. Jest deklaracja, że jest przyjazna użytkownikowi. I zwróćmy uwagę: w Archu nie istnieje żadne wsparcie dla AUR. Jest oczywiście strona wiki (ale wiki Archa jest społecznościowe), ale np. narzędzia automatyzujące korzystanie z AUR (w tym budowanie paczek), dopóki AUR nie otrzyma oficjalnego wsparcia ze strony Archa (a pewnie długo tak się nie stanie, o ile w ogóle) są w… AUR :) One również w żaden sposób nie są wspierane, a info odnośnie kompilacji z AUR jest od dawna niezmienne: ściągnij źródła, przeglądnij pliki, w katalogu wydaj polecenie makepkg, sprawdź co powstało, zainstaluj. W przypadku Manjaro otrzymujesz te narzędzia przy pierwszej instalacji. Pamac zawiera, Octopi po zainstalowaniu jednego z trzech (w tym jednego porzuconego helpera), w tym jednego – i to najgorszego z możliwych – instalowanego również bodaj z systemem, również.
Skoro ZU otrzymuje taki system OTB, to myślisz, że zastanowi się jakie konsekwencje niesie paczka z AUR? Szczerze wątpię. Skoro jest taka możliwość dawana przez twórców, to oznacza, że… jest ona przez nich zaplanowana i uznawana za możliwą i bezpieczną (inaczej to jak siedzenie na gałęzi i jej podcinanie). Dodatkowo dochodzą informacje o 100% kompatybilności z Archem, co nie jest prawdą (kompatybilne w ten sposób są np. Calculate, czy Sabayon z Gentoo, ba można nawet stwierdzić, że kompatybilny jest np. Antergos z Archem, ale nie Manjaro z Archem). Innymi słowy – wg mnie – użytkownicy Manjaro przez twórców tej dystrybucji są nabijani w butelkę.
Ok, można powiedzieć – nie moja dystrybucja, cóż mi do tego co w niej robicie. Tyle, że moją jest Arch i potem otrzymuję w komentarzach instalowanych, albo nawet tworzonych przeze mnie paczek jakieś bzdurne komentarze, że coś nie działa, jest popsute… Potem to mój czas jest marnotrawiony, bo nikt nawet nie stwierdzi: mam Manjaro (wówczas, sorry – radź sobie sam, to nie dla ciebie). To oczywiście nie ma większego znaczenia dla użytkownika Manjaro. Ba, nawet jestem w stanie go zrozumieć, albowiem w jego dystrybucji zostało stwierdzone, że dostęp do AUR ma zagwarantowany. Nieistotne.
Wracając do tego czy można, czy nie. Oczywiście na poziomie możliwości jest to w Manjaro dostępne. Narzędzia, jakie otrzymuje Manjaro, które są wprost przejęte z Archa (cały pacman), czy korzystające z rozwiązań w AUR (yaourt, octopi), czy też nawet jego własne oczywiście, że umożliwiają korzystanie z AUR. Ba, zakazu nie ma, wręcz odwrotnie. Tyle, że… odpowiedz sobie na pytanie:
Czy istnieje w Manjaro możliwość:
– dodania do listy jego repozytoriów repozytoriów Archa, w tym np. kde-unstable lub gnome-unstable?
– dodania repozytoriów nieoficjalnych Archa, bądź np. Antergosa i innych jego pochodnych?
– instalacji paczek deb bądź rpm narzędziami, które znajdziesz – jeśli nie w repozytorium Manjaro, to w AUR?
Pytanie retoryczne, bo oczywiście, że to wszystko jest możliwe. Pytanie zasadnicze, czy choć jedną z tych opcji poleciłbyś komuś. Czy w ogóle, ktokolwiek rozwijający Manjaro taką opcję by scharakteryzował jako np. „access to Arch repository”, „possibility to install rpm or deb packages” itp.
Ty patrzysz przez pryzmat możliwości, ja przez pryzmat konsekwencji dla użytkownika. O ile na pierwsze pytanie odpowiedź jest także oczywista – tak istnieje, to w przypadku przyjęcia tego drugiego spojrzenia oczywistość ta nie jest już tak klarowna. A skoro przy różnych przypowiastkach o kołach od roweru w motocyklu, to podam Ci jedną z innej branży. Argumentacja: nie jest zabronione, to jest możliwe niekoniecznie musi być właściwa. W polskim prawie nigdzie nie znajdziesz pozytywnej normy, że nie wolno zabijać. Pomimo tego kodeks karny przewiduje konsekwencje takiego czynu.
Podobnie z AUR, czy opisanymi przeze mnie w pytaniach powyżej możliwościami. Tak, to wszystko jest możliwe, ale konsekwencją jest wadliwie działający system. I tylko o to mi chodzi, że w imię PR ktoś, gdzieś, w Manjaro zadeklarował: dajemy możliwość mieszania dystrybucji, zamiast pójść własną drogą i w istocie zrobić dystrybucję, która jest bezpieczna dla swego użytkownika. A na ile ów „AUR dla Manjaro” tkwi w głowach jego użytkowników (tkwił w mej również, gdy z niego korzystałem, wszak używałem część programów z AUR, dlaczego nie? :)), to zobacz sobie na swoją odpowiedź w jednym z wątków. Tutaj twierdzisz, że „AUR nie jest dla Manjaro” (pkt. 1 w Twojej odpowiedzi powyżej). We wspomnianym wątku natomiast, w kolejności „poszukiwania” paczek, na drugim miejscu sugerujesz właśnie paczki z AUR.
I powtórzę: tak, zgadzam się z Tobą. Istnieje możliwość zbudowania w Manjaro paczki na podstawie PKGBUILDu zawartego w AUR. Co do tego nie ma żadnej kontrowersji między nami – gdybym robił PKGBUILD dla Manjaro, to prawdopodobnie wyglądałby on tak samo jak dla Archa (pomijając pewne okresy, gdzie takiego samego zbudować się po prostu nie da). Natomiast samo AUR, a w szczególności umożliwiony przez Manjaro sposób korzystania z AUR jest – wg mnie – całkowicie niedostosowany do… Manjaro, a konsekwencje tego prowadzić mogą do wadliwego działania systemu. I jeszcze by postawić kropkę nad „i” – jeśli w Manjaro zostanie zbudowana jakakolwiek paczka na podstawie jakiegokolwiek PKGBUILDu, który w chwili jego stworzenia był do Manjaro dostosowany, a następnie osoba, która to zrobiła przejmie kontrolę nad taką paczką (czyli stanie się jej, w swoim systemie, deweloperem), to nie istnieje żadne zagrożenie. System będzie działać poprawnie i bez żadnych konsekwencji w postaci jego destabilizacji. Problem leży gdzie indziej, ale to już wiesz.… zacznijmy od didaskaliów. Nie rozumiem przypowieści o zabójstwie:
# w polskim prawie jest pozytywna norma: nakaz udzielenia pomocy w sytuacji zagrożenia życia i prawo antyaborcyjne;
# jest również norma negatywna: zakaz zabijania, zabójstwo jest wyraźnie zabronione.
… do rzeczy. Polityka informacyjna Manjaro, być może, nie jest właściwa. Być może, bo nie analizowałem tematu i nie przykładam do tego większej wagi (może niesłusznie). Nie mam na ten temat zdania, ale Twoje zastrzeżenia wydają się być sensowne, więc roboczo zakładam możliwość istnienia problemu. Nie należy jednak wyciągać daleko idących wniosków na podstawie marnych przesłanek, bo przecież nie wiemy (ja nie wiem) dlaczego twórcy i developerzy Manjaro podejmują takie, a nie inne decyzje a propos AUR. Jak już wspominałem wcześniej, skazani jesteśmy na spekulacje; diagnozujemy konkretny rodzaj nowotworu na podstawie częstotliwości mrugania pacjenta.
… wsparcia (oficjalnego) dla AUR nie ma, zarówno w Arch’u, jak i Manjaro. W obu dystrybucjach występuje w tej kwestii schiza, bo nie wspieramy, ale instruujemy, w jaki sposób korzystać. Rzecz jasna, z powodów wielokrotnie wymienianych, w Arch’u jest to tylko lekko niestosowne, w Manjaro bardzo, bardzo. Do tego dochodzi problem (j.w. roboczo zakładam jego istnienie) niewłaściwej polityki informacyjnej, co może powodować zamieszanie. Nie zmienia, to jednak faktu, że Manjaro na każdym kroku ostrzega o niebezpieczeństwie: w Wiki, w funkcjach włączających obsługę AUR, przy każdej instalacji pakietu z AUR. Ludzi, którzy nie czytają komunikatów nie uratuje żaden bezpieczny system, który będzie za nich myślał. Wcześniej, czy później 'zabije’ ich, bo zgadzają się na wszystko. Sądzisz, że wszelkiego rodzaju zabezpieczenia we współczesnych samochodach wyeliminują lub zrównoważą masę idiotów jeżdżących po drogach? Za to ci, którzy potrafią sprawnie i bezpiecznie poruszać się samochodem, są współczesnymi technologiami ograniczani. Nie po to migrowałem z Windows’ów na Linux’a, aby słuchać 'nie wolno’, 'nie rób’, etc; nie po to, aby producent lepiej wiedział czego mi potrzeba. Oczekuję sensownej funkcjonalności i rzetelnej informacji nt. skutków ich wykorzystania, tak aby podjąć racjonalną decyzję. Wchodzenie na Chłopka czy szwendanie się po Granatach nie jest dla ludzi, bo wiąże się z niebezpieczeństwem i jest niezgodne z instrukcją obsługi człowieka, który ewoluował na równinach i dla którego, teoretycznie, drzewo stanowi wyzwanie. Nie chcę dożyć czasów, w których zamknie się takie miejsca dla ludzi, w imię ich bezpieczeństwa.
… Ty chcesz uchronić ludzi przed niebezpieczeństwem i uważasz, że jest, to możliwe. Po pierwsze, realne jest tylko poczucie bezpieczeństwa, a bezpieczeństwo sensu stricto, to termin czysto marketingowy. Bezpieczeństwo nie istnieje. Po drugie, nie zapewnisz ludziom bezpieczeństwa, ponieważ źródło zagrożenia jest w ludziach, a nie w czynnikach zewnętrznych.
… ja wychodzę z założenia (popartego wieloletnimi doświadczeniami i przemyśleniami), że ludzi należy edukować, przekazywać im wiedzę nt. metod przeżycia, a nie iluzorycznie chronić przed niebezpieczeństwem. Jaki fundamentalny błąd wychowawczy popełnia większość rodziców? Chroni swoje dzieci przed każdym niebezpieczeństwem – bakteriami, otarciem kolan, złą oceną w szkole. Chcą chronić, a krzywdzą. Z user’ami jest tak samo – należy edukować. Oczywiście, mądrze skonfigurowany system, to podstawa, zawsze; ale bez edukacji, to d…
… z mojego punktu widzenia ten wątek spełnił swoje zadanie. Pozwolił mi spojrzeć z innej strony na, teoretycznie, znany mi temat. Zmieniłem zdanie, co do sposobu informowania innych nt. wykorzystania AUR w Manjaro (należy wyraźnie zaznaczać, że możesz, jeżeli wiesz co robisz). Upewniłem się również w przekonaniu, że kierunek na rozwiązania kontenerowe, jako rozszerzenie funkcjonalności systemu, jest właściwy. Mam nadzieję, że inni również skorzystają na tej potyczce – pojawiło się sporo konkretnych informacji i trochę różnorodnych poglądów, które mogą stanowić zachętę do refleksji. Czytajcie, analizujcie i podejmujcie WŁASNE decyzje.Nie zadawaj pytania, jeżeli nie jesteś gotów usłyszeć odpowiedzi
@azja – Dla mnie to również ciekawa wymiana poglądów, poznanie innego punktu widzenia (choć przecież również i mi i to z własnego doświadczenie z systemem, o którym piszemy, znanego). Nie – nie zakazuję niczego, choć wprost mówię: AUR nie jest dla Manjaro pomimo „pomocnictwa” (wracając na chwilę do prawniczego żargonu), jakie jest udzielane przez jego twórców (w istocie w Manjaro nie ma wsparcia dla paczek z AUR na poziomie „supportu” udzielanego – przynajmniej oficjalnie – przez twórców; dostarczanie wraz z systemem /i to od samego początku/ narzędzi dla korzystania z AUR ja rozumiem jednak jako „wsparcie” dla AUR; takie samo znajdziemy choćby w Antergosie, w Anarchy-Arch, RebornOS itd.; to nie jest wyłączna domena Manjaro i także tam opiekunowie tych dystrybucji „nie udzielają wsparcia” :)).
To, co napisałem powyżej traktuję właśnie w kategoriach… hmmm… edukacyjnych (nie Ciebie, ale w ogóle użytkowników Manjaro, którzy hurra optymistycznie podchodzą do możliwości instalowania z AUR. Te wywody, czy polemika z Tobą, to tylko unaocznienie pewnego problemu pn. „piekło zależności”, który jest zresztą moim zdaniem nadużywany.
Podsumowując swoje zdanie:
– tak, uważam, że w żadnym przypadku AUR nie jest stworzone do bezpośredniego korzystania z niego w Manjaro,
– tak, można na podstawie tych przepisów skonstruować paczkę dla Manjaro, która może w nim działać prawidłowo.
Najważniejsze, czego może nie powiedziałem (choć wiem, że Twoje zdanie tu jest takie samo), że Manjaro (choć w zasadzie dowolna dystrybucja, włączając Archa), w którym znajduje się paczka budowana z AUR jest systemem, którego osoba, która tego dokonała jest całkowitym i wyłącznym opiekunem. Bierze na swoje bary odpowiedzialność za to, czy będzie to działać, czy nie. Taką paczką, którą zbudował musi się samodzielnie opiekować i wiedzieć, czy dostarczenie do systemu nowej wersji jej zależności wymaga, czy też nie wymaga jej co najmniej przebudowania, bądź sięgnięcia po jakieś patche (przykład pierwszy z brzegu: octopi-git, które nie zadziała w tym momencie w Archu, oraz octopi-git z dodatkowym alpm_octopi_utils, które zadziała /pewnie to jeszcze zmodyfikuję, by octopi wymagało podbicia alpm_octopi_utils; choć napisałem to w wątku, gdzie POLAUR jest opisywany/). Przede wszystkim jednak będzie musiał też wiedzieć, czy zbudowana z AUR paczka ma wpływ na to, czy system uruchomi się po aktualizacji (chodzi o repozytoria), czy też nie. Przykład z octopi jest banalny (a i tak w Manjaro pewnie dostaniecie go w nowej wersji, gdy wejdzie pacman 5.1 oraz Qt5.11) – tu nie zadziałałaby jedna aplikacja, która nawet nie jest w ogóle wymagana do działania systemu. Problem zaczyna się choćby w prozaicznych paczkach, o których wiele osób nawet nie ma świadomości, że mają one wpływ na działanie systemu (przynajmniej DE) jak choćby tematy, wystroje, pluginy itp. itd. dla używanego środowiska. Tu jest pies pogrzebany.I w kwestii owych kontenerów jeszcze. Dla mnie w tej chwili istnieją dwa: AppImage i flatpak. Ich podstawową bolączką jest, że… oferują mniej niż to, co mamy w repozytoriach (tak w Twoich, jak i moich). Jeśli flatpak w istocie się przyjmie, to być może będzie to jakaś dobra alternatywa dla AUR w Manjaro (choć najlepszą – moim zdaniem – byłoby powstanie „MUR”). W przypadku AppImages – nie ma róży bez kolców. Na kilkanaście paczek, jakie próbowałem, uruchamiała się mniej więcej połowa. Wynika to ze sposobu ich budowania i tego konsekwencji (a zwykle budowane są na jakichś mocno – w stosunku do naszych systemów – „starych” już Debianach, czy CentOSach). W takim przypadku pozostaje przebudować taki AppImage samemu na podstawie podobnych przepisów jak PKGBUILDy (a jest ich dostępnych w sieci nawet więcej niż zbudowanych paczek). To jak się wydaje jednak droga dla lekko bardziej zaawansowanego użytkownika, choć problemu wielkiego nie ma: ściągnąć *.appimage, wykonać budowanie lokalnie – winno zadziałać.
Będąc raczej ograniczonym entuzjastą rozwiązań kontenerowych (z bardzo wielu powodów) – uważam, że może się ono okazać dobrym wyłącznie dla bardzo mało doświadczonych użytkowników. Ci, którzy dysponują odpowiednią wiedzą winni się jednak wziąć z bykiem za rogi i spróbować budować paczki we własnym zakresie nawet na podstawie PKGBUILDów w AUR, ale… nie z wykorzystaniem AUR :) (innymi słowy – uważam, że dopiero w przypadku Manjaro wychodzi kompletna nieprzydatność jakichkolwiek aurhelperów). No i niestety potem dbać.
PS: Już śpieszę wyjaśnić to, co sygnalizowałeś, że jest niezrozumiałe. Otóż art. 148 k.k. nie zawiera żadnej pozytywnej normy. Jest wyłącznie sankcją. Prawnik to rozróżnia. Nie znajdziesz w polskim prawie normy, jak katechetyczne V przykazanie Dekalogu. Jak polskie prawo długie i szerokie, niestety, nie istnieje norma mówiąca: Zakazuje się zabijać inną osobę (pomijam kwestie związane z aborcją; nie mieszajmy tu tego). Taka norma byłaby pozytywna. Art. 148 k.k. mówi jedynie o konsekwencjach zabicia innego człowieka (sama sankcja).
Przekładając to na „nasze”. Nie istnieje „pozytywna” norma mówiąca, że AUR w Manjaro stosować nie wolno (ba, jak wspomniałem wręcz istnieje ku temu całe, dość rozwinięte „pomocnictwo”). Masz natomiast sankcję – stosowanie paczek zbudowanych z AUR w Manjaro jest źródłem problemów w działaniu tej paczki bądź całego systemu, do braku możliwości jego uruchomienia włącznie.
No i dzięki za pogaduchy.… @pavbaranov -> jeżeli czasu starcza, to zawsze chętnie – również dziękuję za inspirującą dyskusję :-)
Nie zadawaj pytania, jeżeli nie jesteś gotów usłyszeć odpowiedzi
- Musisz być zalogowany aby odpowiedzieć w tym wątku.