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.

LXDE, laptop, jasność i głośność – HOWTO

Jest taka rzecz w laptopach z Linuksem, która często nie działa zaraz po instalacji. Przynajmniej nie na środowiskach korzystających z Openbox, np. LXDE. Chodzi o sterowanie jasnością ekranu oraz głośnością dźwięku.

Nie pamiętam, czy coś się ostatnio zmieniło, czy zawsze tak było, tylko miałem skonfigurowane, ale ostatnio konfigurowałem laptopa z LXDE i jak wszystko działało, tak sterowanie głośnością i jasnością ekranu – nie. Wydaje mi się, że kiedyś obsługa dodatkowych klawiszy była robiona przez ACPI i skrypty (zob. linki na końcu wpisu), ale teraz można prościej.

W obu przypadkach wykorzystywany będzie plik ~/.config/openbox/lxde-rc.xml.

Jasność

Na początek kontrola jasności. W przypadku karty intela, bo taką miałem, kontrola jasności odbywa się z wykorzystaniem programu xbacklight, który musiałem doinstalować. Rozwiązanie powinno działać także dla innych kart. Dodatkowo musiałem utworzyć plik /etc/X11/xorg.conf.d/20-intel.conf o następującej zawartości:

Section "Device"
    Identifier "Intel Graphics"
    Driver "intel"
    Option "Backlight" "intel_backlight"
EndSection

W pliku XML zaś dodałem:

<keybind key="XF86MonBrightnessDown">
  <action name="Execute">
    <command>xbacklight -5</command>
    <startupnotify>
      <enabled>yes</enabled>
      <name>Decrease screen brightness</name>
    </startupnotify>
  </action>
</keybind>
<keybind key="XF86MonBrightnessUp">
  <action name="Execute">
    <command>xbacklight +5</command>
    <startupnotify>
       <enabled>yes</enabled>
       <name>Increase screen brightness</name>
    </startupnotify>
  </action>
</keybind>

Głośność

Trzeba oczywiście mieć zainstalowane programy, które będziemy wykorzystywać – w przypadku instalacji pełnego środowiska LXDE i Debiana 10 wszystko już było zainstalowane. Natomiast w pliku konfiguracyjnym XML wystarczy dodać:

  <keybind key="XF86AudioRaiseVolume">
    <action name="Execute">
      <execute>pactl set-sink-volume 0 +10%</execute>
    </action>
  </keybind>
  <keybind key="XF86AudioLowerVolume">
    <action name="Execute">
      <execute>pactl set-sink-volume 0 -10%</execute>
    </action>
  </keybind>
  <keybind key="XF86AudioMute">
    <action name="Execute">
      <execute>pactl set-sink-mute 0 toggle</execute>
    </action>
  </keybind>

Istnieją warianty wykorzystujące inne polecania pamixer czy amixer (zob. linki).

Oczywiście w ten sposób można zmieniać zachowanie dowolnych skrótów i wykorzystywać dowolne klawisze, nie tylko te wymienione. Pełna lista w źródłach (zob. linki)

Linki:

UPDATE: Skoro już konfigurujemy, warto też pod Print Screen dodać robienie screenshotów. Podobno jest domyślnie, nie potwierdzam, ale może „zasługa” unstable.

    <keybind key="Print">
      <action name="Execute">
        <command>gnome-screenshot -i</command>
      </action>
    </keybind>

Aktualizacja do Catalina 10.15.5

Dawno nie było nic o macOS. Jest stabilnie, czyli korzystam i zbyt zadowolony nie jestem. Ostatnio zrobiłem aktualizację do 10.15.5, więc jest okazja do narzekania.

Przede wszystkim, robiłem aktualizację z 10.15.3, nie z 10.15.4, który był wydany pod koniec marca, co też świadczy o tym, że te aktualizacje nie są takie lekkie łatwe i przyjemne, bo lubię mieć aktualny soft. Czynników było oczywiście więcej, taki drobiazg jak średnia wygoda by mnie nie powstrzymał. A to zespół opiekujący się systemami w firmie nie dał zielonego światła od razu, a to pandemia, więc trochę strach, że nie pójdzie i co wtedy, a to dyżury i wypada mieć sprzęt działający. Koniec końców, zdążyli wydać 10.15.5, nim zaktualizowałem.

Sama aktualizacja przypomniała mi, czemu nie jest to miły proces – stąd notka. 5 GB danych do pobrania, więc dużo. Wiedziałem, że to trwa, więc załączyłem i poszedłem precz. Gdy wróciłem, system marudził, że nie umie zamknąć programów. Znaczy głaszcz mnie użytkowniku, pozamykaj i try again. Zamknąłem kilka programów, dłuższą chwilę trwała walka z edytorem Atom. Bardzo nie chciał się zamknąć i koniec końców używałem force quit. Jeśli ktoś jest przyzwyczajony do podejścia linuksowego, gdzie system robi co mu się każe, bez szemrania i dodatkowego popychania – bardzo słabo to wygląda.

Jak już wszystko pozamykałem i w końcu się zrestartował, przypomniała mi się anegdotka o tym jak Windows liczy czas/postęp: ostatnie 5 min/5% trwa kwadrans/jedną trzecią czasu. Jak podczas pobierania wiało optymizmem, że będzie pół godziny, tak pół godziny to zbierał się po reboocie. To już nawet nie tylko Linux, ale nawet Windows jakoś szybciej sobie radzi z aktualizacjami.

Potem, po uruchomieniu, było z górki, za wyjątkiem jednego ostrzeżenia, które wyglądało tak:

Informacja o przestarzałym rozszerzeniu systemowym

Existing software on your system loaded system extension signed by „Fumihiko Kakayama”, which will be incompatible with a future version of macOS. Contact the developer for support.

Zgadza się, nie jest napisane o jaki program chodzi, za to jest imię i nazwisko developera, który podpisał rozszerzenie systemowe. Nie wiem jak czytelnicy, ale ja kojarzę jakiego softu używam, nie kto go jest developerem, a już o rozszerzeniach i osobach je podpisujących nie mam pojęcia. No ale ja truskawki cukrem… Odnośnika brak, w learn more również pustka.

W każdym razie szybkie wyszukanie ujawniło, że chodzi o Karabiner. I jestem trochę przerażony, bo bez tego softu macbook będzie dla mnie nieużywalny praktycznie, przynajmniej w zakresie pisania z pl-znakami. Mam nadzieję, że poprawią lub będzie inna opcja na przemapowanie klawiszy.

Trochę jestem zdziwiony, że nie jest napisane o którą wersję chodzi. Dużą? Małą? Najbliższą? Którąś kolejną?

Praca zdalna

W związku z obecną sytuacją w kraju i na świecie[1] pracuję zdalnie, z domu. W moim przypadku było to trochę łatwiejsze, bo i IT, i zespół rozproszony, więc ćwiczyliśmy dłuższy czas pracę raz w tygodniu zdalnie, ale nadal czym innym jest okazjonalnie dzień zdalnie, a czym innym codzienna praca zdalna. Z tej okazji garstka mniej oczywistych porad, może przyda się komuś, kto dopiero zaczyna.

Zapasowy dostęp do internetu

Jeśli pracuje się zdalnie, warto zadbać o zapasowy dostęp do internetu. Głupio byłoby musieć jechać do firmy tylko dlatego, że nasz ISP wysiadł. Zwłaszcza teraz. Jako zapas wystarczy tak naprawdę karta SIM, za router WiFi spokojnie może robić stary smartfon, można przełożyć kartę do zwykłego smartfona albo użyć drugiego slotu na kartę SIM. Co lepsi IMO operatorzy komórkowi, których używam lub używałem, zapewniający backup dostępu do internetu w wersji na kartę, czyli prepaid:

Aero2
Jest to mój zdecydowany faworyt – nie wymaga inwestycji w postaci opłacania co miesiąc abonamentu, pamiętania o wygasaniu konta, po prostu jest, gotowy do użycia. Wadą jest długi czas oczekiwania na kartę – nie kupimy jej w sklepie. Warto załatwić i niech sobie leży.
Oferuje Darmowy pakiet 512 kb/s bez konieczności odnawiania (z CAPTCHA co godzinę) oraz różne pakiety od 5zł/m-c. Cokolwiek sensownego to jednak 30 zł.

a2mobile
Najlepszy operator, jeśli potrzebujemy korzystać z internetu regularnie, ale umiarkowanie. Oferuje nieograniczony ilością danych dostęp do internetu, z tzw. lejkiem, czyli zmniejszającą się prędkością.
W zupełności wystarcza do komfortowego przeglądania stron i korzystania z poczty, problemy pojawią się dopiero przy streamingu, zwł. w większych ilościach, choć jest możliwość „resetu” lejka.
Jest tańszy/szybszy od aero2 przy podobnym zaangażowaniu (kupno pakietu raz na miesiąc). Pakiet za 13 zł/m-c daje nam:
do 5 GB – bez limitu prędkości
5–10 GB – prędkość max. 3 Mb/s
10–15 GB – prędkość max. 1 Mb/s
powyżej 15 GB – prędkość max. 512 kb/s

Virgin Mobile
Warto rozważyć VM, jeśli planujemy mieć numer „stacjonarny” z opcją na backupowy internet. Ze względu na kupno pojedynczych pakietów 1 GB daje dużą granularność kosztu. W razie potrzeby nie ma więc problemu ze streamingiem. Może być tańszą alternatywą dla a2mobile, kosztem większego zaangażowania przy kupnie pakietów. Porównując z poprzednikiem – jeśli wydamy 13 zł, to będziemy mieli 10 GB internetu.
Pakiety na kartę od 3 zł/m-c + 1zł/1GB

Oczywiście realna prędkość zależy w przypadku dostępu bezprzewodowego od wielu czynników – sprzętu, zasięgu, operatora. Ograniczenia dostawcy to górny limit.

Narzędzia

Zoom to jeszcze jedno rozwiązanie do telekonferencji. Celują raczej w firmy, ale oferują pakiet darmowy, a w związku z aktualną sytuacją także bezpłatną wersję dla szkół.
W aplikacji jest opcja push to talk (domyślnie spacja przy wyłączonym mikrofonie, można zmienić w skrótach klawiszowych). Na odpowiednio wydajnym sprzęcie (podobno wymagany procesor i7) daje możliwość ustawienia tła, które maskuje bałagan w pokoju. Wykrywanie postaci działa bardzo dobrze. Jest też możliwość wspólnego rysowania. Dostępne wersje dla Windows, macOS, Linux. Ta ostatnia była stara i kulawa, jak ostatnio patrzyłem, ale dało się używać.

Ćwiczenia

Pracując przy komputerze przysługuje nam przerwa 5 min na każdą godzinę pracy. Warto ją wykorzystać – przynajmniej w części – na ćwiczenia, szczególnie, jeśli mamy mniej ruchu przez niewychodzenie z domu. Najlepsze wydają mi się dość intensywne ćwiczenia (mamy tylko 5 minut na wszystko!), które nie wymagające specjalnego przygotowania, miejsca czy sprzętu. Moi faworyci:

  • przysiady – nie trzeba nikomu przedstawiać, istnieje wiele wariantów
  • wykroki – jedną nogą robimy krok do przodu i uginamy tylną tak, by kolano niemal dotknęło ziemi, następnie powrót i zmiana nogi
  • pompki – znowu raczej popularne, wiele wariantów z różnym rozstawieniem rąk. Jeśli ktoś ma, to można użyć uchwytów. I bardziej higienicznie, i lepsza efektywność.
  • podciąganie na drążku – odstępstwo od braku sprzętu. Podciąganie nachwytem to bardzo fajne ćwiczenie angażujące plecy.

Przy okazji ćwiczeń pamiętamy oczywiście o wietrzeniu, jeśli tylko pogoda pozwala.

Pracując zdalnie warto pamiętać o bezpieczeństwie, ale o tym już pisał Sekurak.

[1] Pandemia covid-19 oczywiście. Myślałem o wpisie na blogu, ale trochę za mało materiału i za szybko się zmienia, więc luźne myśli lądują w formie lżejszej na Diasporze. Może coś jeszcze napiszęw tym temacie, ale raczej nieprędko.

Instalacja podatnych wersji oprogramowania HOWTO

Niekiedy zachodzi potrzeba uruchomienia starej, podatnej wersji systemu lub usługi w celu przetestowania czegoś, np. exploita. W przypadku Debiana i podobnych dystrybucji opartych na pakietach deb, instalacja starej wersji systemu bywa nieco problematyczna, ponieważ po pierwsze system pakietów nie wspiera downgrade’u, po drugie, domyślnie instalator instaluje najnowsze wersje pakietów, jeśli tylko ma taką możliwość.

Sposobów na instalację starszych wersji pakietów jest wiele. Można kompilować określoną wersję, ale nie jest to wygodne, jest czasochłonne i niekoniecznie uzyskamy wersję dokładnie taką, jaka była w systemie, np. z powodu patchy nakładanych przez Debiana czy nieco innego środowiska w którym pakiet był budowany[1].

Skoro jednak korzystamy z dystrybucji opartej o pakiety binarne, można także próbować robić downgrade pakietów, albo usuwać pakiety i instalować przy pomocy dpkg zamiast apt[2]. Jeśli nie mamy pecha, wszystko zadziała czy to od razu, czy po małym force przy instalacji. Można też instalować ze starych obrazów instalacyjnych, bez dostępu do sieci. Czasem jednak nie mamy szczęścia. A wszystko można zrobić szybciej i prościej.

Przede wszystkim, i tak trzeba jakoś zdobyć podatne wersje pakietów. W przypadku Debiana istnieje snapshot.debian.org, czyli serwis z oficjalnymi, snapshotami mirrorami repozytoriów Debiana. Doskonałe miejsce pozwalające i na pobranie pakietów w takich wersjach, w jakich były w danym momencie w repo, i na postawienie całego systemu w stanie na dany dzień. Snapshoty wykonywane są częściej, niż raz dziennie, poza głównym repozytorium pakietów dostępne inne, w tym security i backports, więc trudno sobie wyobrazić coś lepszego. Pozostaje instalacja systemu z wykorzystaniem powyższych repozytoriów.

Naprościej można to zrobić z użyciem debootstrap, poprzez podanie mirrora., z którego mają być pobierane pakiety. Przykładowo, aby zainstalować Debiana Buster w wersji, w jakiej był on dostępny dzień po wydaniu:

debootstrap buster /chrooted/ https://snapshot.debian.org/archive/debian/20190707T150059Z/

Po instalacji należałoby jeszcze wejść do chroota i uzupełnić sources.list o wpisy dla repozytorium security, zaktulizować pakiety i… gotowe. W katalogu /chrooted będzie dostępny podatny system. Jeśli był tam podmontowany dysk zdalny, to można uruchomić podatną maszynę według podlinkowanej wyżej instrukcji.

Istnieje jeszcze szybszy i IMO wygodniejszy sposób uruchomienia podatnej wersji systemu – można wykorzystać kontenery LXC do instalacji, a następnie uruchomienia podatnego systemu. O tyle wygodne i bezpieczne, że kontener LXC może być dostępny – i jest to domyślna konfiguracja – wyłącznie z poziomu hypervisora, bez udostępniania go na świat. Kontener z Debianem Buster w wersji na dzień po wydaniu z użyciem LXC tworzymy:

lxc-create -n test -t debian -- -r buster -a amd64 --mirror=https://snapshot.debian.org/archive/debian/20190707T150059Z/ --security-mirror=https://snapshot.debian.org/archive/debian-security/20190707T153344Z/

I gotowe. Po zakończeniu powinniśmy mieć dostępny kontener LXC z podatną wersją systemu o nazwie test, którym możemy zarządzać w standardowy sposób. W sources.list będziemy mieli:

cat /etc/apt/sources.list
deb https://snapshot.debian.org/archive/debian/20190707T150059Z/          buster         main
deb https://snapshot.debian.org/archive/debian-security/20190707T153344Z/ buster/updates main

[1] W weryfikacji zgodności pakietów pomóc mogą reproducible builds.
[2] W tym miejscu nadal odsyłam do wpisu o wajig i zachęcam do zapoznania się z narzędziem. To stary wpis, nie wszystkie opisane okoliczności muszą być prawdziwe, ale nadal wajig działa i ma ciekawe opcje, więc warto go znać.