Udostępnianie internetu z telefonu

Niedawno usłyszałem pytanie o setup dla abcc, które zawierało ciekawy element – jedno z dostępnych połączeń było przez USB[1]. Zaintrygowało mnie to, bo tak się złożyło, że zupełnie nie znałem tematu. Zawsze udostępniałem internet z Androida wykorzystując WiFi i tworząc access point. Nie byłem pewien jak takie połączenie w ogóle jest widoczne pod Linuksem.

Poczytałem, sprawdziłem i sprawa jest prosta. Aby udostępnić internet z telefonu z Androidem należy najpierw podłączyć kabel USB. Dopiero wtedy aktywna staje się opcja USB tethering. Po jej aktywacji na telefonie, w systemie powinno pojawić się urządzenie usb0. Traktujemy jak zwykłą przewodową kartę sieciową.

Takie proste, a nigdy nie korzystałem. Czy warto udostępniać połączenie z Androida po USB, zamiast po WiFi? Jedna zaleta jest oczywista – podczas udostępniania połączenia telefon zużywa więcej prądu. Podłączenie kablem do komputera zapewnia od razu ładowanie. Z kolei oczywista wada to mniejsza swoboda ruchów – kabel jest zawsze jakimś ograniczeniem.

Pora sprawdzić wydajność. Szybki zgrubny test, po prostu fast.com, w dodatku pojedynczy pomiar dla każdej konfiguracji.

Operator nr 1
42 Mbps download 10 Mbps upload, latency 32 ms unloaded, 462 ms loaded na WiFi 2,4 GHz
42 Mbps download 15 Mbps upload latency 30 ms unloaded, 420 ms loaded na USB

Operator nr 2 (IPv6)
78 Mbps download 11 Mbps upload, latency 30 ms unloaded 321 ms loaded na WiFi 5 GHz
71 Mbps download 14 Mbps upload, latency 28 ms unloaded 446 ms loaded na USB

Wielkich różnic jak widać nie ma. Wariancie optymistycznym, czyli nieobciążonym łączu na kablu zyskamy nieco na opóźnieniach sieciowych. Lepsze powinien też być upload. Czyli domyślnie warto podłączyć kabel USB. Nie są to jednak wielkie różnice, więc jeśli nie gramy w gry online albo nie zależy nam na prędkości uploadu, wygląda, że może decydować wygoda.

UPDATE I jeszcze dla porównania wyniki z mojej kablówki, nominalnie 60/10:
62 Mbps download 7 Mbps upload, latency 6 ms unloaded 50 ms loaded na WiFi 5 GHz

Oczywiście inny serwer, pomiar dzień później itd. Ale i tak widać, jak bardzo LTE dogoniło, albo wręcz przegoniło kablówkę opartą o miedź. Światłowód zapowiadany był dwa lata temu, ale nadal nic nie wskazuje, by miał się pojawić.

[1] Sprawa w toku, może zasłuży na osobny wpis jak skończę.

Bateria w laptopie

Jakoś tak zeszło ze znajomymi na rozmowę o komputerach. Dokładniej o laptopach wykupionych z pracy. No i mówię, że wszystko fajnie, ale bateria chyba będzie wymagała wymiany u mnie, bo nie trzyma jak dawniej. Oczywiście gdyby laptop był zbudowany jak kiedyś, zwyczajnie wymieniłbym ją i zapomniał o temacie. Jednak teraz zamiast osobnej baterii, którą można wpiąć z zewnątrz, są zabudowane, w środku laptopa. Czyli z prostego wypięcia starej i wpięcia nowej zrobiła się trochę bardziej skomplikowana operacja, co trochę zniechęca.

Tym bardziej, że bateria nadal trzyma tylko… krócej. W zasadzie określenie „trzyma krócej” to nadużycie, bo nie wiedziałem, ile naprawdę trzyma. Zauważyłem, że komunikat o niskim stanie naładowania pojawia się wcześniej. I miałem wrażenie, że nagle. Trochę sfera domysłów, ale po pierwsze raczej rzadko korzystam z tego sprzętu na baterii, a po drugie raczej nie śledzę wtedy stanu naładowania, bo robię coś innego.

Pomiar

W każdym razie rozmowa skłoniła mnie, żeby sprawę zbadać dokładniej. Żeby zobaczyć, ile trzyma bateria, popełniłem szybki skrypt:

#!/bin/bash
OUT='/home/rozie/battery.log'
while :
do
date >> $OUT
acpi >> $OUT
sleep 60
done

Po uruchomienu, co minutę w pliku dodawane są dwie linie. Data i stan baterii. Na przykład:

nie, 30 maj 2021, 19:49:52 CEST
Battery 0: Discharging, 95%, 09:06:51 remaining

Nie jest to idealna wersja do parsowania, ale widać co się działo i kiedy.

Odłączyłem laptopa od zasilania i czekałem. W sumie nie doczekałem się wyłączenia, bo usnąłem. No ale po to właśnie był log.

Okazało się, że laptop działał długo. Stwierdziłem, że do określenia wszystkie wystarczy tak naprawdę sam stan naładowania baterii. W końcu próbki są robione dokładnie co minutę, więc czas będzie znany.

Wynik

Przerzuciłem do CSV i zrobiłem wykres:

Wizualizacja raportowanej pojemności baterii w procentach

Jak widać potwierdziło się wszystko, co mi się wydawało. Bateria trzyma długo, bo prawie 6h. Co prawda to raczej okolice idle, ale nadal sporo, zwłaszcza jak na kilkuletni sprzęt. Widać też, że zgłaszana pojemność gwałtownie spada po ok. 3,5 h.

Czyli jest problem. Szukałem jak go rozwiązać i póki co wyczytałem tylko tyle, że system ma tu niewiele do powiedzenia. Na razie znalazłem taką radę. Rozładowałem do zera, choć miałem opory, bo coś mi się kojarzy, że to niezbyt zdrowe dla baterii. Chyba nie pomogło. Ewentualnie hibernacja coś tu ma do rzeczy.

Za to znalazłem lepsze narzędzie do pomiaru stanu baterii laptopa w czasie. Battery-stats, bo o nim mowa, jest ładnym rozwinięciem prostej idei z powyższego skryptu dostępnym w repozytoriach Debiana. Jest i porządny plik, czytelny dla człowieka, i skrypt w bashu, który z pomocą gnuplot generuje wykres.

Gdyby ktoś miał pomysł, jak sprawić, aby cały czas pokazywana była rzeczywista pojemność i pozostały czas pracy, chętnie przyjmę rady. Wymieniać nie będę. Nawet gdybym miał wyłączać laptopa po tych 3,5 h, to w zupełności mi to wystarcza.

Mapowanie klawiszy w macOS bez Karabiner Elements – HOWTO

Karabiner Elements to popularne narzędzie do mapowania klawiszy na macOS. Narzędzie jest wygodne, ale ma parę problemów. Trzeba instalować oddzielny program, były ostrzeżenia o legacy system extension, które opisywałem przy okazji opisu upgrade. Nie testowałem, ale podobno nie działa po upgrade do Big Sur.

Większość znanych mi ludzi wykorzystuje Karabiner Elements do prostego celu: zamiany prawego option z prawym command. Wszystko po to, żeby wygodnie, czyli tak samo jak na PC, wpisywać polskie znaki diakrytyczne. Robiłem tak i ja, a program był w ogóle zupełnym must have na macOS.

Mapowanie klawiszy w macOS bez Karabiner Elements - obrazek
Źródło: wygenerowane za pomocą https://thumbnail.ai/

Ponieważ znalazłem dziś kolejną osobę, która nie wiedziała, że się da, a wykorzystywała właśnie w tak prosty sposób, podzielę się sposobem, który sprzedał mi znajomy z pracy (dzięki J!). Rozwiązanie nie wymaga dodatkowych programów, wystarczy wbudowane oprogramowanie systemowe.

hidutil property --set '{"UserKeyMapping":
[{"HIDKeyboardModifierMappingSrc":0x7000000e7,
  "HIDKeyboardModifierMappingDst":0x7000000e6}]}'

Powyższe polecenie spowoduje, że klawisze zostaną przemapowane tymczasowo, do restartu systemu. Aby osiągnąć ten efekt na stałe, tworzymy plik ~/Library/LaunchAgents/mapkeys.plist o zawartości:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.nanoant.KeyRemapping</string>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/bin/hidutil</string>
        <string>property</string>
        <string>--set</string>
        <string>{"UserKeyMapping":[{"HIDKeyboardModifierMappingSrc":0x7000000e7,"HIDKeyboardModifierMappingDst":0x7000000e6}]}</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
</dict>
</plist>

Oczywiście rozwiązanie można stosować także do bardziej skomplikowanego mapowania klawiatury. Jednak jak wspominałem na początku, większości użytkowników powinien wystarczyć ww. gotowiec. Po takim zabiegu, skoro mamy działającą aleternatywę, można odinstalować Karabiner Elements zupełnie.

UPDATE: Przydatne linki
Generator mapowania
Gotowa do użycia wersja online