Tag: laptop

Opublikowane w

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.

Opublikowane w

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, czyli klawisze multimedialne.

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 tzw. klawiszy multimedialnych 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 klawisze multimedialne, 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>
Opublikowane w

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 w jakiś sposób o tym, że te aktualizacje nie są wcale 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[1].

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

[1] UPDATE Po czasie okazało się, że można przemapować klawisze bez Karabiner Elements.