Stamattina (ora italiana) è finalmente stata rilasciata la nuova Debian stable, versione 5.0, codename Lenny.

Le novità rispetto alla “vecchia” Etch sono talmente tante da aver convinto i releaser a passare dalla versione 4.0 (etch, appunto) alla 5.0. Si va dal supporto hardware (naturalmente, visto l’aggiornamento del kernel) alle nuove versioni dei desktop environment (anche se non è stato ancora adottato KDE 4, ancora troppo instabile), passando per Xorg 7.3 che elimina quasi completamente la necessità del file xorg.conf (tranne in casi particolari). Nuove versioni anche per Apache 2.2, Samba 3, MySQL 5, Postgres 8.3, PHP 5.2, Python 2.5 e Java 6, finalmente open source e integrato nel ramo main della distribuzione.

La release è dedicata a Thiemo Seufer, morto in un incidente stradale il 26 dicembre 2008.

Uso sul campo

Sto usando Lenny su tutti i “desktop” praticamente da quando è uscita Etch. Gli aggiornamenti sono sempre stati più che giornalieri, ma non ricordo nessuna situazione di rottura di dipendenze. Alcuni programmi sono stati un po’ instabili per 1-2 giorni, ma poi sono stati sistemati. E negli ultimi mesi, da quando è in deep freeze, è stata praticamente una roccia. Questo mi ha spinto ad iniziare a installarla anche su un paio di server, e non me ne sono pentito.

Ora dovrò aggiornare anche tutti gli altri server, e onestamente ci sono un paio di aggiornamenti che mi fanno un po’ paura (PostgreSQL e MySQL vista la rogna di ripristinare i backup in caso di problemi), ma il passaggio Sarge -> Etch è stato adrenalinico ma assolutamente liscio (leggendo le release notes attentamente), quindi mi aspetto di non faticare poi molto.

La prossima release

Come ormai risaputo, la prossima versione si chiamerà Squeeze e, se tutto va come di recente, dovrebbe uscire come stable intorno al 2011-2012, anche se ci sono discussioni nel team Debian che spingono ad accelerare un po’ i tempi di rilascio.

In ogni caso, come già successo per Etch, ci saranno sia volatile.debian.org per i pacchetti che hanno bisogno di aggiornamenti frequenti (come clamav) che lenny-and-a-half, con aggiornamenti al kernel e ad altri componenti, per mantenerla al passo coi tempi.

E, naturalmente, i consueti aggiornamenti di sicurezza costanti che fanno di Debian una delle distribuzioni (se non “la distribuzione”) più stabili e sicure.

Per chi usasse, come me, la versione testing sui vari PC, consiglio di aspettare qualche giorno/settimana prima di impostare “squeeze” nel sources.list (e di impostare “lenny” se avete scritto “testing”). Questo perché in unstable e in experimental negli ultimi mesi si sono accumulate tonnellate di nuove versioni di software, che potrebbero riversarsi nella testing e presentare problemi di dipendenze o di stabilità. Dategli il tempo di assestarsi.

Negli ultimi due giorni ho visto almeno 3 blog riportare la “sensazionale notizia” che Debian Lenny verrà rilasciata a giugno del 2009, contrariamente alla roadmap che lo prevedeva per settembre 2008.

Chiariamo subito una cosa: Debian NON HA una roadmap. Debian NON HA date di rilascio fissate.

Debian ha un processo di freeze della distribuzione. Quando sembra il momento adatto, viene fatto un freeze: nella versione “testing” non entrano più nuove versioni dei pacchetti, ma solo correzioni alle versioni presenti in quel momento. Da lì parte il lavoro di debug in base alle segnalazioni nel bugtracker, vengono definiti i cosiddetti RC-bugs (Release Critical bugs) e devono essere risolti tutti prima che la “testing” diventi “stable”.

Se un bug non è risolvibile, il pacchetto viene rimosso dalla nuova stable, ed eventualmente reintrodotto nella “unstable” (e poco dopo nella nuova “testing”) dopo il rilascio della stable.

La fonte della disinformazione

Come fonte di questa notizia, i blog riportavano un articolo su TheRegister.

Peccato che non abbiano letto bene l’inglese. In quell’articolo c’è scritto che Steve McIntyre (project leader attuale di Debian) “has dismissed claims” che la nuova versione verrà rilasciata a giugno. Dismissed significa “negato”, non “confermato”…

Bastian Venthur, uno sviluppatore Debian, si era divertito oltre due mesi fa (1 agosto) a disegnare un grafico con la velocità di soluzione degli RC-bugs e, per interpolazione, aveva calcolato che Lenny sarebbe stata rilasciata a giugno 2009. All’epoca c’erano circa 400 RC-bug aperti.

Bene, peccato che già una settimana fa (7 ottobre) Alexander Reichle-Schmehl nel suo blog riportasse la notizia che degli oltre 200 bug ancora aperti, 118 erano già corretti e dovevano solo entrare in Lenny, 33 avessero già una patch da applicare e ne rimanessero quindi solo 104.

L’articolo su TheRegister è del 10 ottobre. I blog l’hanno riportato tra ieri e oggi (13 e 14 ottobre).

Quando si dice il tempismo!

Ma allora quando esce?

Come ho detto, quando è pronta.

La filosofia di Debian è sempre stata questa. L’importante non è rispettare una data, ma far uscire una distribuzione senza bug critici, che funziona e che si installa sul maggior numero di architetture possibile. Perfetta per un server.

E non ci saranno problemi legati all’uso della versione beta di Firefox 3 o alla Release candidate del kernel 2.6.27 come in altre distribuzioni che si impongono di rispettare delle date di rilascio.

Se volete usare Debian su un client, è inutile aspettare la stable: sarebbe vecchia già al momento dell’uscita, per via dei 2-3 mesi di freeze. Usate la testing.

Se tutto va bene, potremmo vedere lenny stable già a fine mese, ma io credo arriverà a metà/fine novembre.

Per i curiosi, la prossima testing si chiamerà Squeeze.

Grazie al lavoro di Giggio, che, oltre a creare il pacchetto per Ubuntu di lxterminal ha anche modificato il sorgente in modo che le modifiche alla configurazione vengano applicate al volo, oggi vi presento un’altra versione di lxterminal.

Ma bando alle ciance, ecco i pacchetti da scaricare:

• Paccetto tar.gz (debianizzato)
• Pacchetto deb per Debian Lenny x86-32
• Pacchetto deb per Debian Lenny x86-64 (amd64)
• Pacchetto deb per Ubuntu 8.04 x86-32

Oltre ai pacchetti deb già pronti per l’installazione, potete scaricare il tar.gz dei sorgenti, già debianizzato, nel caso vogliate compilarlo da soli, fare altre modifiche o semplicemente se non vi fidate dei pacchetti già pronti.

Nella puntata precedente abbiamo visto come personalizzare sospensione e ibernazione, oggi vediamo come ho personalizzato Gnome per adattarlo al meglio alle caratteristiche dell’Eee. Per la maggior parte si tratta di modifiche estetiche o di preferenze personali, ma molte sono orientate a risparmiare spazio sullo schermo o anche ad allungare la durata della batteria.

Innanzitutto uno screenshot:

Come potete vedere, ho eliminato la barra in alto (lo schermo è già abbastanza “basso” di suo). Ho quindi proceduto a configurare il pannello in basso. Right-click sul pannello e Proprietà richiama la finestra di configurazione. Qui ho selezionato Orientamento ->Basso, Dimensione -> 21pixel (il minimo), Espandere -> attivo, Nascondere automaticamente -> non attivo, Mostrare i pulsanti di riduzione -> non attivo, Sfondo -> Nessuno.

Per chi volesse ancora più spazio, può selezionare “Nascondere automaticamente”, oppure attivare i pulsanti di riduzione, che permettono di ridurre il pannello a pochi pixel a destra o a sinistra, e farlo riapparire cliccando su quello che rimane dopo la riduzione. Provate un po’ di configurazioni e vedete come vi trovate meglio.

Per i più “fissati” con OSX, si può anche installare Avant Window Navigator, che fornisce una barra come quella di OSX, a scomparsa. Io ho puntato sul minimalismo.

Le applet installate, da sinistra a destra, sono “Menu principale” (non “Barra dei menu” che occupa molto più spazio), “Variazione frequenza CPU” per monitorare le variazioni dinamiche della frequenza CPU, “Mostra scrivania”, per tornare velocemente al desktop (sto pensando di toglierla, non la uso mai), “Selettore area di lavoro” più per vedere dove sono e quali workspace sono occupati che per passarci, visto che ho impostato degli shortcut (mi sono limitato a 4, di solito ne uso 10 sul fisso… ), quindi c’è “Elenco finestre” che occupa gran parte dello spazio, configurato per mostrarmi solo le finestre del workspace corrente e, a destra, “Area di notifica”, che ora contiene le notifiche della batteria e del WiFi di NetworkManager, quindi “Volume” per controllare il volume delle casse, “Lock Keys” per monitorare CAPSlock e NUMlock, in quanto la tastiera non ha i led (va installata a parte, pacchetto lock-keys-applet), e infine il banale “Orologio”,.

Con questa configurazione, con Nautilus attivo, dopo il login (automatico con GDM) la RAM occupata è intorno ai 150 MB.

Perché non LXDE?

Ho provato anche lxde, che sta crescendo velocissimamente, ma non mi soddisfava pienamente. Per esempio non era ancora pronta l’applet per monitorare NetworkManager (ho visto che recentemente ne è entrata  una in Debian, ma va in conflitto con NetworkManager), e il pcmanfm non montava automaticamente i dispositivi mobili.La configurazione, poi, è sparsa per troppe interfacce (quella di lxpanel, quella di openbox) e a volte richiede di modificare manualmente file di testo, come per gli shortcut da tastiera di openbox.

Inoltre il risparmio di RAM rispetto a Gnome era di una trentina di MB, quindi ho preferito quest’ultimo che ha molte più funzionalità. Ma sicuramente riproverò lxde a breve. Per ora gli ho “rubato” lxterminal, che uso al posto di gnome-terminal, perché molto più veloce ad aprirsi e risparmioso di RAM, anche se ha un buffer ridottissimo e il tasto F10 hardcoded per aprire il suo menu, cosa che mi dà qualche problema con mc (risolto usando Esc-0 al posto di F10 per uscire).

Personalizzazioni nascoste

Quello che non si vede dallo screenshot è la configurazione delle scorciatoie da tastiera. Sono una caratteristica che trovo fondamentale, soprattutto per un notebook. La possibilità di fare più cose possibile senza staccare le mani dalla tastiera per raggiungere il touchpad (una delle periferiche più scomode mai inventate, secondo me) fa risparmiare moltissimo tempo e permette di concentrarsi meglio sul proprio lavoro.

Una delle cose che non sopporto di Gnome e KDE, e in generale delle nuove interfacce su Linux, è la mania di copiare Windows, e quindi di assegnare, per esempio, Alt-F4 alla chiusura della finestra corrente. Alt-F4, da che Unix è Unix, serve a passare alla console numero 4, quindi ho assegnato da Alt-F1 a Alt-F4 per passare ai rispettivi workspace, relegando a Home-F4 (Home è il tasto con la casetta, equivalente del tasto finestra delle tastiere Windows-oriented) la funzione di chiusura e di conseguenza tutte le altre funzionalità sulle finestre, da Home-F2 a Home-F9.

Ho impostato Home-F11 per attivare lo stato di massimizzazione della finestra, e F11 (come di default) per la modalità a tutto schermo. In questo modo ingrandisco velocemente qualsiasi finestra, sia che lo supporti (come Firefox) sia che non lo faccia. La differenza tra i due è che con Home-F11 rimangono visibili la barra del titolo della finestra e il pannello di Gnome, mentre con F11 sparisce tutto, e rimane solo in contenuto della finestra, facendo guadagnare una cinquantina di pixel in verticale.

Come dicevo, Alt-F1 passa al workspace 1, quindi Shift-Alt-F1 sposta (to shift = spostare, in inglese) la finestra corrente al workspace 1. E Alt-Left e Alt-Right (tasti cursore) vanno al workspace a sinistra e a destra, quindi Shift-Alt-Left e Shift-Alt-Right spostano la finestra di conseguenza.

Ho invece lasciato di default l’Alt-Tab per cambiare finestra attiva, mentre ho impostato su Home-D il “Mostra desklop” (ecco perché voglio togliere l’applet).

Ed ora i problemi

Nella sezione “Ambiente grafico” del configuratore di shortcut, si possono impostare solo i tasti per mostrare “Esegui applicazione” e per aprire un terminale tra le applicazioni lanciabili. Per questi due ho scelto Home-X e Home-T, rispettivamente. Ho lasciato Stamp per catturare schermate e Alt-Stamp per catturare screenshot di finestre, mentre ho impostato il tasto Menu (quello tra AltGr e la freccia a sinistra) per mostrare il menu del pannello.

Tutte le altre associazioni (visualizza manuali, calcolatrice, email, browser, cartella home, cerca) vengono impostato della sezione “Desktop”. E qui c’è un bug. Di gnome-settings-manager, per la precisione.

In particolare, questi shortcut funzionano solo se li associate a combinazioni con Ctrl, Shift e Alt, mentre se cercate di usare AltGr, Home o (volendo configurarlo apposta) Menu, non lo potete fare. L’interfaccia vi farà credere di averlo fatto, ma poi il daemon che dovrebbe intercettarli non li riconosce.

C’è un bug aperto dal 2005 (!!) sul bugtracker di Gnome, ma sembra che sia stato finalmente risolto solo con Gnome 2.23.5 (appena rilasciato), che però è una versione per sviluppatori, quindi per averlo in Debian dovremo aspettare Gnome 2.24. Considerando che Lenny è in freeze e uscirà come stable, forse, a settembre, e che Gnome 2.24 dovrebbe essere contemporaneo, forseforse avremo il tutto nella prossima testing, secondo me intorno a dicembre/gennaio.

Per ora ho dovuto impostare combinazioni con Shift-Ctrl-tasto (F1 per i manuali, C per la calcolatrice, M per le mail, W per il browser, H per la home e F per la ricerca).

Tema

Il tema che ho scelto è un miscuglio.

In particolare uso Clearlooks per i controlli (Crux era troppo scuro per i miei gusti, e Murrina-Tangoesque non mi piace), che mi permette anche di personalizzare i colori di alcuni componenti del desktop.

Anche i bordi delle finestre sono Clearlooks, perché preferisco il tasto di chiusura a sinistra e tutti gli altri a destra, e non tutti i temi permettono di farlo. Sto pensando di passare a Murrine che uso con soddisfazione sul fisso, anche se ho paura che sia un po’ più pesante di Clearlooks.

Per avere il tasto di chiusura a destra, bisogna aprire l’editor della configurazione e modificare in /apps/metacity/general la voce button_layout. La mia è “close:menu,minimize,maximize”, ma potete impostarla come preferite. Io sono abituato all’Amiga.

Le icone sono le classiche Tango, esteticamente belle ma senza essere troppo “fancy” come le NuoveTX o troppo simili ad altri S.O.

Il puntatore è quello standard.

Come caratteri uso “DejaVu Sans Condensed” da 7 punti per applicazioni, documenti e scrivania, la versione Bold dello stesso per i titoli delle finestre, e la “DejaVu Sans Mono Book” da 7 punti per la larghezza fissa. Per la resa a schermo ho selezionato “Ottimizza contrasto”, e in particolare, sotto “Dettagli” ho impostato il valore corretto di 133 punti per pollice per la risoluzione dello schermo, la Sfumatura a “Scala di grigi” e l’Approssimazione (hinting) a “Completa”.

I vostri gusti potrebbero essere diversi, e potreste, per esempio, volere la “Sfumatura subpixel”. Io non ne vado pazzo perché a volte mi capita di vedere le sfumature blu o rosse attorno ai caratteri.

Nella sezione “Interfaccia” delle preferenze di aspetto ho infine impostato di mostrare le icone nei menu e di mostrare solo le icone nelle toolbar, in modo da risparmiare spazio. Non ho ancora avuto la necessità di impostare le scorciatoie modificabili.

Nautilus

Ho configurato Nautilus (Menu->Sistema->Preferenze->Gestione dei file) in modo da usare di default la vista a elenco ordinata per nome, elencando le cartelle prima dei file, con un ingrandimento predefinito del 50%. Ho anche disattivato il pannello laterale delle finestre, e impostato la visualizzazione, nell’ordine, di Nome, Dimensione, Data di modifica, Permessi Ottali e Proprietario, in modo da avere nel minor spazio possibile il maggior numero di informazioni.

Ho quindi configurato le anteprime per non mostrarla per i file di testo, e solo per file locali inferiori a 100 KB per tutto il resto.

Ho quindi abilitato il “browser mode” di Nautilus andando in Menu->Strumenti di Sistema->Editor della configurazione e modificando in /apps/nautilus/preferences la voce “always_use_browser”, impostandola a true. Non mi piace la modalità spaziale di Nautilus, e mi piace ancora meno quando ho così poco spazio a disposizione sul desktop.

Già che ci siete (nell’editor della configurazione), potete anche impostare come preferite le icone sul desktop, alla voce /apps/nautilus/desktop. Io le ho impostate tutte a true: computer_icon_visible, home_icon_visible, network_icon_visible, trash_icon_visible, volumes_visible.

Network Manager

Se, come penso, usate l’Eee soprattutto quando siete in giro, e quindi vi collegate spesso a reti diverse, sia Ethernet che WiFi, la cosa migliore è lasciar fare tutto a Network Manager.

Installate quindi il pacchetto network-manager-gnome, che si porterà dietro le sue dipendenze, e, se vi servono, i pacchetti network-manager-openvpn-gnome e network-manager-pptp-gnome, utili per collegarsi via VPN (non mi è ancora successo di averne bisogno, ma averli non dà fastidio).

Quindi, da root, modificate /etc/network/interfaces per cancellare tutti i riferimenti alle reti, tranne quelli all’interfaccia “lo”. Il mio file è più o meno così:

auto lo
iface lo inet loopback

Tutto il resto verrà gestito da network manager. Quando attiverete la radio WiFi (con Fn-F2) si cercherà da solo le reti dosponibili, e quando attaccherete il cavo ethernet partirà automaticamente la ricerca di un IP tramite DHCP.

Con un RightClick sull’icona dentro la notification area e selezionando Edit Wireless Networks vi apparirà una finestra in cui potrete configurare anche i parametri per WEP e WPA, che verranno salvati nel portachiavi condiviso di Gnome (protetto da password), quindi non dovrete impostarli ogni volta che vi collegherete a quella rete (a meno di admin fannulloni che lasciano l’ESSID di default sull’access point…)

Retroilluminazione

Onestamente non ricordo se ho fatto modifiche sostanziali, ma una cosa molto utile per risparmiare batteria, e implementata in modo anche abbastanza gradevole, è la possibilità per Gnome di “giocare” con la retroilluminazione dello schermo.

La configurazione si raggiunge tramite Menu->Sistema->Preferenze->Gestione alimentazione, ed è suddivisa in “alimentazione da rete elettrica” e “alimentazione da batteria”, oltre alle impostazioni generali.

Alcune di queste voci le abbiamo già impostate “a mano” nello scorso post, lavorando con l’Editor di Configurazione.

Io ho impostato, tra le altre cose, di mostrare sempre l’icona nell’area di notifica e di non usare suoni per gli errori. Nell’alimentazione a batteria ho scelto di non mettere mai in pausa il computer, anche se inutilizzato, ma di mettere in pausa lo schermo dopo 15 minuti. Ho attivato anche la riduzione della retroilluminazione e l’oscuramento dello schermo quando inattivo. Nell’alimentazione da rete ho scelto di non mettere in pausa né il computer né lo schermo quando inattivo, e di impostare la luminosità al 70%, più che sufficiente per qualsiasi uso. Anche qui ho impostato di oscurare lo schermo quando inattivo.

L’effetto è un fade della retroilluminazione, che si abbassa quando non usate il PC e si rialza al livello precedente appena toccate un tasto o il touchpad.

Dopo aver configurato tutto l’harwdare nella puntata precedente, in questa puntata vediamo come attivare e soprattutto personalizzare la sospensione e l’ibernazione.

In realtà, avendo installato il pacchetto eeepc-acpi-scripts e uswsusp, ed avendo una partizione di swap già attiva, la sospensione dovrebbe già funzionare, ma a me il comportamento di default non piace molto, quindi mi sono messo a studiare cosa succede effettivamente durante queste fasi. Purtroppo alcune parti mi sono ancora oscure, e non sono riuscito ad ottimizzarle, ma qualcosa di nuovo l’ho imparato.

Mi devo scusare per il ritardo di questo articolo, ma mentre stavo per pubblicarlo sono stati aggiornati il kernel, gli script eeepc-acpi-scripts e anche gnome. Sono stato costretto a rivedere tutta la configurazione. Il lato buono è che ora è un po’ più preciso e dettagliato.

Configurazione di base

Innanzitutto avremo bisogno di una partizione di swap, visto che l’ibernazione (non la sospensione) ne ha bisogno.

Se ne avete creata una durante l’installazione, potete usare quella, altrimenti uswsusp supporta anche gli swapfile, quindi possiamo crearne uno con due semplici comandi (attenti a non sbagliare a scrivere qualcosa, qui si inizia a rischiare ). Date, da root:

dd if=/dev/zero of=/home/.swapfile bs=1M count=512
mkswap /home/.swapfile

In questo modo abbiamo creato un file nascosto (notate il punto davanti a swapfile) di 512 MB, posizionato nella partizione con le home, e l’abbiamo trasformato in un file di swap.

Ora la scelta sta a voi. La strada più facile è di utilizzare sempre questo file come swap, con il vantaggio che avrete 512 MB di memoria (virtuale) disponibile in più, ma con due svantaggi:

1. State usando una flash memory per la swap, che non è molto bello, perché aumenta notevolmente il numero di scritture
2. Se andate ad occupare la swap perché finite la RAM, l’ibernazione non funzionerà più, perché non ha spazio dove salvare l’immagine della RAM.

Usare sempre la swap

Se volete comunque procedere, almeno limitate al minimo l’uso della swap, editando il file /etc/sysctl.conf (sempre da root, come tutto quello che faremo oggi tranne la config di gnome) e scrivendoci una riga come questa:

vm.swappiness = 0

In questo modo il sistema userà la swap solo se veramente necessario. Infine aggiungete la swap in /etc/fstab per attivarla automaticamente ad ogni riavvio:

/home/.swapfile       none            swap    sw              0       0

Naturalmente questa riga va inserita DOPO la riga che monta la partizione /home (se avete scelto di partizionare come vi ho detto nelle puntate precedenti).

Usare la swap solo per l’ibernazione

Io ho preferito attivare la swap solo quando iberno il notebook, e disattivarla quando lo risveglio, in modo da evitare il più possibile gli svantaggi che ho elencato sopra.

Il pacchetto eeepc-acpi-scripts dipende già da pm-utils, che raccomanda uswsusp. Installateli entrambi, mal che vada vi dirà che sono già aggiornati:

aptitude install pm-utils uswsusp

Ora avrete una nuova directory di configurazione, /etc/pm, che contiene varie sottodirectory. Quella che interessa a noi è sleep.d. Creiamo qui dentro il file 00swap:

/etc/pm/sleep.d/00swap

 #!/bin/sh
case $1 in
        suspend|hibernate)
                mkswap /dev/sdb2
                swapon /dev/sdb2
        ;;

        resume|thaw)
                swapoff /dev/sdb2
        ;;
esac

Io ho usato una partizione, ma se avete creato lo swapfile come ho detto sopra, sostituite /dev/sdb2 con /home/.swapfile in entrambe le righe dopo hibernate e in quella dopo thaw.

La riga mkswap serve a ripulire la swap da eventuali immagini salvate in precedenza, in modo da evitare errori durante l’ibernazione.

Ho dovuto impostare la swap sia per hibernate che per suspend, perché pm-utils, quando si usa lo script pm-suspend-hybrid (che sospende e iberna, come vedremo dopo) richiama le opzioni per suspend/resume, e non quelle per hibernate/thaw. Non dovrebbero esserci controindicazioni, a parte un leggero rallentamento (qualche decimo di secondo) durante il suspend “puro”, e il fatto che si perde l’immagine dell’ultimo hibernate quando si va in suspend puro, ma non dovrebbe mai servirvi, a meno che non stiate facendo cose molto brutte.

I nomi vengono passati automaticamente dalle pm-utils quando parte l’azione corrispondente, quindi manteneteli così (suspend, hibernate, resume, thaw).

Basta solo questo file, in quanto gli script qui dentro vengono richiamati in ordine alfabetico durante la sospensione, e in ordine inverso durante il risveglio. Usando 00 all’inizio del nome del file, siamo sicuri che venga eseguito per primo al suspend e per ultimo al resume.

Uswsusp funziona in modo un po’ particolare. Appena parte l’ibernazione cerca di mettere in swap tutto il possibile, poi comprime la RAM e la salva sul resto della swap. Questo provoca uno strano effetto al resume: dopoche riappare la vostra schermata, la SSD “frulla” per un po’, a causa dello swapoff che riporta tutto il contenuto della swap in RAM per poi disattivare la swap. Il sistema rimane comunque usabile, e l’operazione non dura più di qualche secondo.

Ora editate il file /etc/pm/config.d/default. Il mio è così:

SLEEP_MODE="uswsusp"
SUSPEND_MODULES="snd_hda_intel,snd_pcm,snd,snd_page_alloc,ath_rate_sample,ath_pci,wlan,ath_hal"

Questo dice a pm-utils di usare uswsusp come metodo di sospensione, e di provare a rimuovere dal kernel i moduli elencati prima di sospendere o ibernare.

I moduli elencati qui davano problemi con linux-image-2.6.25-1-686, ma almeno il modulo audio sembra non abbia più bisogno di essere rimosso con la nuova linux-image-2.6.25-2-686 (versione 2.6.25-6. Ogni tanto Debian mi perplime…). Sto pensando di mettere qui anche il modulo per la ethernet (atl2), perché, anche se solo una volta, mi ha piantato l’Eee dopo il resume con il cavo ethernet collegato. Dovrò fare altri esperimenti.

Ricordatevi anche di rigenerare la configurazione di uswsusp e l’initrd:

swapon /dev/sdb2
dpkg-reconfigure uswsusp
swapoff /dev/sdb2

Bisogna attivare la swap prima di configurarlo, in modo che la trovi da solo, senza doverla specificare a mano. Naturalmente se avete scelto di mantenere la swap sempre attiva, i due passi non servono, e basta il dpkg-reconfigure.

E rispondete alle varie domande che vi fa. Selezionate la compressione della RAM, altrimenti il thaw sarà lentissimo. Non ho notato differenze sostanzial, invece, tra l’avere scritture preventive o non averle. Alle altre domande normalmente basta premere Invio.

Al termine della configurazione viene rigenerato l’initrd, quindi dovete riavviare per renderlo attivo.

ATTENZIONE!

Questa operazione (dpkg-reconfigure) va fatta solo la prima volta, o se cambiate la partizione o il file di swap. NON va fatta se cambiate semplici configurazioni negli script di suspend/resume o in quelli di ACPI. Quindi praticamente la farete una volta sola, a meno che non usiate un file di swap e vogliate cancellarlo e ricrearlo periodicamente per evitare danni alla SSD, ma a meno che non mandiate in ibernazione il vostro Eee ogni 5 secondi, non dovreste averne bisogno. Con 3 ibernazioni al giorno la SSD dovrebbe durarvi qualche centinaio di anni.

Provare la configurazione

Se avete appena riconfigurato uswsusp con dpkg-reconfigure, ricordate di riavviare, poi potete provare le varie procedure di sospensione e ibernazione coi i comandi:

pm-suspend
pm-hibernate
pm-suspend-hybrid

Il primo sospende in RAM, il secondo iberna su disco, il terzo fa entrambe le cose. Per risvegliare l’Eee basta premere il pulsante di accensione. Non tenetelo premuto per troppo tempo (4 secondi), altrimenti l’effetto sarà quello di spegnerlo in modo brusco, che comporta anche l’invalidazione del BootBooster (non preoccupatevi, si riattiva da solo al successivo reboot) e, naturalmente, un tempo di boot più lungo, in quanto viene eseguito anche il controllo sui dischi.

Personalizzare tutto

Come ho detto, non mi piacevano i default scelti dal team Debian per l’ibernazione. Ho quindi configurato tutto in modo che:

• chiudendo il coperchio si attiva il suspend2ram
• premendo il tasto di accensione/spegnimento si attiva il suspend2disk
• premendo Fn-F1 si attivano entrambi: lo stato viene salvato su disco ma il sistema entra in suspend2ram. In questo modo il resume è immediato, e se si scarica la batteria comunque si riprende a lavorare senza perdere dati, caricando l’immagine da disco

Vediamo come fare. Il tutto viene controllato dagli script in /etc/acpi. Alcuni li ho dovuti creare io, altri li ho solo modificati. Eccoli qui:

/etc/acpi/events/lid

event=button/lid LID
action=/etc/acpi/actions/mysuspend.sh

/etc/acpi/events/powerbtn

# /etc/acpi/events/powerbtn
# This is called when the user presses the power button and calls
# /etc/acpi/powerbtn.sh for further processing.

# Optionally you can specify the placeholder %e. It will pass
# through the whole kernel event message to the program you've
# specified.

# We need to react on "button power.*" and "button/power.*" because
# of kernel changes.

event=button[ /]power
action=/etc/acpi/actions/myhibernate.sh

/etc/acpi/events/sleep

event=button/sleep SLPB
action=/etc/acpi/actions/myhibernatesuspend.sh

Questi sono i file di configurazione che determinano quale script viene eseguito quando un certo evento ACPI viene attivato. Ho usato nomi diversi da quelli di eeepc-acpi-scripts per le azioni, in modo che non vengano sovrascritti dopo un aggiornamento. Naturalmente verrebbe chiesta conferma, ma è più comodo verificare i cambiamenti e modificare i propri script.

Di seguito gli script veri e propri che vengono richiamati, presenti in /etc/acpi/actions:

/etc/acpi/actions/mysuspend.sh

#!/bin/sh

# do nothing if package is removed
[ -d /usr/share/doc/eeepc-acpi-scripts ] || exit 0

if (runlevel | grep -q [06]) || (pidof '/sbin/shutdown' > /dev/null); then
    exit 0
fi

brn_control=/sys/class/backlight/eeepc/brightness
[ -e $brn_control ] || brn_control=/proc/acpi/asus/brn # pre-2.6.26

brightness=$(cat $brn_control)
pm-suspend --quirk-s3-bios
echo $brightness > $brn_control

Viene verificato che non sia in corso un halt o un reboot (controllando il runlevel o se sta venendo eseguito il comando shutdown), quindi inizia la sospensione tramite “pm-suspend”. Prima del suspend viene salvata la luminosità dello schermo, e ripristinata dopo il resume.

/etc/acpi/actions/myhibernate.sh

#!/bin/sh
# do nothing if package is removed
[ -d /usr/share/doc/eeepc-acpi-scripts ] || exit 0

if (runlevel | grep -q [06]) || (pidof '/sbin/shutdown' > /dev/null); then
    exit 0
fi

brn_control=/proc/acpi/asus/brn

brightness=$(cat $brn_control)
/etc/acpi/actions/wireless.sh off
pm-hibernate
echo $brightness > $brn_control

Lo script è molto simile al precedente, ma ho aggiunto l’opzione per disattivare il wireless, senza riattivarlo al risveglio, contando sul fatto che se sto ibernando il PC, difficilmente quando lo risveglio mi troverò nello stesso posto ed anzi, potrei essere in aereo…

In ogni caso basterà premere Fn-F2 per riattivare il wireless dopo il risveglio.

Vediamo ora come sospendere e ibernare contemporaneamente:

/etc/acpi/actions/myhibernatesuspend.sh

#!/bin/sh

# do nothing if package is removed
[ -d /usr/share/doc/eeepc-acpi-scripts ] || exit 0

if (runlevel | grep -q [06]) || (pidof '/sbin/shutdown' > /dev/null); then
    exit 0
fi

brn_control=/proc/acpi/asus/brn

brightness=$(cat $brn_control)
pm-suspend-hybrid --quirk-s3-bios
echo $brightness > $brn_control

Lo script è praticamente identico a quello di sospensione, cambia solo il comando eseguito: pm-suspend-hybrid invece del semplice pm-suspend.

Quando avete fatto, riavviate acpid:

/etc/init.d/acpid restart

per ricaricare le impostazioni.

Quel ficcanaso di Gnome

Gnome ha la “brutta” abitudine di prendere il controllo di tutto il sistema di risparmio energetico appena attivate il demone gnome-power-manager. Il problema è che per avere l’indicazione dello stato della batteria sul panel, dovete per forza attivarlo. Non ho ancora capito quali script vada a richiamare per la sospensione, ma quel che è certo è che ignora quelli che abbiamo appena impostato, e gestisce da solo tutto.

Vediamo come disattivare questo comportamento.

Aprite l’editor di configurazione (menu Gnome->Strumenti di sistema->Editor della configurazione) e andate alla voce /apps/gnome-power-manager/actions. A destra avrete diversi flag di configurazione. Io li ho impostati così:

critical_battery           hibernate
critical_ups               shutdown
event_when_closed_battery  v (attivo)
low_ups                    nothing
sleep_type_ac              nothing
sleep_type_battery         nothing

Mentre a /apps/gnome-power-manager/buttons ho questi:

hibernate               nothing
lid_ac                  nothing
lid_battery             nothing
power                   nothing
suspend                 nothing

In questo modo disabilitiamo la gestione dei tasti per Gnome, abilitando la nostra, che funziona anche se usate altri Desktop o Window Manager.

Io ho impostato anche alcuni valori in /apps/gnome-power-manager/backlight:

battery_reduce             v (attivo)
brightness_ac              70
brightness_battery         20
dpms_method_ac             default
dpms_method_battery        default
enable                     v (attivo)
idle_brightness            0
idle_dim_ac                v (attivo)
idle_dim_battery           v (attivo)
idle_dim_time              30

Così la luminosità sarà del 70% con l’alimentazione attiva, e del 20 a batteria, ma potete comunque regolarla con i soliti Fn-F3 e Fn-F4. Quando non usate l’Eee per 30 secondi, se siete “a batteria” la luminosità scende a 0, per risparmiare energia.

Se volete potete sperimentare con gli altri parametri di gnome-power-manager, visto che la gran parte di quelli configurabili qui non sono disponibili dall’interfaccia di configurazione, che è eccessivamente semplificata, secondo me.

Prestazioni

Le prestazioni in fase di suspend, resume sono eccellenti. In pochi secondi (3 o 4) il sistema va in sospensione e si risveglia. In fase di thaw (il risveglio dopo l’hibernate) sono ottime. Dall’avvio del kernel da parte di GRUB al desktop pronto com’era prima passano circa 10-15 secondi.

Il problema, che non ho trovato come risolvere, riguarda l’ibernazione, che impiega circa 30 secondi. Il sistema sembra non fare nulla per quasi 20 secondi, mentre scrive “Snapshotting system”, e poi in meno di 5 secondi scrive l’immagine compressa della RAM su disco. Forse sta comprimendo la RAM. Devo scoprire se c’è modo di fargli usare un algoritmo più leggero.

Conclusioni

Mi pare di non aver scordato nulla, anche se le modifiche da fare sono abbastanza numerose.

Una cosa che non ho preso in considerazione, ma che sarà una bella rogna, è la gestione di periferiche rimovibili. Se mandate in sospensione l’Eee con una penna USB o una SD inserite, quindi le staccate e poi risvegliat, succedono cose molto brutte. Purtroppo non c’è un modo sicuro per sistemare tutto, perché un’applicazione potrebbe avere un file aperto sulla penna, e un umount prima della sospensione non andrebbe a buon fine. Ricordatevi quindi di smontare i device rimovibili prima di sospendere o di non toglierli dopo aver sospeso (o almeno di ricollegarli prima di risvegliarlo).

Nella prossima puntata parlerò delle mie personalizzazioni di Gnome: scorciatoie da tastiera, panel, applet, ecc.

Se avete seguito la prima parte di questa serie, ora avrete la vostra Debian Lenny installata sull’Eee 900, e dovreste avere anche le schede di rete (sia ethernet che wifi) funzionanti. Potete quindi procedere con aptitude (o con synaptic, se avete già installato e configurato X) ad installare tutto il software che vi serve.

Forse lo avete già notato, ma (con il kernel 2.6.24) la scheda audio non funziona, e con lei anche tutti i tasti “azzurri”, come la sospensione e l’audio. Funzionano solo i tasti per la regolazione della luminosità, gestita in hardware. Iniziamo quindi con l’aggiornare il…

Kernel 2.6.25

La prima cosa da fare è di installare un kernel più recente, e già che ci siamo anche gli script per la gestione dei tasti via ACPI (i suddetti “azzurri”).

Avete due possibilità per farlo.

La prima è di prendere i pacchetti dai repository Debian tramite un browser, e poi installarli con dpkg. La seconda (quella che ho scelto io) è di aggiungere i repository di unstable (sid) e di mettere dei pin sulla testing, in modo da mantenere lenny ed avere alcuni pezzi di unstable.

Prendere i pacchetti manualmente

Potete scaricare manualmente i pacchetti dai repository Debian (i link sono al repository principale, ma potere usare un mirror qualsiasi):

• http://ftp.debian.org/pool/main/l/linux-2.6/
• http://ftp.debian.org/pool/main/l/linux-modules-extra-2.6/
• http://ftp.debian.org/pool/main/e/eeepc-acpi-scripts/

Dal primo link scaricate il kernel. In questo momento è il pacchetto linux-image-2.6.25-2-686_2.6.25-5_i386.deb, ma nel frattempo potrebbero essere uscite nuove versioni. Dal secondo link vi servono i pacchetti atl2-modules-2.6.25-2-686_2.6.25+2.0.3-3_i386.deb e eeepc-acpi-modules-2.6.25-2-686_2.6.25+1.0-3_i386.deb, mentre dal terzo eeepc-acpi-scripts_1.0.3_all.deb.

Vi servirà anche il pacchetto per i driver wifi, che però non si trova nei repository ufficiali. Lo trovate qui: http://eeepc.debian.net/pool/non-free/e/eeepc-modules-non-free-2.6/ e si chiama madwifi-eeepc-modules-2.6.25-2-686_2.6.25+0.9.4+r3366-2_i386.deb

Trovate anche il pacchetto dei sorgenti a http://eeepc.debian.net/pool/non-free/m/madwifi-eeepc/ e si chiama madwifi-eeepc-source_0.9.4+r3366-1_i386.deb.

Devo ringraziare Niccolo Rigacci che mi ha dato un paio di dritte sulla ml di Debian EeePC. Sul suo sito trovate anche i driver per la webcam, che personalmente non uso, quindi non ho testato.

Usare il pinning per avere Lenny+Sid

Questo sistema permette di gestire i pacchetti suddetti, e soprattutto i loro aggiornamenti, in modo più semplice, ma attenzione: aptitude (o chi per lui) vi mostrerà come aggiornamenti dei pacchetti già installati (e conosciuti) le versioni di testing, ma vi mostrerà anche, come nuovi, i pacchetti che entrano in sid ma non sono ancora in testing. State quindi attenti quando vedete nuovi pacchetti nella lista. Personalmente preferisco così: ho i pacchetti nuovi appena entrano in unstable, e li aggiorno solo quando vengono aggiornati in testing, e conosco i rischi di questo approccio. Come dicono gli americani, Your Mileage May Vary.

Ecco come fare: dovete aggiungere i repository di sid e di Debian EeePC in /etc/apt/sources.list:

deb http://ftp.debian.org sid main contrib non-free
deb-src http://ftp.debian.org sid main contrib non-free

deb http://eeepc.debian.net/debian lenny main contrib non-free

Io ho messo anche il repository per i sorgenti, non si sa mai…

Dovete quindi modificare /etc/apt/preferences in modo da impostare lenny come standard:

Package: *
Pin: release a=testing
Pin-Priority: 1001

Tutto qui. Lanciate aptitude e premete “u” per aggiornare la lista dei pacchetti, dopdiché dovreste avere disponibile tutta la lista dei pacchetti elencati sopra disponibili per l’installazione: linux-image-2.6.25-2-686, atl2-modules-2.6.25-2-686, eeepc-acpi-modules-2.6.25-2-686, eeepc-acpi-scripts-1.0.3, madwifi-eeepc-modules-2.6.25-2-686.

I tasti Fn

Dopo aver installato i vari pacchetti, i tasti Fn dovrebbero (più o meno) funzionare tutti, ma, a dire il vero, per la maggior parte delle funzioni non mi hanno soddisfatto del tutto.

Prima di tutto, se volete avere un feedback a schermo, conviene installare anche il pacchetto aosd-cat. Gli script appena installati prevedono già la sua presenza e vi scrivono a schermo le operazioni che fate, se il desktop manager lo supporta. Io uso Gnome e non ho problemi.

Lasciando da parte la sospensione (di cui parlerò la prossima volta), e la luminosità (che funziona in hardware) rimangono i tasti per (dis)attivare il WiFi, per attivare un monitor esterno, per avviare applicazioni e per la regolazione del volume.

Vi dico subito che non ho ancora provato ad usare monitor esterni, quindi mi riservo l’argomento per un articolo futuro. Il tasto per avviare applicazioni (Fn-F6) non è ancora previsto, e non funziona nemmeno come hotkey su Gnome, quindi per ora è inutile.

I tasti per l’audio hanno bisogno di una ritoccatina per funzionare. Innanzitutto bisogna impostare quale volume vanno a modificare, nel file /etc/default/eeepc-acpi-scripts:

VOLUME_LABEL="Master"
HEADPHONE_LABEL="Capture"

Il modello 900 usa label diverse da quelle già impostate (LineOut e iSpeaker) che vanno bene per il 701, credo.

In questo stesso file poteteabilitare l’OSD (sempreche abbiate installato aosd-cat) e scegliere il relativo font. Quello di default è perfettamente leggibile anche con la risoluzione più alta del 900 rispetto al 701, quindi potet lasciarlo così (DejaVuSans 24). Potete impostare anche la risoluzione del monitor esterno attivato con la combinazione Fn-F5 ma, come dicevo, non l’ho ancora testato.

Un’altra modifica che ho fatto io è stata proprio sugli script di gestione del volume. Di default alzano o abbassano il volume del 2% per ogni click, ma io preferivo dover cliccare meno, quindi l’ho messo a 5%. Basta modificare /etc/acpi/actions/hotkey.sh e cercare le due righe che seguono, cambiando il 2 già presente con il 5 che vi mostro qui:

...
	amixer -q set $VOLUME_LABEL 5- unmute
...
	amixer -q set $VOLUME_LABEL 5+ unmute
...

Se siete smanettoni della bash, in questo script potrete cambiare il comportamento dei vari tasti (tranne il suspend, la chiusura del coperchio e il pulsante di accensione). State attenti a quel che fare e ricordate che questo file viene sovrascritto (ma vi chiederà conferma) quando aggiornate il pacchetto eeepc-acpi-scripts.

Se usate Gnome, l’applet di regolazione del volume si aggiornerà automaticamente quando premete questi tasti, quindi non è necessario impostarli nelle “Scorciatoie Da Tastiera”.

Per quanto riguarda il wireless, lo script funziona disabilitando completamente la scheda WiFi, quindi non viene solo spenta la radio, ma è come se la scheda venisse rimossa dallo slot.

Se usate Network Manager (e la relativa applet per Gnome) dovete editare /etc/network/interfaces e cancellare tutto quanto riguarda la scheda wlan0, in modo da permettere a NM di gestirla da solo. Se anche con la rete ethernet avete un server DHCP, cancellate anche tutto quello che riguarda eth0: NM gestisce anche l’hotplug del cavo ethernet. In pratica qui dovrebbe rimanere solo la configurazione di “lo” (localhost).

Quando attivate il WiFi, NM se ne accorge e inizia a scandagliare le reti WiFi disponibili. La Atheros non è proprio un fulmine a fare lo scan delle reti, quindi portate pazienza per 10-20 secondi e dovreste avere il vostro collegamento.

A proposito di NM, ho provato a usarlo per collegarmi con il cellulare via Bluetooth, tramite PPP (su GPRS) ma sembra che il modulo PPP funzioni solo se un’altra rete è attiva, configurandosi come VPN, quindi in pratica inutile. Sto cercando altre soluzioni, ma per ora ho paura che l’unico modo sia usare g-ppp-on o applet simili per Gnome.

CAPS? NumLock?

Un’ultimo dettaglio, prima di chiudere, riguarda i tasti CAPS e NumLock, per i quali l’Eee non ha led di stato. Su suggerimento di Davide Cavalca ho installato l’applet lock-keys-applet per Gnome, e attivato solo questi due (l’applet prevede anche lo ScrollLock, se vi serve).

Concludo qui questa seconda parte. La prossima volta parleremo di sospensione e ibernazione.

Non ho resistito… Ho provato ad utilizzare Xandros sull’Eee, ma i repository ufficiali non hanno praticamente software oltre a quello preinstallato, e quelli aggiuntivi per xandros 4 hanno una selezione di software veramente misera, e nessuno che si integri con l’interfaccia Easy (non mostrano le icone, insomma). Oltretutto, passando in modalità desktop/advanced ci si ritrova con KDE, che a me non piace per niente.

Motivo per cui ho installato Debian dopo nemmeno 2 giorni di utilizzo, ed ora la sto configurando a puntino. Ho deciso di riportare qui i vari passi che ho fatto (e che farò) sia per tenerne traccia, sia per aiutare chi voglia fare la stessa cosa. Quindi…

Da dove partire?

Innanzitutto vi consiglio di procurarvi una scheda SD. Io ne avevo una vecchissima (comprata col mio primo Zaurus 5500 direttamente dagli USA) da 128 MB, più che abbondanti per quello che ci serve. Dovrebbero bastare anche schede da 16 MB, ma ve ne consiglio una da 32 MB. Non metteteci dati importanti, e se li avete copiateli da qualche altra parte, perché questa scheda non la potrete usare per niente altro (vi spiegherò poi perché )

Poi andate sul sito di DebianEeePC a scaricare l’immagine dell’installer, che occupa circa 16 MB (per questo consigliavo almeno 32 MB di SD).

Io l’ho scaricata direttamente dall’Eee, e sempre da lì ho “flashato” la SD con il comando dd, come indicato nella pagina di download. La scheda viene vista come /dev/sdc, se non ricordo male.

L’immagine dell’installer occupa tutta la chiavetta, indipendentemente dalle dimensioni della stessa, con un filesystem FAT32 da 16 MB. Probabilmente si può sfruttare in qualche modo lo spazio in più, magari con parted per allargare la partizione, ma non ho provato, anche perché non è una partizione…

Se siete avventurosi, potete provare a crearvi da soli un installer customizzato per sfruttare tutto lo spazio sulla chiavetta, magari mettendoci del tool di ripristino/recupero aggiuntivi.

Ed eccoci al motivo per cui quella chiavetta è “persa”: è un ottimo sistema per avere un “CD di ripristino”. Basterà far partire l’installer, selezionare lingua e tastiera, rilevare i dischi e quindi passare alla seconda tty con alt-F2 per avere una shell con un discreto numero di comandi base disponibili. Mi ha già salvato una volta, dopo una modifica a fstab un po’ “avventurosa”!

Le partizioni

Bene, avete flashato l’installer sulla SD, non vi resta che riavviare l’Eee con la SD inserita, e (se non avete modificato la sequenza di boot del BIOS) partirà l’installer Debian.

Non starò qui a spiegarvi i vari passi. Se volete Debian (e non, per dire, Ubuntu) sull’Eee significa che siete molto appassionati di questa distro, quindi sapete come installarla.

L’unico punto su cui voglio soffermarmi sono le partizioni.

L’Eee 900 monta, di serie, due SSD: una da 4 GB (vista come /dev/sda) e una da 16 GB (come sdb). La prima è suddivisa in 4 partizioni. sda1 (da 2.5 GB in ext3) contiene il sistema base Xandros, mentre sda2 (da 1.5 GB) contiene un fs ext2 che viene montato tramite unionfs assieme a sda1. Il risultato è un fs con 1.5 GB liberi. Quando installate aggiornamenti o nuovi software, questi vengono messi in sda2, e i file “nascondono” i loro corrispondenti in sda1. Una spiegazione un po’ arzigogolata, ma l’effetto finale è che se incasinate il sistema installando roba sbagliata o modificando qualche file che non dovevate toccare, basta cancellare tutto da sda2 per tornare alla configurazione di fabbrica. Ed è quello che fa l’utility di ripristino fornita col computer.

Le altre due partizioni sono un po’ particolari. Occupano 8 MB ognuna (corrispondenti a 1 cilindro, il minimo possibile su questa SSD). sda3 contiene una copia del BIOS, e presumo che serva per farne il flash. Teoricamente basta scaricare l’aggiornamento del BIOS dal sito Asus, copiarlo qui dentro con un nome particolare e riavviare l’Eee perché il BIOS venga automaticamente flashato.

sda4 invece serve per la funzionalità BootBooster. Quando viene attivata (dal BIOS) questa modalità, dopo il primo avvio il BIOS copia qui dentro un’immagine dei suoi registri e di quelli della scheda video. Al riavvio successivo li legge e non deve più fare lo scan dell’hardware, riducendo da 10 a 0,5 secondi il tempo di boot.

Per l’installazione di Windows XP, Asus consiglia di eliminare tutte le partizioni e di farne una unica per il S.O.

Per l’installazione di Debian io vi consiglio di eliminare le prime tre, di tenere sda4 così com’è, e creare sda1 che copra il resto del disco. Se cancellate sda4 o se ne cambiate il tipo (di default “ef”), il BIOS non vi presenterà più l’opzione per il BootBooster. Se la mantenete, cercate di non scriverci mai niente sopra, altrimenti rischiate che non si avvii più l’Eee.

Potete decidere di tenere anche sda3 per flashare il BIOS, ma c’è una procedura che permette di farlo da una SD o da una chiavetta USB, quindi non fatevi troppi problemi.

Per quanto riguarda il secondo disco, io l’ho usato (come nella Xandros originale) per metterci /home, quindi marcate la partizione come “da formattare” e procedete con l’installazione.

Update 22 giugno 2008

Come vedremo nei prossimi articoli, potete usare un file per l’ibernazione del sistema, ma alcuni metodi di ibernazione permettono di salvare l’immagine della RAM solo su una partizione di swap. Quindi, se volete usare uno di questi sistemi, dovreste creare una partizione di swap su uno dei due dischi (consiglio sdb). La dimensione può essere della metà della RAM se avete intenzione di comprimere l’immagine o delle stesse dimensioni della RAM senza compressione. Ma ne parleremo più approfonditamente.

L’installazione

L’installer contiene già i driver per le due schede di rete (ethernet e wifi), quindi potrete configurarle durante l’installazione e scaricare i pacchetti direttamente dai repository Debian.

La distribuzione utilizzata è Lenny (Debian testing, mentre vi sto scrivendo) per diversi motivi. Il principale è che lenny contiene un kernel 2.6.24, che supporta meglio l’hardware dell’Eee 701. Inoltre contiene diversi componenti necessari al funzionamento dei driver aggiuntivi. Come vedremo in un prossimo articolo, è necessario installare il 2.6.25 da sid (unstable) per avere il supporto alla scheda audio.

Il resto dell’installazione non presenta alcuna differenza con una standard. Io ho scelto GRUB come bootloader perché lo preferisco, ma l’Eee è un normale PC, quindi se preferite LILO, usate quello.

Conclusioni

Il lavoro del team Debian Eee è stato veramente grandioso. Praticamente non c’è alcuna differenza con un normale PC, e alla fine dell’installazione tutto l’hardware funziona senza problemi.

Se avete configurato il wifi durante l’installazione, ve lo ritroverete già configurato, funzionante ed attivato al riavvio. I tempi di boot sono ancora altini, ma vedremo in seguito come accorciarli.

Io ho, come sempre con Debian, deselezionato tutti i meta-pacchetti (Ambiente Desktop e Sistema Base) durante l’installazione, quindi al riavvio mi sono trovato la mia (bella) shell da cui, con aptitude, ho installato quello che mi serviva. Vedremo in seguito cosa installare e come configurarlo al meglio, per ora vi dico che l’ambiente completo (X, Gnome, Ooo, Firefox, ecc.) mi occupa 2.7 GB sulla root. Magari non potrete installare sia Gnome che KDE, ma di spazio ce n’è in abbondanza.

Alla prossima puntata.

Nei giorni scorsi una notizia ha invaso i blog di tutto il mondo: la pubblicazione della seconda beta della nuova versione di Debian (Lenny). La notizia mi era sembrata strana fin da subito, perché Debian non ha mai pubblicato delle beta, ma si basa su un sistema di aggiornamenti continui della versione “testing”.
Beh, la notizia era falsa.

In realtà è stata reso pubblica la beta del nuovo Debian Installer, quello che diventerà l’installer della suddetta Lenny, quando questa sarà stable, presumibilmente verso la fine dell’anno.

Sembra che Android prima, e QTopia (con Nokia) poi abbiano risvegliato i produttori “minori”, spingendoli ad annunciare i loro nuovi dispositivi, prima che gli annunci dei “big” rischino di seppellirli sotto la loro pubblicità.

Readius

Partiamo quindi con il primo della lista, il Readius della Polymer Vision (uno “spinoff” della Philips), che presenta il modello forse più interessante per noi italiani, visto che uscirà direttamente qui in Italia, in collaborazione con Telecom Italia, a metà di quest’anno.

Le due caratteristiche che saltano subito all’occhio sono due: uno schermo e-paper da 5″ (risoluzione non dichiarata, ma presumo intorno agli 800×600) pieghevole e l’assenza di qualsiasi tipo di tastiera.

Il primo permette di avere un grande schermo mantenendo piccolo il cellulare, e quindi di leggerci e-book, funzione primaria di questo modello, mentre il secondo sega praticamente le gambe all’utilizzo come cellulare, perché costringe ad avere una rubrica nella memoria del cellulare, trasferita dal PC, da cui scegliere i numeri. Il display, infatti, non è touchscreen, ed esistono solo 8 tasti hardware per navigare nei menu. In compenso, oltre a supportare e-book in diversi formati, è anche lettore musicale, RSS ed e-mail (però non si può rispondere…).

Magari ci si può attaccare una tastiera bluetooth o USB (non si sa ancora se sia USB host, OTG o solo slave).

Una nota negativa: probabilmente ci sarà anche un modello con Windows CE, e altrettanto probabilmente qui in Italia venderà più di quello con Linux (anche se potrebbe stupirmi come hanno fatto le vendite dell’Eee, già introvabile ovunque sia arrivato).

Purple Labs

Probabilmente il primo cellulare Linux-based sotto i 100$ (che significa meno di 70 euro, se tutto va bene).

Questo Purple Magic non ha apparentemente nessuna caratteristica di spicco, oltre al costo. Il cellulare è pensato per essere il più economico possibile, e Linux non si vede assolutamente trasparire dall’interfaccia mostrata finora nelle foto.

Supporta 3G, quindi UMTS, e posso solo supporre che abbia capacità bluetooth, quindi almeno lo si potrà usare come modem.

SysOpen Digia

Questa azienda presenta forse il modello più interessante, accompagnandolo (anzi, anticipandolo) anche con il codice sorgente del kernel e dei driver modificati.

Pochi i dati tecnici del dispositivo. La CPU è una Marvell PXA300, mentre la parte WCDMA viene gestita da un Ericsson WCDMA 3G.

Purtroppo usa una versione quasi antica del kernel (2.6.14), ma la disponibilità dei sorgenti potrebbe accelerare lo sviluppo dei driver in conformità con gli ultimi kernel. L’interfaccia grafica è basata su QTopia di Trolltech, con cui SysOpen Digia ha siglato un accordo lo scorso settembre.

Il modello clamshell (quello di destra) con tastiera QWERTY sembra molto interessante.

Android

Raggruppo qui gli ultimi due modelli, perché entrambi useranno lo stack Android di Google.

Il primo è di un’azienda canadese, la Koolu di Jon “Maddog” Hall, e non sembra altro che un restyling del Neo Freerunner, al punto di avere la stessa forma e quasi lo stesso hardware (probabilmente la CPU sarà leggermente diversa e un po’ più lenta).

Si chiama W.E.Phone, e sarà disponibile anche con un plaid nella parte frontale che, se letto in codice Morse, si traduce in “Debian”, che è appunto la distribuzione alla base di tutto lo stack, naturalmente adattata per il particolare hardware.

Il telefono sarà fornito con un SDK (basato anch’esso su Debian) completamente open, in pieno spirito Debian.

L’altro modello non esiste ancora, ma verrà presentato la prossima settimana al Mobile World Congress (3GSM) dalla Arm. Non essendo ancora stato presentato non ho immagini da allegare qui.

Sicuramente ci saranno altri annunci di Android Phone allo stesso congresso, primo fra tutti quello di HTC .

Altro

Si sta muovendo anche la LiMo Foundation, evidentemente intenzionata a non essere lasciata indietro.

Ha presentato la sua nuova piattaforma Azingo (che si pronuncia più o meno come “as in go”, traducibile grossolanamente con “come nell’andare”) .

Si tratta del (ennesimo?) tentativo di unificare la piattaforma Linux per il mobile, costituita da kernel, middleware e SDK. Sono della stessa opinione dell’autore dell’articolo linkato: la LiMo è arrivata ultima a proporre questo tipo di piattaforma, e va solo contro quello che loro stessi dichiarano (di aver bisogno di una piattaforma unificata). Ad oggi, nell’ordine, sono state annunciate o presentate: QTopia Phone Edition, OpenMoko, Android, ed ora Azingo. Senza contare tutte le piattaforme “nascoste” o quelle ibride o semi-proprietarie.

Chiudo dicendo che i prezzi dei vari dispositivi sono ancora sconosciuti, tranne i ventilati 400 $ per il WEPhone di Kooku, in linea con il prezzo del Neo1973 e del Freerunner. Abbastanza logico considerando che hanno più o meno lo stesso hardware.

La parte più “delicata” del tutto è la scheda madre. Non volevo spendere un capitale, ma nemmeno mettere roba troppo vecchia, quindi ho puntato sulla MoBo in oggetto per diversi motivi: 6 porte USB esterne e 4 interne, 6 porte SATA interne e 2 esterne, 4 slot DDR2 (con supporto dualchannel) e scheda WiFi integrata. Le altre caratteristiche erano meno importanti, ma comunque utili: firewire, un (solo) connettore PATA, ethernet 10/100/1000, due connettori PCIe (16x e 4x) oltre ai due PCIe 1x e ai tre PCI (che non uso, eliminando anche la scheda WiFi che era l’ultima rimasta sul vecchio PC, a parte la scheda video).

Wi-Fi

Il dubbio più grosso era sulla scheda WiFi, inizialmente perché non sapevo nemmeno quale chipset montasse e poi, avendolo scoperto, sul suo supporto. Si tratta infatti di un Realtek 8187. La mia precedente esperienza con questo chipset era stata disastrosa, al punto che ho reinscatolato la scheda e ne ho comprata un’altra con chipset Atheros, già allora (circa 3 anni fa) abbastanza ben supportato.

Mi sono quindi guardato intorno e ho scoperto che il kernel 2.6.24 (appena uscito) la supporta.

Finito di installare la Debian testing, attraverso la Ethernet ben supportata dal kernel 2.6.21 che c’era sul DVD di installazione, ho scaricato dai repository il nuovo kernel, prendendolo direttamente da “pool” tramite lynx e ho installato tutto. Ho scaricato anche i pacchetti necessari a module-installer, perché in seguito mi sarebbero serviti per i driver fglrx, necessari per avere il 3D sulla nuova Radeon HD3870.

Riavviato il computer, il (magico) udev ha rilevato la scheda WiFi senza alcun problema, e ho dovuto solo dare un paio di comandi:

iwlist scan    			# per vedere se funzionava e rilevare l'AP
iwconfig essid MioEssid    	# Per associarla con l'AP
ipconfig wlan0 1.2.3.4    	# Per assegnare l'IP statico
route add default gw 1.2.3.1    # Per impostare la route verso l'AP

Tutto perfetto (dopo aver impostato i DNS in /etc/resolv.conf naturalmente), 1 minuto ed ero in rete. Non mi era mai successo con le schede WiFi. Sembra che il nuovo stack WiFi nel kernel funzioni bene, e anche il kernel di per sé sembra molto stabile, almeno per i 3 giorni di funzionamento continuato che sono riuscito a fare.

L’unico problema l’ho avuto con network-manager. L’avevo installato sperando mi “desse una mano” nella configurazione, ma visto che uso un IP statico per esigenze di forwarding dall’AP al PC, alla fine non l’ho usato. Solo che ogni tanto, senza apparente ragione, la scheda perdeva la portante, per poi riprenderla qualche secondo dopo.

Secondi sufficienti a rallentare mostruosamente i trasferimenti, e a far cadere anche qualche connessione per timeout. Non me ne sono accorto subito perché ogni tanto succedeva anche prima, a causa della linea ADSL.

Rimosso network-manager, la scheda non ha più avuto problemi. Ho quindi provveduto a configurare /etc/network/interfaces per attivarla al boot.

CPU e RAM

La CPU che ho scelto è un Intel Core 2 Duo E6550, a 2,33 GHz.

Da questo punto di vista nessunissimo problema. Linux riconosce due processori e lavora in parallelo. Un mostro in confronto al vecchio Athlon XP 2400.

Qualche problemino dal punto di vista della RAM, ma solo perché non ci ho perso troppo tempo: ho installato la Lenny a 32bit (per rimanere compatibile con alcuni software che dovrò far girare, è un po’ lunga…) e “vede” solo 3.5 GiB dei 4 installati. Magari nei prossimi giorni proverò il kernel bigmem (che supporta fino a 16 GiB) e vedrò cosa salta fuori.

Tutto il resto

Non ho avuto occasione di provare il firewire, perché non ho nessuna periferica di quel tipo, ma tutto il resto funziona al primo colpo: USB 2.0, scheda audio (funziona talmente in automatico che non so nemmeno che chipset monti), ethernet (stesso discorso della scheda audio), SATA (il disco appare come SCSI: /dev/sda), PATA (riconosciuti lettore e masterizzatore DVD), e anche il pannello frontale con lettore di flashcard e porte USB, ma questo lo sapevo già visto che lo usavo anche prima.

La scheda video richiede i driver closed source fglrx per funzionare in 3D. Purtroppo i driver liberi radeonhd (peraltro inclusi in Debian) non supportano ancora l’accelerazione 3D, e sono ancora indietro anche per l’accelerazione 2D. Fortunatamente Debian pacchettizza tutto e basta un

m-a a-i fglrx

per installarli, e un

aticonfig --initial

per configurare Xorg.

Non ho ancora avuto occasione di provare a fondo la nuova scheda video, ma il tutto è sicuramente molto più silenzioso del precedente. Ho scelto tutto in modo che “downclocki” quando non viene usato, quindi le ventole sono quasi ferme.

Durante questa ricerca sono incappato in due documenti che raccolgono una messe di informazioni su come configurare varie componenti in diversi modi.

Non sono sempre “digita e dimentica”, anzi, a volte richiedono un’analisi preventiva dell’hardware presente, e un tuning dei parametri per funzionare al meglio, ma sono una bella lista abbastanza completa. Alcune cose le ho già scritte nella prima parte di questo articolo.

Ma ecco i link: Velocizzare Debian e Recuperare spazio sull’HD.

I consigli sono diretti a utenti Debian, ma la maggior parte sono validi per qualsiasi distribuzione.

Non tutti sono da applicare ad occhi chiusi, ma richiedono una minima conoscenza del (sotto-)sistema che si sta configurando. Magari in futuro ne estrapolerò qualcuno e lo approfondirò qui. Nel frattempo ne approfitto per ringraziare il progetto Linguistico per queste e per le altre guide che hanno pubblicato, oltre che per i dizionari e i thesaurus in italiano, naturalmente.