pierloz.com

Dopo svariati mesi di uso la mia copia di firefox risultava parecchio “appesantita”. Tempi di avvio piuttosto lunghi (così come anche di chiusura), frequenti stalli durante l’uso (soprattutto nei primi minuti) e altre cose noiose.

A quanto pare il colpevole è il file places.sqlite presente nella directory del profilo (solitamente ~/.mozilla/firefox/qualchecaratterecasuale/).

Il mio è arrivato a pesare 21 MB, non poco considerato che è un database plain text e che viene acceduto molto spesso da firefox.

Con firefox non in esecuzione l’ho rinominato. In teoria quel file contiene non solo la cronologia ma anche i segnalibri. Di questi ultimi però firefox fa dei backup automatici. Facendo ripartire firefox dopo aver rinominato place.sqlite infatti ho ritrovato i segnalibri così come li avevo lasciati, e ovviamente la cronologia azzerata.

Ma la cosa più importante è che finalmente firefox è tornato ad avere prestazioni più che decenti, oserei dire quasi “da primo avvio”.

Per una volta mi trovo a scrivere qualcosa che riguarda l’ambiente Windows (e non è poi un caso, visto che nonostante non ne sia un utente, il 95% delle richieste di assistenza mi arriva da macchine Windows).

Questa volta si trattava di un rootkit, prontamente rilevato dallo scanner di AVG anti rootkit, che si presentava nella forma di un driver (.sys) nella cartella (su Windows le directory si chiamano così!) system32/drivers.

Tale rootkit non solo provocava il crash della macchina dopo N minuti di connessione alla rete, ma impediva anche la navigazione (presumo risolvendo i domini in locale) verso i siti di prodotti antivirus, verso il sito microsoft e chissà che altro.

Il maledetto driver resisteva ai tentativi di rimozione con lo stesso AVG, e anche un salto in un più rassicurante live cd linux si è rivelato inutile: il file incriminato non risultava presente sul disco.

In effetti questo file cambiava nome ad ogni boot, e ad ogni scansione veniva rilevato con un nome (casuale) diverso.

Qualche ricerca in google mi ha portato su alcuni forum dove si incolpava Daemon Tools. L’ho disinstallato dalla macchina ed effettivamente era quello. Strano però, considerato che quell’installazione di Daemon Tools esisteva da quasi un anno ormai e non aveva mai dato di questi problemi.

E ora? bye bye Daemon Tools, alla ricerca di un software alternativo.

Sul forum inglese di arch (e non solo lì) diversi utenti si sono lamentati di un calo di prestazioni dei driver video intel.

Ho voluto verificare se il consiglio di utilizzare XAA come AccelMethod sia valido.

Ho usato il bechmark gtkperf per controllare le prestazioni dell’intel 945GME integrata nell’eeepc 901.

Ecco i risultati per quanto riguarda XAA:

GtkEntry – time: 0,15
GtkComboBox – time: 2,30
GtkComboBoxEntry – time: 1,47
GtkSpinButton – time: 0,28
GtkProgressBar – time: 0,21
GtkToggleButton – time: 0,42
GtkCheckButton – time: 0,28
GtkRadioButton – time: 0,66
GtkTextView – Add text – time: 2,07
GtkTextView – Scroll – time: 0,70
GtkDrawingArea – Lines – time: 1,81
GtkDrawingArea – Circles – time: 3,98
GtkDrawingArea – Text – time: 5,76
GtkDrawingArea – Pixbufs – time: 0,28
—
Total time: 20,37

e per quanto riguarda EXA:
GtkEntry – time: 0,15
GtkComboBox – time: 2,33
GtkComboBoxEntry – time: 1,42
GtkSpinButton – time: 0,27
GtkProgressBar – time: 0,21
GtkToggleButton – time: 0,38
GtkCheckButton – time: 0,28
GtkRadioButton – time: 0,73
GtkTextView – Add text – time: 2,22
GtkTextView – Scroll – time: 0,92
GtkDrawingArea – Lines – time: 2,39
GtkDrawingArea – Circles – time: 5,45
GtkDrawingArea – Text – time: 5,03
GtkDrawingArea – Pixbufs – time: 0,28
—
Total time: 22,07

Infine, EXA con opzione “MigrationHeuristic” “greedy”

GtkEntry – time: 0,12
GtkComboBox – time: 2,07
GtkComboBoxEntry – time: 1,69
GtkSpinButton – time: 0,28
GtkProgressBar – time: 0,24
GtkToggleButton – time: 0,47
GtkCheckButton – time: 0,24
GtkRadioButton – time: 0,68
GtkTextView – Add text – time: 2,27
GtkTextView – Scroll – time: 0,89
GtkDrawingArea – Lines – time: 2,45
GtkDrawingArea – Circles – time: 5,71
GtkDrawingArea – Text – time: 18,29
GtkDrawingArea – Pixbufs – time: 0,55
—
Total time: 35,96

Come si può vedere, XAA risulta il più performante, seguito a ruota da EXA, mentre EXA con l’opzione “greedy” risulta molto molto più lento (eppure viene consigliata in certi siti).

Sembra però che con la recente inclusione del GEM di intel (graphics execution manager) nel kernel 2.6.28, EXA (o meglio, il nuovo UXA) migliorerà al punto da essere finalmente più veloce di XAA.

Non tentare di aggiornare il bios di un eeepc nel cuore della notte, a meno di non essere soli.

Bippa da morire, maledetto

Oggi pomeriggio ho voluto sperimentare sreadahead sull’eeepc 901.

Prima cosa da fare è stato portare la patch da ext3 a ext2, visto che sul piccolino ho scelto ext2 come filesystem per la root.

Considerato la diretta discendenza di ext3 da ext2, è stato molto semplice prendere la patch di sreadahead scritta per ext3 e crearne una per ext2.

Ho poi ricompilato il kernel (lo zen presente nel repository di robertek), ovviamente con l’aggiunta della patch appena scritta.

Ora ho sreadahead funzionante, anche se a onor del vero non vedo nessun incremento di velocità di boot (ovvero, anche senza sreadahead, sono sempre sotto i 20 secondi compreso ambiente grafico openbox+lxpanel+qualche_altra_robetta).

Mi resta da togliermi lo sfizio di guardare un bootchart, perchè stranamente bootchart non vuole funzionare.

A presto per altre osservazioni.

Eccomi a scrivere un paio di righe, ovviamente le sto scrivendo dal piccolo eeepc901 finalmente animato da una aggiornatissima archlinux

I dettagli li rimando, lascio solo un breve resoconto dell’installazione e della prima configurazione.

Partizioni Originarie

Il disco principale dell’eeepc (4 GB) si presenta partizionato in 4 partizioni. Le prime due sono utilizzate da xandros (di cui una in sola lettura). Le restanti 2 sono due piccole partizioni di circa 8 MB (mega!), una utilizzata per eventuali aggiornamenti bios (è possibile copiarci li il file del bios e al boot questo verrà aggiornato), e l’altra utilizzata per la funzione fastboot del bios.

Io ho piallato tutto eccetto l’ultima partizione, visto che il fastboot è assai splendido

Eventuali aggiornamenti del bios li farò passare da una pennetta usb.

Installazione di arch

Ho usato un masterizzatore dvd usb e l’iso di test 2008.12, per installare un sistema base.

Ho creato un’unica partizione nel disco da 4GB (eccetto quella per il fastboot) e l’ho formattata in ext2.

Niente swap.

Ho in seguito utilizzato la connessione ethernet (il modulo era già presente nel kernel) per compilare il modulo wifi (rt2860, si trova in AUR).

netcfg ha qualche problemino a funzionare. Seguendo il consiglio del wiki di arch ho optato per wicd.

Xorg funziona splendidamente senza dover scrivere nessun file di configurazione. Nota: ricordarsi di installare hal e aggiungerlo ai demoni, altrimenti xorg parte senza le periferiche di input e bisogna riavviare la macchina.

Improving it!

Tra le prime cose che ho fatto, ho montato un tmpfs in /tmp e lì ci ho fatto anche cachare (non è una brutta parola!) firefox.

Oggi ho un po giocato con i kernel di robertek, uno zen ricompilato su misura (oserei dire “striminzito”, sono 5MB) per il 901.

Installato il kernel zen-eee dal suo repo, ho installato anche acpi-eee901, che contiene gli script acpi per gestire i tasti funzione. Contiene anche il programma asusosd, che lanciato all’avvio di openbox mi da un riscontro visivo con un popup quando alzo/abbasso volume e luminosità.

Successivamente ho ricompilato il kernel zen-eee per includere un po di moduli che non so per quale motivo erano stati lasciati fuori.

A breve scrivero di qualche altro pasticcio, e di tutto quello che causa dimenticanza e fretta ho sicuramente dimenticato di dire.

E’ semplicemente assurdo quanto veloce sia pacman con ext2 su una SSD.

Pazzesco

Ah, eeepc 901 powered by arch

Due giorni fa mi è stato consegnato l’eeepc 901 che avevo ordinato il primo dicembre da Wireshop.

Ovviamente ho scelto la versione Linux, e non solo perchè ha una SSD più capiente, ma anche per dimostrare come consumatore il mio apprezzamento verso il pinguino.

Prime veloci impressioni:

• è piccolo! però si mantiene ancora utilizzabile. La tastiera richiede un minimo di pazienza per adattarcisi. Questo post lo sto scrivendo proprio dalla sua mini tastiera, e non ho grosse difficoltà.
• Lo schermo mi piace: molto luminoso ma utilizzabile anche a livelli di luminosità bassi (con miglioramento dell’autonomia della batteria). La risoluzione è sufficiente per lavorare, forse è un po’ troppo alta per le dimensioni del display, però questo fa si che la densità di pixel sia molto alta e così l’immagine appare molto nitida.
• Xandros non è poi così male. Sarà giocattoloso e tutto il resto, però il suo sporco dovere lo fa, e anche l’integrazione con l’hardware è ottima: tasti funzione perfettamente funzionanti e con feedback visivo (popup)

Altre cose le scriverò in seguito.

A causa di altri impegni, non sono ancora riuscito a smanettarci come vorrei (qualcuno ha detto arch?). Da sabato però il piccolino dovrà sopportare una lunga serie di esperimenti

Rilasciate le iso di test 2008.12

info: http://downloads.archlinux.de/iso/archboot/2008.12/

Non è una release ufficiale, sono in test, però possono tornare utili a chi serve un cd di installazione con l’ultimissimo kernel.

Negli ultimi due giorni mi sono interessato alla faccenda del famigerato boot in 5 secondi (quel famoso proof of concept uscito a settembre, per mano dell’altrettanto noto arjan… qualcuno ha detto powertop?)

Ovvero mi sono interessato a questo: http://lwn.net/SubscriberLink/299483/fa0208e48cf3eeac/

L’interesse è partito da un topic sul forum archlinux.it iniziato dal buon adriano (http://adrinux.wordpress.com/2008/12/04/boot-rapido-5-secondi-anche-su-archlinux/).

Per farla breve, fino ad adesso si è lavorato su questi due punti:

• inclusione nel kernel -ARCH della patch fastboot, che riduce il tempo di avvio del kernel facendo alcune cose in modo asincrono
• inclusione di sreadahead negli script di init di arch (rc.sysinit in particolare) e con esso anche l’integrazione della patch a ext3 per marcare i file utilizzati in fase di boot (è necessaria una root in ext3)

A giudicare dai grafici bootchart di adriano fatti su una macchina reale (io per ora sto lavorando su una macchina virtuale), sreadahead fa il suo dovere.

Il tempo di boot però non pare ridursi così tanto, anzi si notano ancora delle pause indesiderate (in particolare nella fase finale, guardate nel topic del forum i grafici).

C’è dell’altro da fare con gli script di init, quasi sicuramente.

Aggiornamenti a seguire.