Lecton, Wędrowycz i kompresja audio

Jakiś czas temu[1], jeśli dobrze pamiętam w okolicach marca, InPost zrobił promocję dotyczącą paczkomatów. Wygrać można było nawet samochód, udział nie wiązał się z przekazaniem dodatkowych danych, więc wziąłem udział. Samochodu oczywiście nie wygrałem, za to wygrałem – jak wszyscy inni znani mi uczestnicy loterii – parę kodów dających dostęp do programu Lecton, czyli aplikacji Audioteka s.a pozwalającej na dostęp do audiobooków.

Nieuchronnie będę porównywać z produktem Legimi, do którego dostęp uzyskałem wcześniej na podobnych zasadach. Są jednak różnice. Przede wszystkim Lecton rozlicza w postaci czasu dostępu do biblioteki, nie na sztuki. Także w promocji. Udało mi się w ten sposób poznać większą część cyklu o Jakubie Wędrowyczu.

Appka działała bez zarzutu. Być może kwestia niższych oczekiwań po kontakcie z Legimi, być może kwestia większej ilości miejsca na urządzeniu. W każdym razie słuchało się przyjemnie, intuicyjnie i bez walki z techologią. Oczywiście dostęp do książek jest tylko za pośrednictwem aplikacji, bez możliwości pobrania na urządzenia zewnętrzne, ale w modelu, gdzie płaci się za czas dostępu, nie za pozycje jest to zrozumiałe.

W ramach abonamentu korzystać można na jednym urządzeniu i jednym dodatkowym w trybie offline. Abonament to 20 zł/m-c (po prostu, bez promocji) Brak ebooków, tylko audiobooki, plus jakieś dodatki w stylu audycji cyklicznych itp. Mnie interesują tylko książki. Nadal – jest taniej, niż w przypadku Legimi, ale brak ebooków i mniejsza liczba urządzeń. Za Lecton ma prostsze warunki umowy – mniej wariantów i sumarycznie bardziej mi się podobał.

W Lecton drażni mnie tak naprawdę jedna rzecz – sposoby płatności. Nie ma klasycznego prepaid, trzeba podać albo kartę płatniczą, albo PayPala, żeby sobie pobierali opłatę abonament. Rozumiem, że subskrybcję można wyłączyć. Rozumiem, że tak jest prościej zaimplementować (i pewnie rozliczać), rozumiem, że tak jest korzystniej dla sklepu, bo klient nie może zapomnieć zapłacić, najwyżej zapomni wyłączyć subskrybcję. Wiem, że to coraz bardziej popularny model. Nadal drażni i finalnie doprowadziło do tego, że nie kupiłem abonamentu, wracając do książek tradycyjnych. Wiem, to nie jest dokładny odpowiednik, bo książki tradycyjnej nie posłucham w tramwaju.

Książki o Jakubie Wędrowyczu – wciągają. Znałem tylko pierwszy tom opowiadań, gdzie dominują krótkie utwory, w pozostałych tomach cyklu pojawiają się dłuższe. Jest niestety monotematycznie i z powtórzeniami, a żart opowiadany wielokrotnie przestaje bawić. Może kwestia dawki. Dodatkowo na przestrzeni cyklu pojawia się wiele niespójności, opowiadania są jakościowo różne. Niektóre naprawdę fajne koncepcyjnie, część to po prostu zgrabnie opowiedziane historyjki. IMO najsłabiej wypadają momenty, gdy zaczyna się politykowanie, często nachalne i znowu z powtórzeniami. Niemniej, warto. Całość jest ciekawa, zabawna, jako gawęda – zgrabna. Dodatkowo audiobooki są ładnie zaaranżowane i dobrze czytane. Chociaż tak w ogóle, po przeczytaniu opowiadań z 2586 kroków oraz Rzeźnika drzew mam wrażenie, że w utworach niewędrowyczowych Pilipiuk wypada lepiej.

Skoro przy audio jesteśmy – część techniczna, poniekąd będąca odpowiedzią na moje narzekania na zajmowane przez audiobooki miejsce. Audiobooki są duże, zapewne kompresowane do formatu MP3 lub zbliżonego. Tymczasem w przypadku mowy (audiobooki, podcasty itp.) nie potrzebujemy pełnego spektrum, więc można skorzystać z innych formatów, pozwalających na znacznie lepszą kompresję. Typowe MP3 to 128 kbps, tymczasem Speex pozwala na zejście do 4 kbps, lepiej wspierany na różnych playerach Opus na 7 kbps. Więcej opisane tutaj, a narzędzia są w repo. Prawdziwi hardcore’owcy mogą zejść nawet poniżej 1 kbps (dostępne sample).

[1] Kolejny wpis, który dość długo przeleżał w szkicach, a ostatecznie został opublikowany w niemal oryginalnej wersji.

Yerba z sokiem pomarańczowym

Lato zmierza ku końcowi, więc ostatnia szansa na spróbowanie genialnego orzeźwiającego napoju, o którym przypominam sobie co roku o wiele za późno, dopiero podczas największych upałów. Chodzi o yerba mate z sokiem pomarańczowym.

Przygotowanie odbywa się bez gotowania – bierzemy porcję yerba mate (2-3 czubate łyżki stołowe), wsypujemy do butelki 1,5-2 litra, zalewamy wodą, zakręcamy i wstawiamy do lodówki na 2-3 doby. Przechowujemy w lodówce. Po tym czasie używamy do zrobienia napoju – nalewamy do szklanek jedną trzecią do połowy uzyskanej esencji i dopełniamy sokiem pomarańczowym. Pić przez bombillę, ew. można próbować nalewać przez gęste sitko.

Napój ma fajny „złamany” smak – nie jest tak słodki jak sam sok, nawet rozcieńczony wodą. W przypadku, gdy i sok, i esencja są przechowywane w lodówce, nie ma potrzeby dodawania lodu. Można próbować postąpić analogicznie z herbatą lub zieloną herbatą zamiast yerba mate – na oko powinno działać, ale nie testowałem.

Tąpnięcie

W pierwszej chwili myślałem, że posypały mi się statystyki. Nie zaglądam do nich często, ale strona ze statystykami jest otwarta w którejś tam zakładce w przeglądarce. Pewnego dnia ujrzałem ilość wejść na blog w okolicach zera. Była jedna czy dwie wizyty parę godzin wcześniej i… to wszystko. Odświeżenie strony nie pomogło. Korzystam z Matomo (dawniej Piwik) na własnym serwerze, więc jakaś awaria systemu, bazy czy koniec miejsca na dysku mogły mieć dokładnie taki efekt.

Posprawdzałem, nawet coś poprawiłem (drobny warning dotyczący bazy) i… bez zmian, a spadek wizyt dotyczył tylko podstawowego bloga, nie wszystkich stron. Spojrzałem w Google Webmaster Tools, a w zasadzie w Search Console, bo teraz tak to się chyba nazywa i… sprawa się wyjaśniła:

Blog w Google Search Console

Widać duży spadek przeciętnej pozycji w wyszukiwarce (z ~20 na ~60), idealnie skorelowany ze spadkiem wyświetleń (z ~800 na ~200), który przekłada się na trochę większy niż czterokrotny spadek odwiedzin. Myślałem, że chwilowe przeindeksowanie, zwłaszcza, że 04.08 w zasadzie wróciło do normy, wraz z wizytami na blogu, ale jak widać jest to raczej trwała zmiana.

Zapytałem wiedzących czy jest jakaś większa zmiana w Google. Ano jest, nazwa kodowa Maverick. Chociaż raczej chodzi o zmianę z pierwszego sierpnia. W każdym razie w Matriksie coś zmieniają.

Taka ciekawostka i ładny przykład, żeby się nie przywiązywać do strony, jej miejsca w wyszukiwarce i ilości wejść, skoro monopol na kształtowanie widoczności ma Google. W Search Console jest opóźnienie, więc jeszcze tego nie widać, ale patrząc na statystyki wizyt w ostatnich dniach wygląda, że sytuacja wraca do normy. I w sumie dobrze, bo nie mam weny na grzebanie w SEO.

PS Wpis pisany na raty, ostatecznie wygląda, że wizyty wracają do normy. Ziew.

Mac i problemy z locale w terminalu – HOWTO

Jak pisałem, częściowo siedzę na macu. Zrozumiałem ludzi, którzy narzekali na obsługę systemu klawiaturą w macach. Wiele skomplikowanych combo na trzy palce. Ale to mogła by być kwestia przyzwyczajenia, zwłaszcza w trybie graficznym. Jeśli jednak ktoś korzysta głównie z terminala, to „fun” jest na zupełnie innym poziomie. Otóż funkcję klawisza Ctrl w macOS „normalnie” (czyli w GUI) spełnia lewy klawisz command, umieszczony tam, gdzie normalnie jest alt. Jeśli jednak przejdziemy do terminala, to w aplikacjach uruchomionych w konsoli żeby zrobić ctrl-c należy wcisnąć… control-c. Tak, jest też osobny klawisz control, którego należy używać w terminalu.

Jeśli jednak korzystamy z VirtualBox i uruchomimy tam Linuksa, to żeby utworzyć nową zakładkę w przeglądarce należy użyć… control-t. W GUI. W tej samej przeglądarce pod macOS używamy command-t. IMO totalna porażka UXowa i coś do czego nie sposób się przyzwyczaić, jeśli ktoś używa systemów na przemian. Można najwyżej nieustannie pamiętać, ale u mnie kończy się to masą missclicków. Zobaczę jeszcze co będzie po podłączeniu zewnętrznej, pecetowej klawiatury, choć to raczej z ciekawości – w końcu to nie stacjonarka. Ew. poszukam jakiegoś software’owego rozwiązania, choć staram się unikać przemapowywania klawiszy jak mogę – ciężko się później korzysta z instrukcji w necie.

Z pozytywów – doceniam działające kopiowanie i wklejanie w terminalu przy pomocy command-c i command-v. Pod Linuksem są na to osobne skróty, choć do tego akurat używałem myszy i zaznacz (i automatycznie skopiuj) i środkowego przycisku do wklejania. Domyślnie działa też – analogicznie jak pod Linuksem – wklejanie zaznaczonego w terminalu tekstu przy pomocy środkowego klawisza myszy. Niestety, jest ograniczone do konsoli, aby skopiować jakieś polecenie z przeglądarki trzeba już używać skrótów klawiszowych.

Wracając do tematu z topica. Po zmianie systemu na macOS i logowaniu przy pomocy ssh na serwery witał mnie komunikat w stylu:

-bash: warning: setlocale: LC_ALL: cannot change locale (pl_PL.UTF-8)
-bash: warning: setlocale: LC_ALL: cannot change locale (pl_PL.UTF-8)
-bash: warning: setlocale: LC_ALL: cannot change locale (pl_PL.UTF-8)

Sprawa jasna, problem ustawieniami locales, tyle, że nigdy mi się nie zdarzał, w systemie (macOS) niby są ustawione. Na chwilę odpuściłem temat, bo mało estetyczny komunikat przy logowaniu to nie dramat, ale szybko okazało się, że potrafi to wpływać – rzecz jasna ujemnie – na działanie poleceń i skryptów. Gdy tylko siadłem do szukania rozwiązania okazało się, że problem jest popularny, wręcz powszechny.

Pierwsze rozwiązanie, które znalazłem, wyglądało elegancko i nawet tłumaczyłoby, czemu nie działa skoro locales są ustawione. Niestety, po włączeniu i otwarciu nowych zakładek w terminalu, a nawet restarcie terminala okazało się, że… nie działa. Teraz widzę, że rozwiązanie jest stare, z 2012, wtedy mi umknęło.

Dopiero tu znalazłem faktyczne rozwiązanie problemu z locale w terminalu pod macOS. Jest proste i sprowadza się do dodania dwóch linii w pliku ~/.bash_profile:

export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8

Powinno działać także z wersją polską, ale nie testowałem – w moim przypadku powyższa wersja jest OK, przynajmniej po pobieżnym sprawdzeniu nie zauważyłem problemów. Ustawienie z pierwszego rozwiązania również zostawiłem.

Aktualizacja Debiana do Buster

Parę dni temu Debian ogłosił wydanie nowego stabilnego wydania o nazwie kodowej Buster. Aktualizację zacząłem natychmiast, ale dopiero teraz mogę nieco o niej napisać.

Przede wszystkim, pospieszyłem się. Szóstego lipca tylko zerknąłem na newsy i… pomyliłem poprzedniego newsa, dotyczącego wydania wersji 9.9 z wydaniem Bustera. Co prawda rzecz działa się już w trakcie wydawania (co widać było na Twitterze), ale zrobiłem lekki falstart.

Lekko zdziwił mnie brak release notes (zasługa falstartu), ale większość rzeczy mam odseparowanych w kontenerach LXC, więc aktualizacje powinny proste, poza tym, który to już raz? Wziąłem na warsztat przy kawie jedną maszynkę fizyczną i kontenery LXC na niej. Kontenery poszły od kopa w stylu apt-get update && apt-get upgrade && apt-get update && apt-get dist-upgrade. Nie jest to zalecany sposób – w release notes jest napisane, by korzystać z apt, ale nie wiedziałem o tym i… nie miało to znaczenia.

Aktualizacja hypervisora również gładka, kontrolny reboot i… kontenery się nie podnoszą. Co prawda apt-listchanges (polecam!) pisał, że LXC 3 got some significant changes from LXC 2, ale pozwoliłem zmienić konfigurację do nowej wersji, stosowane brakujące linie też były dodane. Wyszukiwarka nie pomagała, ludzie na kanale też nie. Z szybkiego upgrade od kawy zrobiła się godzinna walka z debugiem. Okazało się, że czyste, nowe kontenery z Busterem z minimalnym konfigiem także nie startują (error w loglevel INFO, hmm…):

# create
lxc-create -n test3 -t download -- -d debian -r buster -a amd64

# run
lxc-start -n test3 -l debug -o /tmp/debuuug.txt

# logs
tail -n 8 /tmp/debuuug.txt
lxc-start test3 20190706132233.984 NOTICE   start - start.c:start:2037 - Exec'ing "/sbin/init"
lxc-start test3 20190706132233.985 NOTICE   start - start.c:post_start:2048 - Started "/sbin/init" with pid "8584"
lxc-start test3 20190706132233.985 NOTICE   start - start.c:signal_handler:430 - Received 17 from pid 8582 instead of container init 8584
lxc-start test3 20190706132233.985 DEBUG    lxccontainer - lxccontainer.c:wait_on_daemonized_start:830 - First child 8580 exited
lxc-start test3 20190706132233.999 DEBUG    start - start.c:signal_handler:447 - Container init process 8584 exited
lxc-start test3 20190706132233.999 INFO     error - error.c:lxc_error_set_and_log:49 - Child <8584> ended on error (255)
lxc-start test3 20190706132233.999 DEBUG    network - network.c:lxc_delete_network:3180 - Deleted network devices
lxc-start test3 20190706132234.152 INFO     conf - conf.c:run_script_argv:356 - Executing script "/usr/share/lxcfs/lxc.reboot.hook" for container "test3", config section "lxc"

O dziwo kontenery w wersji ze Squeeze startowały. Doraźnie wróciłem w kontenerach do Squeeze (z backupu, nie downgrade) i na pewien czas zostawiłem sprawę., chociaż okazało się, że startują dość kulawo – nie podnosiła się sieć ani nie uruchamiały usługi, trzeba to było robić ręcznie po każdym restarcie kontenera. Niefajne, ale do czasu znalezienia rozwiązania docelowego można wytrzymać, tym bardziej, że restarty są rzadkością.

Ostatecznie właśnie problemy ze startem i porównanie działania LXC na innym, świeżym hypervisorze z Buster, gdzie wszystko działało bez problemu naprowadziły mnie na rozwiązanie. Przy diagnostyce przy pomocy systemctl status otrzymywałem komunikat:

System has not been booted with systemd as init system (PID 1). Can't operate

Rozwiązaniem okazało się przejście na systemd i odinstalowanie pakietów związanych ze starym systemem init (niestety nie zapisałem nazw). IIRC na hypervisorze i w kontenerach. Po tym zabiegu wszystko działa poprawnie i startuje automatycznie, zarówno ze Squeeze w kontenerach, jak i po aktualizacji do Bustera.

Nie zaktualizowałem jeszcze wszystkich maszyn[1], ale z godnych odnotowania zmian – kontener generujący Planetę Joggera został w końcu zaktualizowany do nowej wersji Debiana, tj. do Bustera, bezpośrenio z Jessie zresztą[2]. Z działaniem na Squeeze był problem, na wersji testowej czy unstable także wtedy nie działało. Na szczęście jest już poprawione, co oznacza, że planeta ma szansę istnieć kolejne parę lat.

Ogólnie póki co aktualizacja całkiem przyjemna i prosta, o ile się ma systemd.

UPDATE: Na ostatnim serwerze napotkałem kolejny problem – skrypty w Pythonie korzystające z virtualenv przestały działać. Rozwiązanie łatwe do znalezienia po wpisaniu komunikatu – trzeba usunąć i utworzyć virtualenv na nowo. Dotyczyło zarówno Pythona 2 jak i Pythona 3.

[1] Został jeden serwer i jakieś desktopy na których akurat nie mam unstable i RPi robiące za router, którego trochę boję się zdalnie aktualizować, bo to zdalny system i nie mam żadnej alternatywnej łączności.

[2] Aktualizacja z przeskokiem wersji nie jest zalecanym sposobem, ale skoro to tylko okrojony kontener, który mogę w każdej chwili przywrócić z backupu, to czemu by nie spróbować?