piątek, 29 lipca 2016

Zbieramy użyteczne informacje w przypadku błędów w aplikacji

Ze względu na sposób paczkowania w Archu (a co za tym idzie wszystkich jego pochodnych, w tym Manjaro, jak również wszystkich systemów, które wykorzystują pacmana) użyteczne dla programistów informacje, w przypadku błędów aplikacji, zbiera się nieco inaczej.
Podstawowe informacje może dostarczyć uruchomienie programu w konsoli i sprawdzenie komunikatów, które w ten sposób uzyskujemy. Niekiedy będą to informacje użyteczne, np. że program nie potrafi znaleźć jakiejś biblioteki, niekiedy jednak program nie uruchamia się, bądź też w sposób niekontrolowany wyłącza, a terminal dostarcza nam jedynie suchej informacji o zrzucie pamięci itp. Jeśli taki wynik przedstawimy komukolwiek, kto zechce nam pomóc, to najczęściej będzie to bezwartościowa informacja, która nie jest w stanie nawet wyjaśnić, czy błąd tkwi w samym programie, czy jest związany z paczkowaniem, czy kompilacją. Nie będzie też wiadomo czy i w jaki sposób taką aplikację można naprawić. Z pomocą przychodzi uruchomienie programu poprzez gdb, który prawdopodobnie w systemie macie. Jeśli z jakiejś przyczyny się on nie znajduje, to musimy go zainstalować. Stosowna paczka również nazywa się gdb.
Wyposażeni w tego debbugera uruchamiamy podejrzany program:
gdb nazwa_programu
przy czym nazwa_programu to jest program wykonywalny (binarny), a nie skrypt powłoki, który go wywołuje. Nie sprawdzimy zatem poprzez wywołanie gdb chromium czy gdb libreoffice ani przeglądarki chromium, ani pakietu libreoffice. Próba uruchomienia takiego "programu" spowoduje jedynie wyświetlenie informacji:
"/usr/bin/nazwa_programu": not in executable format: File format not recognized
W takim przypadku musimy przeglądnąć znajdujący się w podanej ścieżce program będący w istocie skryptem wywołującym właściwy plik wykonywalny, odszukać go i tę nazwę (najczęściej z całą ścieżką wywołać w gdb. Dla przykładu, w przypadku chromium będzie to:
gdb /usr/lib/chromium/chromium
Wywołanie, poprzedzone krótką informacją o programie, skończy się przejściem do znaku zachęty gdb, który wygląda tak:
(gdb)
By wykonać wewnątrz gdb program, musimy go uruchomić. Wpisujemy albo run, albo samo r:
(gdb) r
Jeśli poddany inspekcji program zakończymy i ujrzymy informację:
[Inferior 1 (process LICZBA) exited normally]
(w miejscu LICZBA pojawią się jakieś cyfry), to działanie programu przebiega poprawnie, nie wywołuje on żadnych błędów.
Prawdopodobieństwo, że program działający wadliwie zwróci taką informację w gdb jest jednak znikome. Najczęściej ujrzymy wówczas informację, o jakiejś wadliwości, a sam program w sposób niekontrolowany zamknie się. Już wówczas dysponujemy jakąś informacją, ale najcenniejszą uzyskamy poprzez podanie tzw. backtrace. Uzyskujemy to wpisując bt po znaku zachęty gdb, czyli;
(gdb) bt
Uzyskaną w ten sposób informację możemy podać osobom, które odpowiedzialne są za paczkowanie. Winny one na podstawie tej informacji móc ocenić, czy proces paczkowania i kompilacji przebiegł prawidłowo, czy też nie i w zależności od tego albo będą w stanie naprawić paczkę, albo odesłać problem (i nas) do osób odpowiedzialnych za kod źródłowy.
Z tego typu informacjami najsensowniej zgłaszać problem na forum Archa, bądź jego bugzilli (jeśli paczka pochodzi z Archa, jeśli nie - w odpowiednich forach danej dystrybucji), pamiętając, że "paczki" z AUR nie są objęte wspieraniem przez Archa. W tym przypadku, jedyne miejsce to albo poinformowanie o tym bezpośrednio opiekuna paczki, albo stosowne miejsce na forum Archa. Jeśli informacje taką zgłosicie na naszym forum, to prawdopodobnie uzyskacie jedynie informację, że problem należy zgłosić u źródła.
Na koniec jeszcze informacja dla osób podejrzewających Plasmę (jej elementy) o błędy. W takim przypadku wywołanie w gdb plasmashell musimy poprzedzić jej "ubiciem", co uzyskamy wpisując:
kquitapp5 plasmashell
w przypadku Plasmy, czy
kquitapp5 kwin_x11
w przypadku KWin pracującego w Xach (proces w Waylandzie nazywa się kwin_wayland).

czwartek, 28 lipca 2016

Sprawdzamy ile RAM zabiera nam jakaś aplikacja

Na wstępie, by nie było nieporozumień: poniżej prezentowane rozwiązanie jest wspólnym dziełem dwu użytkowników Archa: graysky'ego oraz grimscythe, a zostało zaprezentowane w wątku na forum Archa. Jest na tyle proste i ciekawe, że postanowiłem je przybliżyć.
Po wykonaniu poniżej przedstawionych operacji, wywołanie skryptu z nazwą programu jako parametru pokaże ile pamięci RAM jest zajmowanych przez ten program.
Do dzieła.
Otwieramy jakikolwiek edytor tekstu (czyli np. nano, kwrite, kate, gedit itp.) i umieszczamy tam następujące linie basha:

#!/bin/bash
ps -A --sort -rss -o comm,rss | grep $1 | awk '{ sum+=$2 } END { print sum/1024 }'

Zamykamy i zapisujemy, nadając mu jakąkolwiek, łatwą do zapamiętania przez nas nazwę. Koledzy z BBS zaproponowali appusage.sh. Może być.
Dla ułatwienia sobie korzystania ze skryptu nadajemy mu uprawnienia wykonywalne:

chmod +x appusage.sh

Teraz jeszcze warto byłoby umieścić ów skrypcik w katalogu widzianym przez system. Domyślnie programy do używania przez tzw. zwykłego użytkownika w Archu znajdują się w /usr/bin. Katalog może być jednak dowolny. Jeśli nie znajdzie się w PATH, to musimy go wywołać z pełną ścieżką.
Używanie jest banalne, np.:

appusage.sh qupzilla

Kernele z patchem CK

Pewnie większość użytkowników Archa dawno już spotkała się z tzw. kernelami Cona Kolivasa, czy też z patchami BFS lub CK. Część z nas ich używa. Teoretycznie kernel Manjaro winien zawierać te patche już od dość dawna, jednakże kiedy go ostatni raz sprawdzałem (wczoraj) nie był wyposażony w te łatki.
Na bieżąco nowe wersje kernela udostępnia w postaci binarnej użytkownik graysky, a zatem nie musimy ich kompilować. Co ciekawe, w jego repozytorium dostępnych jest bardzo wiele odmian dostosowanych do poszczególnych rodzajów procesora, a nie tylko wersje dla architektury 32 i 64 bitowej. Kompilacja jest zatem konieczna wyłącznie osobom, które z jakichś przyczyn chciałyby dokonać większych zmian w swoich kernelach. Dla nich są skrypty w AUR, które radzę dokładnie przeglądnąć, albowiem można w nich poustawiać sporo opcji. Jeśli ktoś chciałby dokładniej to poznać - zapraszam do dyskusji, czy to tutaj, czy na forum.
Oprócz kerneli z najnowszej linii, są jeszcze repozytoria, w których można znaleźć kernele LTS wyposażone w łatkę CK i to zarówno z ostatniej linii LTS, jak i z linii 3.x. Te kernele nie są jednakże już dostosowane do poszczególnych typów procesorów, oferując niekiedy wersje wyłącznie dla procesorów 64 bitowych. Z lektury ich zawartości wynika, że nie udostępniają nawet najnowszych kerneli LTS (np. zamiast ostatniego 4.4, oferuje 3.14, które już w sierpniu br. stanie się EOL). Jeszcze inne, jak np. linux-ck-pax oferują je dla linii 3.14, 3.16, 3.17 i 3.19, spośród których w zasadzie wartą odnotowania jest wyłącznie linia 3.16 ze względu na wsparcie sięgające 2020 r. (3.17 i 3.19 już są EOL). Jest jeszcze repozytorium z linux-ck dla linii 3.10 i to może jeszcze być dla kogoś ciekawe, ze względu na wsparcie do października 2017 r. W niniejszej notatce pomijam te repozytoria. Jeśli znajdzie się ktoś zainteresowany, używający takiej linii kerneli, to proszę się zaznajomić z tą informacją.

Co to daje?
Patche tworzone przez Kolivasa (a także innych użytkowników, albowiem sporo tu pracy Alfreda Chena i Oleksandra Natalenki) są przeznaczone dla desktopów. Ich głównym celem ma być większa responsywność systemu. Programy winny się uruchamiać szybciej. Winniśmy odczuwać większą płynność pracy.

Nieco ładu.
Kolivas oferuje dwa rodzaje łatek: BFS oraz CK, za każdym razem dostosowanych do danego wydania kernela. Główny patch, to BFS. To on jest planistą procesów alternatywnym dla CFS, który jest domyślnym obecnie schedulerem CPU w kernelu. Drugi z patchy zawiera w całości BFS a nadto jeszcze inne, które mają dodatkowo poprawić responsywność systemu jak np. ustawienie tick rate na 1000Hz (domyślny kernel w Archu ma tę wartość ustawioną na 300Hz). Takie ustawienie częstotliwości jest rekomendowane dla pracy BFS, choć nie jest ono warunkiem jego poprawnego działania. Tutaj uwaga ta ostatnia zmiana może mieć wpływ na długotrwałość pracy na zasilaniu bateryjnym. Niestety to jedna z tych wartości, której nie możemy zmienić na pracującym już kernelu. Jest "wszyta" w kernel na stałe, zatem jeśli odczujecie spadek długotrwałości pracy na kernelu CK przy zasilaniu bateryjnym, to wówczas dobrze mieć w systemie drugi, bardziej energooszczędny kernel, na którym uruchamialibyśmy notebooka, gdy pracujemy na takim zasilaniu. Może to być kernel "linux" z Archa, może to być nawet linux-ck, ale wówczas zbudowany z AUR, albowiem tylko tam możemy zdecydować się na nienakładanie tego patcha. Sens tego ostatniego rozwiązania wydaje się być jednak problematyczny.
Oprócz kerneli "linux-ck", patch BFS lub CK jest dość popularny i rozpowszechniony. Dla przykładu, każde wydanie pf-kernel zawiera BFS. Podobnie zawiera je również kernel kalterfx.
BFS jest też stosowany w kernelach niektórych dystrybucji. Przedziwna sytuacja występuje w przypadku kernel-lqx, albowiem PKGBUILD daje możliwość skompilowania kernela z tym patchem, jednakże nie znajduje się on w źródłach, na podstawie, których kernel ten jest kompilowany. Jedynym patchem, jaki jest tu nakładany jest liquorix, który niekiedy ma zaimplementowane BFS, a innym razem nie.

Pozostawmy jednak na boku inne kernele, które korzystają z BFS/CK i zainstalujmy ten kernel w możliwie najprostszy sposób.
W przypadku najnowszej linii kerneli skorzystamy w tym celu z repozytorium graysky'ego. Pierwsze, czego musimy dokonać, to w pliku /etc/pacman.conf dodać to repozytorium. Dopisujemy w dowolnym miejscu listy repozytoriów następujący wpis:
[repo-ck]
Server = http://repo-ck.com/$arch
Następnie musimy dodać sygnaturę podpisu graysky'ego. W konsoli wpisujemy:
# pacman-key -r 5EE46C4C && pacman-key --lsign-key 5EE46C4C
Teraz synchronizujemy bazę pacmana:
# pacman -Syy
Pojawi się nam całe mnóstwo nowych kerneli, których nazwa rozpoczyna się od linux-ck. Kernel linux-ck, który został oznaczony wyłącznie numerem wersji jest pozbawiony optymalizacji dla określonego typu procesora. Pozostałe kernele, jak np. linux-ck-piledriver, linux-ck-silvermont itd. są kernelami zoptymalizowanymi, których kompilacja została wykonana z użyciem patcha graysky'ego. Osobiście sądzę, że lepiej jest zainstalować ów dostosowany do naszego procesora kernel. Właściwą nazwę rozpoznajemy po wydaniu w konsoli polecenia:
$ gcc -c -Q -march=native --help=target | grep march
W wyniku jego działania otrzymamy wynik wyglądający np. tak:
  -march=                               bdver2
Interesująca dla nas część, to informacja znajdująca się za -march=, czyli w tym przypadku bdver2. Teraz odnajdujemy jakiej nazwie kernela ona odpowiada z poniższej przedstawionej listy.
Dla procesorów Intela będą to:
bonnel - atom
silvermont - silvermont
core2 - core2
nehalem - nehalem
sandybridge - sandybridge
ivybridge - ivybridge
haswell - haswell
broadwell - broadwell
skylake - skylake
pentium4 - p4
prescott - p4
nocona - p4
pentm - ck
pentm - ck
pentium-m - ck
Dla procesorów AMD:
athlon - kx
athlon-4 - kx
athlon-tbird - kx
athlon-mp - kx
athlon-xp - kx
k8-sse3 - kx
amdfam10 - k10
btver1 - bobcat
bdver1 - bulldozer
bdver2 - piledriver
Lewa kolumna listy oznacza wynik jaki uzyskujemy wpisując powyżej przedstawioną komendę po "-march=", zaś prawa odpowiada nazwie kernela występującej po oznaczeniu linux-ck. Jeśli się zdecydujemy na instalację dostosowanych kerneli, to musimy w tej samej wersji instalować pliki nagłówkowe, czy sterowniki nvidia lub moduły virtualbox czy sterowniki dla kart wifi broadcom-wl.
Paczki w repo-ck są podzielone na grupy, które odpowiadają wpisom umieszczonym w powyższej liście poprzedzonym prefiksem ck-. Jedynie dla podstawowej linii kerneli musimy wpisać ck-generic.
Po instalacji wybranego kernela musimy o tym oczywiście poinformować stosowany przez nas program rozruchowy (np. GRUB2). W tym ostatnim przypadku będzie to:
# grub-mkconfig -o /boot/grub/grub.cfg
Jak już może się zorientowaliście, repozytorium dostarcza nie tylko kerneli, ich pliki nagłówkowe, ale również sterowniki nvidia w różnych wersjach, sterowniki broadcom-wl oraz moduły virtualbox. Jeśli zdecydowaliśmy się na korzystanie ze kerneli linux-ck, to mając sprzęt, który ich wymaga musimy również zastosować te sterowniki dla linux-ck.

Kernele linux-ck udostępniane przez graysky'ego mają również wbudowanego alternatywnego (dla domyślnego CFQ) planistę I/O pod nazwą BFQ. Nie jest on jednakże uruchomiony automatycznie (to możemy dokonać kompilując kernel). Uruchomić go możemy dodając wpis elevator=bfq w linii poleceń kernela i oczywiście przebudować program rozruchowy. Możliwe jest również uruchomienie tego planisty dla określonego urządzenia dyskowego. Jest to rozwiązanie ciekawe w przypadku stosowania w tym samym komputerze dysków talerzowych oraz SSD, albowiem te ostatnie - wg wszelkich danych - najlepiej używać z planistą noop. Jeśli takie rozwiązanie komuś będzie potrzebne, zapraszam na forum, albo do lektury niżej podanych stron.

Więcej dowiecie się m.in. z:
- strona na wiki Archa o kernelu linux-ck,
- strona na wiki Archa o repozytorium repo-ck,
- strona graysky'ego (wraz z podanymi na niej linkami)


środa, 27 lipca 2016

Otter-Browser #134

Kolejna wersja beta zbliża się dużymi krokami, jak na razie pojawiło się wydanie tygodniowe #134 i jesteśmy o tydzień bliźsi pierwszego wydania stablinego. Tymczasem PKGBUILD, a więcej - jak zwykle - dowiecie się ze strony programu i z githuba.

niedziela, 24 lipca 2016

KDE Applications 16.08Beta

Właśnie ukazała się nowa odsłona aplikacji od KDE. Oczywiście dzięki arojasowi jest już dostępna dla Archa w repozytorium [kde-unstable]. Jeśli ktoś chciałby z niej skorzystać, to przypominam, że należy uruchomić to repozytorium oraz repozytorium [testing] albowiem programy trafiające do [kde-unstable] są budowane na podstawie aplikacji mieszących się właśnie w testing. W pliku /etc/pacman.conf należy zatem usunąć znak "#" przed [testing] oraz figurującym pod nim "Include = /etc/pacman.d/mirrorlist" oraz najlepiej na samej górze listy udostępnionych repozytoriów dodać:
[kde-unstable]
Include = /etc/pacman.d/mirrorlist

Z informacji niezbyt miłych:
- Blogilo nie potrafi jak na razie używać protokołu Bloggera - konieczna jest nowa biblioteka libkgapi,
- nie działają kody QR w kaddressbook - wersja prison nie jest kompatybilna z Plasmą,
Jak zwykle w przypadku udostępniania przez arojasa paczek w kde-unstable nie są dostępne pliki lokalizacyjne. Jeśli ktoś ich potrzebuje, to udostępniłem PKGBUILD, ale wyłącznie dla polskiej wersji językowej.
Do sierpnia błędy te winny być naprawione, a na pewno wraz z publikacją KDE Applications 16.08 arojas udostępni też kde-l10n.

Jeśli ktoś oczekiwał spektakularnego przeportowania pozostałych aplikacji należących do rodziny KDEApps do KF5, to może się rozczarować. Przeportowaniu uległy wyłącznie kdf, kolourpaint oraz cervisia. Oznacza to, że np. okular dalej oficjalnie jest w wersji nieprzeportowanej. A mijają już dwa lata od czasu publikacji KF5 i Plasma 5.

Znakomita większość paczek odpowiada ostatnio opublikowanej stabilnej wersji 16.04.3. Największe zmiany zaszły w Ark, który w końcu staje się pełnoprawną aplikacją do archiwizacji plików oraz KDEPIM, gdzie "wypadła" jednolita biblioteka kdepimlibs, która została podzielona na trzy inne. Powinno to umożliwić większe możliwości dostosowania do siebie aplikacji sładających się na KDEPIM i mniejsze ich zależności.

W przypadku znalezienia błędów w paczkowaniu, prosimy o ich zgłaszanie na bugzilli Archa z dopiskiem [kde-unstable], zaś w samych aplikacjach na bugzilli KDE.

AzPainterB

Kolega Salvadhor stwierdził, że w Archu i Manjaro mamy jedynie "zwykłego" AzPaintera. Siadło mi na ambit :)
Oto PKGBUILD umożliwiający budowę nowego AzPainterB 1.0.2.
O samym programie więcej oczywiście na blogu Salvadhora.

Skracamy czas instalacji

Wraz z nastaniem pacmana w wersji 5.x zarządanie bazą man zostało z nim zintegrowane. Powoduje to, że baza ta jest przebudowywana praktycznie w każdym przypadku na końcu instalacji paczek. W niektórych przypadkach trwa to długo. Z odsieczą przyszedł znany w świecie Archa graysky tworząc mandb-ondemand, który skraca ten proces. Skrypty dostępne są w AUR, a kod źródłowy na githubie. Cały proces instalacji ogranicza się do zbudowania i zainstalowania paczki w systemie. Nie wymaga żadnej ingerencji. Zatem:
pb -S mandb-ondemand

PS: Jeśli chcielibyście wiedzieć co oznacza tajemnicze pb, to nie jest to kwestia przyzwyczajenia do moich inicjałów, a postanowienie wspierania polskiej myśl informatycznej. Od tej chwili PKGBUILDer, którego autorem jest Kwpolska zastąpi tu yaourt, czy packera. Program dostępny jest w AUR, także w wersji GIT i kiedyś go pewnie omówię (źródła).

sobota, 23 lipca 2016

Paczki deb i rpm w Archu

Co jakiś czas pojawiają się pośród użytkowników Archa, czy Manjaro rozpaczliwe głosy związane z próbą zainstalowania paczek pochodzących z najpopularniejszych dystrybucji, a w zasadzie paczek oferowanych w formacie deb lub rpm. Najczęściej głosy te pochodzą od bardzo świeżych użytkowników naszej dystrybucji. Co gorsza dotyczą one często sterowników, albo aplikacji, które i tak są oferowane w AUR albo w jakchś repozytoriach.
Ze względu na dostępność w repozytoriach Archa dpkg oraz rpm w ślad za takim "lamentem" idzie cudowna podpowiedź: zainstaluj sobie dpkg/rpm i za pomocą tego menedżera zainstaluj paczkę w systemie.
Czy coś takiego ma szansę powodzenia? Oczywiście. Menedżer paczek jest wszak aplikacją wyspecjalizowaną w m.in. ich instalacji.
I wszystko wydaje się wspaniałe.
STOP.
Niestety nic nie jest wspaniałe. Nie tak się to robi i tak instalacji aplikacji pakowanych dla obcych dystrybucji się nie robi. Kiedy o tym pisałem, spotykałem się z najpopularniejszym pytaniem sześciolatka; dlaczego? Skoro działa, skoro zainstalowało, to dlaczego mi tego robić nie wolno? Wolno. Kto komu zabroni. Niemniej jednak nie licz w takim przypadku, że ktokolwiek potem pomoże, a biorąc pod uwagę co zrobiłeś sam sobie nie pomożesz i zamiast zaktualizować oprogramowanie, za którymś razem okaże się, że będziesz instalować system od początku, oczywiście złożecząc na pacmana, Archa i kogo tylko będziesz chciał obarczać odpowiedzialnością swoich błędów.
Dlaczego zatem rozwiązanie powyższe jest wadliwe?
Niemal każda dystrybucja linuksowa stosuje menedżery paczek. Oczywiście z punktu widzenia użytkownika, szczególnie bardzo "zielonego", jest on traktowany jako uniwersalny instalator oprogramowania. Fakt, każdy menedżer paczek posiada taką funkcjonalność. Jego rola w systemie jest jednak znacznie szersza i m.in. służy zachowaniu w nim porządku. Mówiąc kolokwialnie: po prostu dba, by system działał. Wprowadzając do systemu paczki za pomocą menedżera możemy liczyć na to, że system działał będzie długie lata.
Co się zatem dzieje, gdy do instalacji wykorzystamy obce narzędzie? Otóż nasz menedżer paczek (pacman) nie zostanie o tym powiadomiony. W systemie pojawią się pliki, o których on nic nie wie. Przy jakiejś aktualizacji programów dojść może zatem do sytuacji, w której istniejące, obce pliki, będą kolidować z tymi, które mają zostać zainstalowane. Instalacja nie powiedzie się. Długo sobie będziesz przypominał co zrobiłeś, by utrudnić pacmanowi życie i najczęściej winą obarczysz bogu ducha winny menedżer czy deweloperów oprogramowania.
Jest też druga przyczyna, aktualna szczególnie w przypadku paczek deb. Otóż struktura katalogów Archa i Debiana różni się. Oba te systemy gdzie indziej oczekują istnienia poszczególnych plików, składających się na paczkę. Instalacja przez dpkg oczywiście się uda, wszak z tego punktu widzenia, dokona on rozpakowania paczki deb i umieszczenie wypakowanych plików w strukturze, która została w niej zadeklarowana. Sam program jakiś czas może nawet i działać, ale instalacja w ten sposób to proszenie się o kłopoty.
Jeszcze inna przyczyna, to zwróćmy uwagę, że instalujemy w ten sposób paczki binarne, już skompilowane na jakimś systemie i dla określonego systemu tworzone. W tym, docelowym dla takiej paczki systemie znajdować się mogą biblioteki w różnych wersjach. Zwróciliście uwagę, że paczki deb czy rpm często mają określenia sugerujące dla jakiej konkretnej wersji dystrybucji są one przygotowane? To m.in. właśnie dlatego. Pamiętajcie również, że w Archu od dawna jest systemd, a wiele paczek dla Debiana, czy Ubuntu dostosowanych jest jeszcze do upstartu.
Dobrze, co zatem robić, gdy koniecznie musicie mieć program oferowany w deb lub rpm?
Po pierwsze należy wnikliwie i spokojnie przeszukać dostępne repozytoria Archa oraz AUR. Jeśli są to należy zainstalować lub zbudować, te, które są dostępne w ten sposób. Jeśli ich nie ma, należy poszukać źródeł. Jeśli te są - stworzyć odpowiedni PKGBUILD (lub poprosić o jego stworzenie, gdy wiedzy zbyt mało osoby bardziej doświadczone), skompilować program i zainstalować go za pomocą pacmana. Kiedy źródeł nie ma w istocie to można spróbować poszukać jakiegoś appimage, czy flatpaka (snappy nie polecam ze względów, które już opisałem). Innym źródłem takiej paczki może być jakiś system pochodny od Archa. W przypadku Antergosa, czy innej dystrybucji korzystającej bezpośrednio z repozytorium Archa, instalacja takiej paczki nie powinna robić problemów w systemie. Należy jedynie pamiętać, że jakaś paczka została zainstalowana z obcego repozytorium, które poniekąd można traktować również jako tzw. nieoficjalne. W przypadku paczek Manjaro i Archa. Tu pewien problem może istnieć, albowiem repozytoria stable obu systemów nie odpowiadają w 100% sobie i wersje paczek mogą być różne. Jeśli w Archu decydowalibyśmy się na taki krok, to należałoby się pokusić o instalację paczki z testowego bądź niestabilnego repozytorium Manjaro, a i wówczas zalecałbym ostrożność i traktowanie tego jako ostateczność, ale i tak lepszą niż instalację paczki deb, czy rpm. Najlepiej jednak byłoby taką paczkę po prostu przebudować. Inne systemy, które wykorzystują pacmana jako menedżer paczek, jak np. Charka czy KaOS mogą być traktowane wyłącznie na takich samych zasadach jak paczki deb, czy rpm. Bezpośrednie zainstalowanie paczki z KaOS graniczy zresztą z cudem, ze względu na odmienną ich nomenklaturę.
Dopiero ostatecznością winno być pokuszenie się o instalację paczki deb lub rpm, jednakże nie stosując w tym celu ich menedżerów plików. Przede wszystkim, jeśli dostępne są oba rodzaje paczek, to lepszym wyborem będzie rpm. Struktura katalogów Fedory jest zbliżona do Archa. Możemy też liczyć na to, że szczególnie w stosunku do paczek dla Debiana Stable czy Ubuntu LTS (zwłaszcza pod koniec jego wsparcia), użyte do budowy programy są w tej samej wersji, co w Archu. Kiedy już znajdziemy odpowiednią paczkę, należy dla niej zrobić PKGBUILD, który dokonałby rozpakowania rpma czy ewentualnie deba, a następnie umieściłby otrzymane w ten sposób pliki w zgodzie ze strukturą katalogów Archa. Niekiedy trzba będzie jeszcze dokonać zmian w plikach *.desktop i innych. Otrzymaną paczkę dopiero będzie można zainstalować w systemie za pomocą pacmana. Jak zwykle - jeśli nie potrafisz tego dokonać sam, to możesz się zwrócić do społeczności o pomoc w takiej sprawie.

piątek, 22 lipca 2016

Ładniejsze czcionki w linuksie

UWAGA: Wraz z instalacją harfbuzz 1.4.x prezentowane tu rozwiązanie nie jest już prawidłowe i spowoduje błędy w systemie!

Szczerze powiedziawszy, to nie widziałem jeszcze tyle osób narzekających na to, czego używa, jak w świecie linuksa. Tym razem poradnik dla osób narzekających na niewłaściwy wygląd czcionek. Jeśli te, które są dostępne zaraz po instalacji Wam nie pasują z jakiejś przyczyny, to radzę spróbować zainstalować czcionki z patchami tzw. infinality. Można to zrobić "przez mękę", bawiąc się w budowanie tych paczek z AUR, a następnie mozolnie konfigurując, można prościej, dopisując odpowiednie repozytorium do ich listy dla pacmana, a następnie instalując odpowiednie paczki. Ograniczę się do tej ostatniej opcji. Też bywam leniwy.

Więcej o Infinality dowiecie się z oficjalnej strony.

Instalację rozpoczynamy od edycji pliku /etc/pacman.conf i dopisaniu odpowiedniego repozytorium:

[infinality-bundle]
Server = http://bohoomil.com/repo/$arch

W następnej kolejności, musimy dodać klucze do paczek z tego repozytorium:
# pacman-key -r 962DDE58 && pacman-key --lsign-key 962DDE58

Teraz jesteśmy już przygotowani do instalacji paczki z poprawionymi czcionkami.

Rozpoczynamy jak zwykle od synchronizacji bazy pacmana i aktualizacji systemu:
# pacman -Syu
Teraz do wyboru będziemy mieć trzy opcje:

  1. freetype2-infinality-ultimate - która oferuje freetype2 zbudowane z patchami Infinality (i kilkoma innymi),
  2. fontconfig-infinality-ultimate - oferuje fontconfig zoptymalizowany do współpracy z freetype2-infinality-ultimate (zostanie zainstalowana jako zależność), oferując również dodatkowe czcionki i kilka plików konfiguracyjnych dla nich; paczka oferuje również fonty MS,
  3. cairo-infinality-ultimate - cairo zbudowane z patchami Ubuntu i dodatkowymi.

Wydaje mi się, że optymalnym rozwiązaniem jest instalacja drugiej z paczek (dla systemów opartych o Qt) lub trzeciej (dla systemów opartych o Gtk, ale nie jest to konieczne).
Instalacja przebiega standardowo:
# pacman -S <nazwa_paczki_z_powyższej_listy>
Podczas instalacji otrzymamy informację o tym, że system chce zastąpić zainstalowane wcześniej pakiety - akceptujemy proponowane rozwiązanie, czyli godzimy się na zmianę paczek.

Oprócz powyższych, możemy się pokusić również o doinstalowanie dodatkowych paczek dostępnych w repozytorium, takich jak poprawiony font Oxygen, czy fonty dla oprogramowania wykorzystującego środowisko java. Listę otrzymamy po wpisaniu:
pacman -Sl infinality-bundle

Jeśli ktoś korzysta z dobrodziejstw multilib i programów 32-bitowych w systemie 64-bitowym, to przydatne jest również zainstalowanie odpowiednich paczek przygotowanych na taką sytuację. Bohoomil oferuje bowiem również paczki multilib. Podobnie jak poprzednio rozpoczynamy od edycji pliku /etc/pacman.conf i dopisujemy:
[infinality-bundle-multilib]
Server = http://bohoomil.com/repo/multilib/$arch
Tym razem nie musimy już dodawać kluczy, albowiem wcześniej są one dodane, zatem po aktualizacji bazy pacmana, znów mamy analogiczne 3 paczki do wyboru:
  1. lib32-cairo-infinality-ultimate,
  2. lib32-fontconfig-infinality-ultimate,
  3. lib32-freetype2-infinality-ultimate.
Jak się domyślacie, odpowiadają one wcześniejszym. Instalacja  podobnie jak poprzednio:
# pacman -S <nazwa_paczki_z_powyższej_listy
System będzie chciał podmienić paczki, na co się godzimy.

Po instalacji i ewentualnym poprawieniu ustawień resetujemy Xy.

W zasadzie system winien być gotowy do pracy. Niemniej jednak możliwym jest również jego stuningowanie. W "dużych" środowiskach mamy odpowiednie GUI, które ułatwiają konfigurację. Zasadniczo, winny one odpowiadać temu, co jest widoczne w /etc/X11/xinit/xinitrc.d/infinality-settings, czyli winno to odpowiadać następującym ustawieniom:
Xft.antialias: 1
Xft.autohint: 0
Xft.dpi: 96
Xft.hinting: 1
Xft.hintstyle: hintfull
Xft.lcdfilter: lcddefault
Xft.rgba: rgb

Teraz łyżka dziegciu. Wprawdzie czcionki "Infinality" winny być "ładniejsze" jednakże nie zawsze tak jest, szczególnie w przypadku polskich (i prawdopodobnie również innych) znaków diakretycznych. Często zdaża się, że literki te są większe od innych. Wówczas, niestety - dopóki Bohoomil nie poprawi skryptów, trzeba się pobawić w ręczną korektę ustawień czcionek. Ogólnej reguły nie ma, zatem w przypadku problemów - zapraszam na forum.

Na podstawie oraz więcej w:
wiki Archa
strona Bohoomila

Nomacs 3.4.0

Z jakichś niezbadanych dla mnie przyczyn, Nomacs w Archu dostępny jest jeszcze w wersji 3.0, podczas, gdy obecna to już 3.4. Jej budowa trwa chwilę, zatem proponuję wykonać:
yaourt -G nomacs
cd nomacs
wget -c http://pastebin.com/raw/Jr4d8WVn
mv Jr4d8WVn PKGBUILD
makepkg -sirc

czwartek, 21 lipca 2016

Poprawiamy zbyt duże ikony w systray w Plasma 5.7

Wraz z przebudowaniem od początku kodu odpowiedzialnego za wyświetlanie tzw. tacki systemowej w Plasma 5.7 niektórzy borykają się z problemem zbyt dużych ikon, które się w niej pojawiły po aktualizacji.
Problem został dostrzeżony i naprawiony. Poprawka prawdopodobnie pojawi się w wersji 5.7.3, której można oczekiwać 3.08. Do tego czasu trzeba sobie jednak jakoś radzić.
Są dwa rozwiązania.
Pierwsze to przebudować plasma-workspace, używając PKGBUILDu wersji 5.7.2 z repozytorium dodając do niego łatkę. Nie przedstawiam PKGBUILDu, albowiem rozwiązanie drugie wydaje się szybsze. Niemniej jednak, gdyby ktoś chciał zaprowadzić bezwzględny porządek w systemie, a nie potrafił tego samodzielnie dokonać, to proszę zgłosić w komentarzach, a uzupełnię informację o stosowne skrypty do przebudowania paczki.
Drugie rozwiązanie wydaje się być banalne. Otóż m.in. za wielkość ikon odpowiadają ustawienia w pliku /usr/share/plasma/plasmoids/org.kde.plasma.private.systemtray/contents/ui/main.qml. Należy w nim odszukać 34 linię o treści:
property int itemSize: Math.min(Math.min(width, height), units.iconSizes.medium)
i dokonać jej zmiany na;
property int itemSize: Math.min(Math.min(width, height), units.iconSizes.smallMedium)
Wg informacji z BBS Archa sztuczka pomaga.

Otter-Browser wydanie tygodniowe 133

Tym razem już bez zbędnej zwłoki - PKGBUILD.

środa, 13 lipca 2016

Plasma 5.8 LTS - czyżby pierwsze jaskółki Plasma 6/KDE 6?

Następne wydanie środowiska KDE - Plasma 5.8 uzyskuje status LTS i będzie wspierane przez osiemnaście miesięcy od chwili wydania (planowane na 18.10.2016 r.). Wydanie to jako wymaga wersji Qt 5.6, która również uzyskała status LTS (3 letnie wsparcie). Co ciekawe, przynajmniej jak na razie, w zapowiedziach wydań, aż do końca kwietnia 2018 r. nie pojawiają się nowe wydania Plasmy. Czyżby Plasma 5.8 mogła być ostatnim wydaniem? Podobnie wszak stało się z kdeworkspace 4.11, który równolegle funkcjonował wraz z Plasma 5 przez szereg miesięcy (około półtora roku).
Jak na razie plany Qt sięgają po wersję 5.8, która wstępnie była planowana na koniec 2016 r. Rewolucja raczej nie grozi, zwłaszcza, że Plasma 5.8 będzie utrzymywana aż do kwietnia 2018 r. Niemniej jednak zaczyna to wyglądać jak pierwsza przymiarka do powstania nowej wersji Plasmy, czy KDE (jakkolwiek się nie będzie nazywać).
Oznaczenie Plasmy 5.8 mianem LTS oznacza, że w tej wersji nie pojawią się raczej jakiekolwiek nowe funkcje. Wysiłki zespołu KDE skupią się na stabilizowaniu kodu oraz poprawie wydajności.
LTSem nie są jednak objęte kwestie dotyczące prac nad implementacją środowiska KDE dla Waylanda. W tym zakresie możemy się zatem spodziewać różnych zmian w ramach Plasma 5.8.

sobota, 9 lipca 2016

AppImage, Snappy, Flatpak - Cz. 4 - Refleksja końcowa

Udało mi się zapoznać z 3 rodzajami "bundli". W zasadzie czterema, albowiem z jeszcze jednym w czasach, gdy używałem Chakry. Tam wówczas, bo już obecnie tak nie jest, aplikacje Gtk były umieszczane również w swoich "kontenerach" - rozwiązanie zbliżone do omawianych. Pozostałe, wprawdzie istniejące, jakoś nie ściągnęły mej uwagi po próbie przeszukania dostępnych aplikacji. Na placu boju pozostały zatem: appimage, flatpak i snappy.
Każde rozwiązanie ma pewnie swoje zalety i wady - pora na bardzo subiektywną refleksję.
Spośród tych trzech, na pewno nie będę używał snappy. Nie dość, że skomplikowane, używające bez sensu systemd (tzn. wiem do czego go używa, ale nie znajduję wytłumaczenia na to po co go używa), to przede wszystkim kompletnie nieużyteczne. Być może w jakimś systemie, być może osobie bardziej zdeterminowanej ode mnie w próbie uruchomienia tu czegokolwiek, uda się coś uruchomić. Mi się nie udało. Biorąc pod uwagę moją wiedzę jako użytkownika systemów linuksowych od wielu lat, to raczej trudno uważać ów produkt jako user-friendly. Do tego dochodzi już wątpliwa reputacja w zakresie bezpieczeństwa. Odinstalowanie snapd (tzn. całego systemu zarządzania tymże) to również katorga.
Pozostają zatem dwa rozwiązania: appimage i flatpak. W pierwszym przypadku mam wątpliwości co do bezpieczeństwa tego rozwiązania. Niemniej jednak sam pomysł wydaje się być sensowny. Niczego nie muszę instalować, ściągam aplikację w jednym pliku, zmieniam atrybut na wykonywalny i powinno działać. Otóż istotą jest owe słowo "powinno". Jak wynika z mojego wpisu poświęconego temu typowi paczkowania - nie zawsze się to udaje. Być może nie przetestowałem większości dostępnych appimage (na pewno nie), ale udało mi się to zrobić z jakąś 1/6-1/7 aplikacji (nie jest ich wiele). Około połowa odmówiła współpracy, w tym wszystkie oparte o chromium. Ciekawe. To rozwiązanie ma też jedną wadę - w żaden sposób nie zmienimy aplikacji poprzez użycie dodatków, spolszczeń itp. Dodatki zadziałały tylko w przypadku Firefoksa, ale spolszczenie już nie. Nie mam pojęcia dlaczego, wszak jedne i drugie to pliki xpi. Na pewno też nie ma możliwości spolszczenia takich aplikacji jak np. LibreOffice, które wymagają "podmiany" plików dla uzyskania lokalizacji.
Wydaje się zatem, że najsensowniejszym rozwiązaniem jest flatpak. Jeśli uda się mu uzyskać pewną łatwość obsługi, a taką przyniosą zapewnie narzędzia GUI, które dla niego powstaną, to pomysł wydaje się być sensowny. Był też najmniej kłopotliwy.
Pozostaje jeszcze kwestia rozmiaru aplikacji i duplikacji bibliotek zawartych w poszczególnych paczkach. Pierwsze - ma znaczenie w przypadku małych dysków. Nie jest to jednak jakaś wielka różnica. Niemal wszystkie paczki (z wyjątkiem snappy) miały rozmiar zbliżony do paczek zawartych w repozytoriach. Problem zaczyna się, jeśli zainstalujemy sobie więcej aplikacji, które korzystają, bądź mogą korzystać z tych samych komponentów. Tu w istocie dysk się szybko zapełnia. Niestety jak na razie nikt nie znalazł pomysłu na ograniczenie duplikowania się paczek w systemie. Co ciekawe, kilka lat temu właśnie problem z tym związany spowodował przyjęcie innego rozwiązania w Chakrze (nie ma sensu tu wskazywać jak go rozwiązano).
Ogólny wniosek dla mnie jest taki: nie używać żadnego z tych rozwiązań, dopóki na pewno się nie musi. Nie ma to sensu. Zaczyna on istnieć wyłącznie wówczas, gdy jakąś aplikację mogę zainstalować wyłącznie z appimage lub flatpaka (snappy - z powyżej przytoczonych względów odrzucam). Żadne z tych rozwiązań nie należy również rozpatrywać jako jakiekolwiek panaceum na "bolączki" obecnej koegzystencji wielu różnych systemów paczkowania i zarządzania paczkami w linuksie. Niby niosą one uniwersalność rozwiązań, ale same również rodzą nowe problemy. Pomijam już aspekt ekonomiczny, albowiem aplikacje rozprowadzane w tych formatach są mocno przerośnięte. Największe paczki otrzymujemy w snappy - tu ich rozmiar zaczyna być olbrzymi (co z tego, że libreoffice udało się spaczkować do blisko 290MB, skoro nie zawiera on wszystkiego, co jest potrzebne do użytkowania tego pakietu, a nie ma moliwości doinstalowania do tego niczego).
Innymi słowy - dziękuję bardzo, pozostanę przy pacmanie.

AppImage, Snappy, Flatpak - Cz.3 Snappy

Od końca. Poległem. Instalacja snapów rozpoczyna się od instalacji, a następnie skonfigurowania paczki snapd. Widzicie do "d" w nazwie? Tak, jest to program i usługa systemd. Bez systemd nie zadziała na żadnym systemie. Wbrew temu, co twierdzi PR Canonicala. To znaczy oni o tym nie wspominają. Twierdzą natomiast, że ich pomysł jest powszechny i zadziałać ma docelowo na każdym systemie. Nie jest to prawdą.
Instalacja jest prosta. Pacman jak zwykle rozwiąże każdy problem. Potem trzeba podnieść usługę. Całe szczęście to socket, a zatem nie będzie bez sensu zaśmiecał pamięci. Potem już sama przyjemność: można jednym poleceniem - w tym przypadku snap - przeglądać, instalować, odinstalować, oraz robić wiele rzeczy z paczkami snap. Można je instalować zarówno ze "sklepu" jak i z plików lokalnych. Ba, jedna z usług zapewnia również automatyczne aktualizowanie paczek. Super.
To zaczynamy. Przegląd paczek. Nie jest ich jak na razie wiele, a ich wybór jest poniekąd dziwny. Mój wybór padł na zainstalowanie Krity (bo tę mam w systemie, znam jak się zachowuje z AppImage, a zatem miałbym jakieś porównanie), edytora Atom (bo zawsze chciałem zobaczyć co to, ale przerażała mnie ilość zależności w moim Qt-centrycznym systemie), oraz - już nie ze "sklepu" - LibreOffice (bo tu miałbym porównanie zarówno z zainstalowaną aplikacją, jak i z flatpakiem).
Na początek - niespodzianka. Mój kernel uniemożliwia zainstalowanie jakiegokolwiek pakietu snap. Pewnie coś wyciąłem, czego nie potrzebuję w codziennym używaniu, a czego snapsy wymagają. Przerzuciłem się zatem na linux-ck (ale prawdopodobnie zadziała każdy "uniwersalny" kernel). Tu instalacja przebiegła bez problemu. Zdziwiło mnie jedynie, że instaluje się również jakaś tajemnicza paczka ubuntu-core. Po co? Tego już nie sposób ustalić.
Przyszło do testowania. Żadna z zainstalowanych paczek nie odpaliła się. Albo uzyskiwałem informację o naruszeniu pamięci, albo że nie mam w systemie czegoś od Gtk, albo informacja, że "proces nie jest dostępny", czy "znany". Nie ma to znaczenia.
Po około 3 godzinach spędzonych w necie na próbie identyfikacji problemu oraz znalezieniu możliwości jemu zaradzenia udało mi się jedynie ustalić, że... nie ma takiego rozwiązania. To znaczy nikt nie widzi problemu (pierwszy, z kernelem był zauważany).
Koniec.
Jeśli to ma być rozwiązanie powszechne, to nie może ono tak wyglądać.
Przyszło do odinstalowania snapd. Cóż... samo odinstalowanie paczki nic nie da. Pobrane snapy zostają w systemie, o czym lojalnie uprzedza wiki Archa. Najpierw zatem trzeba odinstalować paczki snap, potem usunąć snapd wraz z zależnościami, potem ręcznie usunąć katalogi, które potworzył (oprócz tych, które są wymienione na wiki Archa, w katalogach systemowych, to także katalogi w katalogu domowym, w tym również katalogi uryte). Potem jeszcze przeszukanie pozostałości po snapd (tak, znajdą się) i ich usunięcie.
Nie dla mnie to rozwiązanie. Jeśli używając linuksa przez ponad 10 lat i to bardzo różnych systemów (spośród tych najbardziej znanych chyba nigdy nie ruszyłem jedynie Slackware), po osiągnięciu możliwości samodzielnego diagnozowania problemów i radzenia sobie z nimi, nie potrafiłem uruchomić jakiegokolwiek programu (a próbowałem na kilka sposobów, których nie ma sensu w tym miejscu opisywać), to co dopiero ma począć ktoś, kto zaczyna przygodę z linuksem i otrzymał właśnie w prezencie doskonałe rozwiązanie od Canonicala.
Do tego dochodzi jeszcze wątpliwej jakości izolacja paczek snap w systemie. Okazało się bowiem, że paczki te mają możliwość dostępu (w X11) do dowolnych informacji, jakie są na dysku, wykradzenia dowolnych haseł.
Jak dla mnie - snap - nazywa się zapomnij raz na zawsze o istnieniu tego czegoś.

piątek, 8 lipca 2016

Niesforne qtwebengine 5.7.0

W kilku wpisach sygnalizowałem wadliwą pracę wszelkich przeglądarek wykorzystujących qtwebengine. Okazało się, że problem spowodowany jest przez niekonsekwentne wyłączenie pewnej optymalizacji w qt5-webengine. Obecnie do repozytorium trafiła przebudowana paczka w wersji 5.7.0-2. Wraz z nią zniknęły problemy aplikacji wykorzystujących tę odmianę blinka. Qupzilla 2.x, czy Otter-Browser (z tym silnikiem) pracują już prawidłowo.

czwartek, 7 lipca 2016

Plasma 5.7 i Qt 5.7 w Archu i co z tego wynika

Po dwu tygodniach testowania Plasma 5.7 Beta (5.6.95) (można się było z nią zapoznać z kde-unstable), dwa dni temu pojawiło się jej stabilne wydanie, które trafiło do repozytorium testing. Pewnie gdzie indziej przeczytacie sporo o nowościach środowiska, ale... osobiście uważam, że wystarczająca jest wizyta na stronie kde oraz przeglądnięcie erraty. Podzielę się zatem z Wami wrażeniami z korzystania z Plasmy w tej wersji. Od razu mówię - moja wersja jej wyglądu nie jest dostarczana ze środowiskiem. Dotychczasowe doświadczenia z Plasmą 5 wskazują na dość znaczne jej "przywiązanie" do tematu Breeze, którego używanie w istocie sprawia, że działa ona lepiej niż z różnymi tematami, motywami, a nawet zestawami ikon, które dostępne są w zarówno w repozytoriach różnych dystrybucji, w AUR, jak i na kde-look.org. Nie mówię już o próbach użycia tematów z KDE4, które wcześniej czy później skończy się pokazową wywrotką środowiska (w najgorszym przypadku), a na co dzień powoduje błędy, których gdzie indziej nie ma. Niestety nie ustrzeżemy się od nich, albowiem - niestety - wiele tematów udostępnianych przez swoich twórców jest deklarowanych jako zgodne z Plasma 5, podczas, gdy w istocie są one nadal skonstruowane dla KDE4. Jeśli zatem środowisko zachowuje się wadliwie, to w przypadku używania niestandardowych ustawień, tematów itp, jednej z pierwszych przyczyn należy poszukiwać właśnie tutaj.
Czego się zatem można spodziewać, oprócz tego o czym szeroko jest i będzie mowa? Pierwsze, co się narzuca, to brak możliwości korzystania z innego menedżera okien niż KWin. Niegdyś taka funkcjonalność została wprowadzona w KDE4, a wcześniej jeszcze - choć nie w tak prosty sposób - można było korzystać z niej nawet w KDE 3. Obecnie - bodaj ponownie mój ulubiony deweloper KDE - stwierdził, że nikt z tego nie korzysta, ludzi do rozwijania, czy nawet utrzymywania rozwiązania brak, a zatem i ta funkcjonalność została wyłącznona. Nie tylko próżno szukać zatem takich ustawień w systemsettings, ale nawet, gdy mamy zainstalowanego OpenBox obok Plasmy, nie będziemy mogli z rozwiązania KDE/OpenBox, jakie dostarczane jest wraz z paczką openbox skorzystać. Tzn. środowisko się uruchomi, jednakże cały panel będzie kompletnie nieużywalny.
Czy rozwiązanie w dobrym kierunku? Z punktu widzenia twórców rozwijających KDE na pewno tak. Pozbyli się kodu, o który nikt nie dba i nie ma ochoty tego rozwijać. Drugą zaletą z ich punktu widzenia jest to, że nie muszą już nawet próbować w jakikolwiek sposób zapewnić kompatybilność w przypadku działania Plasmy z alternatywnym wobec KWina menedżerem okien. Trzecia związana jest z Waylandem, z którym jak się wydaje, twórcy KDE łączą dość duże nadzieje, bo wciąż kod odpowiedzialny za współpracę Plasmy z Waylandem jest poprawiany, sporo też w tym zakresie informacji i tzw. szumu medialnego. Z Waylandem natomiast nie zadziała praktycznie żaden alternatywnie wykorzystywany w KDE do tej pory menedżer okien.
Nieco inaczej ma się sprawa z punktu widzenia użytkownika, szczególnie systemów instalowanych na notebookach. Nie łudźmy się - choć twórcy KDE mają zasługi w zakresie optymalizacji zapotrzebowania ich środowiska na zasoby komputera, to jednakże trudno uznać Plasmę za środowisko "lekkie" (cokolwiek by to nie znaczyło). Tutaj częściowym rozwiązaniem, które zmniejszało apetyt na energię, było właśnie używanie sesji KDE/OpenBox. W sumie nie miałbym nic przeciwko podjętemu krokowi, gdyby wraz z nim pojawiło się rozwiązanie, które się narzuca: proste przełączanie profilu w przypadku wykrycia zasilania bateryjnego. Oczywiście coś takiego w KDE jest i istnieje od lat, jednakże akurat te ustawienia (Zarządzanie energią) nie wyczerpują całego problemu. Wielu z nas, ustawia Plasmę z różnymi "zabawkami", "efektami", które powodują większe zapotrzebowanie na energię. Gdyby wprowadzić "profil zasilania", który automatycznie potrafi nie tylko przyciemniać, czy wyłączać ekran, sieci bezprzewodowe, ale również przełączać się na "suchy", pozbawiony wszelkich ficzerów wygląd, praca na bateriach trwała by dłużej. Gdyby, gdyby... Takiego rozwiązania nie ma, a zatem do dyspozycji mamy wyłącznie albo ustawianie całej sprawy "ręcznie" po zalogowaniu się (a najlepiej przed) do sesji zasilanej z baterii, albo stworzenie innego użytkownika, który dzieliłby jednakże to co niezbędne z użytkownikiem "prądowym".
Druga kwestia. Wayland. Cóż... Mimo wielu zapowiedzi, wielu filmików z uruchomioną sesją Plasmy w Waylandzie, istnieniem specjalnej dystrybucji Neon, możliwość tę należy skwitować krótkim: nie działa. Gdyby nie to, że bodaj trzy razy udało mi się ją uruchomić (dwa razy Neon i raz w moim Archu), to stwierdziłbym, że taka możliwość istnieje, jednakże nie na moim sprzęcie. Sprzęt - jak się okazuje - nie ma tu nic do rzeczy. O możliwości tej należy zatem zapomnieć i choć wyścig z Fedorą i zapowiadanym w niej Gnome 3 uruchamianym domyślnie w Waylandzie, choć Martin Graesslin dwoi się i troi, by zapewnić taką możliwość, to sądzę, że nie ujrzymy stabilnie działającej Plasmy "Wayland" co najmniej do wydania 5.9/10. KDE Frameworks 5.24 wiosny tu nie czynią (mam KF5.24RC1).
Tyle narzekania, cała reszta (u mnie) działa bardzo dobrze i stabilnie. Nawet zmiany w wyglądzie oceniam tym razem pozytywnie (szczególnie w modułach KCM). Znane mi są natomiast informacje o problemach, jakie występują w systemach ze sterownikami Intela oraz - niekiedy - własnościowymi NVidii. Pierwsze są związane z istniejącym błędem w sterowniku. Twórcy KDE praktycznie porzucili próby dostosowania swego środowiska do wadliwie działającego sterownika, zwłaszcza, że od miesięcy trwa sytuacja, że jak coś poprawili, to nowa wersja sterownika wprowadzała regresje. Znane są możliwości obejścia problemu, ale to temat na forum. Problemy związane z NVidią nie są przeze mnie śledzone. Prawdopodobnie wynikają jednak z wadliwych ustawień sterownika.
Nieco wcześniej, do repozytorium extra weszła nowa wersja Qt - 5.7. Co do zasady działa to stabilnie i niewiele jest programów, które wymagałyby przebudowania. Te, które pochodzą z repozytorium i wymagały przebudowania, zostały już przebudowane. Problem dotyczyć może wyłącznie aplikacji zbudowanych z AUR. Jeśli zatem napotkacie problem niedziałającego programu, najsensowniej wywołać go z konsoli. Gdy zobaczymy, że program nie widzi jakiejś biblioteki, której nazwa sugerować nam będzie, że należy ona do Qt5, to należy go przebudować. Niestety wraz z pojawieniem się Qt5.7, a w zasadzie z pojawieniem qtwebengine w tej wersji, korzystanie z jakiejkolwiek przeglądarki zbudowanej z wykorzystaniem tego silnika staje się mocno problematyczne. Stwierdzić w zasadzie należy, że możliwości takiej nie ma. Na całe szczęście, w oficjalnych repozytoriach nie ma dzisiaj przeglądarki opartej o qtwebengine 5.7, z wyjątkiem QupZilli 2.x, która jest w community-testing. I będzie tam pewnie długo, albowiem twórcy Qt zrzucają problem na Archa, pomimo tego, że nie jest to problem występujący wyłącznie w tej dystrybucji. Z przetestowanych, które używają Qt5.7 oraz udostępniających przeglądarki wykorzystujące qtwebengine, działa prawidłowo wyłącznie QupZilla w KaOS 16.06. Nigdzie indziej nie udało mi się znaleźć stabilnie działającej jakiejkolwiek przeglądarki wykorzystującej qtwebengine 5.7 (testowałem Otter-Browser, QupZillę, w tym również wersję rozwojową z GIT, Quill). Nawet zatem, gdy ktoś się zdecyduje na używanie repozytorium testing oraz używa QupZilli (bądź jakiejkolwiek innej), to polecam dodanie qupzilli do IgnorePkg, zaś w przypadku Otter-Browsera do wykorzystywania qtwebkit. Niestety - dobrze nie jest (w przypadku qupzilla-qt5), ale i tak lepiej.

środa, 6 lipca 2016

Otter-Browser #131

Więcej przeczytacie jak zwykle na stronie projektu. Zmian nieco jest, włącznie z "dopuszczeniem" jako jeszcze jednego silnika, alternatywnie rozwinanego projektu qtwebkit. Swoją drogą - mocno kibicuję, albowiem pochodna Blinka, jaką jest qtwebengine mocno mnie nie zadowala. Doprawdy nie rozumiem zachwytów Blinkiem. Jeden z gorszych silników, jakie istnieją na rynku. Przynajmniej jeśli chodzi o żarcie (bo inaczej się wyrazić nie mogę) zasobów.
Budowa Otter-Browser z mojego PKGBUILDu ponownie umożliwia zbudowanie przeglądarki w opaciu zarówno o qt5-webengine, jak i qt5-webkit. Ponownie, albowiem pomimo upływu dwu tygodni od publikacji Otter-Browser, zespół Qt nie zrobił nic, by silnik qtwebengine prawidłowo działał i nie zanosi się na to. Dyskusja w którą w końcu się włączył jakiś deweloper Qt wykazuje iście "korporacyjne" podejście. Niestety - nic z tego nie będzie i będziemy musieli poczekać do czasów qtwebengine 5.8. Wówczas być może qtwebengine zacznie działać. Szczerze - wątpię, a jeśli tak, to stanie się tak przez przypadek.
Używając, możecie się liczyć zatem z mnóstwem nieprzewidzianych "wypadków przy pracy". Lepiej - ale tylko niewiele lepiej - używać qt5-webkit, choć i ten powoduje wypadki. Swoją drogą, to coraz mocniej twierdzę, że linux obecnie nie ma dobrego silnika przeglądarek. Na pewno nie istnieje taki w ramach projektu Qt. W miarę najlepszym jawi się stare gecko, czy tego chcecie czy nie. Akurat jednak ten silnik nie ma jakoś szczęścia do implementacji go w aplikacjach Qt. Co pozostaje? Chyba wyłącznie czekać. Niestety ten czas wykorzystają przeglądarki należące do innych toolkitów. Szkoda, bo miało być tak pięknie.
Podsumowując ten raczej rozgoryczony wpis: qtwebengine - tragicznie, qtwebkit - źle. Być może w istocie trzeba użyć owego nowego projektu, o którym wspomniałem na wstępie. Być może wówczas będzie można normalnie oglądać strony. Tak, czy inaczej - nie jest to raczej wina twórców Otter-Browsera.

wtorek, 5 lipca 2016

AppImage, Snappy, Flatpak... - Cz.2 Flatpak

Druga przygoda z "bundlami", czyli flatpak. Pierwsza różnica w porównaniu do AppImage - by korzystać z tego typu paczek konieczna jest instalacja ich menedżera oraz wykonanie kilku czynności, które umożliwią - przynajmniej w teorii - pracę z programami spaczkowanymi w tym standardzie. W Archu menedżera flatpaków znajdziemy w repozytorium extra lub możemy zainstalować wersję rozwojową kompilowaną z AUR (flatpak-git). To nie wszystko. Po instalacji musimy dodać odpowiednie klucze publiczne oraz biblioteki uruchomieniowe (runtime). Dopiero potem możemy przystąpić do instalacji programów, które instalujemy bądź repozytoriów (czyli dokładnie jak w przypadku każdej dystrybucji), bądź też z lokalnie pobranego pliku (tak np. zainstalujemy LibreOffice). Po dodaniu repozytoriów możemy je przeglądać, możemy instalować, aktualizować, czy odinstalować aplikacje. Sam flatpak po prostu oferuje wszystko to, co każdy inny menedżer pakietów znany z linuksa. Wprawdzie składni należy się nauczyć, a nazwy repozytoriów gdzieś wyszukać, ale może niegdyś dorobimy się jakichś skryptów czy aplikacji, w większym stopniu ułatwiającym zarządzanie owymi paczkami. Jak na początek drogi - obecne narzędzie ocenić można pozytywnie, ale wyłącznie dla osób, które przywykły do instalacji programów w konsoli. Jeśli miałoby to być jednak narzędzie dla bardzo początkujących użytkowników linuksa, to trudno go takim odnaleźć. Jak wspomniałem - kwestią czasu jest kiedy otrzymamy jakiegoś graficznego instalatora, albowiem raczej pewnym jest, że zespół odpowiedzialny za rozwój projektu będzie go starał się promować. Także i w taki, ułatwiający codzienne korzystanie z komputera, sposób.
Po zainstalowaniu aplikacji, pojawia się ona w menu. Przynajmniej powinna. W Plasma 5 tego nie zaobserwowałem.
Czynności, jakie są konieczne do wykonania, opisane zostały dość dobrze na stronach projektu, niekiedy znajdziemy je również na stronach określonych aplikacji, jak np. LibreOffice. Ze względu na dość ścisłe powiązanie projektu z zespołem odpowiedzialnym za rozwój środowiska Gnome, informacje, jakie znajdujemy na stronie projektu są zwykle związane z aplikacjami należącymi do rodziny Gtk. Co ciekawe, pośród dostępnych repozytoriów Gnome jest nie tylko oferujące paczki aktualnego wydania stabilnego, ale również wydania deweloperskie. To cenna informacja dla tych, którzy chcą się włączyć w testowanie i pomoc w rozwoju oprogramowania. Także zespół KDE przygotował swoje repozytorium z bibliotekami uruchomieniowymi dla paczek opartych o Qt5 i KF5 w tym standardzie. Samej jednakże aplikacji flatpak "ze stajni" KDE nie znalazłem. Fakt, niezbyt długo jej poszukiwałem.
Dość dobrze rozwiązana jest lokalizacja programów, albowiem oferowana jest co do zasady przez odpowiednie repozytorium (oczywiście o ile zostało ono przygotowane).
Także rozmiar programów jest do przyjęcia. Dla przykładu około 150MB paczka LibreOffice odpowiada rozmiarowi paczek z repozytorium.
Programy jeśli już się zainstalują, pracują mniej więcej równie sprawnie jak aplikacje instalowane w natywny dla dystrybucji sposób.
Znów jednakże musimy pamiętać, że przygotowane w taki sposób programy mają swoje ograniczenia. Dla przykładu LibreOffice nie zostało spakowane w taki sposób, który umożliwiłby korzystanie z dodatków wykorzystujących javę. Choć ta ostatnia - jak sądzę - prędzej czy później w ogóle z LO zostanie usunięta, to jednakże dzisiaj praca w LO musi się odbywać np. bez możliwości skorzystania choćby z popularnego rozszerzenia LanguageTool.
Ogólnie pozytywne wrażenie psują dwie rzeczy. Stosunkowo długie dodawanie repozytoriów, ale to jest być może związane z szybkością serwerów, a być może z wielkością pobieranych plików z ich danymi, które do małych raczej nie należą (np. ok. 170MB to repozytorium KDE SDK). Pamiętajcie jednak, że to jest wrażenie osoby, która na co dzień korzysta z pacmana, a ten jest niesamowicie szybkim zarządcą pakietów w porównaniu do np. APT-a. Drugi problem, z jakim się spotkałem, to brak możliwości zainstalowania niektórych aplikacji. Dla przykładu próba instalacji obu wersji GIMP-a udostępnione w repozytorium nigthly-graphics powodują naruszenie ochrony pamięci. Tak, nie korzystanie z GIMPa, ale sama jego instalacja.
Według zapewnień twórców, jak również ze specyfikacji rozwiązania wynika, że aplikacje działają w sandboksie (piaskownicy). Takie rozwiązanie ma ponoć sprawiać, że są one odizolowane i w ten sposób bezpieczne dla systemu. Podczas polemiki między zwolennikami flatpaka a snappy właśnie ten argument był wskazywany na korzyść flatpaka, ale sam nie potrafię zweryfikować na ile nasze dane są chronione przed flatpakowymi aplikacjami.
Co ciekawe, flatpak jest zależny od systemd. Przynajmniej w wersji paczkowanej na Archa. Aczkolwiek systemd zaczyna być zdecydowanie dominującym rozwiązaniem w linuksowym świecie, to jednak nie jest jedynym. Dla przykładu, może to oznaczać, że flatpaków nie użyjemy choćby w Manjaro OpenRC. Co najciekawsze - doprawdy nie wiem po co ów systemd jest zależnością flatpaka, albowiem jego używanie nie wymaga uruchomienia żadnej usługi systemd.
Na koniec pierwsze porównanie: AppImage kontra Flatpak. Każde ma swoje dobre i złe strony. Na pewno sama instalacja aplikacji AppImage jest absolutnie prostą czynnością. Oprócz nauczenia się nadania ściągniętemu plikowi atrybutu wykonalności (ale to można zrobić nawet we wszystkich menedżerach plików w sposób "klikalny") nie wymaga żadnych innych czynności. Gorzej z aktualizacją takiej paczki, albowiem jeśli deweloperzy sami nie umieszczą w niej jakiegoś mechanizmu aktualizacji, to obowiązek ten spadnie na użytkownika. Tu znaczną przewagę ma flatpak. Podobnie jest z lokalizacją programów. W znakomitej większości w przypadku flatpaka jest ona organizowana na poziomie repozytorium, a lokalizacja odbywa się automatycznie przy instalacji. Pomimo zalet flatpaka, jedynym chyba czynnikiem, jaki obecnie niektórym użytkownikom może utrudniać korzystanie z tego rozwiązania, jest nieco niezbyt komfortowa (jak na XXI wiek) obsługa.

poniedziałek, 4 lipca 2016

AppImage, Snappy, Flatpak... i wiele innych. Cz. 1 - AppImage

Już jakiś miesiąc po publikacji Ubuntu 16.04 blogerzy linuksowi całego świata zauważyli "nowy system paczkowania" jakim Ubuntu nazywa swoje snappy, czy snaps (raz tak, raz inaczej o nim pisze, zatem sam nie wiem jak się nazywa). Pewnie gdyby informacja nie pochodziła od Canonicala, pewnie wszyscy przeszliby koło niej jak koło AppImage, Autopackage, 0install, czy xdg-apps (obecnie Flatpak). Co ciekawe... przeszli, skoro najstarszy z wymienionych wyżej (a przecież nie wszystkich) systemów uniwersalnego paczkowania dla linuksa obecny jest na rynku od... 2002 roku.
Biorąc ten fakt pod uwagę, w zasadzie kończą się dyskusje na temat, że o to w tej chwili, dzięki oprogramowaniu Canonicala, które dostępne jest na różne systemy, firmy produkujące komercyjne i zamknięte oprogramowanie, rzucą się w ramiona linuksa i zaczną na ten system produkować swoje ulubione Photoshopy itp. Pies z kulawą nogą tego nie chce. Skoro przez całe lata nikt się tym nie zainteresował, to nowy "standard" Canonicala nic tu nie zmieni, chyba, że jednemu bogatemu człowiekowi uda się namówić innego równie bogatego, by stworzył coś, co może być w ten sposób dystrybuowane. Wątpię. Szczerze wątpię.
Niemniej jednak sam pomysł - choć znany mi z czasów, gdy korzystałem z Chakry, która wówczas wszystkie programy oparte o Gtk+ rozpowszechniała w postaci tzw. bundle - wydał się ciekawy. Mógłbym w ten sposób utrzymywać swój system we względnym porządku toolkitowym, zaś gdybym potrzebował czegoś innego, instalowałbym sobie taki właśnie "pakiet".
Postanowiłem zatem przetestować owe "standardy", umożliwiające uniwersalne paczkowanie aplikacji, tak, by mogły być uruchamiane niezależnie od linuksowej dystrybucji.
Na pierwszy ogień poszedł AppImage, którego użytkownicy linuksa z większym stażem mogą znać pod nazwą Klik. Pod taką bowiem po raz pierwszy pojawił się na rynku.
Dlaczego AppImage na początek? Cóż, w przeciwieństwie do np. Snappy wydaje się on być banalnie prosty i w istocie multidystrybucyjny. Snappy bowiem nie uruchomimy na niektórych systemach.
Aplikacje AppImage są rozprowadzane w pojedynczym pliku o rozszerzeniu appimage. Po ściągnięciu ze strony producenta takiego oprogramowania lub ze strony z aplikacjami AppImage należy tylko nadać plikowi atrybut wykonywalności i voila. Można sobie używać do woli. Większość skryptów, które przeglądnąłem dostosowane są do lokalizacji ~/Applications, a zatem sensownie, by w takim katalogu były przechowywane, choć nie jest to bezwzględnie konieczne.
Owe aplikacje *.appimage winny w zasadzie mieć w sobie wszelkie niezbędne im zależności, biblioteki itd. itp., które umożliwiają im uruchomienie się i prawidłowe działanie. Nie ma przy tym znaczenia w jakim języku napisana jest aplikacja.
Jak dotąd nie wpadła mi w ręce żadna aplikacja komercyjna, paczkowana w ten sposób. Fakt nie szukałem zbyt intensywnie. Znakomita większość aplikacji dostępnych w wymienionym powyżej "sklepie" jest dostępna również w postaci paczek binarnych w systemach. Gdzie i kiedy ma zatem sens instalowanie takiej paczki? Dla mnie np. do przyglądnięcia się nowościom w nadchodzącym LibreOffice 5.2, czy Firefox, a także by zainstalować jakieś oprogramowanie, z którego chcę skorzystać incydentalnie (np. Darktable). Także w przypadku sporych aplikacji, które nie są dostępne w repozytorium, a są budowane ze źródeł, co zwykle długo trwa, pomysł skorzystania z appimage wydaje się być sensowny.
Zanim jednak wyniki testów - muszę się wytłumaczyć z systemu, na którym przyszło mi paczki te testować. Nie jest wykluczone, że przetestuję je jeszcze na systemie mniej "ekstremalnym" od mojego, by wykluczyć błędy związane z konfiguracją (a w zasadzie z używanymi wersjami oprogramowania) mojego systemu.
Krótko: dystrybucja, której bazą jest Arch Linux, z otwartymi repozytoriami testing, community-testing, multilib-testing i kde-unstable, używająca również oprogramowania pochodzącego z tzw. unofficial repositories (w tym przypadku są to programy związane z KDE, które oficjalnie nie są jeszcze dostępne w wersjach opartych o KF5 oraz repozytorium mesa-git), nadto oparta o kernel, który sam kompiluję.
Wypróbowałem kilka programów, wszystkie z ww. sklepu: obie wersje Firefox, Krita, LibreOfficeDev (czyli 5.2.0Beta2), Chromium (51.0.2684), Darktable, GIMP, Iridium - ok. 1/7 dostępnego oprogramowania w sklepie i nadto Drawpile ze strony programu.
Można powiedzieć koncepcja prawie się sprawdza. Zwracam jednak uwagę na słowo "prawie". Spośród powyższych programów nie udało mi się uruchomić żadnego opartego o Blinka. Ani Chromium, ani Iridium nie uruchamiają się, powodując dość nieładny zrzut pamięci. Wersja Chromium zainstalowana z repozytorium działa prawidłowo.
W przypadku Firefox nie ma możliwości ingerencji w język interfejsu. Pomimo doinstalowania spolszczenia, przeglądarka uparcie komunikuje się ze mną w języku Szekspira. Co ciekawe, niektóre inne dodatki zainstalowały się i działają prawidłowo.
Drawpile... cóż wymaga SELinux. Bez zainstalowania - nie będzie działać. W Archu SELinux dostępny wyłącznie z AUR. Zatem o co chodzi z ową interdystrybuowością?
GIMP, Darktable, Krita - działają w zasadzie perfekcyjnie.
LIbreOfficeDev i działa i nie. W przeciwieństwie do wersji przebudowanej z rpm - niekiedy zalicza niezapowiedzianą wpadkę. Oczywiście nie można również zmienić języka interfejsu.
Co ciekawe - wszystkie aplikacje, które działały w Xach udało się również uruchomić na Waylandzie.
Stwierdzić zatem należy, że AppImage mają swoje dobre i złe strony. Część aplikacji nie uruchamia się, w części nie można zmienić ustwień interfejsu. Prawodpodobieństwo, by dla linuksa np. LO, czy FF były paczkowane we wszystkich wersjach językowych jest iluzoryczne. Jeśli zatem ktoś wymaga spolszczenia interfejsu, to otrzyma go chyba wyłącznie tam, gdzie aplikacje używają jakichś ustawień systemowych, albo zostały spaczkowane ze wszystkimi wersjami językowymi (Krita), jakie są dostępne.
Niestety nie doczytałem się (jeszcze) informacji na temat bezpieczeństwa tego rozwiązania. Wspominam o tym, albowiem z w przypadku konkurencyjnego snappy nie jest z tym najlepiej w przypadku uruchamiania tych aplikacji w X11.