LXDE -> LXQt – podejście pierwsze

Od dłuższego czasu (notka wskazuje, że już sześć lat, jak ten czas leci…) moim domyślnym – i w zasadzie jedynym używanym – środowiskiem na desktopie (ang.: desktop environment) jest LXDE. Nie udało mi się oczywiście całkiem zrezygnować z zależności od KDE. Z aplikacji przychodzących z KDE ostały się: edytor kate (jednak z GUI – najwygodniejszy, obecnie myślę o Atom, ale kobyła…); konsole (w szczególnych przypadkach typu konieczność wyboru charsetu, bo lxterminal ogólnie działa bardzo fajnie) oraz… kdiff3, który jest wygodny. Ale nie o tym ma być notka. Będzie porównanie LXDE vs LXQt.

Środowisko LXDE

Środowisko LXDE Źródło: http://lxde.org/lxde_desktop/

Swego czasu w sieci było sporo zachwytów nad LXQt i trochę bolało mnie, że nie ma paczek w Debianie, żeby się pobawić. Potem zauważyłem, że paczki pojawiły się w unstable, ale nie było już jakoś ani czasu, ani ochoty. Ostatnio sobie przypomniałem o ich istnieniu, zainstalowałem pakiety, przelogowałem się i… trochę rozczarowanie. Może za dużo czytałem zachwalania i miałem za wysokie oczekiwania, ale przyznam, że LXQt nie powaliło mnie.

Pierwsze co mi się rzuciło w oczy, to brzydkie dekoracje okien i brak większego wyboru w tym zakresie. OK, może kwestia przyzwyczajenia. Do tego doszły braki widgetów (np. wyloguj) oraz zmiany działania tych, które były wcześniej używane. Przykładowo wykres użycia CPU czy RAM zawiera teraz więcej informacji, na jednym wykresie. W przypadku CPU pokazuje nie po prostu zużycie, ale z rozbiciem na nice, system, user. RAM podobnie – used, buffers… Po co to komu na desktopie, tak naprawdę? Na pierwszy rzut oka jest mniej czytelnie, choć informacji więcej. I jest to ogólny trend. Widget do pokazywania temperatury korzysta domyślnie ze wszystkich możliwych źródeł, zarówno tych działających, jak i nie działających. I żeby było „normalnie”, to trzeba wyłączyć niechciane (i niedziałające).

Podgląd pulpitów jakiś taki brzydszy. Znaczy wybór pulpitów, bo podglądu po prostu nie ma. QTerminal nadal nie ma możliwości wyboru kodowania. Wbudowane blokowanie terminala (czyli screensaver) odwołuje się do nieistniejącej binarki, chociaż to akurat obchodzę przy pomocy xscreensavera, tak samo miałem zrobione w LXDE.

Żeby nie było, że tylko wady: widać, że poświęcono trochę pracy na łatwiejsze (drag & drop) dodawanie programów do pasków. Pojawiło się jakby więcej opcji w wielu miejscach. Trochę mam skojarzenia z KDE 3.5 (tak jak je pamiętam), jeśli chodzi o możliwości konfiguracji. Wiele rzeczy daje się obejść, np. zamiast brakującego widgetu do wylogowania można użyć drugiego paska ze skrótami do aplikacji i tam przeciągnąć z menu odpowiednie programy. Zdecydowanie fajny jest menadżer nośników wymiennych – w LXDE nie korzystałem, nie wiem czy w ogóle był.

Drobiazgów typu zużycie RAM nie mierzyłem – w porównaniu z dowolną przeglądarką WWW to są orzeszki teraz… Ogólnie środowisko działa szybko i sprawnie. Mam je na domowym desktopie od jakichś dwóch tygodni i zdecydowanie daje się używać.

Środowisko LXQt

Środowisko LXQt. Źródło: http://lxqt.org/screenshots/dark/

Podsumowując: wygląd jest sprawą dyskusyjną. Moim zdanie LXQt nie wnosi nic specjalnego w stosunku do LXDE, poza wyglądem, więc jeśli ktoś korzysta z LXDE, to raczej nie będzie zachwycony zmianą. Faktem jest, że LXQt działa i daje się używać, więc gdyby LXDE zniknęło, to mam wybranego następcę. Zmiana filozofii z „jest prosto i działa” na „można więcej skonfigurować” – co kto lubi. Mi LXDE pasowało, bo korzystałem z praktycznie niemodyfikowanej konfiguracji domyślnej i wielką zaletą przesiadki na LXDE był właśnie fakt, że praktycznie wszystko od kopa działa i nie trzeba rzeźbić. Przy przejściu z LXDE na LXQt trochę trzeba się pobawić z konfiguracjami.

Póki co zostawiam LXQt, żeby pozbyć się przyzwyczajeń, ale nie wykluczam, że za parę tygodni wrócę do LXDE. Tym bardziej, że właśnie z LXDE korzystam na innych desktopach – paczki LXQt w Debianie są dopiero w testing i wyżej.

UPDATE Pojedynek LXDE vs LXQt na dłuższą metę wygrało jednak LXDE. Jakoś przyjemniej to moim zdaniem wygląda.

Muzyka z YouTube w konsoli

Na YouTube można w prosty sposób znaleźć sporo różnej muzyki i obecnie jest to mój wybór numer jeden, jeśli chodzi o muzykę z sieci[1]. Odtwarzanie YouTube w przeglądarce jest oczywistym wyborem w przypadku filmów. Jeśli jednak zależy nam tylko na audio, czyli np. słuchamy w pracy, to odtwarzanie w przeglądarce tylko przeszkadza. Niepotrzebnie obciążamy i sieć, i CPU, i RAM.

Niedawno znalazłem program mps-youtube, który jest napisany w Pythonie i który stawia sobie za cel obsługę YouTube w konsoli. Można m.in. wyszukiwać utwory, dodawać URLe, tworzyć lokalne playlisty, a także pobierać muzykę w określonym formacie na dysk. Opis mówi, że można też importować istniejące playlisty z YouTube, ale tej funkcjonalności jeszcze nie testowałem. Całość pomyślana w taki sposób, aby można było dowiedzieć się wszystkiego z samej aplikacji, bez konieczności czytania manuali. Sam program przychodzi z sensownymi ustawieniami domyślnymi.

Pomoc programu mps-youtube
Pomoc programu mps-youtube – screenshot

Wersja z Jessie 0.01.46-3 jest o wiele starsza, niż dostępna w unstable 0.2.5-5, ale… obie wersje mają błędy, niestety i bywa, że jedna wersja potrafi otworzyć dany URL, a druga nie. Na GitHubie dostępna jest wersja 2.6, ale jeszcze nie testowałem. W pracy, gdzie słucham najwięcej (niby leci jakieś radio ogólnie, ale słaba muza, w kółko te same utwory, dużo reklam, poza tym, „uroki” openspace…), wystarcza mi wersja z Jessie. Niemniej nadal polecam przymiarkę do programu.

Wyniki wyszukiwania w mps-youtube
Wyniki wyszukiwania w mps-youtube. Źródło: strona projektu.

Lokalna playlista mps-youtube
Lokalna playlista w mps-youtube. Źródło: strona projektu.

Niby działa na dowolnym systemie operacyjnym, ale z racji trybu obsługi (konsola) wróżę popularność raczej na Linuksie i wśród geeków. Dla porządku: wymaga mplayera lub mpv, z których korzysta do odtwarzania muzyki.

[1] Jak widać, opisywane kiedyś słuchanie radia w konsoli się nie sprawdziło, podobnie jak wykorzystanie mpd. Łatwe tworzenie playlist z dostępnych od ręki zasobów jednak wygrywa.

3 powody dla których nie kupię Raspberry Pi 3

Blisko trzy lata temu (ależ ten czas leci) pisałem, dlaczego nie kupię Raspberry Pi. Parę dni temu opublikowana została specyfikacja Raspberry Pi 3. I też widzę, że nie kupię, choć cieszę się na płytkę z 64 bit ARM. Powody są trzy:

  1. Brak portu SATA. Najmniej istotny, bo można podłączyć dysk po USB (i raczej tak zrobię), ale nadal trochę boli.
  2. Tylko 1 GB RAM. Mało. Na desktop – przeraźliwie mało. IMO minimum dla desktopa na dzień dzisiejszy to 2 GB RAM. Zresztą skoro mocniejszy procesor, to i serwer można by bardziej obciążyć, a tu RAM też się przydaje.
  3. 100 Mbps ethernet. Dla rozwiązań typu NAS 100 Mbps to zdecydowanie za mało.

Co zamiast Raspberry Pi 3? Czaję się na najwyższy model Pine 64 czyli PINE64+ 2GB. Co prawda też nie ma SATA, ale ma 1Gbps kartę sieciową oraz 2 GB pamięci RAM. I ma kosztować przy tym 29 dolarów + 12 dolarów za wysyłkę do Polski.

Wady Pine64? Wspomniany brak SATA, jeśli ktoś potrzebuje USB i bluetooth, to musi dołożyć kolejnych 10 dolarów, albo kupić wersje na USB (2,5 w Chinach) i zająć oba porty. No i trzeba poczekać do maja.

UPDATE To wszystko oczywiście z mojego punktu widzenia, który można streścić „małe, tanie, mocne i Linux działa”. Z punktu widzenia kogoś, kogo bardziej interesuje zabawa elektroniką będzie to wyglądało zupełnie inaczej, bo w grę wchodzi choćby łatwość supportu czy dostępność rozszerzeń.

Warto też przeczytać komentarz Piotra (pierwszy) – Odroid wygląda nieźle (jak zwykle zresztą), choć jest nieco droższy (jak zwykle zresztą). Patrz porównanie. Czyli ciekawych alternatyw dla Raspberry Pi 3 jest więcej.

Dowiedziałem się też o istnieniu dystrybucji Armbian. Autorzy nie piszą niestety zbyt wiele, ale wygląda interesująco i wspiera wiele płytek. Oferuje świeży kernel i wspiera Debiana (Wheezy, Jessie) oraz Ubuntu Trusty.