Ergonomia maców – 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.

Odnoszę wrażenie, że ergonomia maców generalnie jest chwalona. 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. Oczywistą wadą w stosunku do Linuksa jest 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. W każdym razie i w zakresie współpracy ze stacją dokującą ergonomia maców pozostawia sporo do życzenia.

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

Alternatywa dla VirtualBox – AQEMU.

Zachciało mi się zmiany kernela z 3.2 na 3.5. Inspiracją był znajomy, który zaobserwował spadek zużycia prądu na laptopie przy zmianie z kernela 3.2 do 3.4 z 28W do 19W (pomiar wg powertop). VirtualBox po zmianie kernela oczywiście przestał działać. Nic nowego i nawet pisałem o tym, że debianowa paczka dla VirtualBox jest pod konkretny kernel robiona. Pisałem też, jak uruchomić VirutalBox na Debianie z własnym kernelem.

Co prawda u mnie kernel 3.5 nic nie daje w kwestii zużycia energii, ale skoro już pojawił się temat, to trzeba go pociągnąć. Mogłem użyć poprzednio opisanego sposobu z uruchomieniem VirutalBox na Debianie z własnym kernelem, ale jakoś nie uśmiechała mi się zmiana VirtualBox na wersję z repozytorium Oracle (poza tym, kiedyś różniły się licencją – w Debianie było OSE, nie żeby miało to jakiekolwiek znaczenie w tym przypadku), ściąganie plików nagłówkowych i kompilacja kernela, więc postanowiłem się rozejrzeć za alternatywami dla VirtualBox.

Ludzie podszepnęli KVM, który jak najbardziej znam i używam, ale w innym, serwerowym zastosowaniu. Okazuje się, że KVM ma także, obok narzędzi do zarządzania CLI i webowych, także narzędzia desktopowe, czyli GUI. Na stronie z listą frontendów dla KVM znaleźć można trzy frontendy typu desktop: AQEMU, virt-manager oraz GKVM. W pierwszym podejściu przeoczyłem virt-managera i wziąłem się za AQEMU. Już miałem orzec, że bootowanie z obrazu iso płyty CD nie działa, ale dogrzebałem się do ustawienia, które pozwala wybrać medium (i które nie jest zapamiętywane, bug zgłoszony).

Po tym było już z górki. Wirtualizacja desktopu z użyciem KVM generalnie po prostu działa. Nie testowałem jakoś specjalnie mocno, bo służy mi to głównie do zabaw z różnymi systemami liveCD, ale sieć działa, bootowanie z CD-ROM działa, przeglądarka działa. Zarządzanie, wygląd i dostęp do opcji też wygląda też sensownie, co można zobaczyć na screenshocie poniżej.

AQEMU screenshot

Źródło: strona projektu AQEMU

Zrobiłem, po przebootowaniu do 3.2, rzecz jasna, krótki benchmark, a w zasadzie namiastkę benchmarku, dla AQEMU i VirtualBox, w postaci zmierzenia czasu uruchamiania systemu z liveCD (padło na T(A)ILS – akurat nowe wydanie jest; 1GB RAM dla wirtualki, 1 CPU, parę uruchomień, ustawienia zbliżone do domyślnych). Dla AQEMU bootowanie (do momentu pierwszej interaktywności) trwało zwykle 44,9 sekundy, dla VirtualBox – 45,2 sekundy. Różnica pomijalna. Co ciekawe, dołożenie drugiego procesora nie wpływa na wynik i to w żadnym z przypadków.

Przy okazji, gdyby ktoś się brzydził frontendami i był hardcore’owym użytkownikiem wiersza poleceń, to do uruchomienia liveCD z w pliku o nazwie plik.iso użyciem KVM wystarczy:

kvm -m 1024 -vga vmware -boot d -cdrom plik.iso

Chwilowo to wszystko nt. wirtualizacji na desktopie. Szybki wniosek VirtualBox nie jest jedynym rozwiązaniem, AQEMU daje radę i wygląda na rozwiązanie wygodniejsze, jeśli ktoś używa Debiana niekoniecznie z dystrybucyjnym kernelem, lub kernelem z innej wersji. Nie będę testował GKVM – projekt wygląda na porzucony. Prawdopodobnie niebawem szansę dostanie virt-manager – na razie nie uruchomił się OOTB i krzyczy o niemożności dostania się do libvirtd. Nie miałem czasu bliżej się przyjrzeć sprawie. Jak uruchomię, to nie omieszkam opisać. Stay tuned.

Virtualbox i własny kernel

Krótkie howto jak w Debianie Lenny korzystać z własnego kernela (tu: 2.6.30.5) i Virtualbox.

W związku z remasteringiem Knoppiksa na potrzeby Anonymiksa zainteresowałem się bliżej rozwiązaniami do wirtualizacji. Kiedyś (3 lata temu?) korzystałem z VMware Playera, który idealny nie był. Trochę za sprawą licencji, trochę za sprawą tego, że nie do końca pozwalał na tworzenie własnych obrazów. IIRC dało się je zrobić, z użyciem qemu. Także bootowaniem z CD było trzeba powalczyć. Z kolei remastering Knoppiksa na fizycznej maszynie jest jak najbardziej wykonalny, ale niewygodny – rebooty, uruchamianie Knoppiksa itd. Aż się prosi o wirtualizację.

Sporo dobrego słyszałem ostatnio o Virtualbox. Niestety, wersja w Debianie zrobiona jest pod konkretny kernel. Ponieważ znajomi korzystają, postanowiłem się zapytać, w jaki sposób. Okazuje się, że nie korzystają z wersji dystrybucyjnej, a z wersji bezpośrednio od producenta, czyli przez dodanie

deb http://download.virtualbox.org/virtualbox/debian lenny non-free

do /etc/apt/sources.list, a następnie apt-get install virtualbox-3.0. Tyle, że także korzystają z dystrybucyjnego kernela. Co mnie szczerze mówiąc zdziwiło, bo lapek i dystrybucyjny kernel jakoś mi ze sobą nie pasują (nie żeby nie działało, bo działa). Albo ja po prostu jestem dziwny i lubię mieć nowe i na miarę (I, ricer), albo jeszcze mam czas na takie zabawy. 😉

W każdym razie korzystanie z dystrybucyjnego kernela wydało mi się nieporozumieniem. Niemal takim nieporozumieniem, jak praca na fizycznej maszynie i rebooty (tak, wiem, przesadzam). FAQ na stronie i dokumentacja na pierwszy rzut oka nie przewidują takiej możliwości. Poszukałem więc rozwiązania ma własną rękę (pomoc na IRC jest przereklamowana). Nie pamiętam słów kluczowych do wyszukiwarki, ale ostatecznie trafiłem na ten wpis (dead link). Rozwiązanie jest – jak widać – bardzo proste.

Dla porządku, dla niespikających: należy pobrać paczkę .deb właściwą dla naszego systemu ze strony producenta i zainstalować ją (apt-get install pakiet.deb). Podczas instalacji, wykryty zostanie brak modułu i zostaniemy zapytani, czy chcemy zbudować tenże moduł dla aktualnie działającego kernela. Wymagane są oczywiście źródła (headers?) w /usr/src i narzędzia do kompilacji kernela. Zakładam, że jak ktoś ma custom kernel, to wie, co potrzebne. Wadą rozwiązania jest konieczność pamiętania o dpkg-reconfigure virtualbox po każdej zmianie kernela w celu zbudowania modułu dla nowej wersji. Dla 2.6.30.5 działa bez problemu.