Udzielone Odpowiedzi
- Posty
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ę.Ś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ę.@warsztat-dom – Zatem w pierwszej kolejności, bezwzględnie wykonujesz to o czym napisał @czapnaper, a potem to co podałem. Potem ponowna instalacja VB (najlepiej też jakieś wersje dkms) i reszta, o której pisałem. Ma działać. Jeśli nie będzie, to wówczas przeczytaj to z wiki Archa i rozeznaj się w systemie, co i jak to wygląda. Jeśli będziesz miał jakieś problemy – zgłoś.
Paczka virtualbox-ext-oracle (z AUR lub instalowana ręcznie) to zupełnie co innego dodaje/rozszerza zupełnie inne funkcjonalności
UPS, mea culpa i uszy po sobie.
Zatem @warsztat-dom – masz zainstalować paczkę virtualbox-ext-oracle, oficjalnie tak:
1. Upewnić się, czy grupa base-devel jest zainstalowana, jeśli nie – zainstalować.
2. Odinstalować do spodu paczkę wskazaną przez Ciebie w pierwszym wątku, czyli z https://www.techworld.com/. W razie problemów należy system wyczyścić z całego VB i jego różnych pozostałości (przełącznik dla pacmana: -Rcns, ale ostrożnie). Ewentualnie jeszcze przeglądnąć, czy to z techworld, gdzieś się nie posiało po systemie. W razie wątpliwości pytaj.
3. Wykonać:git clone https://aur.archlinux.org/virtualbox-ext-oracle.git cd virtualbox-ext-oracle makepkg -sirc@czapnaper – Wiki Archa jest lekko już stare. Paczka virtualbox-ext-vnc znajduje się w repozytorium community obecnie.
@warsztat-dom – Nie jestem lekkim i miłym współpracownikiem na forach, bo zwykłem nazywać rzeczy po imieniu, a w obecnym społeczeństwie nie jest to politycznie poprawne (tak, zdaję sobie z tego sprawę). „Idiotyczne” nie niesie u mnie żadnego ładunku, charakteryzuje jedynie coś. Możemy znaleźć jakiś eufemizm. Nie bierz w każdym razie tego do siebie, bo nie o Ciebie mi w tym chodzi, a o czynność, sam sposób w jaki program działa. Jeśli wziąłeś do siebie – nie było to moją intencją – przepraszam.Niemniej jednak znów chcesz wykonać taką czynność :)
W wolnym czasie sprawdzę paczki z archa bo mnie kusi sprawdzić czy i tam nie będzie problemu z usb2.0.
Możesz mi powiedzieć co Cię kusi, by mieszać dystrybucje? Do Manjaro trafia niemal 100% tych paczek, które są tworzone w Archu (wyjątkiem są paczki, które są tu tworzone i zastępują oryginalne paczki Archa). Paczki te znajdują się w repozytorium Manjaro. Wszelka instalacja ma się odbyć z tych repozytoriów. Jest także paczka rozszerzeń VB. Koniec kropka.
I raz jeszcze problem nie leży w samej paczce (czy ona jest z Archa, czy z Manjaro to jest to ta sama paczka). Problem leży w konfiguracji i raz już Ci link do rozwiązania podałem. Masz zatem zastosować się do niego, a nie kombinować z jakimiś innymi paczkami. Jeśli sposób tam opisany nie będzie działać, to wówczas to przedstaw. Pomyślimy co dalej.
Przy okazji – ja mam 52. Średnią zawyżam :)
Ok ale jak już napisałem na paczce ext z Manjaro nie szło włączyć usb2.0.
Bo nie czytasz… :) Proponowałem wiki Archa (bo jest dziesiątki razy lepsze od wiki Manjaro i rozwiązuje problemy): Twój winien być rozwiązany tutaj.
Raz jeszcze, bo chyba nie doszło: używanie oprogramowania GUI pod Xami na prawach roota jest ostatnim idiotyzmem. Nie tak się to rozwiązuje, a uprawnieniami.Virtualboxa mam w najnowszej wersji po aktualizacjach 5.2.12 i takiego też pobrałem packa (https://www.techworld.com/download/system-desktop-tools/virtualbox-extension-pack-5212-3249099/?linkid=185645)
To nie jest z menedżera pakietów. Pewnie samo VB zainstalowałeś z menedżera, ale paczkę rozszerzeń już nie. Jedno i drugie – z tego samego źródła.
Dlaczego nie używasz paczek VB z repozytorium i dlaczego instalujesz w systemie paczki, które nie są dla niego przeznaczone? Prędzej, czy później takie czynności skutkują rozwaleniem sobie systemu.
Ja mam Archa, ale biorąc pod uwagę, że większość paczek jest do Manjaro przenoszonych z niego, to:
– samo VirtualBox,
– paczka rozszerzeń,
– inne, które również się przydają.
Również o całej instalacji oraz – dla porównania – w Archu (to drugie niesie sporo więcej treści).
Nazwy paczek nie powinny się różnić.
Dlaczego program, który tego nie wymaga (ba, nawet nie jest to wskazane) w ogóle usiłujesz uruchamiać z prawami administratora?! To wprawdzie nie musi doprowadzić do rozwalenia systemu, ale po prostu nie jest bezpieczne i generalnie wysiłki już chyba wszystkich deweloperów idą w kierunku uniemożliwienia w ogóle uruchamiania jakiegokolwiek programu z GUI na prawach roota…@Robert75 – Mint nie jest taki zły jak go malują (w tym ja), przynajmniej w obecnych swoich 3 wersjach. Dopóki działa. Jeśli coś przestanie, to jakiejkolwiek dokumentacji brak. Trzeba się posiłkować Ubuntu/Debianem. Inna sprawa, że cenniejsze od Minta (dystrybucji) jest środowisko Cinnamon przez nich rozwijane. I prawdopodobnie, gdyby w 100% poświęcili się samemu środowisku od czasu do czasu wydając „poglądową” wersję (opartą o cokolwiek, mniej więcej wówczas, gdy wychodzi nowa wersja Cinnamona), to byłoby zdecydowanie lepiej.
@napcok – Najśmieszniejsze, że najbardziej popularny system na desktopy jest bardzo zbliżony do rolling release. Przynajmniej w takiej formule, w jakiej pokazuje się np. Manjaro. Biorąc pod uwagę problemy z jego aktualizacjami, to nie robi dobrej marki dla rolling release (ale przynajmniej w odniesieniu do niego nikt tego sformułowania nie używa). I by było śmieszniej. Przysłowiowej Pani Basi, rolling release ustawione przez kogoś i aktualizowane raz na czas, będzie pracować zdecydowanie lepiej niż owym lekko lub średnio zaawansowanym użytkownikom („średnio” = tym, którzy takie mniemanie o sobie mają). Ci przy braku pojęcia jakie są konsekwencje zmian dokonywanych w swoim systemie bardzo często doprowadzą do: „X jest jakiś taki niestabilny i znów muszę postawić system od nowa” (oczywiście w miejscu X może być dowolne Manjaro, Antegos, czy cokolwiek).Manjaro okupuje pierwszą pozycję od paru miesięcy. Świadczy, to o dużym zainteresowaniu systemem.
Statystyki distrowatch.com absolutnie o niczym nie świadczą. Zobacz sobie jak one są tworzone (zob.: informacja o zasadach rankingu). Ranking ten świadczy wyłącznie o tym, że ileś osób mających dystrybucję zgłaszającą się w określony sposób (uwaga można to łatwo zmienić) odwiedziło tę stronę. Zrób sobie test i przeglądnij np. ostatnie 7 dni itd. Wyszłoby na to, że taki TurnKey jest popularniejszy od CentOSa by nie wspominać już o zdeklasowanym przezeń Xubuntu. W ostatnich 30 dniach natomiast zaobserwować można na 9 miejscu „klon” WinNT/XP pn. ReactOS, który jest – pomimo tego, że wciąż w fazie dość wczesnej bety – „dystrybucją” bardziej popularną od RedHata (którego deklasuje z jego 38 miejscem). Itd. itp.
Pozostaje jednakże zupełnie inną sprawą, że Manjaro cieszy się pośród osób tak już używających linuksa, jak i chcących się z nim zapoznać pewnym zainteresowaniem. W zależności od kraju można je nawet uznać za „duże”.Nie używam kosza, ale ten winien być w ścieżce: ~/.local/share/Trash. Masz tam dwa podkatalogi: info oraz files. Przeglądnij sobie co i jak, ale o ile wiem, to nie powinno tu być jakichś symlinków, tylko fizyczne pliki. Jeśli jest jak sądzę, to plik z kosza podlega usunięciu na zasadzie „rm ~/.local/share/files/plik” oraz przebudowane zostaje to co w info.
Cała zabawa z „koszem” polega na tym, że „kasowany” plik nie jest „fizycznie” (żaden nie jest, chyba, że przez wipe, ale to na inny temat) usuwany z dysku, tylko zostaje przenoszony do kosza. „Usuń do kosza” jest zatem równoważne:`
mv <path>/file ~/.local/share/Trash/files
i stworzeniu odpowiedniej informacji w info, a nie:
rm <path>/file
Odłącz sda6 i możesz usuwać do woli. Nawet jeśli jestem w błędzie (co na 99,9999% wykluczam) to niczego nie zrobi złego.
Pamiętaj jednak – usunięcie z kosza = rm plik :)Jeśli kosz jest na innej partycji niż sda6, to wyczyszczenie kosza nie zrobi niczego na sda6.
Skoro masz tam pliki z sda6, to je po prostu odzyskaj. Część roboty za Tobą.
Niemniej jednak – do czasu uporania się z odzyskiwaniem plików z sda6 po prostu odmontuj tę partycję na stałe. Jak coś będziesz na niej robić chciał – to będziesz ją montować. To jedyna gwarancja nienaruszenia czegokolwiek tam.Uruchom ten system na innym użytkowniku. Jeśli nie masz – stwórz. Zobacz, czy również obserwujesz ten sam problem. Inaczej nikt nie będzie wiedzieć, czy problem wynika z jakiejś Twojej konfiguracji, czy leży gdzieś głębiej w systemie.
