MacOS problemy z zaśnięciem

Dawno niczego o macOS nie pisałem, bo nie było o czym. System generalnie działa, jest trochę słabo konfigurowalny, ale działa. Trochę potrafi się znarowić i przymulać, głównie za sprawą wygaszacza ekranu zżerającego cykle procesora, ale odkąd zmieniłem wygaszacz na inny, to jakby przestało występować.

Jednak jedna rzecz nie daje mi spokoju. I wbrew temu co może sugerować tytuł, nie chodzi o kofeinę[1]. Mam stację dokującą, do której podłączone są trzy rzeczy: zasilacz, by dostarczać prąd, dodatkowy monitor oraz mysz. Mysz zwykła, pecetowa, taka jak lubię. Sama stacja dokująca jest podłączona do komputera przez USB C.

Problem polega na tym, że gdy uśpię system przy pomocy sleep (bez zamykania ekranu), to jakiekolwiek naciśnięcie klawisza na klawiaturze czy ruch myszą wybudzają go. Klawiatura to nie problem, ale mysz – trochę tak. Wystarczy szturchnięcie biurka i już obudzony.

Dopóki korzystałem z myszy bezprzewodowej, wyłączałem ją przełącznikiem. Niezbyt wygodne, ale przywykłem. Tak samo mógłbym traktować bezprzewodową klawiaturę, ale nie miałem potrzeby. Niestety mysz zaczęła ostatnio nieco szwankować, więc wymieniłem ją. Stwierdziłem, że przewodowa będzie lepsza, bo i tak używam stacjonarnie. No i jest lepsza. Poza jedną rzeczą, czyli nieszczęsnym wybudzaniem.

Poradziłem się znajomych i rady były… nieco dziwne. Odłączanie kabla od stacji dokującej (meh). Odłączanie kabla myszy (meh). Usypianie przez zamykanie klapy. To ostatnie nie było takie całkiem nieakceptowalne, więc spróbowałem. Niestety, macOS, który ma podłączony monitor i zasilanie, traktuje zamknięcie klapy jako sygnał do przełączenia wyświetlania na monitor, nie sygnał uśpienia. Co prawda wybranie sleep po zamknięciu klapy już usypia system tak, że nie reaguje na ruchy myszą, ale nie jest to zbyt wygodne.

Wiem, problemy pierwszego świata. ale może znacie jakieś magiczne zaklęcia konsolowe, które pozwolą zahibernować system z podłączonym monitorem i zasilaniem? Tak, żeby poruszenie myszą go nie wybudzało? Dodatkowe, zewnętrzne programy raczej odpadają – polityka firmy. Pozostaje to, co przychodzi z systemem.

[1] Caffeinate znaczy.

Bateria podwójnie chroniona

Jakiś czas temu telefon mnie zaskoczył przy okazji ładowania. Pojawiło się jakieś powiadomienie, że teraz o baterię[1] w moim telefonie może dbać AI. Upewniwszy się, mam pod ręką ciężki i twardy przedmiot, na wypadek gdyby AI postanowiło przejąć kontrolę nad urządzeniem, zacząłem czytać dokładniej.

Przypuszczam, że to jakaś nowa funkcjonalność, która przyszła z ostatnią aktualizacją Androida, bo wcześniej tego nie kojarzyłem. Optimized charging – bo tak się nazywa funkcja – ma być przydatna, gdy podłączamy telefon do ładowarki w stałych porach. Nie jest zalecana, jeśli ładujemy nieregularnie.

Niby wykorzystuje AI, aby nauczyć się wzorca, kiedy telefon jest podpięty do ładowarki, następnie ogranicza ładowanie do 80%. Około godziny przed planowanym odłączeniem, pozwala się naładować baterii do 100%. Znaczy się nie AI w obecnym rozumieniu, a pewnie jakiś machine learning, zapewne.

Druga funkcja to overcharge protection. Działa prościej, jeśli 3 kolejne dni telefon był podłączany do ładowarki, to ogranicza ładowanie do 80% pojemności baterii. A raz w tygodniu, w celu utrzymania poprawnej kalibracji, ładuje do 100%.

Tak, Android dorobił się dwóch niezależnych, konkurencyjnych sposobów ochrony baterii.

Korzystam z tego drugiego wariantu, bo raczej nie podłączam ładowarki, jeśli bateria nie jest bliska rozładowania. I mam wątpliwość, czy faktycznie ładuje do 100%, bo jakoś tego nie zauważyłem. Czy to coś daje? Nie potrafię zweryfikować, ale ładowanie do 80% zupełnie mi nie przeszkadza. Jeśli potrzebuję pełnej pojemności (podróż itp.) to po prostu wyłączam funkcję.

[1] Znaczy się akumulator. Ale pomału pomału kalka z angielskiego zdobywa polski język. Stawiam, że jeszcze dekada, może dwie i akumulator będzie równie częsty, jak obecnie niedeklinowane radio.

Debian Trixie

Wczoraj została nowa wersja Debiana, o nazwie kodowej Trixie. Podobnie jak przy okazji Bookworm, wrażenia z instalacji.

Na pierwszy rzut, jeszcze wczoraj, poszedł kontener LXC w którym działa nowy certstream[1]. Nie bardzo miało co pójść nie tak i… nie poszło. Aktualizacja w zasadzie nudna, jedyne o czym warto pamiętać, to zmiana formatu w jakim podawane są źródła apt. Nie była to nowość, bo w końcu na desktopie mam od dawna Debiana Sid.

Rozochociło mnie to i jako drugi zacząłem aktualizować kontener z Linuksem na Chromebooku. No nie polecam. Będę przywracał z backupu. Ale to raczej nie wina Debiana, raczej coś przeoczyłem, lub – co najbardziej prawdopodobne – po prostu są dodatkowe elementy wymagane przy interakcji. Komunikaty niezbyt pomocne, w zasadzie naprowadzają jedynie na zbyt małą ilość przydzielonej pamięci ale… nie wygląda na używaną.

Potem zaktualizowałem jeszcze kontenery LXC w których działają blogi. Wymagane były drobne poprawki związane ze zmianami w składni nginx oraz wersją PHP. Dość standardowo.

Więcej roboty było ze skryptami Pythona i virtual environments. Musiałem wszystkie utworzyć, przy okazji wyszły drobne zmiany w bibliotekach. Problemem jest ilość i konieczność ręcznej roboty, nie stopień komplikacji.

Szybka ściągawka z poleceń, oczywiście polecam lekturę instrukcji:

apt update
apt upgrade
# Zmiana wpisów w sources (sed -i "s/bookworm/trixie/" /etc/apt/sources.list)
apt update
apt upgrade --without-new-pkgs
apt full-upgrade
apt autoremove
apt modernize-sources
# Opcjonalnie
apt list '~o'
apt purge '~o'
apt list '~c'
apt purge '~c'

Jeśli coś ciekawego wyniknie na pozostałych systemach, dam znać.

[1] Notka w trakcie tworzenia, nie ma chronologii, oj, nie ma…