Ergonomia maca – system i software

W poprzednim wpisie o podobnym tytule było o hardware maców, pora zająć się softem i systemem. Będzie z ponad półrocznej perspektywy, ale muszę przyznać, że niewiele się od pierwszego wrażenia zmieniło. A nie ukrywam, że jestem rozczarowany. Mocno rozczarowany.

Pierwsze na co się naciąłem korzystając z macowego filesystemu to fakt, że jest prawie case sensitive. Prawie. Otóż lubię robić symlink download -> Download, bo wygodniej się wpisuje bez shift w konsoli. I co? I nie da się. Nawet nie ma sensownego komunikatu o błędzie.

Spotkałem się z opiniami, że maci są wygodne, dopracowane, a system jest przyjazny. Tymczasem konfiguracja wyglądu kuleje i nie daje miejsca na dostosowanie do indywidualnych preferencji, nawet w podstawowym zakresie.

Pasek z zegarkiem, statusem Wi-Fi, stanem baterii itp. musi być u góry. Nie da się przesunąć go na dół i sprawdzić, by zawsze był widoczny. Nie i już – musi być u góry, a o tym, że ktoś chciałby cały czas mieć dostęp do zegarka itp. również jakby nie pomyślano – o tym niżej.

Na dole jest z kolei dock, który IMO jest totalnie nieprzydatny i – jak pisała Yzoja – zachowuje się dziwnie i nielogicznie. Na szczęście da się skonfigurować jego ukrywanie, więc kontakt z nim ogranicza się w zasadzie do „skaczących” powiadomień. Może są one ładne, ale na dłuższą metę irytujące. Na szczęście nie wyskakują często.

Przyciski do maksymalizacji, minimalizacji okien są po lewej stronie belki okna i nie da się tego zmienić. Dodatkowo brakuje przycisku do maksymalizacji okna takiej, aby pasek statusu był widoczny. Da się to osiągnąć klikając na belce okna, ale przycisku nie ma, a domyślna maksymalizacja ukrywa pasek z zegarkiem i nie da się tego zmienić konfiguracją. Jak dla mnie poświęcenie kikunastu pikseli ekranu to niewielka cena za stały dostęp do skrótu uruchamiania programów, statusu programu i kilku innych informacji.

Systemowy zegarek. Gdy zobaczyłem, że kliknięcie w zegarek nie pokazuje kalendarza, zupełnie zwątpiłem w zdrowy rozsądek twórców systemu. Funkcja bardzo przydatna, obecna i w Linuksie, i w Windows, nawet nie sądziłem, że tak często z niej korzystam. Nie znalazłem fajnego darmowego rozwiązania, które naprawia ten problem, ale przyznaję, że szukałem pobieżnie – i tak mam cały czas w pracy otwarty Google Calendar.

Przełączanie między programami – pisałem, że mi się podoba, bo przełącza nie kolejno, tylko na ostatnio używane, co jest nawet fajne. Niestety, jeśli mamy uruchomione dwie instancje tego samego programu, np. Firefox z dwoma różnymi profilami, to przełączanie cmd-tab nie działa między nimi i trzeba korzystać z innego skrótu: cmd-`. Czyli najpierw cmd-tab, by wybrać Firefoksa, potem cmd-`, by wybrać instancję. Korzystam na szczęście rzadko, bo jest to wyjątkowo niewygodne. Oczywiście możliwości zmiany zachowania brak. Jak cmd-c i cmd-v działające między wszystkimi aplikacjami są plusem, tak ww. jest analogicznym minusem. IMO bardziej upierdliwym.

Aplikacje i ich instalacja. Yzoja nazwała instalator aplikacji żartem dla kilkulatków. Faktycznie jest fatalnie. Oczywista wada w stosunku do Linuksa to brak centralnego zarządzania pakietami – nie da się jednym poleceniem/kliknięciem zaktualizować wszystkich aplikacji – wymagana jest instalacja każdego programu z osobna, a aktualizacje żyją własnym życiem. Miało być łatwo (przeciągnięcie w celu instalacji), wyszło koślawo, bo każda aplikacja realizuje to trochę inaczej (np. pozwalając na różne wersje tej samej aplikacji lub nie), są też aplikacje instalowane zupełnie inaczej (brew, macports). Czyli nie jest to jeden sposób instalacji. Dodatkowo kwestię instalacji nowych wersji komplikuje wymuszanie zamknięcia działających instancji. A czasem po prostu wygodniej jest zainstalować nowszą wersję, dokończyć pracę w starej i dopiero wtedy zrobić restart.

Stabilność aplikacji pozostawia wiele do życzenia. LibreOffice Calc z arkuszem kalkulacyjnym, nawet pustym, wiesza mi się po kilkunastu sekundach. Na szczęście nie potrzebuję arkusza, tj. mam online. Może reinstalacja pomoże, tylko zastanawiam się, co poszło nie tak, bo wersję mam najnowszą…

Virtualbox nie jest szybki (w porównaniu z natywnym linuksowym KVM), ale to jakby niekrytyczne i jestem w stanie wybaczyć. Za to po wybudzeniu z uśpienia zużywał 100% CPU i powodował radosne wycie wiatraków, a tego wybaczyć nie mogę. Drążyłem temat, dobrzy ludzie z supportu desktopów w firmie podpowiedzieli polecenia diagnostyczne (konsola, dużo konsoli), w logach padały często odniesienia do dźwięku i faktycznie – po wyłączeniu dźwięku w wirtualkach jest spokój. Ponieważ moje VMki to raczej serwery, to brak dźwięku w nich mnie nie boli, ale wada pozostaje wadą.

Skoro przy dźwięku jesteśmy to kolejna sprawa. Korzystam ze stacji dokującej (Belkin), do której podłączone mam słuchawki. Po odłączeniu od stacji dźwięk przełącza się na wbudowane głośniki, po podpięciu z powrotem do stacji wraca na słuchawki. Prawie zawsze, bo czasem nie wróci i trzeba klikać w ustawieniach systemowych. Urządzenie jest widoczne, więc nie wiem o co mu chodzi.

Ja rozumiem, że I don’t like the bugs, but the bugs like me zobowiązuje, ale jak dla mnie macOS łączy najgorsze cechy Windowsa i Linuksa i zdecydowanie daleko mu do wygodnego, bezproblemowego systemu, działającego OOTB, jak niektórzy próbują go przedstawać. YMMV

Darmowy upgrade z Windows 7 do Windows 10

Microsoft zakończył support dla Windows 7 w dniu 14 stycznia 2020. Oznacza to brak aktualizacji, w tym brak poprawek bezpieczeństwa. W idealnym świecie systemy z Windows 7 powinny zniknąć, jako przestarzałe.

W 2016 Microsoft przeprowadzał kampanię promującą darmową aktualizację do Windows 10. Oficjalnie kampania została zakończona, ale mechanizm nadal działa, co oznacza, że technicznie nadal można zaktualizować Windows 7 do Windows 10.

Aby dokonać aktualizacji, wymagany jest oryginalny Windows 7 lub 8 z aktywowaną licencją. Wystarczy pobrać narzędzie ze strony Microsoftu i uruchomić je. Istnieje możliwość stworzenia nośnika, albo aktualizacji bieżącej instalacji, i ta ostatnia możliwość jest najbardziej interesująca. Upgrade’u można dokonać dla dowolnego wariantu systemu (szczegóły w źródle).
Oczywiście przed tak poważną operacją warto zrobić kopię bezpieczeństwa. Na pewno danych, ale na wypadek, gdyby coś poszło źle, warto zrobić także backup systemu, na przykład obraz dysku.

Systemy bez aktualizacji bezpieczeństwa stanowią zagrożenie zarówno dla swoich użytkowników, gdyż może dojść do infekcji i wycieku danych, jak również innych komputerów w sieci, stając się po infekcji częścią botnetu i uczestnicząc w atakach. Z punktu widzenia bezpieczeństwa sprawa jest prosta – trzeba aktualizować.

Czy operacja jest legalna? Nie jestem prawnikiem. Za przemawia fakt, że sam producent udostępnia mechanizm i oferuje możliwość aktualizacji, była nawet specjalna kampania promująca taki upgrade, a system nie różni się od takiego aktualizowanego w roku 2016.

Źródło: https://www.zdnet.com/article/heres-how-you-can-still-get-a-free-windows-10-upgrade/

Chromium w Debianie unstable nie startuje

Gdyby komuś w Debianie unstable przestało działać chromium, a przy uruchomieniu polecenia w konsoli pokazywało się coś takiego:

$ chromium 
[4278:4278:1113/085947.509811:FATAL:zygote_host_impl_linux.cc(116)] No usable sandbox! Update your kernel or see https://chromium.googlesource.com/chromium/src/+/master/docs/linux_suid_sandbox_development.md for more information on developing with the SUID sandbox. If you want to live dangerously and need an immediate workaround, you can try using --no-sandbox.
#0 0x562ca49ba9ee <unknown>
#1 0x562ca492699c <unknown>
#2 0x562ca55b8f90 <unknown>
#3 0x562ca45f9365 <unknown>
#4 0x562ca45fe5ce <unknown>
#5 0x562ca45f7e5a <unknown>
#6 0x562ca2d09e95 ChromeMain
#7 0x7fbb5a4f6b17 __libc_start_main
#8 0x562ca2d09d3a _start

Received signal 6
#0 0x562ca49ba9ee <unknown>
#1 0x562ca49b9433 <unknown>
#2 0x562ca49ba965 <unknown>
#3 0x7fbb633dc8e0 <unknown>
#4 0x7fbb5a509f3b gsignal
#5 0x7fbb5a50b2f1 abort
#6 0x562ca49ba905 <unknown>
#7 0x562ca4926a76 <unknown>
#8 0x562ca55b8f90 <unknown>
#9 0x562ca45f9365 <unknown>
#10 0x562ca45fe5ce <unknown>
#11 0x562ca45f7e5a <unknown>
#12 0x562ca2d09e95 ChromeMain
#13 0x7fbb5a4f6b17 __libc_start_main
#14 0x562ca2d09d3a _start
r8: 0000000000000000 r9: 00007ffe7d2f0920 r10: 0000000000000008 r11: 0000000000000246
r12: 00007ffe7d2f0da0 r13: 00007ffe7d2f0f60 r14: 000000000000016b r15: 00007ffe7d2f0ba0
di: 0000000000000002 si: 00007ffe7d2f0920 bp: 00007ffe7d2f0b70 bx: 0000000000000006
dx: 0000000000000000 ax: 0000000000000000 cx: 00007fbb5a509f3b sp: 00007ffe7d2f0920
ip: 00007fbb5a509f3b efl: 0000000000000246 cgf: 002b000000000033 erf: 0000000000000000
trp: 0000000000000000 msk: 0000000000000000 cr2: 0000000000000000
[end of stack trace]
Calling _exit(1). Core file will not be generated.

to sprawa jest znana, błąd jest zgłoszony i wystarczy doinstalować pakiet chromium-sandbox.

Polecenie su – zmiany

Jakiś czas temu zauważyłem, że mój Debian unstable na domowym desktopie zmienił zachowanie. Na koncie root przestał działać skrypt do aktualizacji systemu i usypianie.

Szybko sprawdziłem i oczywiście chodziło o PATH. Dopisałem pełne ścieżki do poleceń i prawie zapomniałem o sprawie, przypuszczając, że chodzi o jakiś chwilowy błąd w którymś z pakietów.

Jednak problem nie zniknął, więc postanowiłem sprawdzić dokładnie, co się wydarzyło. Na pierwszy ogień poszło sprawdzenie /etc/profile, w którym znalazłem spodziewane:

if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"

Również w /etc/login.defs wszystko wyglądało poprawnie:

# *REQUIRED* The default PATH settings, for superuser and normal users.
#
# (they are minimal, add the rest in the shell startup files)
ENV_SUPATH PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
ENV_PATH PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Skończyły mi się pomysły, więc udałem się na kanał #debian-next z pytaniem, czy to błąd, czy może były ostatnio jakieś zmiany. I okazuje się, że zmiany były, grubsze, dotyczące polecenia su.

Uprzednio, wydanie „gołego” polecenia su zmieniało użytkownika na root oraz ustawiało należną mu ścieżkę. Obecnie należy podawać su – (forma niezalecana) lub, lepiej, su -l, aby osiągnąć ten efekt.

I jeszcze co ciekawsze fragmenty dokumentacji (man su). Było:

The current environment is passed to the new shell. The value of $PATH is reset to /bin:/usr/bin for normal users, or /sbin:/bin:/usr/sbin:/usr/bin for the
superuser. This may be changed with the ENV_PATH and ENV_SUPATH definitions in /etc/login.defs.
[...]
-, -l, --login
Provide an environment similar to what the user would expect had the user logged in directly.

Aktualnie jest:

For backward compatibility, su defaults to not change the current directory and to only set the environment variables HOME and SHELL (plus USER and LOGNAME
if the target user is not root). It is recommended to always use the --login option (instead of its shortcut -) to avoid side effects caused by mixing envi-
ronments.
[...]
-, -l, --login
Start the shell as a login shell with an environment similar to a real login:
o clears all the environment variables except TERM
o initializes the environment variables HOME, SHELL, USER, LOGNAME, and PATH
o changes to the target user's home directory
o sets argv[0] of the shell to '-' in order to make the shell a login shell

Więc gdyby komuś w jakiejś debianopodobnej dystrybucji niebawem su przestało ustawiać PATH, to najprawdopodobniej chodzi o tę zmianę.

Entropia w Linuksie – HOWTO

Dawno temu pojawił się mit, że w Linuksie /dev/random jest źródłem prawdziwej entropii, a /dev/urandom jest gorszy. Pokutuje on do dziś i część softu za źródło danych przyjmuje właśnie /dev/random, niezależnie od realnych potrzeb. Ilość losowych danych w systemie nie jest nieskończona i zależy od dostępnych źródeł i zdarzeń zewnętrznych. Dopóki komputery były głównie fizyczne, często obsługiwane przez ludzi, problem był nieco mniejszy. W epoce wirtualek systemy i ruch są coraz bardziej powtarzalne, więc z „prawdziwą” entropią są problemy. A entropia nadal jest w systemach aplikacjom potrzebna – słusznie lub nie, chyba nawet bardziej niż kiedyś, bo szyfrowanie wszystkiego jest coraz bardziej popularne i wykorzystywane są coraz silniejsze algorytmy.

Od pewnego czasu (okolice wersji 3.7) kernel Linuksa potrafi co prawda korzystać ze sprzętowych modułów (TPM) zapewniających źródła losowych danych, o ile takie są obecne. Nie każdy sprzęt jest jednak w to wyposażony, nie każda wirtualka posiada dostęp do danych z hypervisora i obecność modułu nie oznacza jeszcze, że dane będą dostępne dla programów, więc problem nadal pozostaje.

Sprawdzenie dostępnej entropii

Jeśli nie wiemy, czy faktycznie system ma problem z dostępną entropią, możemy to w prosty sposób sprawdzić. Aktualną ilość można odczytać przez wydanie polecenia:

cat /proc/sys/kernel/random/entropy_avail

Oczywiście jest to wartość chwilowa, zmieniająca się w czasie, żeby z całą pewnością stwierdzić, jak system stoi z entropią, trzeba by poobserwować w dłuższym czasie, a najlepiej monitorować ją, np. przy pomocy Zabbiksa. Wartość powyżej 1000 oznacza, że na pewno problemu nie ma, wartości poniżej 300 oznaczają, że prawie na pewno są niedobory, mogące wpływać na pracę usług.

rngd

Istnieją dwa rozwiązania, które pomogą zwiększyć ilość dostępnych danych losowych w systemie. Pierwsze z nich, to rngd z pakietu rng-tools. Jego zadanie jest proste – dostarczać dane do napełniania /dev/random korzystając ze wskazanego źródła.

Jeśli platforma posiada sprzętowy moduł dostarczający dane losowe, rngd warto skonfigurować, by z niego korzystał. W tym celu w pliku

/etc/default/rng-tools

należy umieścić linię

HRNGDEVICE=/dev/hwrng

Natomiast w przypadku braku takiego modułu, sugerowane jest dodanie linii

HRNGDEVICE=/dev/urandom

 

Kontrowersje korzystania z /dev/urandom

Korzystanie z /dev/urandom jako źródła danych dla /dev/random powoduje kontrowersje. Główne zarzuty to niegwarantowana losowość danych w /dev/urandom (ale patrz mit), oraz powstawanie sprzężenia zwrotnego, co łącznie może powodować okresowość, a zatem teoretyczną możliwość przewidzenia stanu generatora liczb pseudolosowych. Podkreślam, że jest to możliwość czysto teoretyczna, nie wykazana w praktyce.

Alternatywa dla rngd

Istnieje drugie popularne rozwiązanie programowe, które pozwala na zwiększenie dostępnej w systemie entropii. Jest to demon haveged z pakietu o tej samej nazwie. Korzysta on z faktu, że czas wykonania kodu przez procesor jest mało powtarzalny i zależy od wielu czynników. Jest to rozwiązanie obecne w dystrybucjach od wielu lat, proste w użyciu.

Wybór rozwiązania

Jeśli system posiada moduł sprzętowy, to bym z niego korzysał, za pośrednictwem rngd. Czy haveged jest lepszy od rngd zasilanego z /dev/urandom? Nie podejmuję się odpowiedzi na to pytanie. Oba zapewniają najważniejszą sprawę, czyli dostępność danych losowych. Oba rozwiązania spełniają proste testy badające losowość danych. Osobiście uważam, że w większości przypadków rozwiązanie korzystające z rngd jest wystarczające. Tam gdzie do losowości danych przykładana jest duża waga, nie jest nie powinno być problemu z dostępem do sprzętowych generatorów, a niedobory entropii zawsze są bardziej szkodliwe, niż jej teoretycznie niższa jakość.

Linki

Na koniec zbiór linków, zarówno źródła jak i dalsza lektura, czyli ciekawe linki (kolejność losowa):