Od dobrych paru tygodni mam jakiś wstręt do androidowych wnętrzności. Po części to efekt presji rzeczywistości, po części – jakaś głupia blokada. Waham się czy przejść już na kolejną wersję Androida (Gingerbread czyli 2.3) czy pozostać z FroYo. Jednak odłóżmy rozterki 'młodego’ wyrobnika na bok i zajmijmy się tępieniem robali czyli dezynsekcją właśnie.

Chyba przedostatnia wersja Androidowego ROMu Laszlo opublikowana na forum XDA miała dość ciekawy błąd mianowicie nie widziała aplikacji zainstalowanych na partycji Ext.

Dorabiając z Fireratem natywną obsługę SdExt prawie w ogóle nie zwracaliśmy uwagi na to czy stosowna partycja karty w ogóle istnieje (o podmontowaniu jej we właściwym miejscu nawet nie wspomnę). Ubocznym efektem (i, do pewnego stopnia, powodem moich programistycznych wypocin) był fakt, że telefon potrafił wpadać w bootloop (czyli w kółko się restartował).

Pierwszym krokiem było zmodyfikowanie Volda (VOLume Daemon – usługa systemowa zarządzająca 'dyskami’), tak by montował odpowiednią partycję pod /sd-ext i sprzedał informację o sukcesie (lub porażce) reszcie systemu. Jak już umiał przekazać informację to trzeba było sprawić by framework wiedział co z tą informacją zrobić i tak powstała funkcja o nazwie getSdExtState(). Tak prosta, że nie sposób popełnić w niej błędu. Od razu też wykorzystałem ją do sprawdzania dostępności /sd-ext przed próbą skanowania zainstalowanych tam aplikacji przy starcie systemu. Kawałek kodu tak trywialny, że nawet nie przyszło mi do głowy jakieś większe testowanie.

if (Environment.getSdExtState().equals(Environment.MEDIA_MOUNTED)) {
   scanDirLI(mSdExtInstallDir, PackageParser.PARSE_ON_SDEXT, scanMode);
}

Jak podmontowane to skanuj, jak nie – to nie. Prawda, że proste? W samym frameworku jest parę newralgicznych miejsc (związanych z instalacją aplikacji) w których użyłem identycznego testu. Świat stał się lepszym miejscem :-) a ja mogłem się zająć dorabianiem informacji o SdExt w Ustawieniach czy czymś takim. Mniej więcej w tym momencie Laszlo zapewne zsynchronizował swoje źródła z moimi i wypuścił na świat kolejną wersję swojego ROMu. Chyba w sobotę Firerat dał mi znać na Twitterze, że ludzie mają kłopoty z Apps2SdExt na najnowszym FbL. Zerknąłem na forum i, na podstawie zamieszczonych tam postów, doszedłem do wniosku, że dochodzi do tzw race condition. Vold działa asynchronicznie względem reszty systemu i w czasie gdy jeszcze zajmuje się sprawdzaniem systemów plikowych uruchamiane są pozostałe komponenty systemu takie jak usługa PackageManagera. To ona właśnie przeprowadza początkowy skan katalogów z aplikacjami. Skoro nie widać aplikacji zainstalowanych na SdExt to (patrząc na powyższy kawałek kodu) getSdExtState zwraca coś innego niż MEDIA_MOUNTED i system nawet nie próbuje zajrzeć do /sd-ext/app. Wniosek z tego jest taki, że Vold jeszcze nie zdążył pozałatwiać swoich spraw z /sd-ext. Problem znany zatem teraz wystarczy znaleźć rozwiązanie. Na szybko Firerat przekompilował framework.jar z wywalonym sprawdzaniem getSdExtState(), wrzucił na XDA i 'rozwiązał’ problem (to był akurat weekend i, zdaje się, byłem po jakimś większym maratonie Singstara w towarzystwie sąsiadów i paru butelek Dark Whisky :-)).

To, co zrobił Firerat było jednak tylko obejściem problemu a nie jego rozwiązaniem. Poczytałem jeszcze raz posty na forum, popsioczyłem, że nikt z pomstujących nie zdobył się na złapanie logów ze startu systemu i doszedłem do identycznego wniosku jak wcześniej: Race condition. Na swoim telefonie nie miałem problemu z brakiem aplikacji z SdExt ale też miałem wtedy zainstalowaną wersję bardzo rozwojową (czyt: powiązaną sznureczkiem i podpartą patyczkiem z każdej strony). Złapałem logi z restartu swojego telefonu i patrzyłem w nie jak sroka w gnat. No nijak nie było szans na race condition. Zgodnie z tym co widziałem w logach /sd-ext było już dawno podmontowane. Przecież nie da się zrobić błędu w 6 linijkach kodu z jakich składa się getSdExt():

    /**
     * Gets the current state of SD-Ext
     * Note: this call should be deprecated as it doesn't support
     * multiple volumes.
     */
   public static String getSdExtState() {
       try {
           if (mMntSvc == null) {
               mMntSvc = IMountService.Stub.asInterface(ServiceManager.getService("mount"));
           }
           return mMntSvc.getVolumeState(getSdExtDirectory().toString());
       } catch (Exception rex) {
           return Environment.MEDIA_REMOVED;
       }
   }

Poza tym w innych miejscach kodu funkcja ta działa perfekcyjnie. Tak się zafiksowałem na tym race condition, że dobre dwa dni nad tym spędziłem. Albo raczej zmarnowałem. Zmarnowałem bo z całego logu (około 150+ KB tekstu) skoncentrowałem się wyłącznie na części związanej ze PackageManagerem i skanowaniem /sd-ext/app. W końcu mój umysł zaczął rejestrować inne linijki logu i wyłapał coś takiego:

I/sysproc (  147): System server: starting Android runtime.
I/sysproc (  147): System server: starting Android services.
I/SystemServer(  147): Entered the Android system server!
I/sysproc (  147): System server: entering thread pool.
I/SystemServer(  147): Entropy Service
I/SystemServer(  147): Power Manager
I/SystemServer(  147): Activity Manager
I/ActivityManager(  147): Memory class: 16
D/dalvikvm(  147): GC_FOR_MALLOC freed 641 objects / 80848 bytes in 138ms
D/dalvikvm(  147): GC_FOR_MALLOC freed 2131 objects / 317920 bytes in 159ms
I/SystemServer(  147): Telephony Registry
I/SystemServer(  147): Package Manager
D/dalvikvm(  147): GC_FOR_MALLOC freed 5971 objects / 222640 bytes in 181ms
I/dalvikvm(  147): DexOpt: source file mod time mismatch (3e4c9ef4 vs 3e618cf4)
D/installd(  101): DexInv: --- BEGIN '/system/framework/android.test.runner.jar' ---
D/dalvikvm(  163): DexOpt: load 111ms, verify 722ms, opt 13ms

Kilkanaście linijek niżej pojawia się:

I/PackageManager(  147): Pruning dalvik file: sd-ext@app@com.twitter.android-2.apk@classes.dex
I/PackageManager(  147): Pruning dalvik file: sd-ext@app@com.keramidas.TitaniumBackup-1.apk@classes.dex
D/PackageManager(  147): Scanning app dir /system/framework
D/PackageManager(  147): Scanning app dir /system/app
D/dalvikvm(  147): GC_FOR_MALLOC freed 4987 objects / 280408 bytes in 193ms
W/PackageParser(  147): No actions in intent filter at /system/app/Bluetooth.apk Binary XML file line #124
I/PackageManager(  147): /system/app/CMParts.apk changed; collecting certs

I jeszcze kilkadziesiąt linijek niżej:

D/dalvikvm(  147): GC_EXPLICIT freed 7597 objects / 563168 bytes in 221ms
I/SystemServer(  147): Account Manager
I/SystemServer(  147): Content Manager
I/SystemServer(  147): System Content Providers
I/SystemServer(  147): Battery Service
I/SystemServer(  147): Lights Service
I/SystemServer(  147): Vibrator Service
I/SystemServer(  147): Alarm Manager
D/AlarmManagerService(  147): Kernel timezone updated to -60 minutes west of GMT
I/SystemServer(  147): Init Watchdog
I/SystemServer(  147): Sensor Service
I/SystemServer(  147): Window Manager
I/SystemServer(  147): Bluetooth Service
I/SystemServer(  147): Device Policy
I/bluedroid(  147): Starting hciattach daemon
I/SystemServer(  147): Status Bar
I/SystemServer(  147): Clipboard Service
I/SystemServer(  147): Input Method Service
I/SystemServer(  147): NetStat Service
I/SystemServer(  147): NetworkManagement Service
I/SystemServer(  147): Connectivity Service
V/ConnectivityService(  147): ConnectivityService starting up
D/ConnectivityService(  147): getMobileDataEnabled returning true
V/ConnectivityService(  147): Starting Wifi Service.
I/WifiService(  147): WifiService starting up with Wi-Fi disabled
D/Tethering(  147): Tethering starting
D/NetworkManagmentService(  147): Registering observer
I/bluedroid(  147): Starting bluetoothd deamon
I/SystemServer(  147): Throttle Service
I/SystemServer(  147): Accessibility Manager
I/SystemServer(  147): Mount Service
I/SystemServer(  147): Notification Manager

Widać?
Nie widać?? Hmmm… A teraz?

I/SystemServer(  147): Entropy Service
I/SystemServer(  147): Power Manager
I/SystemServer(  147): Activity Manager
I/SystemServer(  147): Telephony Registry
I/SystemServer(  147): Package Manager
I/SystemServer(  147): Account Manager
I/SystemServer(  147): Content Manager
I/SystemServer(  147): System Content Providers
I/SystemServer(  147): Battery Service
I/SystemServer(  147): Lights Service
I/SystemServer(  147): Vibrator Service
I/SystemServer(  147): Alarm Manager
I/SystemServer(  147): Init Watchdog
I/SystemServer(  147): Sensor Service
I/SystemServer(  147): Window Manager
I/SystemServer(  147): Bluetooth Service
I/SystemServer(  147): Device Policy
I/SystemServer(  147): Status Bar
I/SystemServer(  147): Clipboard Service
I/SystemServer(  147): Input Method Service
I/SystemServer(  147): NetStat Service
I/SystemServer(  147): NetworkManagement Service
I/SystemServer(  147): Connectivity Service
I/SystemServer(  147): Throttle Service
I/SystemServer(  147): Accessibility Manager
I/SystemServer(  147): Mount Service

Jeszcze nie widać? No, dobra. Widzisz kiedy jest startowany Mount Service? A teraz zobacz gdzie jest Package Manager. Między jednym a drugim wpisem mija dobrych kilkanaście – kilkadziesiąt sekund.  W tym czasie skanowane są aplikacje systemowe (/system/app) i użytkownika (/data/app i ewentualnie /sd-ext/app). Poprawność działania getSdExtState() jest uzależniona od działania Mount Service a w chwili próby skanowania /sd-ext/app ta usługa jeszcze nie działa. I to właśnie było źródło problemu :-)

W systemie Android część usług została zaliczona do usług krytycznych (w powyższym wyciągu z logów od Entropy Service do Bluetooth Service). Na moje nieszczęście Mount Service nie trafił do tej kategorii. Z punktu widzenia twórców Androida nie było takiej potrzeby. Usługa ta jest potrzebna tylko do dostępu do kart pamięci. Zmiana kategorii tej usługi nie jest za bardzo możliwa bez potężnej ingerencji w nią samą i szereg innych komponentów a to oznacza więcej potencjalnych bugów. Najprostszym rozwiązaniem było porozmawianie (prawie) bezpośrednio z Voldem. Ubocznym skutkiem jest potencjalne wydłużenie startu systemu o maksymalnie 20 sekund. W skrajnej sytuacji może się okazać, że i tak aplikacje zainstalowane na SdExt się nie pokażą (w przypadku kłopotów z filesystemem). Wygląda to mniej więcej tak. Zdaję sobie sprawę z braków tego rozwiązania. Właściwie jest to tylko nieco hakerskie obejście. Prawidłowym rozwiązaniem jest skanowanie aplikacji z SdExt już po starcie systemu, tak jak to jest robione z aplikacjami zainstalowanymi na partycji FAT karty. Mam już nawet mgliste pojęcie jak to zrobić :-) Jako bonus dostaniecie wtedy możliwość odmontowania i wyjęcia karty pamięci bez wyłączania telefonu :-) Cieszycie się?

Tytuł wpisu wyjaśni się pewnie gdzieś niżej (bo jak zwykle zaczynam pisanie bez konkretnego planu, zaledwie z mglistym zarysem tego co ma się pojawić). Ogólnie rzecz ujmując będzie o Androidzie. Taki śmieszny system operacyjny stworzony przez Google dla urządzeń mobilnych. Chyba od samego początku Android kusił mnie swoją otwartością. Jakoś tak w połowie 2009 roku stałem się właścicielem aparatu Era G1 – znanego bardziej jako HTC Dream. Z Androidem 1.5.

Zdaje się, że z niezmodyfikowanym systemem wytrzymałem jakieś 2-3 miesiące. Proces rootowania/odblokowania Dreama był wówczas nieco skomplikowany i wymagał przygotowania specjalnej karty. Bodaj w sierpniu pokazała się malutka aplikacja, dzięki której można było jednym kliknięciem odblokować Dream. No i się zaczęło.

Zainstalowałem wtedy jakiegoś CyanogenMod-a 4-coś. Przez jakiś czas wystarczało mi instalowanie kolejnych aktualizacji CM4, potem  CM5 i wreszcie CM6. Jakoś w wakacje zwróciłem uwagę na inne ROMy pojawiające się na forum XDA-Developers. Początkowo traktowałem je identycznie jak CMy czyli wipe i flash.  Zainwestowałem nawet w Titanium Backup, żeby nie tracić danych. Raz mnie jednak podkusiło, że zajrzeć do środka zipa. Wydaje mi się, że to był jakiś SpeedTeam Froyo. Numerka nie pamiętam, za to głównym hmmm… „developerem” był (sympatyczny skąd inąd) Jacob Chu-Hing bardziej znany jako XxKOLOHExX.

Developement w wykonaniu SpeedTeam polegał na podmianie paru grafik i xml-i (tzw theming) i dorzuceniu (nieco na oślep) paru cudownych skryptów do /system/etc/init.d. Dodatki typu „apps2sdext-out-of-the-box!” robione były poprzez wywoływanie (przy każdym starcie telefonu) bardzo popularnego (i przy okazji bardzo dobrze napisanego) skryptu Firerata o nazwie All in One Patch. Ten właśnie fakt sprawił, że zacząłem się bawić w modyfikowanie ROMów. Pierwsze kroki robiłem w znanym sobie terenie skryptów shellowych i ogólnie w tej części Androida, która leży na samiusieńkim spodzie i jest po prostu, przyciętym na miarę, Linuxem.

Parę tygodni później miałem na dysku komplet źródeł CyanogenModa a na telefonie samodzielnie skompilowany ROM. Znowu parę tygodni minęło i delikatnie zacząłem gmerać w kodzie. Pierwszym zupełnie samodzielnym dziełkiem było dołożenie możliwości kontrolowania swapu do CyanogenMod Settings. Trywialna modyfikacja javowego kodu i jeden czy dwa skrypty w shellu. Nic skomplikowanego. Dołożenie obsługi CPUFreq było trochę bardziej pracochłonne (i nie obyło się bez pomocy Joëla Bourquarda – autora Titanium Backup) ale się udało :)

W międzyczasie SpeedTeam zawiesił działalność a XxKOLOHExX przeszedł do Biff Squad. Wersja 2.0 BiffModa była w całości oparta o moją kompilację i pewnie byłaby sukcesem ale RoyalKnight zdecydował się na inny kernel i trochę niefortunnie wkleił go w przygotowaną przeze mnie paczkę. Zdarza się a ja się czegoś nowego nauczyłem :) Potem był BiffMod 2.1 przygotowany przez Ezterry’ego, z jego kernelem i moimi dodatkami. Mogłem spocząć na laurach i grzecznie czekać na Gingerbreada.

I pewnie bym spoczął gdyby nie twitterowa rozmowa najpierw z Cyanogenem a potem Fireratem. Jakoś tak wyszło, że razem z Fireratem zajęliśmy się tzw natywnym apps2sdext. Do tej pory możliwość instalacji aplikacji na partycji Ext2/3/4 karty była realizowana przy pomocy skryptów shellowych i polegała na oszukiwaniu systemu co do faktycznej lokalizacji plików apk. Gdybym miał chociaż blade pojęcie jak skomplikowany to projekt pewnie bym sie nigdy nie odważył za to zabrać. Prace nad wbudowanym w system apps2sdext trwały dobrze ponad 2 miesiące. Choć rozwiązań kolejnych problemów poszukiwaliśmy wspólnie, to jednak gross rozwiązań znajdował Firerat. Wiele razy zdarzało się, że dłubaliśmy nad jakimś kawałkiem kodu i już miałem rozwiązanie problemu na końcu języka gdy Firerat zaćwierkał „Ok, I made it”. Nigdy go nie spytałem czy kiedyś przydarzyła mu się podobna sytuacja ale ze mną w roli głównej. Mam nadzieję, że tak :D jest w tym wszystkim ładnych parę linijek mojego autorstwa.

No dobra ale co to ma wspólnego z tytułem wpisu? Ermm… zdradzę pewną tajemnicę… Nie znam Javy. Serio! Nie znam Javy. Nigdy wcześniej nie używałem tego języka (jestem przecież adminem a nie programistą!). Tymczasem całe to apps2sdext wymagało grzebania w jednym z kluczowych komponentów (framework.jar) napisanym w całości w Javie. Dziesiątki razy oglądałem kawałek kodu, dopisywałem kawałek kodu i bez przerwy odpytywałem Google na okoliczność składni tego czy innego polecenia Javy. Sprawdzałem dostępne funkcje, metody i temu podobne sprawy. O, właśnie! Metody! Dodatkowym smaczkiem jest to, że nigdy wcześniej nie pisałem niczego w jakimkolwiek obiektowo zorientowanym języku programowania :) Największym zaskoczeniem dla mnie jest to, że #LearningJavaUsingGoogle działa! :P Nie wierzysz? To zerknij na

• Zupełnie prywatne repo NLJota ;)
• Coś jak oficjalne repo NLJota :)

Miłego haczenia Androida!!

NameLess
the Jedi

W moim własnym mniemaniu jestem geekiem czy też nerdem. Jedną z cech idących w parze z geekowatością jest gadżetomania. Uwielbiam gadżety. Najbardziej te realne ale czasem trafia się taki bardziej wirtualny. Pierwszy raz zwrócił moją uwagę w postaci maila na liście debian-mentors albo debian-devel. W pierwszej chwili pomyślałem, że to trochę głupie. Pierwsze wrażenie jednak mnie zwiodło.Gadżet zwie się blueproximity. Idea jego działania zasadza się na sprawdzaniu dystansu między dwoma urządzeniami  BT. Jednym z nich jest komputer, drugim – na przykład telefon komórkowy. Po co to? Na przykład można automatycznie zablokować sesję w komputerze, w chwili gdy telefon komórkowy oddali się od komputera. Dla kogoś patrzącego na to z boku wygląda jakby komputer wykrywał (nie)obecność właściciela. Sprytne, nie?

Od razu podkreślę jedną rzecz. Bezpieczeństwo komputera może na tym ucierpieć. W domyślnej konfiguracji blueproximity nie tylko blokuje ekran, gdy się oddalisz, ale również odblokowuje sesję bez pytania o hasło, gdy się pojawisz w pobliżu.  Podobnie jak przy innych technikach sieciowych, tak i tu, można się, w miarę łatwo, podszyć pod telefon. Dobrze jest więc wyłączyć widoczność urządzenia w menu telefonu.

Sam programik jest banalny tak w obsłudze jak i w konfiguracji. Nie podam swoich ustawień, bo dla każdego zestawu nadajnik – odbiornik będą inne. Dojście do nich zajęło mi nie więcej jak 20 minut i trochę kręcenia się po pokoju =o)  Domyślnie blueproximity kontroluje gnome-screensaver, nic nie stoi na przeszkodzie by uruchomić dowolny inny programik czy skrypt. Parę przykładów można znaleźć pod koniec tego postu.

Czasem fajnie pracować w dużej firmie. Jednym z pożądanych efektów ubocznych jest możliwość wymiany służbowego laptopa na nowszy model (stary ma całe 3 lata! :) ) Ten stary laptop to Dell Latitude D800. Początkowo chciałem, żeby ten nowy był mniejszy i lżejszy. Tylko początkowo na szczęście.

Model wybrał właściwie mój przyjaciel z pracy. W pierwszej chwili właściwie nie byłem jakoś b. zadowolony. Notebook waży prawie 4 kg (a w sumie to nawet nie jestem pewien czy nie więcej). Zwyciężyło jednak moje gadżeciarstwo: 17″ matryca 1920×1200, 2GB RAM i Core2Duo T7700, o pełnowymiarowej klawiaturze nie wspomnę. Czyż nie robi wrażenia? No, tak… nie, no… jasne… to tylko laptok przecież. Aaaa tam! Na mnie robi wrażenie i to jak cholera! Pierwszy raz w życiu stwierdziłem, że mam wystarczająco dużo miejsca na pulpicie!

Domyślnie, mój Inspiron, miał zainstalowane 32-bitowe Windows Vista Ultimate. Takie kurczowe trzymanie się starej architektury (choć jeszcze nie przestarzałej) trochę mnie dziwi, ale to jest Windows właśnie ;) Vista została obejrzana przez domowników (Kasia – moja żona – spędziła masę czasu grając w pasjansa :) a następnego dnia zainstalowałem XP. Na mniej-więcej 1/3 powierzchni dysku. Na starym laptopie cały dysk miał trochę mniejszą pojemność. Ta windziana część jest mi potrzebna tylko pod VPN-a (CheckPoint-owy klient nie zmienił się od 4 czy 5 lat…. a Linux w międzyczasie trochę się jednak zmienił). No ok, jakieś gierki pewnie też tam wylądują ;)  W końcu GeForce 8600M GT zobowiązuje. Hihihi! Właśnie zdałem sobie sprawę, że jak na razie to całkiem nieźle idzie mi chwalenie się nową zabawką. Nie ma jeszcze tygodnia!

Pozostałe 2/3 dysku to tereny należące do Linuksa. Konkretnie – Debiana. Lubię ten system. Jakoś tak swobodniej się w nim czuję. Jestem jednym z tych dziwów przyrody, które używają Linuksa dłużej niż MS Windows. Dawno już zaplanowałem, że zainstaluję 64-bitową  wersję Debiana. Szkoda tylko, że ta instalacja nie jest niestety jakimś wyczynem. Wszystko czego potrzebuję jest już przygotowane i podane na tacy. Przy okazji instalacji zaskoczyła mnie jedna rzecz. Windows XP SP2 potrzebował dociągnięcia z sieci sterowników do karty graficznej by móc wyświetlić pulpit w pełnej rozdzielczości. Kaszi rzucił nawet w trakcie instalacji, że w życiu nie widział tylu żółtych pytajników na liście sprzętu (dla niezorientowanych – oznaczają one, że brak jest w systemie sterowników). Wszystkie te sterowniki oczywiście są dostępne ale trzeba je było z mozołem wydłubać ze strony Dell-a (uwierz na słowo –  nie jest to proste). Debian (w każdym razie wersja, której użyłem do instalacji) jest oczywiście sporo nowszym systemem ale jest też zupełnie darmowym systemem operacyjnym. Po instalacji, laptop zrestartował się i po chwili zobaczyłem ekran logowania w pełnej rozdzielczości matrycy. Przyznam się, że zaskoczyło mnie to. Zaskoczenie było tym większe, że dosłownie kilka minut wcześniej zakończyłem instalację XP na dokładnie tym samym sprzęcie. Instalator sam rozpoznał typ karty i wybrał odpowiednią dla matrycy rozdzielczość. Darmowy sterownik kart Nvidii dla Linuksa nie ma wsparcia dla grafiki 3D ale do prac biurowych nadaje się znakomicie. Binarny sterownik oferowany przez Nvidię oczywiście daje pełne wsparcie dla 3D a jego instalacja sprowadza się odnalezienia właściwego pakietu w aptitude. No, prawie… ale to jest Debian, jak chcesz mieć jeszcze prościej to polecam Ubuntu. Trochę wyszła mi laurka dla Linuksa/Debiana. Szkoda, że Debian, czy też Linux w ogóle, nie jest gotowy by hurtem zdobyć desktopy. Żeby było śmieszniej najbardziej winny jest temu sam Linux. Desktop musi być łatwy w obsłudze i wszystkie bajery i gadżety nowoczesnego komputera (WiFi, Bluetooth, Intel HDAudio itp itd) powinny być dostępne na pstryknięcie. Typowa instalacja Linuksa wymaga jednak jeszcze grzebania w plikach konfiguracyjnych. Ta potrzeba grzebania w setkach plików schowanych w /etc/ maleje z każdym dniem czy tygodniem ale i tak w świadomości typowego użytkownika Linux jawi się jako diabeł wcielony. Siła Linuksa – duża swoboda konfiguracji, łatwość edycji plików konfiguracyjnych – jest dokładnie tym, co powstrzymuje dżihad na desktopach. Drugą rzeczą hamującą ekspansję jest brak gier. Gier nie ma, bo nie ma jednego Linuksa (jest RedHat Linux, Debian GNU/Linux, Mandrake, Slackware, Ubuntu itp itd). Wydawcy po prostu nie wiedzą jak mają te nieszczęsne gry na Linuksa wydawać.

Znowu zboczyłem z tematu. Po instalacji przerzuciłem swoje katalogi domowe ze starego lapcia na nowy i… mogłem już pracować na nowym. Trochę mi się zeszło z podłączeniem do domeny windowsowej ale bardziej dlatego, że chciałem spróbować „ominąć” adminów domenowych. Nie udało sie. W sumie migracja zajęła mi jeden dzień. Te 24 godziny to czas jaki zajęło mi przejście z 32-bitowego systemu operacyjnego na 64-bitowy. Przejście to było nadspodziewanie łagodne i bezproblemowe. Niektóre rzeczy działają nawet jakby stabilniej (OpenOffice! Poprzednio OOwriter wykładał się na losowo wybranym doc-u, na 64 bitach nie wysypał się nawet raz).

Ale się rozpisałem! Zdaje się, że parę razy wątek zgubiłem ;) Nic to. To jest blog przecież :)