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.

Rockbox 3.11.2

O Rockbox 3.11 nie napisałem nic, bo wcześniej napisali inni w polskiej sieci, a i dopiero niedawno go wgrałem na moje urządzenie, bo wielkich zmian (dla mnie) nie było, więc donoszę o wersji 3.11.2, która zawiera wyłącznie poprawki błędów, w tym naprawia radio dla Sansa e200 i c200. Czyli dla mojego playera. Nie żebym z radia korzystał… 😉 Tradycyjnie pełna lista zmian dla Rockbox 3.11.2.

Debian – flash 11.2.202.228 dla i386 zepsuty.

Jeśli ktoś posiada Debiana w wersji 32bit (architektura i386) i korzysta z niewolnego pluginu flash (pakiet flashplugin-nonfree), to niech uważa z aktualizacją flasha do wersji 11.2.202.228. Wygląda, ze jest bug i po aktualizacji do ww. wersji flash przestaje działać i to we wszystkich przeglądarkach (sprawdzone w Iceweasel, Opera, Chromium). Problem objawia się tak, że sam plugin jest widoczny w przeglądarce, ale po prostu obiekty flash nie są uruchamiane.

Sprawdzone na 2 niezależnych systemach, z czego jeden to praktycznie czysty Squeeze, a drugi „mieszaniec” (Squeeze + backports + unstable). Pierwotnie podejrzewałem kombinację Iceweasel 11 + upgrade flash, ale nie o to chodzi. No i z kanału #debian wiem, że nie jestem jedyną ofiarą błędu.

PS Dla architektury amd64 błąd nie występuje – wszystko działa poprawnie, można spokojnie aktualizować. Jak będę znał rozwiązanie, to pojawi się aktualizacja.

UPDATE: Z tego co widzę w sieci, problem dotyczy wszystkich dystrybucji Linuksa i tylko architektury i386: https://bugbase.adobe.com/index.cfm?event=bug&id=3154276 https://bugbase.adobe.com/index.cfm?event=bug&id=3161034 http://forums.gentoo.org/viewtopic-t-918560-postdays-0-postorder-asc-start-0.html Adobe nie spieszy się do naprawy, jako, że plugin dla Linuksa oficjalnie nie jest wspierany. W którymś wątku pojawiła się sugestia, że wyłączenie akceleracji video rozwiązuje problem (nie weryfikowałem).

UPDATE: Widzę w pytaniach do wyszukiwarki pytanie o alternatywy dla flash, więc dla porządku: jest GNU Gnash, który działa średnio, że tak to ujmę (mało wydajny przede wszystkim z tych paru chwil, kiedy korzystałem) i jest Lightspark, z którym zupełnie nie miałem styczności, a który może być bardziej wydajny, bo przepisany od zera z myślą o wydajności na współczesnym sprzęcie.

UPDATE: Wygląda, że bug występuje tylko na procesorach bez SSE2 (grep –color sse2 /proc/cpuinfo aby sprawdzić, czy procesor ma obsługę SSE2), czyli głównie Athlon i okolice a Adobe nie kwapi się z wypuszczeniem wersji skompilowanej bez tego zestawu instrukcji. Ostatecznie zostaję z Gnash.

UPDATE: 2012.08.12 – Dochodziły mnie słuchy, że na oryginalnym Chrome od Google jest inny Flash, więc sprawdziłem zarówno stable 21.0.1180.75, jak i betę 22.0.1229.2. Nie działa na żadnym.