MacOS, iTerm i problemy z pl-znakami

Niezbyt często używam pl-znaków w konsoli łącząc się po SSH, ale jest parę miejsc, gdzie ich potrzebuję. Po dłuższym czasie zauważyłem, że na nowym komputerze mam problem z pl-znakami. Występował tylko przy połączeniu się z tego macOS przy pomocy SSH do Linuksa. Nic krytycznego, bo w zasadzie nie potrzebuję się tam łączyć z macOS, z innych Linuksów działało, ale byłoby miło, gdyby działało wszędzie. W końcu znalazłem chwilę i postanowiłem się zająć sprawą.

Krótko o środowisku: na workstacji macOS Ventura 13.4 z zsh 5.9 oraz iTerm2 3.4.19. Dla pamięci opis sprawdzania ustawień krok po kroku.

ustawienia iTerm

Upewniamy się, że iTerm korzysta z kodowania UTF-8. W tym celu należy wybrać
settings -> profiles -> terminal
Upewniamy się, że character encoding jest ustawione na UTF-8.

zmienne środowiskowe

Sprawdzamy ustawienia zmiennych środowiskowych na macOS. W tym celu należy wpisać
echo $LANG
i sprawdzić wartość zmiennej LANG. Powinna być jakaś z UTF-8, na przykład pl_PL.UTF-8.

Jeśli jest inaczej, można dopisać odpowiednią wartość w pliku .zshrc[1]
export LANG=pl_PL.UTF-8

Jeśli wykonujemy zmianę, należy uruchomić nowy terminal, aby została zastosowana.

kodowanie w powłoce

Sprawdzamy na macOS, jakie kodowanie mamy ustawione w terminalu. Wpisujemy locale i weryfikujemy zawartość zmiennych LC_CTYPE oraz LANG. Powinny zawierać kodowanie UTF-8. Jeśli tak nie jest, można ustawić odpowiednie zmienne w sposób opisany w poprzedniem akapicie.

ustawienia systemu zdalnego

Należy sprawdzić, czy na serwerze zdalnym locale ustawione są na wersję z UTF-8. W tym celu wpisujemy locale. Jeśli tak nie jest, to w Debianie i Ubuntu polecenie dpkg-reconfigure locales umożliwi zarówno wygenerowanie odpowiednich locali, jak i ustawienie domyślnych.

Przy powyższych ustawieniach pl-znaki powinny wyświetlać się poprawnie.

Dla zupełnej transparentności: tym razem nie ma odnośników do stron, których używałem przy rozwiązywaniu problemu. Posiłkowałem się bowiem chatGPT z niewyszukanym promptem macos problem utf-8 iterm how to solve. Całkiem sprawnie sobie poradził.

[1] Jeżeli z jakiegoś powodu korzytamy z bash, nie zsh, to właściwym plikiem będzie .bash_profile

Przesiadka na M1

Nadszedł ten moment, kiedy mogłem wymienić służbowy sprzęt. Moment długo oczekiwany. Z dwóch powodów. Po pierwsze, z okazji pandemii cykl wymiany został wydłużony. Po drugie, jako entuzjasta ARMów nie mogłem się doczekać laptopa z tego typu procesorem. No dobrze, nie jest to typowy ARM, jaki można znaleźć w laptopach konkurencji. Ale nadal jest to krok w dobrym – moim zdaniem – kierunku. Pora na wrażenia z kilkudniowego używania.

Ponieważ poprzednio miałem MacBook Pro 13,3″, a pracowałem głównie z domu, bez dodatkowego monitora, stwierdziłem, że pora na większy ekran. Także wydajność w stosunku do 15″ pozostawiała nieco do życzenia, a wersja 15″ nie wydawała się wcale specjalnie większa od typowych laptopów 14″. Zatem jak szaleć, to szaleć. Stwierdziłem, że 14″ to za mało i wezmę 16″ (10 core, 32 GB RAM).

Hardware

Przyznaję, że wstępnie żałuję wyboru. Pierwsze wrażenie przy wyjmowaniu z pudełka to jaka to wielka i ciężka cegła. Faktycznie, zarówno wymiary, jak i waga w stosunku do 13,3″ to inna liga. Pierwsze, co rzuca się w oczy, to fakt, że jest o wiele grubszy i o wiele cięższy. Oczywiście w wersji stacjonarnej nie jest to duży problem, z przeniesieniem z miejsca na miejsce też problemu nie ma. Jak będzie przy pracy typowo mobilnej? Zobaczymy…

Ekran jest bardzo fajny i do pracy stacjonarnej idealny. 13,3″, które wydawało się OK już się wydaje nieco małe.

Szeroko dyskutowane wcięcie na kamerę, zabierające część ekranu. Przyznaję, że nie zauważam tego w codziennej pracy. Zapewne w znacznej mierze jest to wynik chłytu marketingowego w postaci czarnej górnej belki okien. I jak mam świadomość, że jest to de facto zmniejszenie użytecznej powierzchni ekranu, tak zupełnie mi to nie przeszkadza. I tak 99,5% czasu w pracy korzystam z wersji z belką.

W końcu jest też normalna klawiatura. Taka jak w innych laptopach, o niebo przyjemniejsza od nieporozumienia w postaci „drewna” w 13,3″. Zapewne jest to jedna z przyczyn, czemu laptop jest grubszy.

Touchpad tradycyjnie dobry, nowego wejścia na ładowarkę nie oceniam, bo jeszcze nie testowałem – i tak korzystam w okresie przejściowym ze starego, a łatwiej mieć mi jedną.

Z minusów: zmienione zostało położenie gniazda słuchawkowego – teraz jest po lewej stronie. Szkoda, bo przywykłem. Dodatkowo po prawej stronie jest tylko jeden port USB. Jak podłączę tam ładowarkę, to nie mam miejsca na przejściówkę dla myszy. A szkoda, bo z racji większych wymiarów samego laptopa miło byłoby mieć wszystko wpięte po prawej i więcej miejsca na biurku po lewej. Niemniej, podsumowując – sprzętowo bardzo dobrze.

Software

Szybka konfiguracja klawiatury, żeby można było pisać wygodnie polskie znaki i można pracować.

Domyślna powłoka zmieniła się z bash na zsh. Zmiana nastąpiła już jakiś czas temu, poza tym można było wymusić zsh ręcznie. Niemniej, nie ciągnęło mnie. Prawda jest taka, że nie widzę wielkiej różnicy. Oczywiście gdyby komuś nie pasowało zsh to jest możliwość powrotu do bash przy pomocy odpowiedniego użycia polecenia chsh.

W związku ze zmianą architektury miałem lekkie obawy, jak wygląda instalacja dodatkowych programów. Jest różnie. Na niektórych stronach po prostu dostaniemy jedną wersję dla macOS czy też wersję odpowiednią dla naszej architektury. Na innych trzeba samodzielnie wybrać. Większość softu jest dostępna w wersji natywnej i po prostu działa.

Póki co znalazłem tylko jeden program, który nie działa: VirtualBox. Jednak wirtualizacja i konteneryzacja na M1 to już zagadnienie zasługujące na osobny wpis.

Prędkość działania jest OK, czas pracy na baterii też wygląda na więcej, niż zadowalający.

Bullseye

Zakończyłem aktualizację ostatniej[1] maszyny do Debiana 11 czyli Bullseye, pora na tradycyjne podsumowanie.

Najpierw zaktualizowałem kontenery. Operacja totalnie bezproblemowa przy pomocy apt. Czyli wariant zalecany. Z większych zmian warto jedynie odnotować zmianę wpisu dla repozytorium security w sources.list.

Główny host jedynie odrobinę gorzej. Coś mu nie poszło przy zależnościach i odinstalował mariadb. Konfiguracje i dane zostały, więc przywrócenie trwało moment. Niemniej miał prawo się pogubić, korzystam z dodatkowych repozytoriów w tym systemie.

Desktopy również niemal bezproblemowo, w tym przejście z unstable na stable przy okazji upgrade. Jedyne z czym był problem to WiFi i wicd. Z uwagi na zależność od Pythona 2.x pakiet jest usuwany i… skończyłem bez sieci na pierwszym systemie. Rozwiązanie jest proste: wystarczy przeprosić się z network managerem i zainstalować go zamiast wicd przed aktualizacją. Po takim zabiegu aktualizacja bezproblemowa.

Ostatnie było Raspberry Pi robiące za router GSM. Tam co prawda jest Raspbian, nie Debian, ale można powiedzieć, że także była to aktualizacja do Bustera z uwagi na zmiany wpisów w sources.list. Nieco się pospieszyłem i instalowałem jako wersję niestabilną. Niemniej – bez problemu. Choć przygotowałem się na reinstalację systemu i operację przeprowadzałem nie zdalnie, a z fizycznym dostępem do sprzętu.

Ogólnie wygląda na brak większych zmian i chyba najbardziej bezproblemową aktualizację w historii. Jedyne co zauważyłem, to nieco większe zużycie miejsca na dysku. Generalnie tak to już bywa, że nowszy soft jest większy niż stary, ale w przypadku maszyny z kontenerami lxc zabolało to nieco bardziej. Dobiłem do granicy wolnego miejsca na dysku przy wykonywaniu się backupów. IIRC nie skończyło się zupełnie, ale było dosłownie na styk.

Zrobiłem porządki zarówno w logach, zbędnych rzeczach, jak i pakietach. Okazało się bowiem, że w kontenerach mam trochę nadmiarowych rzeczy. Przy tej ostatniej operacji okazało się, że na jednym z kontenerów apt działa wolno. Pobieranie działało normalnie, przeliczanie zależności także. Natomiast każde dodanie lub usunięcie pakietu zaczynało się od przestoju, podczas którego nic się na oko nie działo. Szybki strace ujawnił, że chodzi o okolice dbus. Usunięcie pakietu – kolejnego zbędnego, zresztą – rozwiązało problem.

[1] Tak naprawdę jeden kontener został na Buster i póki co zostanie – soft do generowania Planety Joggera zniknął z Bullseye. I raczej nie wróci, więc trzeba pomyśleć nad przesiadką na inny soft. Niemniej, nic związanego z samym systemem.