Oggi ho creato i miei primi calendari multipli, per tenere suddivisi gli impegni di ambiti diversi.

Per tenere sincronizzati tutti i calendari su iphone segnalo questa utile miniguida: http://robertoventurini.blogspot.com/2009/02/sincronizzare-calendari-multipli-google.html

Tutto questo grazie al lavoro di adriano

Ho provato entrambe le soluzioni, e alla fine ho scelto finit-arc perchè 1) mi consente di fare il boot “alla vecchia maniera” in caso di necessità e 2) è risultato anche più veloce di quick-init.

Cronometro manuale alla mano (nessuna voglia di installare bootchart) ora l’eeepc 901 di cui dispongo fa il boot da grub a X in circa 8 secondi.

Utilizzo un kernel che compilo personalmente (si tratta di un vanilla + zen), senza immagine di init e con tutti i moduli statici eccetto ethernet, wlan e eeepc_laptop.
In particolare, eeepc_laptop impiega più di 10 secondi a caricarsi, quindi l’ho aggiunto a /usr/sbin/services.sh per farlo caricare in background.

Questo il services.sh attuale:

#!/bin/sh

#Starts udev events
/sbin/udevd --daemon &>/dev/null &
/sbin/udevadm trigger &>/dev/null &
/sbin/udevadm settle &>/dev/null &

#Make swap (not for ssd)
/sbin/swapon -a &

#Starting background daemons
/etc/rc.d/syslog-ng start &>/dev/null &
(/etc/rc.d/hal start && /etc/rc.d/wicd start) &> /dev/null &
modprobe eeepc_laptop &
echo "24 17 15 15" > /sys/devices/system/cpu/cpu0/cpufreq/phc_vids &
echo "24 17 15 15" > /sys/devices/system/cpu/cpu1/cpufreq/phc_vids &

per disabilitarlo in about:config

browser.ctrlTab.previews va impostata a false

Link al thread: http://forum.emesene.org/index.php/topic,1913.0.html

Gli arcieri trovano già il pacchetto emesene-crazy in aur.

“Arch Linux 2009.02. Ma quanto belli siamo?”

happy arch day e baci a tutti, arcieri e ubuntisti. kiss.

Un po’ di noia in meno, un po’ di tempo in più da dedicare a cose ben più divertenti (archlinux? ).

E’ pur sempe richiesta una patch nel kernel, ma almeno adesso non è richiesto ext3 come fs.

Conto di metterci le mani sopra quanto prima!

A dire il vero ho scoperto ora per caso che esiste in aur il pacchetto del solo modulo acpi-cpufreq per il kernel -ARCH, già patchato.

Quindi anche chi usa il kernel -ARCH può rimpiazzare quel modulo installando il pacchetto da aur e avvalersi del downvolting.

W aur!

Link: http://aur.archlinux.org/packages.php?ID=18310

La bella notizia è che anche l’atom può essere downvoltato, e l’altra bella notizia è che la patch phc (già integrata in zen) lo supporta già.

La mezza cattiva notizia è che non si può abbassare il voltaggio della cpu quando ha moltiplicatore minimo. Ovvero a 0,8Ghz il voltaggio minimo è quello di default.

Per ora me la sono cavata con l’aggiunta in rc.conf di queste due righe:

echo “24 17 15 15″ > /sys/devices/system/cpu/cpu0/cpufreq/phc_vids
echo “24 17 15 15″ > /sys/devices/system/cpu/cpu1/cpufreq/phc_vids

Con il tempo vedrò se i voltaggi vanno bene.
La ventolina al massimo potrebbe essere un ricordo

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”.

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.

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.

Bippa da morire, maledetto

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.

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.

Pazzesco

Ah, eeepc 901 powered by arch

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

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.

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.