W Debianie (zatem w Ubuntu pewnie i także) wystarczy zainstalować paczkę “iotop”:
# aptitude install iotop

Kilka dni po premierze Fify 10,  w moje ręce wpadło oryginalne pudełko Fify 10 wraz z płytką instalacyjną. Gra zainstalowała się poprawnie na systemie Windows Vista. Nie miałem żadnych problemów z uruchomieniem, czy czymkolwiek innym. Gra działa na moim sprzęcie na najwyższych detalach bez żadnego zacinania.

W stosunku  do Fify 08 (bo 09 niestety nie kupiłem i nawet nie grałem), w najnowszej wersji tej gry, podoba mi się odświeżone menu, możliwość sterowania zawodnikami myszką, przypisanie do każdego zespołu jego realnej taktyki oraz formacji i wiele, wiele innych zmian.

Moje początkowe wrażenia po rozegraniu pierwszego meczu, były dość sceptyczne, a to ze względu na bardzo podobną grafikę do 08 oraz praktycznie taki sam sposób rozgrywki (chciałbym rzec, że autorzy zastosowali chyba ten sam engine co w 08 – lecz mogę się mylić).

Cóż, pierwsze wrażenia są zazwyczaj mylne – tak było i w tym przypadku. Po rozegraniu kolejnych meczów, zauważyłem dość sporo zmian w samej rozgrywce. Z najważniejszych mogę wymienić: bardziej “żywi” sędziowie (zarówno główny jak i liniowi), wreszcie realistyczne twarze zawodników oraz ich ruchy (wliczając w to bramkarzy) no i przede wszystkim porządne powiązanie umiejętności piłkarzy z wykonywanymi trikami (w 08 mogłeś kiwnąć wszystkich zawodników bramkarzem i do tego strzelić gola; teraz, w Fifie 10, słabym zawodnikiem po prostu nie przebijesz się przez linię obrony; poza tym, nie wykonasz byle kim jakiś finezyjnych trików). Ponadto, bardzo podoba mi się to, że podczas rozgrywania meczów z komputerem, korzysta on dość często z górnych podań – w 08 była to raczej rzadkość. Dzięki temu, teraz poziom trudności trochę podskoczył – przykładowo: w 08 nie straciłem chyba żadnego gola na rzecz kontrataku przeciwnika; natomiast teraz, większość bramek tracę podczas kontrataku (przerzucenie obrońców no i gol…).

Ogólnie rzecz biorąc, jestem pozytywnie zaskoczony. Wszystkim fanom Fify, polecam zakup dziesiątki.

Jeżeli ktoś chciałby ze mną rozegrać meczyk przez Internet, to jest to możliwe, ale… Po pierwsze – nie hostuję. Po drugie – nie rozegram nawet jednej minuty, jeżeli rozgrywka będzie się zacinać (czytaj: jeżeli masz wolny Internet) , bowiem taka gra jest po prostu bezsensu.

Kilka tygodniu temu, na angielskim forum dystrybucji Ubuntu, natknąłem się na bardzo ciekawy post, w którym to jeden z posiadaczy takiego samego laptopa co ja, wspomniał, że działa u niego subwoofer, jedynie po maleńkiej edycji pliku /etc/modprobe.d/alsa-base.conf oraz po aktywacji suwaka Surround w alsamixer. Nie wiedziałem jednak jaki subwoofer ma na myśli – czy ten wbudowany w laptop czy też znajdujący się w jakimś zestawie głośników, który jest osobno podłączany do karty dźwiękowej. Z drugiej jednak strony, w przypadku drugiej sytuacji (czyli “osobnego” subwoofera), za poprawne działanie powinien – przynajmniej z tego co się orientuję – odpowiadać suwak LFE.

Uznałem jednak, że nie ma co gdybać, a trzeba po prostu samemu to  sprawdzić.

Wyszedłem z założenia, że wspomniany autor postu, posiadał Ubuntu w wersji 9.10 (na 9.04 sprawdzałem już wcześniej działanie łubudubu). Nie mając tej wersji, ściągnąłem ją (amd64) i niezwłocznie wypaliłem na płytkę, po czym dokonałem rozruchu LiveCD. Po uruchomieniu się Ubuntu nawet nie zdziwiłem się z faktu, że dźwięk w ogóle nie działał (ze względu na błędny wpis dotyczący modułu karty dźwiękowej w /etc/modprobe.d/alsa-base.conf). Zdziwiło mnie jednak to, iż po edycji wspomnianego pliku oraz ponownego załadowania modułów do jądra, a także zrestartowania alsy, dźwięku dalej nie było. Zonk.

Czyli co, trzeba przystąpić do edycji obrazu LiveCD i jego ponownego wypalenia? Tak. Wbrew pozorom, jest to bardzo banalna operacja. Obraz można rozpakować większością menadżerów archiwów, bądź po prostu zamontować za pomocą mount (pamiętajmy przy tym o opcji -o loop). Następnie, najczęściej, należy rozpakować plik filesystem.squashfs, który zawiera między innymi pakiety oraz wszystkie pliki konfiguracyjne dystrybucji, wliczając w to alsa-base.conf. Przy rozpakowywaniu tegoż pliku, niezbędny jest pakiet squashfs-tools. Kiedy już uzyskamy dostęp do struktury głównego katalogu (roota) LiveCD, można dokonać dowolnej korekty. Wówczas tworzymy nowy obraz squashfs’a (dobrze odmieniłem?), podmieniamy oryginalny plik z LiveCD i tworzymy nowy obraz iso za pomocą mkisofs, a następnie wypalamy na płytkę.

Kiedy zmodyfikowałem sobie LiveCD, ponownie je uruchomiłem. No i… Uwaga, uwaga! Chwila prawdy! Dźwięk był odtwarzany i… Tak, źle podejrzewałeś – niestety subwoofer dalej nie działał. Oczywiście bawiłem się długo z dodatkowymi ustawieniami dźwięku, ale nic to nie dało. Dodam również, że mikrofon również nie działał.

Cóż, pozostaje mi dalej czekać, na jakiekolwiek rozwiązanie problemu uruchomienia łubudubu na MSI EX625.

Pierwszy problem dotyczył niepoprawnego wyświetlania się kolorów na niektórych zdjęciach (problemem okazały się profile kolorów). Natomiast druga niedogodność polegała na zawieszaniu się scrollingu (przewijania strony). Co jakiś czas, podczas wciśnięcia rolki myszy, nie można już było zatrzymać przewijania strony – wraz z ruchami myszy w górę i w dół ekranu, strona cały czas się przewijała, co uniemożliwiało poprawną nawigację. Ponadto, podczas wystąpienia tego błędu, nie można było wyświetlić w ogóle żadnego menu przeglądarki.

Jako rzekome rozwiązanie tego problemu podałem dodatek “All In One Gestures”. Jak się jednak po kilku dniach okazało, dodatek ten nic nie zmieniał.

Teraz problem ten rozwiązałem całkowicie.
Zacznijmy od tego, że pracuję w środowisku graficznym KDE 4.3, wraz z włączonymi efektami graficznymi KWina. Jako przeglądarkę używam wciąż IceWeasel (3.5) wraz z wieloma dodatkami. Jedno z rozszerzeń, które służy mi codziennie to gesty myszy. I jak się okazało, tutaj leży cały problem.

W momencie kiedy chciałem zminimalizować okno za pomocą gestów myszy, przy następnej maksymalizacji przeglądarka zaczęła szaleć z przewijaniem. Co lepsze, nie jest to jednorazowy przypadek. Sprawdziłem to chyba z kilkanaście razy – i za każdym razem to samo. Rozwiązanie jest proste – wyłączyć minimalizację przeglądarki za pomocą gestów myszy.

Jako że cały ten problem nie występuje na Windowsie Vista, podejrzewam, że całą winę ponosi KWin.

I jeszcze ciekawostka. ATI wydało również sterowniki 9.10, które nie są jednak dostępne na stronie głównej. Więc o co w tym chodzi? Ano, te sterowniki zostały wydane wcześniej, specjalnie dla nadchodzącej wersji Ubuntu (9.10). Nie mam niestety czasu na bawienie się z driverami 9.10, więc przedstawię tylko patchowanie 9.9 (w przypadku 9.10, trzeba się o wiele bardziej namęczyć).

Oto krótka instrukcja patchowania:

• pobieramy wpierw sterowniki 9.9 ze strony ATI,
• pobieramy patch do katalogu gdzie ściągnęliśmy sterowniki,
• rozpakowywujemy sterowniki: # ./ati-driver* --extract
• nakładamy patch: # cd fglrx-install.*/ && cp ../2.6.31.patch `pwd` && patch -p0 <2.6.31.patch
• łatka została nałożona i można przystąpić do instalacji sterowników: # ./ati-installer.sh . --install

Dwie drobne uwagi!

1) Możesz doświadczyć ewentualnych problemów z zarządzaniem energii dla GPU, ze względu na to, iż nie przedstawiłem tutaj jeszcze jednego, wymaganego patcha (postąpiłem tak a nie inaczej, ponieważ drugi patch zawierał błędy, a nie mam czasu na jego ręczne poprawianie).

2) Łatki znalazłem na tej stronie: http://aur.archlinux.org/packages.php?ID=22510

Aby mieć lepszy obraz fontów, poniżej przedstawiam jak wygląda u mnie Opera (QT4) z brzydkimi czcionkami:

A oto dobre czcionki w przypadku Firefoksa i Opery (zwróćcie uwagę, że są one takie same, czego nie można powiedzieć o powyższym screenie):

Gdzie leży problem? Wbrew pozorom nie w ustawieniach Opery, ale w ustawieniach QT3/QT4. Niestety, odpowiednich zmian nie można dokonać poprzez aplikację qtconfig. Są tylko dwa wyjścia: konfiguracja fontów poprzez Centrum Sterowania KDE (zarówno seria 3 jak i 4 tego środowiska), bądź poprzez ręczną edycję np. pliku ~/.fonts.conf.

Osobom nie korzystającym z KDE, nie opłaca instalować się całego środowiska tylko po to, aby zmienić wygląd czcionek dla Opery. Jeżeli zaliczasz się do nich, skorzystaj z gotowego ~/.fonts.conf, który podam niżej.

Jakie są konkretne wymagania jeżeli chodzi o czcionki dla Opery? W przypadku nie korzystania z antyaliasingu (ja osobiście korzystam, co widać na wyżej zaprezentowanych zrzutach przeglądarek), ustawienia hintingu są uzależnione od danej czcionki – np. vistowa czcionka Segoe Ui, wymaga pełnego hintingu aby wyglądała ładnie, w przypadku wyłączonego wygładzania; inaczej za to prezentuje się np. Tahoma, której hinting w ogóle nie jest potrzebny.

Co z osobami, które korzystają z antyaliasingu i chcą mieć ładne czcionki w Operze? Najczęściej jest wymagany włączony antyaliasing dla QT3/4 i włączony pełny hinting.

Nie jestem w stanie powiedzieć Ci, jakich ustawień potrzebujesz, ponieważ nie mam zielonego pojęcia, jakich czcionek używasz. Na końcu tego wpisu zaprezentuję kilka przykładowych plików ~/.fonts.conf, które muszą znajdować się w Twoim katalogu domowym. Ich składnia jest dziecinnie prosta, dlatego w przypadku kiedy któryś z nich nie zadziała u Ciebie, będziesz mógł w prosty sposób dokonać odpowiedniej korekty pliku.

Pamiętaj, że w przypadku kiedy nie wybierzesz w konfiguracji swojego środowiska graficznego, opcji odpowiedzialnej za sterowanie czcionkami przez środowisko graficzne, wszystkie fonty będą mieć takie same ustawienia jakie znajdują się w pliku ~/.fonts.conf, co może – ale nie musi – spowodować zmianę wyglądu Twoich dotychczasowych czcionek w niektórych programach.

Przykładowe pliki ~/.fonts.conf:

• Włączony antyaliasing, hinting ustawiony na pełny (z tego korzystam w przypadku Opery).
• Włączony antyaliasing, hinting ustawiony na średni.
• Wyłączony antyaliasing, hinting ustawiony na średni.

aloha!

// EDIT – 11.09.2009r. 5:04:06
Dodawanie komentarzy – włączone.

KDE 4.3

W kwestii Opery dla QT4 – jest mała świadomość dostępności tej wersji, a to ze względu na to, że linki na stronie głównej firmy Opera Software, prowadzą do wersji skompilowanej dla Qt3.

Osobiście preferuję QT4, ze względu na ładniejszy wygląd i lepszą wydajność biblioteki. Kolejnym powodem, jest fakt używania przeze mnie KDE 4, przez co, Opera Qt4 lepiej integruje się wizualnie na moim pulpicie.

Testowałem przeglądarkę dla amd64 skompilowanej z Qt3 jak i Qt4. Obie działają tak samo wydajnie i bez żadnych błędów. Przy czym, co jest oczywiste, Opera lepiej wygląda w Qt4 (przynajmniej w moim odczuciu).

Link do strony skąd można pobrać wspomniane kompilacje przeglądarki: http://ftp.opera.com/pub/opera/linux/1000/final/en/

Nie jestem w stanie opisać wszystkich wrażeń, bo tego po prostu nie da się opisać słowami – trzeba tam być i po prostu doświadczyć tej wspaniałej atmosfery. Smaczku całemu zlotowi dodają świetne sesje techniczne, bardzo wysoka klasa hotelu (4-gwiazdkowy) oraz wspaniali ludzie (goście, czytelnicy, administratorzy, moderatorzy, sponsorzy, itd.).

Szczerze zachęcam do zapoznania się ze szczegółami dotyczącymi zlotu, który – notabene – jeszcze trwa (niestety, ze względów osobistych nie mogłem przedłużyć swojego pobytu). Niedługo zostanie też (zapewne) udostępniona fotorelacja ze spotkania, a także video z poszczególnych sesji, do których przejrzenia szczerze zachęcam.

Należy jednak pamiętać, że aby mieć wsparcie dla DirectX, podstawowym systemem musi być Windows. W przypadku kiedy postawisz wirtualną maszynę na Linuksie i instalując na niej Windowsa, tak czy siak, nie będziesz miał wsparcia dla DirectX. W przypadku OpenGL nie ma takich problemów – bez różnicy jaki system jest podstawowy, a jaki wirtualizowany.

Jak jest z wydajnością? Testowałem jedynie OpenGL (VirtualBox w wersji 2.4) na systemie Windows. No i muszę przyznać, że klon glxgears dla Windowsa (napisany w QT 4) sprawował się przyzwoicie – tj. nie zacinał się. Miałem jednak tylko około 1000 FPS’ów w ciągu 5s (o ile dobrze pamiętam). Nie jest to duża liczba, aczkolwiek – w mojej skromnej opinii – bardzo przyzwoita.

Zachęcam wszystkich do testów.

O ile na Debianie amd64 nie ma problemu z wykryciem i zaadresowaniem => 4 GB pamięci RAM, o tyle Vista x86 ma z tym poważny problem. Głupotą są wpajane użytkownikom systemu Windows informacje, że każdy system 32-bitowy, nie jest w stanie zaadresować nawet 4 GB pamięci (choć niestety, na wielu forach spotyka się takich “znawców”). Najprostszy dowód? Wystarczy postawić sobie 32-bitowy kernel Linuksa i samemu sprawdzić.

Windows Vista x86, bez SP, nie wykrywa nawet 4 GB pamięci. Po zainstalowaniu SP1, system wykrywa już całą pamięć w sprzęcie, ale dalej nie adresuje więcej niż około 3,2 GB.

Dość sporo szukałem informacji, jak zmusić Vistę do adresowania pozostałej pamięci. Trudno było dogrzebać się do jakichkolwiek informacji na ten temat, właśnie ze względu na – wspomnianych wcześniej – “specjalistów”. Dowiedziałem się jedynie, że standardowo, 32-bitowa Vista nie ma włączonego PAE (Physical Address Extension). Na logikę, włączenie PAE powinno rozwiązać całkowicie problem z adresacją całej pamięci. Zrobiłem małe czary mary:

BCDEdit /set pae ForceEnable

jednakże guzik to dało. Vista dalej nie adresuje całej mojej pamięci.

W końcu dogrzebałem się do informacji, iż Microsoft nałożył limit na Vistę x86, która jest w stanie zaadresować tylko i wyłącznie 4 GB pamięci. No i tutaj pojawia się cały problem. Mam włączone PAE (DEP oczywiście także), a Windows dalej usilnie daje mi do użytku tylko ~3,2 GB RAM-u. No to ile w końcu Vista może mi zaadresować pamięci? Boże, przecież to jest chore!

Jestem nieźle wkurzony na Microsoft, ponieważ jest to kolejny przykład, ich bezmyślnych (co poniektórych oczywiście) praktyk. Co MS chce osiągnąć, nakładając limit na adresację? Jestem jeszcze w stanie zrozumieć, że x86_64 jest przyszłością, ale żeby od razu posuwać się do takich praktyk? Nie bądźmy śmieszni. Co lepsze, oczywiście najdroższe wersje Windows Server (2003/2008) 32-bitowe, teoretycznie, mogą obsłużyć do 128 GB pamięci. Ech…

Dostałem Vistę x86, w dodatku BOX, w prezencie. No i co? Mam teraz płacić około 30 euro za przesyłkę płytki z systemem 64-bitowym? Wrrr.

Dzisiaj mowa o dość niedawno wydanym Firefoksie 3.5. We wcześniejszych notkach wspominałem, że paczka trafiła już do experimental i co ciekawe, jeszcze tam tkwi.

Pierwszą niedogodnością z jaką spotkałem się w Firefoksie, to błędne wyświetlanie niektórych obrazków. Dość długo szukałem rozwiązania, choć było to trudne, ze względu na brak informacji co dokładnie powoduje zniekształcenia kolorów plików graficznych (informacja, że sam Firefox, to za mało). Wczoraj przypomniałem sobie o profilach kolorów, jakie zostały wprowadzone w Mozilli, od stabilnego wydania 3.0. Wcześniej wspomniana niedogodność mnie nie dręczyła, a to z prostego powodu – w wydaniu 3.0 profile kolorów są standardowo wyłączone, dopiero od wydania 3.5 są domyślnie włączone.

Na Google można znaleźć mało osób, które borykają się z tym problemem, a bug został zgłoszony tylko i wyłącznie dla Iceweasel (nie znalazłem natomiast zgłoszenia na samej stronie mozilli). Jednym z obejść bugu, jest wyłączenie menadżera profili kolorów: w about:config należy znaleźć klucz gfx.color_management.mode i zmienić jego wartość na 0.

Mój drugi problem z Firefoksem 3.5, dotyczy automatycznego przewijania. Objawy pojawiają się po około 5 minutach od uruchomienia przeglądarki. Wystarczy tylko raz spróbować skorzystać z automatycznego przewijania, a dana strona w oknie/zakładce, będzie przewijana cały czas, aż do restartu przeglądarki. Tym razem na Google znalazłem tylko jeden wątek, gdzie koleś doświadcza dokładnie tej samej niedogodności. Osobiście podejrzewam, że jest to kolejny bug wersji 3.5, tylko znowuż to, nie mam się czego uczepić, bo Firefox nie wypisuje na konsoli żadnych errorów.

Również i w tym przypadku zastosowałem obejście – skorzystałem z funkcji automatycznego przewijania, która jest dostępna w dodatku “All In One Gestures”, wyłączając przy tym, standardowy mechanizm w preferencjach.

Co ciekawe – żaden z problemów, które opisałem, nie występuje w starszych wydaniach wersji 3.0 (dlatego osobiście kwalifikuję je jako bugi). Ponadto, tym razem, Windows Vista jest górą – ponieważ mimo posiadania na niej wersji 3.5, problemów jak nie było, tak nie ma.

Na koniec jeszcze kilka informacji: współdzielę profil Firefoksa między Debianem a Vistą, ale mimo stworzenia nowego profilu, mimo własnoręcznego skompilowania kodu wersji 3.5, jak i wyłączenia wszelkich dodatków, niedogodności występują na moim Debianie.

make-kpkg --revision kerlen~304 kernel_image kernel_headers

skrypt zwracał następujący błąd:

exec make kpkg_version=12.017 -f /usr/share/kernel-package/ruleset/minimal.mk debian DEBIAN_REVISION=kerlen~304
/usr/share/kernel-package/ruleset/misc/version_vars.mk:159: *** Error. The Kernel Release version 2.6.30.4KaKernel VERSION=[2], PATCHLEVEL=[6], SUBLEVEL=[30], EXTRAVERSION=[.4], iatv=[], LOCALVERSION=[KaKernel], UTS_RELEASE_VERSION=[], KERNELRELEASE=[]. is not all lowercase. Since the version ends up in the package name of the kernel image package, this is a Debian policy violation, and the packaging system shall refuse to package the image. . Stop.
Failed to create a ./debian directory: Nie ma takiego pliku ani katalogu at /usr/bin/make-kpkg line 970.

a konkretniej rzecz ujmując, chodziło o ostatnią linijkę powyższego loga. Trochę pogogliłem i zauważyłem, że problem ten jest spotykany, ale… rozwiązania brak. Został nawet zgłoszony błąd dla paczki kernel-package w Debianie, opisujący dokładnie to co doświadczyłem. Opiekun paczki uznał ten błąd za dziwny i… tak zostało…

Kombinowałem z samym poleceniem make-kpkg i to dość sporo, jednakże nie przynosiło to zadowalających rezultatów. W końcu coś mnie podkusiło aby zajrzeć do pliku konfiguracyjnego kernela (.config). No i jak się po chwili okazało, właśnie tam był pies pogrzebany. A konkretnie chodziło o linijkę:

CONFIG_LOCALVERSION=”KaKernel”

Oczywiście string pomiędzy “” to była moja własna nazwa kernela, sprzed kilku miesięcy. Sęk w tym, że zmieniła się polityka Debiana względem nazywania kerneli, w których to nazwach, nie mogą występować wielkie litery. Tak więc, wystarczyło po prostu zamienić wielkie litery na małe, w powyższej linijce.

Niedawno wspominałem, że używana kiedyś przeze mnie wtyczka, akismet, przestała działać, z racji zablokowania portu 80 na połączenia wychodzące, przez administratorów OVH Free. Taka decyzja została podjęta, ze względu – cytuję – “nadużycia”.

Od tego momentu na moim blogu zaczął się koszmar. Codziennie około 1000 komentarzy, które są oczywiście spamem. Chwilowo musiałem zrezygnować z automatycznej akceptacji komentarzy, ponieważ nie byłem w stanie kontrolować co minutę, jaki nowy komentarz się pojawił.

Jeden ze znajomych polecił mi wtyczkę WP-SpamFree. Niestety, nie spełniała ona moich oczekiwań, ze względu na bardzo ubogie opcje. Nie szukałem więcej wtyczek, z prostego powodu – po prostu mi się nie chciało, a nic i tak nie zastąpi akismeta.

Przypomniało mi się jednak, że w opcjach WP jest coś takiego jak “czarna lista komentarzy”. Ach, od razu zapełniłem ją całą cyrylicą oraz kilkudziesięcioma viagro-podobnymi słowami. No i mam wreszcie święty spokój. Jak wspomniałem w tytule wpisu, jest to dość prymitywne rozwiązanie i na pewno nie na dłuższą metę. Czekam jednak, aż OVH w końcu odblokuje port 80, co zresztą zapowiedzieli (blokada jest – podobno – tymczasowa).

KDE 4.3

Około półtora miesiąca po zakupie laptopa, zaczął on mi z lekka szwankować. Z początku objawiało się to bardzo rzadkim miganiem ekranu. Zdarzało się to naprawdę rzadko, przez co problem pozostawiłem, będąc pewien, że jest to wina sterowników do karty graficznej. W takim przekonaniu żyłem przez około tydzień, aż do momentu, w którym objawy się nasiliły, zarówno na Debianie jak i Viście. Owe nasilenie objawiało się coraz częstszym miganiem ekranu, najczęściej podczas włączania notebooka. Natomiast po kolejnym tygodniu, problemy znowu nasiliły się. Tym razem jednak, znowu najczęściej podczas uruchamiania notebooka, matryca była całkowicie zciemniona – aby zobaczyć jakikolwiek tekst, musiałem patrzeć z 3-5 cm na ekran. Wszystkie te kłopoty zazwyczaj znikały po około 5-15 minutach od uruchomienia sprzętu, ale potrafiły powracać już w praktycznie każdym momencie pracy.

Po dokładnym sprawdzeniu wszelkich możliwości, doszedłem do wniosku, iż niestety, w notebooku `coś` nawaliło i że będę zmuszony odesłać go na gwarancję. Grzebałem w systemie, w logach, w sterownikach, uaktualniałem BIOS, aby ostatecznie wykluczyć problemy z oprogramowaniem.

W końcu zostałem zmuszony do oddania laptopa na gwarancję. W tym celu kilkakrotnie kontaktowałem się z polskim oddziałem MSI, aby uzyskać szczegółowe informacje na temat procesu reklamacji sprzętu.

Szczerze mówiąc, zwlekałem dość długo z wysłaniem sprzętu, a to głównie ze względu na to, że był mi potrzebny każdego dnia do pracy, a nie miałem żadnej możliwości pracy na jakimkolwiek innym komputerze. Notebook wysłałem na gwarancję w momencie kiedy pojechałem na kilka dni odwiedzić rodzinkę w Bydgoszczy. Przez ten czas i tak nie miałbym czasu na pracę, więc głupotą byłoby nie odesłanie laptopa – w tym właśnie czasie – do serwisu.

Tak więc po zgłoszeniu usterki do MSI i dokonaniu wszelkich formalności, zamówiłem kuriera po odbiór przesyłki. MSI pokrywa wszelkie koszty transportu, w obie strony, w przypadku ważności gwarancji. Firma kurierska jaka była wymagana przez MSI, to DHL. I jak zwykle, nie zawiedli mnie. Koleś przyjechał po paczkę dokładnie o wyznaczonej godzinie i cały odbiór odbył się sprawnie.

Należy jeszcze wspomnieć, że przez kilka ostatnich dni, przed wysyłką, byłem zmuszony do zrobienia kompletnego backupu wszelkich danych znajdujących się na moim dysku twardym. Wiadomo – w serwisie mogą mi strzelić “format C:” i katastrofa gotowa. Cóż, była to niezła męczarnia, zważywszy na to, że miałem kilkaset GB danych, a do tego, brak dostępu do jakiegokolwiek dużego dysku zewnętrznego, na który mógłbym skopiować pliki. Jedyne co mi zostało, to dwa pendrive’y 8 GB, jeden 4 GB, jeden 2 GB oraz dwa po 1024 MB i kilka/naście/dziesiąt płyt CD/DVD (również dwuwarstwowych!). Wyobrażacie sobie kopiowanie tych wszystkich GB na  tak małe nośniki danych? Tak, jest to totalne piekło… Koszmar… Wrrr…

Tego samego dnia, pojechałem do Bydgoszczy – bo co mi w sumie pozostało bez komputera? Swoją drogą, Bydgoszcz to bardzo ciekawe miasto. Co mi się rzuciło w oczy, to przede wszystkim dość mały ruch w centrum (nawet w godzinach szczytu) oraz nieźle wnerwiające sygnalizacje świetlne. Rzekłbym również, że to miasto jest bardzo czyste, w porównaniu np. z Trójmiastem. Nie twierdzę w tym momencie, że Trójmiasto jest brudne, ale praktycznie wszędzie można zauważyć jakiś papierek, puszkę, butelkę po 0,5l. Natomiast w Bydgoszczy, mimo dokładnego wpatrywania się, nie zauważyłem aż takiej ilości śmieci (oczywiście, występują one, ale naprawdę rzadko). Ciekawie prezentuje się również tak zwana “Wenecja bydgoska” oraz tamtejszy olbrzymi park (nie pamiętam nazwy). Przyzwoite restauracje i kawiarnie (spędziłem trochę czasu tylko w “Sowie” i “Manekinie”  i… szczerze polecam ; niestety nie miałem okazji zajrzeć do “Opery Nova”).

Cóż, pozwiedzałem trochę Bydgoszcz i bynajmniej nie uważam tego czasu za zmarnowanego :).

Wracając do sprawy notebooka… Sprawdzając stan przesyłki, dowiedziałem się, że paczka dotarła do polskiego oddziału MSI (niedaleko Wrocławia), już w piątek, w dodatku, w mniej niż 24 godziny.

Powróciłem do domu w poniedziałek. Ten dzień spędziłem na wsi, odprężając się trochę (co mi nie wyszło, z racji braku okołu 2,5 kg na kolanach) i nawiedziłem MSI-Polska telefonem w sprawie stanu realizacji naprawy. Niemile mnie zaskoczyli, informując mnie, że przesyłka co prawda do nich dotarła, ale jeszcze się moim sprzęcikiem nie zajęli.

Nie miałem prawa ich poganiać, w sumie po dwóch dniach roboczych, dlatego kolejny telefon postanowiłem wykonać w środę. Jak chciałem, tak i zrobiłem. Dzwoniłem bodajże około trzynastej i… Ucieszyłem się jak dziecko, słysząc, że usterkę naprawiono i paczka jest właśnie odsyłana do mnie.

Notebooka otrzymałem następnego dnia, czyli w czwartek, około godziny piętnastej. Czyli cała naprawa, plus przesyłka w obie strony, trwała równo tydzień (czyli tyle, ile zapewniano mnie podczas rozmów z konsultantkami MSI).

Po odbiorze przesyłki, czym prędzej przystąpiłem do podłączenia i odpalenia sprzętu. Ekran od tamtego momentu, jak i do dziś, działa znakomicie, bez żadnych problemów. Przez chwilę zmartwiło mnie jednak straszne burczenie wiatraczka w komputerze – odgłos był taki, jakby wiatrak o coś haczył. Miałem nadzieję, że po 5 minutach to przejdzie… i faktycznie przeszło.

Mimo że cały sprzęt działa teraz idealnie i został do mnie dostarczony bardzo czysty, bez zabrudzeń, zawsze musi zdarzyć się coś niemiłego. W serwisie z lekka wygięli mi prawą, górną stronę klawiatury, tuż przy klawiszu “PageDown”. Wygięcie nie przeszkadza w pracy, ale nie wygląda za to zbyt estetycznie. Zapewne na dniach się tym sam zajmę.

Powracając do kwestii problemu z matrycą – jaka była diagnoza serwisu MSI? Dokładnie taka jaką przewidywałem – czyli poluzowany kabel. Drobnostka, a ile problemów i nerwów potrafi sprawić.

Jak na razie, ostatnie dwa dni spędziłem na ponownej instalacji i konfiguracji systemów. Z Debianem już w miarę się uporałem. Aktualnie konfiguruję wszystko na Viście. Jeszcze sporo roboty przede mną. Muszę ponadto nadrobić wiele zaległości – głównie e-maile i moderacja forum.

Przy okazji, przepraszam za makabryczną ilość spamu, która pojawiła się na moim blogu, podczas mojej nieobecności. Niestety, mam poważne problemy z modułem akismet (ale to już wina firmy OVH, która zablokowała port 80 na wychodzące połączenie, ze względu na nadużycia ; aktualnie szukam alternatywnego rozwiązania problemu ze spamem, oprócz wyłączenia automatycznej akceptacji komentarzy).

Powracając do pytania z początku wpisu – jestem szczęśliwym posiadaczem MSI EX625-233PL, czy też nie? Uważam, że jestem. Cóż, jakby nie spojrzeć, życie jest jakie jest i codziennie wszyscy ludzie napotykają się na problemy. W tym przypadku ja miałem po prostu pecha. Mimo bardzo ostrożnego obchodzenia się z notebookiem, coś było w nim nie tak. Zdarza się. Nie winę oto nikogo, ani sklepu, z którego go kupiłem, ani kuriera (być może paczka była źle przechowywana? (pytanie retoryczne)), ani tym bardziej firmy MSI. Po prostu, zdarza się.

Moim zdaniem, w całej tej sytuacji, na pewno należą się pochwały polskiemu serwisowi MSI, za – jakby nie patrzeć – błyskawiczną naprawę, jak i firmie kurierskiej DHL, za błyskawiczne dostarczanie paczek (BTW, tylko UPS może jeszcze rywalizować z DHL, reszta firm, z którymi miałem do czynienia, to tylko insekty na łące).

Dobrnąłeś do końca. Gratuluję i dziękuję :).

aloha!

Ostatnio znalazłem rozwiązanie problemu, które – w moim przypadku – działa w 100%.

Po pierwsze, musimy ponownie skorzystać z zewnętrznego programu do ustawiania tapety na pulpicie. Programik feh w ostatnich latach robi wielką furorę, głównie właśnie za sprawą problemów na linii conky <-> KDE 3/4. Oczywiście pomijam inne zastosowania tego narzędzia. W każdym bądź razie, aby móc cieszyć się conky na KDE 4, należy zainstalować wspomniany programik:

# aptitude install feh

Będziemy go uruchamiali następującym poleceniem:

$ feh --bg-scale "`grep 'wallpaper=' ~/.kde/share/config/plasma-appletsrc | tail --bytes=+11`" &

Uwaga! Powyższe polecenie tyczy się wszystkich wersji KDE4, starszych niż 4.3.0. W wersji 4.3.0 zaszło kilka zmian, przez co poprawne polecenie uległo drobnej zmianie:

$ feh --bg-scale "`grep 'wallpaper=' ~/.kde/share/config/plasma-desktop-appletsrc | tail --bytes=+11`" &

Dzięki temu, nie musimy podawać bezpośredniej ścieżki do tapety, za każdym razem kiedy chcemy ją zmienić. Od teraz możemy do woli zmieniać tapetę w konfiguracji KDE4, ponieważ powyższe polecenie sprawi, iż feh ustawi taką samą tapetę, jaką ustawiliśmy w środowisku graficznym.

Podane wyżej polecenie, dodaj do autostartu KDE4.

W przypadku kiedy nie skorzystamy z programu feh, conky może zachowywać się dość dziwnie. Począwszy od zanikania, poprzez wyświetlanie “pod sobą” tapety z menadżera logowania KDM, skończywszy na wywalaniu się.

Czas na krok drugi. Tym razem, mamy dwa rozwiązania. Jeżeli któreś z nich nie zadziała, spróbuj drugiego.

Sposób 1.

Wpisy, które podałem w swojej poprzedniej notce, są dalej wymagane – w swojej konfiguracji musisz zawrzeć poniższe linijki:

own_window yes
own_window_type normal
own_window_transparent yes
own_window_hints undecorated,below,sticky,skip_taskbar,skip_page

Sposób 2.

Podobnie jak w sposobie pierwszym, musimy do konfiguracji conky dodać odpowiednie linijki – dodaj tylko pierwsze trzy linijki z powyższego listingu.

Następny – ostatni już – krok, to konfiguracja conky aby wyświetlał się nam bez obramowania okna, nie był wyświetlany na pasku zadań, ani na ikonach pulpitów. Dokonamy tego poprzez standardowy mechanizm domyślnego menadżera okien KDE4. Wystarczy kliknąć ppm (prawy przycisk myszy) na obramowaniu conky, a następnie wybrać: Zaawansowane -> Dodatkowe ustawienia okna.

W oknie, które się nam pojawi, możemy ustawić wiele przydatnych opcji, dla danego okna. Co więcej, KDE zapamięta te ustawienia i będzie uruchamiać dane okno z zdefiniowanymi przez nas preferencjami.

W przypadku kiedy korzystasz z innego menadżera okien, musisz samemu poszperać w jego opcjach, gdzie można dostosować ustawienia dla danego okna.

W tytule notki wspomniałem jeszcze o terminalu Urxvt. Również i on działał u mnie niepoprawnie w KDE4. Objawiało się to tym, iż podczas przesuwania bądź rozszerzenia okna, momentami zawieszało się ono, bądź podczas wykonywania tych operacji, zżerało całą moc procesora.

W tym przypadku, rozwiązaniem jest ustawienie tapety przez program feh – dokładnie w taki sam sposób, jaki podałem wyżej.

Cóż, myślałem, że w przypadku wersji 9.7, programiści w końcu poprawią co trzeba i driver’y poprawnie skompilują się na 2.6.30 (to znaczy moduł dla kernela). Myliłem się… Znowu trzeba ręcznie łatać sterowniki.

Łaty znalazłem przy pomocy Google, na dwóch stronach: strona Archa oraz na Phoronix Forums. Po odpowiednich operacjach, które opiszę niżej, wszystko instaluje się i kompiluje u mnie poprawnie. Nie odpowiadam za ewentualne problemy ze sterownikami, wynikające z ich łatania, bądź sam fakt ewentualnego naruszenia licencji.

Poniżej prezentuję prosty skrypcik, który należy uruchomić z uprawnieniami roota, w katalogu gdzie znajduje się najnowsza wersja instalacyjna sterowników. Skrypt automatycznie pobierze patche, nałoży je, po czym uruchomi instalator. Zalecam instalować sterowniki z poziomu x’ów.

#!/bin/bash
[ -d "/root/9.7" ] || mkdir "/root/9.7"

mv ati-driver-installer-9-7*.run “/root/9.7/”
cd /root/9.7
chmod +x ati-driver-installer-9-7*.run
./ati-driver*.run –extract
cd fglrx-install*/common
wget -c http://kaka.ovh.org/pliki/fglrx/9.7/2.6.30/2.6.29.diff
patch -p0 <2.6.29.diff
cd ../
wget -c http://kaka.ovh.org/pliki/fglrx/9.7/2.6.30/2.6.30-irqreturn_t-cat9.7.patch
patch -p0 <2.6.30-irqreturn_t-cat9.7.patch
chmod +x ./ati-installer.sh
./ati-installer.sh . –install

Zaznaczam jednak, że będziesz musiał samodzielnie skompilować źródła, ponieważ autor – z tego co widzę – nie udostępnia paczek dla innych systemów niż OpenSuse.

System Load Viewer

// EDIT – 6 sierpnia 2009
Z tego co widzę, aplet trafił do stabilnego wydania KDE 4.3

Zatem udałem się na stronę projektu, po czym pobrałem paczkę .deb dla amd64. Podczas instalacji paczki, zostało zbudowane około kilkunastu modułów, dla różnych kart dźwiękowych. Proces kompilacji odbył się bez żadnych problemów. Po tym, instalator zapytał mnie, czy moja karta graficzna faktycznie korzysta z modułu hda-intel. Mimo że automatyczne wykrycie modułu ucieszyło mnie, moja radość trwała zaledwie kilka sekund – do momentu, w którym ujrzałem informację, że wspieranie hda-intel jest dopiero w fazie BETA.

Nie zniechęciło mnie to jednak do dalszych testów. Wywaliłem alsę z runleveli, dodałem OSS4 i reboot. System się pięknie uruchamia, wszystkie usługi, w końcu ostatnia – MPD. Kiedy MPD zaczęło mi grać, myślałem, że zwariuję. Z głośników zamiast wydobywać się piękny dźwięk, płynął dźwięk niczym `cat /dev/urandom > /dev/dsp` (to jest gorsze niż te wszystkie, skrzeczące koty pod moim blokiem całymi nocami!).

Cóż, również i ta sytuacja znacząco mnie nie zniechęciła. Podejrzewałem, że ten cały skrzekot to wina jakiś ustawień – co okazało się za chwilę trafnym podejrzeniem. Odpaliłem sobie panel sterowania dźwięku, który dostarcza OSS4. Te osoby, które miały zaszczyt go pisać (GTK), chyba nigdy w życiu nie tworzyły żadnego interfejsu – wyobrażacie sobie okno na cały ekran, z porozrzucanymi ustawieniami, do tego brak ustawienia odpowiedniego skalowania, przez co większość przycisków miała nienaturalne rozmiary? Co lepsze, mimo że okno zajmowało całą przestrzeń pulpitu, to 1/3 opcji nie mieściła się na nim – no i oczywiście, pozostały mi paski przewijania. Totalna masakra i szczyt głupoty. Zamiast to jakoś ładnie posegregować w zakładki… Ech.

Wracając do sedna problemu. Jakimś cudem udało mi się połapać w panelu sterowania dźwiękiem i pobawiłem się wszystkimi suwakami. Co się okazało, cały ten masakryczny szum ustąpił, w momencie kiedy zmniejszyłem siłę dźwięku do 50% – powyżej tego progu, dźwięk zaczynał wariować. Byłoby to pół biedy, gdyby działał mi chociażby subwoofer, ale nie, ani nie ruszył. Kolejnym mankamentem był grający tylko i wyłącznie prawy głośnik (mam stereo). Lewy oczywiście grał, ale tylko głupi skrzek, po podwyższeniu głośności powyżej 50%.

Mikrofon jak nie działał na ALSie, tak nie działał na OSS4.

Cóż… hda-intel w OSS4 faktycznie jest w fazie BETA.

Myślę sobie “pewnie coś nawaliło”. Robię restart i problem ponownie występuje.

Uruchomiłem zatem system w safe mode, aby sprawdzić czy klawiatura działa w konsoli – działała. Wywaliłem GDM’a z runleveli, aby w spokoju przystąpić do zdiagnozowania problemu. Nie trwało to zbyt długo. Zauważyłem, że nie działał mi Internet, a podczas próby uruchomienia daemona wicd, otrzymywałem błąd, którego końcówka wyglądała następująco:

dbus: /var/run/dbus/system_bus_socket no such file or directory

Sprawdziłem czy takiego pliku faktycznie nie ma i okazało się to prawdą. Cały problem polegał na tym, że dbus nie został po prostu odpalony, a jako że jest on używany przez wiele daemonów, jak i x’y, niektóre usługi po prostu nie były wstanie poprawnie działać.

Chcąc odpalić dbus’a przez:

dbus-daemon --system

otrzymywałem komunikat, iż nie ma takiego pliku ani katalogu. No i to mnie powaliło. Faktycznie, w /usr/bin, ani w /sbin nie było żadnego pliku, który zawierałby chociażby ciąg “dbus”.

Reinstalacja pakietu dbus również nie pomogła. Zastanawiałem się, czy przypadkiem opiekun pakietu nie pominął przez przypadek kilku plików, wszak dzień wcześniej nastąpiła u mnie aktualizacja tej usługi. Cóż, nawet instalacja starszej paczki nie pomogła.

To już mnie poważnie zmartwiło. Czyżby dpkg miał jakiś problem? Cóż, ostatecznym rozwiązaniem okazała się własnoręczna kompilacja pakietu dbus i jego instalacja.

Perełką w tym labiryncie jest fakt, że paczka dbus’a, która została wczoraj zaktualizowana, posiadała w sobie plik /usr/bin/dbus-daemon, jednakże dpkg za żadne skarby nie instalował tego pliku, nie racząc nawet zwrócić jakikolwiek błąd. Ciekawa sytuacja…

W kwestii samej notki, już na początku uprzedzam, że po dokonaniu współdzielenia profilu między Linuksem a Windowsem, Opera na Debianie uruchamia się znacznie dłużej niż na Windowsie. Nie jestem pewien z czego to wynika, w każdym bądź razie, już po samym uruchomieniu, działa bardzo szybko.

Na Google można znaleźć kilka sposobów na współdzielenie profilu. Pokrótce opiszę tutaj sposób, który ja osobiście zastosowałem, a także podam jeszcze jedno, alternatywne rozwiązanie (które jednak będzie się opierać, w pewnym sensie, na pierwszym).

Co trzeba wiedzieć na początku? Ano bardzo ważną rzecz. Opera zapisuje swoją główną konfigurację w pliku opera6.ini, zarówno na Windowsie jak i na Linuksie. Tego pliku nie da się współdzielić między systemami. Wynika to stąd, iż w owym pliku, Opera zapisuje ścieżki, do kolejnych konfiguracji, a jak wiadomo, ścieżki w Linuksie i Windowsie różnią się miedzy sobą. Ostatecznie, można by spróbować użyć ścieżek względnych, a nie bezwzględnych, w pliku opera6.ini. Nie próbowałem jednak tego robić, dlatego nie daję żadnej gwarancji, że Opera przyjmie takie ścieżki. W tym poradniku, skupię się na ścieżkach bezwzględnych, a co za tym idzie, na dwóch plikach opera6.ini.

Pierwszą rzeczą jaką należy zrobić, to utworzyć nowy katalog, w którym przechowamy większość plików Opery. Może on znajdować się na jakiejś osobnej partycji. Ważne jest jednak, aby zarówno system Windows jak i Linux, miał prawa do zapisu i odczytu owego katalogu.

Po utworzeniu folderu, skopiuj do niego całą swoją konfigurację Opery z Windowsa. W przypadku systemu Windows Vista, są to całe zawartości niżej podanych katalogów:

• C:\Users\NAZWA_USERA\AppData\Local\Opera\Opera
• C:\Users\NAZWA_USERA\AppData\Roaming\Opera\Opera\profile

Jeżeli jesteś posiadaczem innego systemu z serii Windows, poszukaj na Google, gdzie Opera trzyma swoją konfigurację i dokonaj jej przekopiowania.

Kiedy już przekopiowałeś wszystkie pliki i katalogi do nowego folderu, usuń z niego (z tego nowego folderu!) następujące pliki:

• cookies4.dat
• opera6.ini
• pluginpath.ini
• vlink4.dat
• wand.dat

Wymienione tutaj pliku, nie mogą być współdzielone.

Kolejnym etapem, jest stworzenie odpowiednich dowiązań na Linuksie. Oznacza to, że każdy plik, który znajduje się w katalogu domowym opery (~/.opera), a znajduje się w nowo utworzonym katalogu do współdzielenia, musi wskazywać na odpowiedni plik bądź katalog, w nowo utworzonym katalogu. Brzmi to skomplikowanie, wiem. Pokażę zatem przykład. Zakładając, że /mnt/wymiana/Opera to nowo utworzony katalog, który będzie służył do współdzielenia profilu, to:

• ~/.opera/cache4 (katalog) musi wskazywać na /mnt/wymiana/Opera/cache4 (katalog)
• ~/.opera/notes.adr (plik) musi wskazywać na /mnt/wymiana/Opera/notes.adr (plik)
• ~/.opera/toolbar (katalog) musi wskazywać na /mnt/wymiana/Opera/toolbar (katalog)
• itd. itd.

Pamiętaj o wcześniej wymienionych przeze mnie plikach, które nie mogą być współdzielone. Specjalnie kazałem Ci je usunąć z nowego katalogu – właśnie po to, abyś przypadkiem nie zrobił dowiązania również dla nich.

Dowiązania na Linuksie możesz zrobić korzystając z polecenia ln (man ln), bądź za pomocą jakiegoś menadżera plików. Polecam drugą opcję. Wystarczy otworzyć sobie dwa okna, w jednym nowy współdzielony katalog, w drugim ~/.opera. Teraz wystarczy przeciągnąć sobie wszystkie pliki i katalogi z pierwszego okna na drugie.

Jeżeli już zrobiłeś odpowiednie dowiązania, możesz uruchomić Operę na Linuksie, aby sprawdzić czy wszystko jest w porządku. W przypadku napotkania jakiegokolwiek problemu, powinieneś być świadom tego, że najprawdopodobniej po prostu namieszałeś coś z dowiązaniami.

Teraz pozostał już ostatni krok, najbardziej żmudny – stworzenie odpowiednich dowiązań na systemie Windows. Sama idea tworzenia dowiązań, jest dokładnie taka sama jak na Linuksie, czyli np (zakładając, że X:\Opera to odpowiednim /mnt/wmiana/Opera).:

• C:\Users\NAZWA_USERA\AppData\Local\Opera\Opera\mail (katalog) musi wskazywać na  X:\Opera\mail (katalog)
• C:\Users\NAZWA_USERA\AppData\Local\Opera\Opera\profile (katalog) musi wskazywać na X:\Opera\profile (katalog)
• C:\Users\NAZWA_USERA\AppData\Roaming\Opera\Opera\profile\menu (katalog) musi wskazywać na X:\Opera\menu (katalog)
• C:\Users\NAZWA_USERA\AppData\Roaming\Opera\Opera\profile\global.dat (plik) musi wskazywać na X:\Opera\global.dat (plik)
• itd. itd.

Problem jedynie leży w tym, że tego typu dowiązań, nie możesz stworzyć za pomocą menadżera plików, jaki jest w Windowsie, ponieważ Opera nie będzie potrafiła z nich korzystać i ponownie utworzy nowe pliki z konfiguracją. Ja zrobiłem dowiązania za pomocą dwóch narzędzi konsolowych, dla każdego pliku i katalogu z osobna:

• Junction – dla katalogów,
• mklink – dla plików.

Z tego co mi jednak wiadomo, wystarczy jedynie drugie polecenie (mklink), które jest dostępne standardowo w Windows Vista (jak jest w XP? nie mam pojęcia).

Po utworzeniu odpowiednich dowiązań na Windowsie, również i na nim odpal Operę i sprawdź czy wszystko gra. Jeżeli tak, to możesz być z siebie dumny ;).

Drobna uwaga. Z racji, że plik opera6.ini nie może być współdzielony, niektóre z ustawień, np. interfejsu użytkownika, mogą być różne na Windowsie jak i na Linuksie. Jeżeli napotkasz taki problem, nie ma wyjścia – musisz samemu dostosować odpowiednie opcje w konfiguracji Opery, na obu systemach.

To jest jeden ze sposobów. Inne rozwiązanie tego problemu, to chociażby zrobienie dowiązań z ~/.opera, na partycję z Windowsem, do katalogu gdzie jest trzymana konfiguracja Opery, np.:

• ~/.opera/mail (katalog) wskazuje na C:\Users\NAZWA_USERA\AppData\Local\Opera\Opera\mail (katalog)
• itd. itd.

Dzięki temu, unikniesz tworzenia dowiązań na Windowsie, ale… Na Linuksie musisz mieć prawa do zapisu i odczytu danych na partycji windowsowej. Przypominam, że do obsługi partycji NTFS, zalecany jest sterownik ntfs-3g.

Natknąłem się za to na świetny dodatek, który – teoretycznie – jest skierowany dla testerów nowych wersji Fx, ale sam zacząłem z niego korzystać, ze względu na jedną z możliwości dodatku – siłowa instalacja niekompatybilnych rozszerzeń, za pomocą jednego kliknięcia – czyli bez mozolnej edycji plików.

Zachęcam do zapoznania się z dodatkiem Nightly Tester Tools.

BTW, najnowsza wersja Iceweasel (3.5) jest dostępna w repozytorium experimental. Uwaga! Jest ona dostarczana bez tłumaczenia, co oznacza, że np. polski język interfejsu, trzeba będzie zainstalować samodzielnie.

Powyżej Debian GNU/Linux unstable amd64, a poniżej Microsoft Windows Vista Home Premium x86.

Tak więc… Z tego co wiem, w kernelu 2.6.29 wkradł się jakiś poważmy błąd w sterownikach do bluetootha, który – podczas korzystania z niego – powodował zawieszanie się systemu. Błąd poprawiono dopiero w wersji 2.6.30 – nie mam pojęcia dlaczego nie poprawili tego w jednym z wydań 2.6.29 (z tego co pamiętam, błąd był znany już od początku wydania 29 jako stable).

Dla jądra w wersji 2.6.28 i niższej, może być wymagany pakiet ext4dev i e2fsprogs. Dla jąder z wyższymi numerkami, wystarczy ostatni pakiet.

Uwaga! Z tego co się dowiedziałem, korzystanie z ext4 na dobrym poziomie stabilności, zaczyna się od kernela w wersji 2.6.29, ze względu na kilka poważnych błędów we wcześniejszych numerkach (ale na ile jest to prawdziwe? nie mam pojęcia).

OK, po zainstalowaniu wymaganych paczek, przechodzimy do działania (oczywiście ciąg “/dev/sda1″ zamieniasz na własne urządzenie, na którym chcesz dokonać konwersji).

Jeżeli posiadasz system ext2, to przed migracją na ext4, wpierw musisz przejść na ext3:
# tune2fs -j /dev/sda1
Teraz dopiero włączamy rozszerzenia, które oferuje ext4:
# tune2fs -O extents,uninit_bg,dir_index /dev/sda1

Teraz należy dokonać przeskanowania systemu plików, w celu poszukiwania ewentualnych błędów, które powinny zostać automatycznie naprawione:

# e2fsck -fpDC0 /dev/sda1

Uwaga! Powyższe polecenie należy wykonać na niepodmontowanym systemie plików. Ogólnie rzecz biorąc, po wykonaniu wcześniejszych poleceń i zrestartowaniu systemu, sprawdzanie systemu plików odbędzie się automatycznie, jednakże nic nie stoi na przeszkodzie, aby samemu tego dokonać.

Oczywiście należy również pamiętać, o dokonaniu odpowiedniej korekty pliku /etc/fstab, poprzez zamianę systemu plików, jaki znajduje się na danej partycji (czyli po prostu podmieniasz ciąg “ext2″ lub “ext3″ na “ext4″) – przykład:

/dev/sda1 / ext3 errors=remount-ro 0 1

należy zamienić na:

/dev/sda1 / ext4 errors=remount-ro 0 1

Pamiętajmy również o tym, że mimo iż ext4 jest już oznaczony jako stabilny FS, niekoniecznie musi takim być. Osobiście nie mam żadnych złych doświadczeń z ext4, ale zważywszy na ilość poprawek związanych z nim, w każdym nowym numerku kernela, należy brać pod uwagę, ewentualną utratę danych.