Udzielone Odpowiedzi
- Posty
Kart graficzne mam od nowości dwie zintegrowane, druga to Ge Force.
I tu może leżeć problem ze startowaniem Manjaro. W trybie „livecd” w przypadku „podwójnej” karty, Manjaro zawsze chyba się uruchamia na Intelu. Po instalacji – cóż – tę należy prawidłowo przeprowadzić dla takiego typu kart (niekiedy/najczęściej może to wymagać jakiejś korekty). Debian w takim przypadku, jeśli jest instalowany z „oficjalnej” wersji ISO to wykorzystuje również albo Intela (bardziej prawdopodobne) albo nouveau (mniej prawdopodobne). Stąd – pozornie – problem nie istnieje (istnieje, ale na innym poziomie).
Jeśli to taki układ (bo na razie to dalej wróżymy z fusów, a co post to okazuje się, że masz tam coś innego) to przeczytaj o kartach hybrydowych i instalacji systemu w takim przypadku. Powinno być w podręczniku, który Ci podesłałem.PS. To, czy chcesz używać Debiana, czy Manjaro – dla nas nie ma żadnego znaczenia. W przypadku Manjaro będziesz mógł liczyć na pomoc z naszej strony. W przypadku Debiana – nie (i nie dlatego, że nikt z nas go nie zna, bo prawdopodobnie większość).
W Twój wybór systemu nie wnikam. Ja po kilku latach pracy na Debianie po prostu stwierdziłem: dość – nigdy więcej. I pozostaję temu wierny :) Moje kryteria wyboru systemu, to moje – Twoje to Twoje. Nie muszą się one pokrywać. Gdybym miał jednak sugerować system na normalny desktop, to prędzej zasugerowałbym coś z *buntu (a i to nie w wersji LTS), albo lepiej OpenSUSE, OpenMandriva/Mageia lub… Manjaro. Debian prędzej, czy później zaczyna być kołem u wozu (jak potrzeba tam zainstalować jakieś nowsze oprogramowanie). Powtarzam jednak – niczego nie narzucam a i temat to na inną dyskusję i w innym miejscu do ewentualnego kontynuowania.Coż – może po prostu na początek winieneś się zaopatrzyć w podręcznik Manjaro 16.10?
Generalna zasada zanim instaluje się jakikolwiek system, to wiedzieć co jest w komputerze oraz wiedzieć jak się chce to zainstalować. Piszesz o jakichś partycjach extended (masz już tam jakiś system inny?)…
Najpierw zatem – poznaj swój komputer, zorientuj się w jego BIOSie (ustawianie tam na łapu capu czegokolwiek nie jest dobrym rozwiązaniem). Potem sprawdź, czy wybrana przez Ciebie dystrybucja w livecd zachowuje się poprawnie (tj. zasadniczo wszystko wówczas działa). Dopiero potem, po uzmysłowieniu sobie jak ma wyglądać Twój dysk, czy chcesz/będziesz korzystać z takich wynalazków jak UEFI, czy też z BIOSa Legacy itp. itd. przyjdzie czas na instalację. Obecnie jesteś na dobrej drodze (czego Ci nie życzę) do unieruchomienia komputera ;)
Komputer (bebechy) jest wystarczający do pociągnięcia nawet takich środowisk jak Gnome3, czy Plasma 5 w „normalnych” zastosowaniach. Nic nie musisz dokupować. W wymagających grach może się okazać, że nawet jeśli zainstalujesz jakąś wersję OpenBox – to może być zbyt mało.Behawiorystyka nic nie daje. Jeśli chcesz uzyskać jakąkolwiek odpowiedź, to musisz po pierwsze lepiej opisywać problem, po drugie wskazać na jakieś logi systemowe itp.
Do tej pory nie wiemy nawet jaki masz komputer :)
To, że coś działa na Debianie, Windowsie, czymkolwiek innym absolutnie nic nie mówi. Fakt działania na Debianie (a także Manjaro KDE) podpowiada jedynie, że w jakiejś konfiguracji linux działa. To jednak wiemy.PS: Jeśli nie masz karty NVidia, to uruchamianie „non-free” nic nie daje.
PS2: „Krzykliwa grafika” KDE? Nie mam pojęcia co to oznacza, ale w przypadku Manjaro, szczególnie XFCE i KDE, twórcy starają się dbać, by wygląd poszczególnych „odmian” był bardzo do siebie zbliżony. We wszystkich przypadkach masz możliwość zmiany tematów, ikon itd. itp.
PS3: Skoro zainstalował Ci się Manjaro KDE, to spokojnie możesz doinstalować do niego XFCE i pobawić się. Bo chyba tylko temu ostatniemu jak na razie to co robisz służy (bez urazy; trzeba sobie wybrać to na czym się chce pracować).Od razu mówię: z tzw. teorii nie wiem nic. Natomiast z praktyki wynika tak, że jeśli będziesz miał 10 aplikacji, z których każda będzie miała jakieś usługi uruchamiane w tle, to bardziej „spowolnią” one Androida niż 100 aplikacji, z których żadna nie uruchomi usługi.
Zacięcia wynikają z niezoptymalizowanych usług. Niektóre – prawdopodobnie – uruchamiasz bez sensu, są nieskonfigurowane, albo inne jeszcze rzeczy. Efekt jest taki, jaki jest. To – prawdopodobnie – nie środowisko, a system się tnie przy uruchamianiu.
Możesz to spróbować zdiagnozować w ten sposób, by wyłączać kolejno usługi, których nie potrzebujesz/nie używasz. Przede wszystkim te, które w journal powodują jakieś przekroczenia czasu oczekiwania. Od tego bym zaczął.
„Lekkość” środowiska wcale nie oznacza, że będzie się uruchamiać szybciej. Oznacza wyłącznie, że dane środowisko ma – teoretycznie – mniejszze zapotrzebowanie na zasoby.
Zerknij sobie na wiki Archa nt. systemd i jego optymalizacji.Z journala wynika, że są jakieś kłopoty co najmniej powodowane przez bluez oraz pulseaudio. Podobnie jakiś serwis secrets (nawet nie wiem do czego służy :)). Pokaż jeszcze konsolowe systemd-analyze (tak to konsola i tak, jest tam na końcu „d” po system – sorry, zgubiłem poprzednio) zarówno w sytuacji prawidłowo startującego środowiska, jak i wówczas, gdy ma zwłokę.
Myślę, że poszczególne problemy należałoby rozważyć z osobna.Jakiś dziennik logów (journalctl) by się przydał, także systemd-analyze; w obu przypadkach z szybkiego i wolnego uruchomienia się systemu; szczególnie to drugie może – choć nie musi – być pomocne. Tak to wróżenie z fusów.
Nadto opis kiedy to obserwujesz, w jakich okolicznościach. Wszelkie informacje mogą okazać się przydatne.Mogę jedynie podpowiedzieć, że niekiedy pulpit uruchamia się dłużej przy pierwszym uruchomieniu środowiska w danym dniu jeśli zainstalowane są podręczniki systemowe (man).
Info z wiki Archa winno być takie samo dla wszystkich dystrybucji, nie tylko dla niego. Dla Manjaro tym bardziej, albowiem jest na nim oparte. To jest rozwiązanie „generalne”, które nie jest związane z daną dystrybucją. Dla pewności możesz jeszcze przeszukać wiki Manjaro.
Pobocznie:
1. Nie – w przypadku Mint KDE nie istnieje oficjalnie wsparcie dla aktualizacji z Mint KDE 17 do Mint KDE 18. Bierze się to stąd, że obie te wersje używają innych initów oraz innego środowiska (Plasma 5 nie jest „prostym” następcą KDE4).
2. ROSA nie jest chyba dystrybucją ciągłą.
3. Spośród ciągłych dystrybucji, które mają KDE „na pokładzie” (a inne niż ciągłe, czy „pół ciągłe” w przypadku KDE wg mnie w ogóle są nieporozuieniem) sugerowałbym wziąć pod uwagę:
a) Arch Linux – absolutnie najlepsza implementacja KDE spośród wszystkich dystrybucji, które używałem; ma duże szczęście do absolutnie wspaniałych i odpowiedzialnych opiekunów tego środowiska.
b) Manjaro – paczki KDE tu są brane z Archa, w porównaniu do Archa ma w repozytoriach nawet nieco więcej rozwiązań dla KDE (np. Firefox KDE),
c) Chakra – obecnie mógłbym polecić, choć ze względu na szczupłość zespołu zdarzały się tu „przerwy w życiorysie”; dobra dystrybucja, ale to jest semi-rolling (base jest aktualizowane 3-4 razy do roku); ma też ograniczenia w zakresie aplikacji, które nie są aplikacjami budowanymi na KDE/Qt (tj. mniejsza ich ilość, ograniczona prawie wyłącznie do tych, które nie mają zamienników, lub te są gorsze); dystrybucja jest wyłącznie 64 bitowa, ale z multilib
d) KaOS – mocno eksperymentalna dystrybucja, która ma jednakże świetną implementację KDE; trzeba jednak pamiętać – dystrybucja wyłącznie 64 bitowa (brak nawet multilib), bardzo KDE „centryczna” (kto wie, czy nie bardziej jeszcze od Chakry), niekiedy – teraz będzie to już rzadziej – programy w wersjach rozwojowych,
e) OpenSUSE Tumbleweed – odmiana rolling release znanej dystrybucji; paczki trafiają po ich przetestowaniu w repozytorium Factory;
f) OpenSUSE Leap – odmiana „wydawnicza”, ale obecnie bardziej jak semi rolling;
– dokładnie nie wiem jak to będzie wyglądać, bo na razie chyba nikt nie wie, ale prawdopodobnie w zakresie KDE obie OpenSUSE będą się różnić w ten sposób, że w Leap będzie kontynuowane aktualizowanie wydania Plasma 5.8LTS, zaś w Tumbleweed pojawiać się będą nowe wersje tego środowiska,
g) OpenMandriva – o ile udostępni się repozytoria zapewniające (semi) rolling release (jest to możliwe),
h) Neon (mimo wszystko) – bo stoją za nim osoby związane z programowaniem dla KDE (nie mówię tu o Riddlu); jest kilka wersji.
Żadna inna dystrybucja z KDE (pomijam tu Gentoo i pochodne oraz Slackware) nie jest w zasadzie godna uwagi. W Fedorze przyszłość KDE jest niepewna, a w Kubuntu/Mint/Netrunner/Debian obecnie to jest kpina.
To powyżej wyłącznie w celach informacyjnych. Jeśli Cię interesuje – załóż nowy wątek.Jeśli masz hplip i hplip-plugins, to po prostu po podbiciu wersji pythona być może będziesz potrzebował przeinstalować/przekompilować hplip-plugins (to z AUR). I tyle, ale to jeszcze melodia niezbyt odległej przyszłości (w Archu zawitała nowa wersja python3 w testing :)).
Ewentualnie – zgodnie z opisem od HP:
link na HP Linux Imaging and Printing
link na wiki Archa
Wersja hplip jest wystarczająca. Obok niej – prawdopodobnie musiałbyś zainstalować jeszcze hplip-plugin z AUR.Co ciekawe – bardzo mi się podoba informacja ze strony twórcy foo2zjs.
Zaznaczałeś usunięcie libmarble4, a nie libkgeomap4. Usunięcie pierwszego było niemożliwe ze względu na zależące od niego libkgeomap4 istniejące w systemie, co do którego nie było żadnej decyzji, by je usunąć. Pacman zatem nie mógł sobie z czymś takim poradzić, bowiem z jednej strony miał wydaną mu dyspozycję o pozostawieniu paczki libkgeomap4 w systemie, która zależy od libmarble4, a z drugiej decyzję o usunięciu libmarble4 przez nowe marble. Fakt, że gdyby pacman mógł „pójść o krok dalej”, to „zobaczyłby”, że wraz z KDE Apps 16.12 w miejsce libkgeomap4 dostarczana jest paczka libkgeomap i wówczas zaktualizowałby wszystko za jednym zamachem. Niestety (albo na całe szczęście) pacman zaprzestaje działania czekając na dyspozycję użytkownika przy pierwszym napotkanym problemie z zależnościami paczek w systemie. Pamiętaj – pacman to narzędzie zaprojektowane dla Archa, czyli co najmniej średnio zaawansowanych użytkowników.
W przypadku oprogramowania z KDE jeszcze kilka razy tego typu operacje mogą się zdarzyć, co jest związane z nieukończonym jeszcze portowaniem całości aplikacji z Qt4 na KF5(Qt5). Zresztą podobne problemy mogą się zdarzać na styku aplikacji gtk2/gtk3.Sprawdź sobie po co Ci w systemie libkgeomap4 (to bodaj stara zależność marble). Innymi słowy spróbuj go usunąć (pacman -R). Jeśli wyjdzie Ci, że nie może być usunięty jedynie dlatego, że potrzebuje go marble, to biorąc pod uwagę, że i tak go chcesz zainstalować w nowej wersji, spokojnie możesz usunąć go wraz z zależnościami, albo usunąć marble z zależnościami. Potem aktualizacja i ewentualne doinstalowanie brakujących paczek.
Całe „zamieszanie” spowodowane jest przeniesieniem dalszych programów na KF5.
Sprawdź, czy nie masz w systemie zainstalowanych jakichś pakietów „meta” związanych z KDE. To one mogą być przyczyną tych nierozwiązanych zależności. Przed aktualizacją należałoby je wszystkie usunąć.
