Aktualizacja microcode procesora w Debianie Wheezy – HOWTO.

Jakiś czas temu pisałem o 3 rzeczach, których zapewne nie aktualizujesz w Debianie (piszę w Debianie, ale zapewne prawdziwe jest dla większości dystrybucji opartych na nim). Jeśli chodzi o mikrokod, było prosto, łatwo, i przyjemnie. I minęło, wraz z nadejściem Wheezy’ego.

Magiczne polecenie update-intel-microcode, o którym wówczas pisałem, niestety nie jest już obecne w Debianie poczynając od wersji Wheezy. Zamiast tego, trzeba zrobić wszystko ręcznie. Nie wnikałem, ale zapewne chodziło o kwestie licencyjno-copyrightowe – przy pobieraniu pliku z mikrokodem ze strony Intela jest pytanie o zaakceptowanie licencji. W każdym razie nie ma już narzędzia i trzeba zadbać ręcznie o aktualizację mikrokodu.

Jest za to inne narzędzie, które – wraz z bazowymi mikrokodami – znajduje się w pakiecie intel-microcode.

Po pierwsze wchodzimy na stronę Intela, skąd możemy pobrać mikrokod. Wielkiego wyboru nie widzę, ale może się zmienić – wybieramy najnowszą wersję. Akceptujemy licencję, pobieramy plik. Na dysku ląduje plik o nazwie zbliżonej do microcode-20120606-v2.tgz. Należy go rozpakować, a naszym oczom ukaże się microcode.dat. To są mikrokody, których szukacie! 😉

Po drugie, przy pomocy narzędzia iucode_tool produkujemy z niego pliki w formie strawnej dla pozostałych narzędzi. Ja zdecydowałem się na rozpakowanie ich „na boczek”, żeby ręcznie porównać:

mkdir /tmp/ucode && iucode_tool -K/tmp/ucode/ /tmp/microcode.dat

Po tym zabiegu w katalogu /tmp/ucode mamy w tym momencie całkiem sporą ilość plików, które są gotowymi do użycia mikrokodami. Aby były używane, należy je skopiować do /lib/firmware/intel-ucode. Oczywiście jest możliwość rozpakowywania bezpośrednio w domyślną systemową lokalizację, wystarczy użyć przełącznika –overwrite i nie podawać katalogu docelowego.

Pora na użycie. I tu przyznaję zaczynają się schody. O ile wcześniej bez problemu można było załadować mikrokod online, to teraz iucode_tool -vk /tmp/ucode/* niby się wykonuje (wczytując wszystkie, czyli dla różnych procesorów mikrokody – zupełnie tego nie rozumiem), ale chyba nie działa. W każdym razie śladu w dmesg żadnego… Wygląda, że mikrokod jest dodawany do initramfs. Aby dodać mikrokody znajdujące się w domyślnej systemowej lokalizacji do wszystkich zainstalowanych kerneli, popełniamy:

update-initramfs -k all -uv

Po reboocie powinniśmy działać na nowym mikrokodzie. Uwaga: domyślnie do initramfs trafiają tylko mikrokody dla procesora, na którym jest wydawane polecenie. Można to zmienić w /etc/default/intel-microcode.

Dla procesorów AMD istnieje analogiczny pakiet, ale nie mam takiego pod ręką, by przetestować.

Przy pisaniu wpisu posiłkowałem się opisem Mikrokodu na wiki Arch. Co prawda niewiele się zgadza, ale może komuś się przyda. Warto też zajrzeć na ogłoszenie dotyczące mikrokodu, które znalazłem już po napisaniu wpisu.

 

Jak naprawiłem Libre Office 3.5.4 w Debianie.

Niedawno chciałem odczytać jakiś dokument w formacie .doc i okazało się, że Libre Office nie startuje. Pojawiała się plansza logowania i tyle. Potrzebowałem tylko odczytu, więc zwaliłem na Debiana w wersji unstable, locale ustawione na iso-8859-2, więc użyłem sąsiedniego kompa, skonwertowałem do PDF i zapomniałem o sprawie.

Jakiś czas później chciałem coś napisać, więc wróciłem do sprawy. Uruchomienie z wiersza poleceń, zmiana locale itp. nie pomogły. Jedyny komunikat, który dostałem, zawierał:

com::sun::star::uno::RuntimeException

Podejrzewałem Debiana unstable, więc szybkie sprawdzenie bugów i jest jeden #641412, w miarę pasujący opisem, ale niestety bez rozwiązania. Spróbowałem Google i tu efekt był lepszy. Znalazłem tę stronę [SOLVED] LibreOffice 3.5 error: Missing vcl resource. Tytuł optymistyczny.

Zainstalowałem pakiet libreoffice-gnome, tym razem przy uruchomieniu w oknie pojawiła się informacja o braku praw do pliku. Faktycznie, jeden z katalogów z plikami konfiguracyjnymi miał właściciela root. Usunąłem (z roota) ~/.config/libreoffice ~/.config/.libreoffice oraz ~/.config/.openoffice.org (ostatnia nazwa niedokładna), uruchomiłem Libre Office… Tadam!

Piratują RMS.

Richard Matthew Stallman, czyli twórca Projektu GNU i orędownik wolnego oprogramowania, ma – o czym wielu miłośników wolnego oprogramowania wydaje się nie wiedzieć – nieco odmienne podejście do licencji dotyczących dzieł, które wyrażają czyjeś opinie, osąd i poglądy, czyli służą innemu celowi, niż prace dotyczące praktycznych zastosowań, takie jak oprogramowanie czy dokumentacja. W związku z tym, daje on prawo tylko do kopiowania i rozpowszechniania w postaci niezmienionej, dosłownej. Jednym z elementów tego jest publikowanie artykułów na licencji CC BY-ND, która wprost zabrania m.in. tłumaczenia. Więcej na ten temat można poczytać na stronie FSF dotyczącej licencji Licenses for Works of Opinion and Judgment.

Tymczasem świadomość polskich zwolenników wolnego oprogramowania jest w tym względzie niewielka. Przynajmniej dwa razy spotkałem się z „nielegalnymi” publikacjami tekstów RMS. Pierwsza to artykuł na jakilinux.org o jednolitym patencie. Druga, to wpis na nibyblog.pl dotyczący niewolnych gier (skopiowany również na osnews.pl) (dead link). We wszystkich trzech przypadkach złamanie licencji polega nie tylko na stworzeniu utworu zależnego w postaci tłumaczenia. Za każdym razem została też zmieniona licencja na znacznie mniej restrykcyjną CC BY.

Technicznie możemy mówić o piractwie utworów RMS. Żeby było śmieszniej, w tej chwili już sam fakt publikacji tłumaczenia, nawet w dobrej wierze, czyni z publikującego pirata. Przynajmniej przy dosłownym odczytaniu licencji. Dla jasności, sprawę uważam bardziej za śmieszną i to z wielu powodów – poczynając od tego, że RMS używa niemal najbardziej restrykcyjnej licencji Creative Commons, przez niewiedzę orędowników wolnego oprogramowania w temacie licencji, po fakt piractwa materiałów ze strony organizacji, która walczy o dostęp do kodu źródłowego i prawo do swobodnej jego modyfikacji. Zresztą wygląda, że sam RMS nie jest przeciwny takim tłumaczeniom, więc prawdopodobnie mamy do czynienia z niezbyt szczęśliwie wybraną licencją. Moim zdaniem, publikacje tłumaczeń powinny być dozwolone z zastrzeżeniem oznaczenia, że tłumaczenie jest nieoficjalne. Wdałem się w lekką dyskusję z ludźmi z FSF, zobaczymy, czy coś z tego wyniknie…

Natomiast warto mieć świadomość, że licencja Creative Commons, czyli popularny znaczek CC, nie oznacza automatycznie, że z utworem wolno robić wszystko. W szczególności warto mieć świadomość, licencji CC jest więcej, niż jedna, oraz, że w przypadku publikacji oryginalnego utworu, nigdy nie wolno jej zmieniać na inną licencję CC (czy to bardziej, czy mniej restrykcyjną) bez wyraźnej zgody autora. W przypadku utworów zależnych – o ile oryginał nie jest na licencji SA, to możliwe są zmiany licencji. No i ostatecznie warto pamiętać, że tłumaczenie w świetle licencji CC to utwór zależny.