Rozważania o blokowaniu ekranu

Przy okazji trwającej dramy dotyczącej xscreensavera w Debianie[1] przypomniał mi się pokrewny temat, o którym miałem robić wpis jakiś czas temu. Chodzi o blokadę dostępu do komputera, niezależnie od używanego systemu (Windows, Linux, OS X). Tradycyjnie jest to jakiegoś rodzaju wygaszacz ekranu, który po pierwsze blokuje możliwość odczytu danych z ekranu, po drugie, blokuje możliwość wprowadzania danych do uruchomionych programów. Do odblokowania zwykle konieczne jest podanie przez użytkownika hasła do systemu.

Rozwiązanie znane jest od dawna i wydawać by się mogło, że to wystarczy, ale czy tak jest faktycznie? Coraz więcej danych jest wprowadzanych i odbieranych z komputera nie tylko przy pomocy klawiatury i ekranu, ale także przy pomocy innych urządzeń. Programy do komunikacji VoIP, czy to Skype, czy aplikacja dostępna przez przeglądarkę typu appear.in czy hubl.in, po zablokowaniu ekranu nadal działają. Umożliwiają i odsłuchiwanie połączonych osób, i przekazują dane z otoczenia do nich. Zarówno za pośrednictwem audio, jak i video. Blokada ekranu co prawda wyłączy możliwość podglądu naszego rozmówcy, ale już nie wyłączy naszego webcama…

Jak na razie nie wiem nic o alternatywach dla wygaszaczy ekranu, które w momencie aktywacji blokowałyby nie tylko klawiaturę i ekran, ale dodatkowo wyłączały webcam(y) oraz wyciszały (mute) audio[2]. Pobieżne testy urządzeń z Androidem pokazują, że także na nich problem jest aktualny, przynajmniej w zakresie dźwięku. Warto po prostu pamiętać, że zablokowany komputer czy telefon w naszym otoczeniu wcale nie musi być tak do końca zablokowany…

[1] Skomentowałem u developera na blogu i wystarczy, wpisu nie będzie, sytuacja jest IMHO żenująca, więc szkoda klawiatury – jeśli ktoś ma cierpliwość, to wystarczy śledzić podlinkowane źródła.

[2] Jeśli istnieją systemy z takimi rozwiązaniami, albo samodzielne aplikacje, to chętnie poznam – u nikogo z nowszym Windowsem nie widziałem takiego rozwiązania.

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.