Udzielone Odpowiedzi
- Posty
Teoretycznie – w Plasma 5.9 ma być lepiej. Nie jest :)
Najlepiej – znaleźć odpowiedni temat okien.
Inaczej – Ustawienia systemowe -> Zarządzanie oknami -> Zasady okien i popracować
Inaczej – zainstalować plasma-sdk i pobawić się programami, które dostarcza.IMO – najprościej skorzystać z jakichś gotowców na store.kde.org (czyli pkt 2).
Możesz zresztą wypróbować: Breeze AlphaBlack (czytaj opis), Simple Flow czy Silver (ten jest bodaj półprzezroczysty).Zainteresowałeś się może hardware’ową akceleracją? Masz na wiki Archa. Zwykle pomaga. Masz jeszcze w repozytorium program livestream, który umożliwia odtworzenie streamu w jakimś programie (typu mpv). Może to jest jakieś rozwiązanie?
Pierwsze – nie dodawałeś czegoś spoza repozytorium przez przypadek? O ile pamiętam, to u mnie wystarczyło wyrazić zgodę na odinstaowanie caligra-brainstorm (fakt, miałem jakąś „przejściówkę” na Qt5 już; być może jeśli masz wersję na Qt4/kdelibs – błędów więcej).
Drugie – tak.Calligra obecnie (tj. wersja 3.0) ma wszystkie programy w jednej paczce. Inna sprawa, że znów nieco ich wypadło :))
Przy instalacji, gdy wykrywany jest konflikt, musisz się zgodzić na usunięcie wszelkich calligra-coś, które są w konflikcie z nowym calligra. Nadto krita i kexi są obecnie w dwu odrębnych paczkach (ale to już jakiś czas). Możesz też odinstalować dawną grupę calligra, a potem zaktualizować system i zainstalować calligra.A możesz nam zdradzić w jakim DE? Najlepiej byłoby abyś również zdradził co rozumiesz przez „aktywator”.
Nie wygląda na to, by cokolwiek zostało zmienione, co obsługuje modem 3g.
Co to znaczy:
Każda próba połączenia kończy się niepowodzeniem, pomimo poprawnej konfiguracji dostawcy. Po każdej próbie plasma wyświetla komunikat o niedostępności modemu.
Mam rozumieć, że:
1. łączysz się przez modemmanager,
2. używasz w tym celu „Ustawienia połączeń sieciowych” (standardowo na panelu),
3. przy pierwszej próbie połączenia modem/połączenie jest pokazywane,
4. do połączenia nie dochodzi (co dokładnie się dzieje?),
5. po takiej nieudanej próbie – nie ma możliwości już skonfigurowania połączenia 3G bo takie „nie istnieje”, nie można go wybrać, ani skonfigurować, bo nie jest widzialny modem.
Zgadza się?
Ok. pokaż jeszcze wynik dmesg od chwili próby połączenia się do chwili, kiedy nie masz już możliwości połączenia się oraz wynik journalctl z tego samego okresu.Zobacz, czy problem występuje na obu kernelach, które masz (4.4.x i 4.9.x).
Sprawdź, czy masz w systemie: modemmanager (powinno być, ale na wszelki wypadek) oraz modem-broadband-providers-info (podobnie). Sprawdź sobie, czy usługa ModemManager.service jest podniesiona.Tam, gdzie są one przechowywane: /var/log/pacman.log. Tylko obetnij ten log o wcześniejsze wpisy, kiedy wszystko działało, bo inaczej będziemy się bawić w olbrzymią listę od początku postawienia systemu. Wrzuć to zresztą na jakieś pastebin, bo chyba będzie wygodniej.
Czy oprócz aktualizacji robiłeś coś jeszcze? Np. zmiana kernela (nie jego upgrade, tylko zmiana wersji).EDIT:
Przy okazji – masz Manjaro KDE, a zatem octopi. Nie wiem, czy w Manjaro doinstalowywane jest OTB również PacmanLogViewer, które potrafi Octopi wywołać, czy nie. W każdym bądź razie dość fajna przeglądarka logów pacmana i dla wyłącznie zaznajomienia się co było instalowane, aktualizowane i usuwane w systemie – bardzo przydatna.Hmmm…. a, że się tak dziwnie spytam (i retorycznie zresztą i sam sobie na to odpowiedz) – oprócz podniesienia usługi, to skonfigurowałeś sobie to UFW?
No, ale jak na razie, to pokazałeś nam wyłącznie, że ufw jest nieaktywne oraz, że wadliwie jego używasz (nie istnieje coś takiego jak „ufw command”, w miejscu „command” trzeba coś wpisać z wyświetlanej listy, w zależności, co się chce uzyskać).
O ustawianiu UFW.
Na pytanie, czy jest potrzebny odpowiedzi są dwie: tak i nie. Każdy będzie za swoją opcją przedstawiał jakieś argumenty i przeciwko drugiej. Mi się widzi, że najsensowniej mieć fw na routerze, a nie w komputerze (chyba, że używasz przenośnego, często łączysz się z przypadkowych miejsc itp. – wówczas można pomyśleć także o fw w komputerze).Od czego zacząć? Typ modemu (tak jak go system widzi, a nie jak się handlowo nazywa) i logi z ostatniej aktualizacji.
Żaden program. Zidentyfikować jakie usługi są podnoszone, użyć systemctl (dla systemowych i/lub użytkownika). Reszta – właśnie w owych tweakach.
I trzeba uważać :)Jak są podnoszone usługi, ile to zabiera czasu znajdziesz wydając komendy:
'systemd-analyze’
pokaże „zbiorcze” zestawienie z podziałem na to ile czasu zajmuje podniesienie usług kernela, a ile do userspace.
'systemd-analyze blame’
pokaże w jakim czasie podnoszone są i jakie usługi do userspace.
Tutaj masz początek tego, co można zrobić w ramach podnoszenia wydajności systemu (akurat Arch, ale w zasadzie w każdym z systemd tak samo):
1. https://wiki.archlinux.org/index.php/Improving_performance
2. https://wiki.archlinux.org/index.php/Improving_performance/Boot_process
Na witrynie z rozszerzeniami Gnome też łatwo znajdziesz narzędzia GUI do zarządzania usługami.
I jak mówiłem – ostrożnie i usuwać należy wyłącznie to, czego na pewno nie tylko Ty, ale i na 100% Gnome nie używa. W redukcji usług można bowiem pójść zdecydowanie za daleko :)Ups. Moment.
Instalowany obecnie kernel z repo-ck zawiera w sobie patch CK, który zawiera m.in. MuQSS (rozwiązanie Cona Kolivasa) oraz BFQ (w starszej wersji, który jest „wbudowany” w CK; dawniej obok patcha CK dokładałeś BFQ – teraz nie jest to ani potrzebne, ani możliwe). Niczego nie trzeba doinstalowywać, bo zresztą nie ma jak. BFQ jest planistą I/O, który musi być wbudowany w kernel podczas jego kompilacji. Dowolny kernel linux-ck można uruchomić z jednym z czterech planistów I/O: deadline, cfq, bfq i noop. Do tej pory było tak, że ten kernel uruchamiał się domyślnie z CFQ. Jeśli coś chciałeś zmienić w tym zakresie, to – jeśli miałeś jeden dysk – najsensowniej było to zrobić właśnie przekazując info kernelowi podczas startu, jako elevator=, po którym wpisywałeś nazwę planisty spośród wyżej podanych czterech.
U Ciebie niby wszystko wskazuje na to, że zmienna bfq została przekazana, ale system jej nie widzi. Czy po zmianie Grubego zaktualizowałeś go? Powinieneś wydać polecenie update-grub bądź to co się za nim kryje:
sudo grub-mkconfig -o /boot/grub/grub.cfg
Bez tego polecenia, GRUB niczego co się w jego plikach konfigurujących zmieniło nie będzie widział.Zatem tak – obecnie używasz systemu, który jako planisty CPU używa MuQSS, ale jako planisty I/O używa CFQ, a nie BFQ (który jest częścią patcha CK i powinien się włączać praktycznie automatycznie).
Jeśli używasz linux-ck (dowolna wersja) z repo-ck, oraz jeśli masz dodany parametr elevator=bfq do Grubego oraz nie robiłeś żadnych sztuczek opisanych na wiki Archa, to coś dziwnego, albowiem działa to na CFQ, a powinno na BFQ.BFQ jest też domyślnym shedulerem dla kerneli Manjaro. Może opisz jakie zmiany dokonałeś?
Wrażenia, wrażeniami. Różnie to bywa. W tej chwili siedzę na CFQ, które było zawsze bardziej mułowate od BFQ. Różnica jest taka, że BFQ startuje znacznie szybciej (kilka sekund od zimnego startu do sesji usera), ale jest bardziej responsywny przy dużej ilości odwołań do dysku (kompiluję właśnie). Sam start zobaczysz narzędziami systemd-analyze i systemd-analyze blame.
W przypadku linux-ck-procesor, masz tam nałożone obecnie 2 patche: CK, który zawiera MuQSS oraz BFQ (w starszej wersji) oraz tzw. patch graysky’ego na GCC, który „dostosowuje” kernel pod dany procesor. Zdaje się, że – w porównaniu z kernelami Manjaro – inny jest też tzw. tickrate, który tutaj wynosi obecnie 300Hz (albo 100Hz – mniejsza o to, możesz sprawdzić). Jest też to kernel, który nie zawiera innych patchy, które w Manjaro są (jak np. aufs3). Czy to się przejawia na pracę komputera? Tak, ale z różnymi procesorami, z różnymi konfiguracjami, różnie to bywa.
