Terminal HP T620

Czasy się zmieniają, nawet terminale się zmieniają. Wieki temu miałem terminal T5520, który robił za router i potencjalnie mógł robić za media center dla audio. Teraz szukałem czegoś, na czym mógłby zrobić media center bardziej filmowe. Znaczy, upraszczając: miał działać Netflix.

Rozwiązania dedykowane

Początkowo rozważałem coś w stylu Xiaomi Mi TV Stick albo Xiaomi Mi TV Box. Potem znajomy zainteresował mnie sprzętem Fire TV Stick[1]. Ostatecznie od różnych rozwiązań z Androidem odstraszyły mnie stare wersje systemu oraz uwagi w opisach w stylu „Netflix działa, ale nie wolno aktualizować appki, bo przestanie”. Czyli zauważalny nadchodzący brak wsparcia i możliwości aktualizacji, w tym aktualizacji bezpieczeństwa. Czytaj: spory potencjał na elektrośmieć.

HP T620

Równolegle na horyzoncie pojawił się terminal HP T620.

HP T620
Źródło: strona producenta

HP T620 to tak naprawdę nie konkretny model, a cała rodzina terminali. Łączy je wiele cech wspólnych: duża ilość portów różnego rodzaju, umieszczonych zarówno z przodu, jak i z tyłu, pasywne chłodzenie, energooszczędność (<5 W w idle). Posiadają dwu- lub czterordzeniowy procesor AMD. Pamięć można rozbudować do 16 GB przy pomocy modułów SODIMM. Więcej informacji na stronie producenta.

Wybór

Ostatecznie wygrał sentyment do bezwentylatorowych terminali HP i Linuksa. Po co zamknięty TV stick, skoro można za grosze kupić używany terminal HP T620 z 4 GB RAM? Taki, który będzie nie tylko odtwarzał filmy, ale będzie pełnowartościowym komputerem np. do WWW. I który – co najważniejsze – będzie można zaktualizować.

Jak pomyślałem, tak zrobiłem. Co prawda opisy nie zachęcały, bo HP T620 sprzedawane były jako deklarowane bez podstawki i zasilacza. Podstawki nie potrzebowałem, zasilacz to zwykły laptopowy HP, więc i tak miałem. Ostatecznie przybył egzemplarz z podstawką i zasilaczem. Podstawka w nieidealnym stanie, ale do odratowania. Zresztą nie używam na razie.

Instalacja

Instalacja Debiana stable z drobnymi problemami. Nie pamiętam z czego dokładnie instalowałem, bo chwyciłem co było pod ręką. Jeden instalator upierał się przy GPT, efektem czego był niebootujący się system. Drugi z kolei miał problem z WiFi – znany temat braku firmware w instalatorach Debiana. Ostatecznie po prostu na czas instalacji podpiąłem kabel. Przy okazji przetestowałem działanie systemu uruchomionego z USB. HT T620 posiada USB 3.0, więc powinno być OK. I jest. Zresztą taki był pierwotny plan uruchomienia. Jednak wbudowane 8 GB flash okazało się wystarczające nawet na rozbudowany system.

Wydajność

Przyznam, że początek był rozczarowujący. Po włączeniu Firefoksa i Netfliksa trochę jakby cięło, a procesor na 100%. Po włączeniu filmu było lepiej, ale nadal nie byłem przekonany o pełnej płynności. Zmieniłem przeglądarkę na Brave i jest o niebo lepiej. Nadal duże obciążenie CPU po włączeniu strony, ale już po uruchomieniu filmu jest OK. O tyle, o ile może być OK na i przeglądarce. Bo zdaje się full HD wymaga dodatkowych zabiegów. Nie wiem, nie robiłem, jakość jest zupełnie wystarczająca. Może kiedyś się pobawię.

Netflix i 1080p w przeglądarce

No to na koniec garść linków dotyczących Netfliksa w 1080p w przeglądarce. Nie testowałem póki co.

  1. Watch Netflix in 1080p in Firefox web extension download now
  2. Netflix in 1080p in Chrome
  3. Raspberry Pi Netflix One Line Easy Install – along with Hulu, Amazon Prime, Disney Plus, HBO, Spotify, Pandora, and many others

[1] Niezła strona z „hackami”: firestickhacks.com

Linux i powiadomienia via Telegram – HOWTO

Czemu zdecydowałem się na wysyłanie powiadomień via Telegram? Kiedyś wysyłałem SMSy z powiadomieniami, nawet zrobiłem skrypt do wygodnej wysyłki SMSów z CLI. Czasy trochę się zmieniły, telefony zostały zastąpione smartfonami. Po co płacić za SMSy, kiedy można wysłać powiadomienie inaczej, w dodatku za darmo? Wybrałem powiadomienia wysyłane przez Telegram.

logo Telegram
Źródło: https://www.freepnglogos.com/images/telegram-logo-944.html

Oczywiście istnieją inne metody. Zawsze można było wysyłać maile, które są co prawda darmowe, ale z założenia miewają opóźnienia. No i niekoniecznie chcemy dostawać powiadomienie na telefonie o każdym mailu. Gdy rozpoznawałem temat obiecująco wyglądały natywne powiadomienia push na telefon, ale ich uruchomienie nie jest proste. I nie do końca są darmowe, jak widać.

Znajomi zachwalali Telegram i jego możliwości, jeśli chodzi o tworzenie botów. Nawet kiedyś podchodziłem do uruchomienia bota Telegram, ale wydało mi się to wtedy skomplikowane. I samo stworzenie bota, i sama interakcja. Czyli wysłanie komendy, by coś wykonał i odesłał wynik. Dodatkowo nie ma czegoś takiego jak prywatny bot, a uwierzytelnianie czy też sprawdzanie nadawcy trzeba robić samodzielnie. Przynajmniej tak wyczytałem w necie. Może jestem przewrażliwiony, ale za bardzo to wszystko pachniało mi RCE. No i w końcu stawianie bota, gdy zależy tylko na prostych powiadomieniach, to overkill.

Wczoraj odświeżyłem temat i… okazało się, że wysłanie powiadomienia przez Telegram jest proste. I w sumie nie potrzeba żadnych bibliotek, by wysłać powiadomienie – wystarczy tak naprawdę curl.

Przygotowanie wysyłki powiadomień przez Telegram

Aby wysyłać wiadomości, potrzebne są nam dwie rzeczy: TOKEN oraz CHATID.

  1. Korzystając z bota BotFather w Telegramie stwórz swojego bota[1] (/newbot)
  2. Zapisz otrzymany TOKEN (np. 1234567890:AABBccddeeff-ABCDEFGHIJabcdefghi12)
  3. Znajdź swojego bota, wpis /start
  4. Przejdź na https://api.telegram.org/bot<yourtoken>/getUpdates
    W naszym przypadku na https://api.telegram.org/bot1234567890:AABBccddeeff-ABCDEFGHIJabcdefghi12/getUpdates
  5. Znajdź ciąg „id” dla „from” (np. „id”:723456789). Wartość jest szukanym CHATID.

Wysyłka powiadomień przez Telegram

Najprostszym wariantem wysłania powiadomienia jest wywołanie curl w postaci

curl "https://api.telegram.org/botTOKEN/sendMessage?chat_id=CHATID&parse_mode=Markdown&text=WIADOMOŚĆ"

Czyli na przykład, dla powyższych danych uzyskanych podczas konfiguracji

curl "https://api.telegram.org/bot1234567890:AABBccddeeff-ABCDEFGHIJabcdefghi12/sendMessage?chat_id=723456789&parse_mode=Markdown&text=to jest test śćżń ĄŁĘĆ https://zakr.es/"

Po wydaniu tego polecenia powinniśmy otrzymać na w kliencie Telegram telefonie wiadomość. Dodatkowo z klikalnym linkiem.

Nieco bardziej eleganckie, użyteczne i tylko odrobinę bardziej skomplikowane jest wysyłanie przy pomocy Pythona i biblioteki requests. Zostało ono opisane opisane we wpisie How to create a telegram bot and send messages with Python, który był bezpośrednią inspiracją tego wpisu. Znajdziecie tam również dokładną, ilustrowaną instrukcję konfiguracji bota. A o samych botach Telegram może będzie innym razem.

[1] Owszem, miało być bez bota. Ale się nie da – bot musi być. Nie musi obsługiwać żadnych komend ani wdawać się w interakcje, ale ten twór jest tak naprawdę telegramowym botem.

Aktualizacje macOS

Pierwszą aktualizacją macOS, którą robiłem, była ta między „dużymi” wersjami, do wersji Catalina. Wtedy byłem umiarkowanie zadowolony, bo to duża aktualizacja. I pierwsza. I się udała. Od tego czasu miałem parę razy okazję aktualizować system między „małymi” wersjami i… wyrobiłem sobie zdanie.

Źródło: http://www.highstreetcomputers.com/apple-logo-broken/

Aktualizacje systemu w macOS to porażka, generalnie. „Duże” może nie są najgorsze, ale „małe” są tragiczne. Spójrzmy na listę aktualizacji Cataliny na Wikipedii, linkującą do opisu aktualizacji na stronach Apple. Od końca października 2019 do lipca 2020 było sześć aktualizacji. Każda to przynajmniej 3 GB do pobrania i blisko godzina stracona na aktualizację.

No właśnie, jeśli ktoś zastanawia się, o co mi w ogóle chodzi i czy da się system aktualizować lepiej, to szybko nakreślę jak wygląda proces aktualizacji w Linuksie. Otóż sprowadza się do pobrania pakietów i wykonania restartu. Cały czas można pracować na komputerze. Restart i okoliczne czynności nie trwają pół godziny, to zwykły reboot, jak każdy inny, czyli pewnie minuta. Aktualizowany jest zarówno kernel, kluczowe pakiety, jak i pakiety opcjonalne. Nie trzeba pobierać 3 GB, ale to już detal. Chodzi głównie o brak przerwy w możliwości korzystania z komputera.

No właśnie, gdy pisałem o aktualizacji do Cataliny i porównywałem jej czas z aktualizacją Debiana, popełniłem błąd. Porównywałem jabłka z gruszkami – w przypadku macOS brałem pod uwagę czas aktualizacji samego systemu, czyli podstawki, a w przypadku Linuksa systemu i wszystkich dodatkowych aplikacji będących w repozytoriach, a trochę tego jest (LibreOffice, Firefox, Chromium). Nie jest to aż tak ważne, bo to, czy pobieranie trwa pół godziny, czy godzinę nie ma większego znaczenia, jeśli można korzystać z systemu. Kluczowy jest czas niedostępności komputera.

Tyle o aktualizacjach systemu w makach, dopóki coś się diametralnie nie zmieni albo nie wybuchnie przy upgrade, nie będę wracał do tego smutnego tematu.