In realtà il post in oggetto è più che altro una verifica post-aggiornamento a WordPress 2.5 (per ora sta andando tutto bene) però i messaggi di prova fini a loro stessi non mi sono mai piaciuti per cui perché non approfittarne per mettere un attimo in evidenza quella sorta di delirium tremens che spesso sembra governare le decisioni che vengono prese nello sviluppo di questo blog engine? Del resto già il fatto che ad ogni major release — quindi al massimo ogni 6 mesi — si rinnovi il teatrino del cambio di alcune API del core di WP con conseguente balletto del compatibile sì/no/boh/boom denota, almeno secondo me, una roadmap poco chiara che punta più a infilare continuamente funzionalità su funzionalità a scapito della stabilità delle API stesse… come si suol dire, espandere ad cazzum. Ok forse ha un suo ruolo anche il fatto che WP sta cercando di transitare, almeno a livello di implementazione, dallo schifo dell’arte allo stato dell’arte (??), quindi probabilmente tutti questi breaking change sono inevitabili. Poi però viene da pensare di nuovo che di serietà ce ne sia un po’ poca quando su TRAC si leggono certe boiate in risposta a gente (parecchia) che segnala problemi (parecchi) con il nuovo uploader in Flash chiedendo di conseguenza la possibilità di avere un’opzione per disabilitarlo da interfaccia di amministrazione: nada, scrivete un plugin per la gente che vuole disabilitarlo. AH AH AH, OH WOW. Una risposta ineccepibile per un difetto che limita di fatto le funzionalità base di quello che è un blog, non solo perché attualmente vi è appunto un bug da qualche parte ma anche perché non tutti possono avere la possibilità di eseguire il plugin Flash per vari motivi: intranet aziendali, problemi come flash che fa schifo su linux… e se poi io volessi postare dal mio fidatissimo elinks? Installati un plugin sul blog. Eh già. Aaah se quelle faine di Aruba, passate recentemente a PHP 5 sui loro server, non avessero disabilitato PDO nelle loro configurazioni avrei sicuramente cominciato a provare Habari anche soltanto per curiosità e per valutare un eventuale cambiamento, invece mi toccherà aspettare di cambiare hosting provider. Ve lo avevo detto che volevo soltanto provare che funzionasse ancora tutto dopo l’aggiornamento, no?

Premetto di non aver mai seguito con particolare interesse BlogBabel ma soprattutto di non aver mai seguito in toto le polemiche che negli ultimi mesi sembrerebbero averla coinvolta, oggi però non posso fare a meno di notare l’annuncio della sua chiusura a tempo indeterminato. In realtà non è la vicenda in oggetto a spingermi a scrivere, tuttavia leggendo i commenti sparsi (seguiti via wikio per ormai ovvi motivi) che stanno spuntando come funghi da parte di tutti, indipendentemente dalla rispettive prese di posizione, alla fine ho riscontrato un modello già tristemente noto: tutto nasce come gioco, il gioco comincia a essere preso troppo sul serio, il gioco si rompe. La prima volta che ho assistito a film simili è stata una dozzina di anni fa su usenet: cambiano gli attori, la scenografia e la sceneggiatura, ma la storia di fondo rimane sempre la stessa come nelle più classiche americanate cinematografiche. Da qui il titolo, rappresentato da una nota catchphrase con tutto il carico di ironia con la quale viene utilizzata. Internet: serious business. Ma ci starebbe bene anche LOL INTERNET… o meglio, LOL BLOGGERS.

Da qualche settimana è stata rilasciata la sesta versione stabile di Slax, una distribuzione Linux creata espressamente per essere installata su chiavette USB per un’estrema mobilità. Come dice il motto: il tuo sistema operativo tascabile. Finalmente ieri sera ho trovato il tempo per aggiornare la versione 6.0 RC6 che avevo installato sulla mia pendrive MyFlash da 512MB con la recente versione 6.0.2 e devo dire che il tutto risulta molto più stabile pur non essendo esente da qualche glitch e bug qua e là, comunque complimenti a Tomáš per questa release.

L’utilità di Slax è indubbia: con una pendrive di piccole dimensioni (anche da 256 MB dal momento che la distribuzione di base occupa solamente 190 MB) si ha a disposizione un sistema operativo relativamente completo e intuitivo, anche grazie ai software già presenti nella suite KDE di cui attualmente è inclusa la versione 3.5.9, ma che può essere esteso facilmente attraverso il caricamento di moduli lzm aggiuntivi anche nel corso dell’esecuzione stessa del sistema. Ovviamente possono esservi delle esigenze particolari che Slax di base non può soddisfare e per le quali occorre mettere mano al sistema, del resto i compromessi sono necessari quandi si gioca al ribasso con le dimensioni del sistema.

Per uno come me, a cui spesso capita di incappare in contenuti scritti in giapponese, la rimozione dei font asiatici nella versione stabile di Slax può rappresentare un problema anche se di banale risoluzione: nel mio caso è bastato scaricarli e aggiungerli in un modulo lzm che li caricasse nella directory dei font TTF all’avvio del sistema. La creazione di un semplice modulo partendo da una directory con i file già disposti in una struttura uguale a quella del sistema è piuttosto banale grazie all’utility da riga di comando dir2lzm o alla relativa voce presente nel menù contestuale di KDE. Un altro problema nell’ottica della visualizzazione dei caratteri di lingue orientali o più in generale non latini è rappresentato dal modulo italian.lzm, scaricabile a parte dal sito, che offre la localizzazione del sistema in italiano configurandolo tuttavia con il charset ISO-8859-1 quando in realtà UTF-8 sarebbe decisamente più adeguato in situazioni simili. In questo caso è stato necessario creare il locale it_IT.UTF-8 utilizzando localedef per poi rifare il modulo italian.lzm (estraendone i contenuti con lzm2dir) affinché ne includesse il risultato, infine ho dovuto modificare lo script /etc/profile.d/lang.sh affinché esportasse direttamente le variabili LANG e LC_ALL valorizzate con it_IT.UTF-8 anche se devo ancora verificare se c’è un modo migliore senza toccare questo script. Il resto è semplicemente questione di impostare correttamente l’encoding di applicazioni KDE come Konsole ma anche di quelle eseguite nel terminale come ELinks o weechat (entrambi supportano Unicode, basta configurarli correttamente), memorizzandone poi i relativi file di configurazione in un modulo a parte. Nonostante sia possibile eseguire Slax con l’opzione di boot changes che, grazie ad aufs, permette di memorizzare in una directory o in un file tutte le modifiche effettuate durante una sessione live del sistema, personalmente per tutte le configurazioni di KDE o delle applicazioni che per me sono particolarmente ricorrenti preferisco usare modulo lzm dedicato, permettendomi di portare più facilmente le stesse su più chiavette o di averne un backup più comodo (anche se a ogni modifica da tenere sono costretto a rifare il modulo stesso, operazione veloce ma comunque più scomoda anche se ormai non troppo frequente).

Attualmente sul sito non ci sono molti moduli ma sul forum è possibile trovare qualcosa in più realizzato dagli utenti, fortunatamente però la loro creazione in totale autonomia spesso non è un’operazione troppo complessa soprattutto se si parte da un pacchetto tgz per Slackware 12, distribuzione su cui è basata Slax6. In questo caso gli ingredienti necessari sono rappresentati dal pacchetto tgz da convertire in lzm, l’utility tgz2lzm inclusa di default in Slax e un po’ di attenzione per le eventuali dipendenze necessarie all’esecuzione dei programmi. Per esempio la creazione del modulo lzm per Opera 9.26 partendo dal tgz per Slackware 12 è molto semplice: da terminale, il comando tgz2lzm opera-9.26-i486-1kjz.tgz opera-9.26-i486-1kjz.lzm si occuperà di generare il vostro modulo pronto per l’installazione live o per essere memorizzato sulla vostra chiavetta USB nelle directory modules (per i moduli da caricare automaticamente all’avvio del sistema) o optional (dove memorizzare tutti gli altri moduli che possono tornare utili, più che altro una convenzione in questo caso). Nel caso di altri programmi che richiedono determinate dipendenze occorre verificare e scegliere come agire, per esempio ELinks vuole la libreria libjs.so che è disponibile tramite SpiderMonkey per cui le possibili soluzioni sono due:

• creazione di due moduli, uno per ELinks e uno per SpiderMonkey, da caricare separatamente.
• creazione di un modulo custom per ELinks che contenga direttamente libjs.so.

Di norma preferisco tenere in un modulo separato le dipendenze che possono essere ricorrenti o richieste da altri software e unire nello stesso modulo quelle più rare, ma diventa anche una questione di preferenze. Con altre utility c’è la possibilità di creare moduli lzm partendo anche da pacchetti deb o rpm, ma non è certo la soluzione migliore dal momento che le differenze dettate dalla natura dei pacchetti di origine e dei sistemi target degli stessi potrebbe introdurre qualche noia di troppo.

Tutto sommato Slax6 sta mantenendo le aspettative delle precedenti RC pur necessitando ancora di lavoro. Sicuramente il fatto di essere un sistema basato su KDE la rende una distribuzione live che necessita di scendere a qualche compromesso per un’esecuzione ottimale quindi non è particolarmente consigliabile l’esecuzione su computer vecchi e/o con poca RAM (credo che un minimo veramente accettabile sia 128 MB), inoltre il sistema a moduli può essere comodo e facile da utilizzare ma al tempo stesso difficoltoso da mantenere per le varie dipendenze, non esistendo un sistema stile Apt o Yum che le gestisca. Tutto sommato però trovo che per il suo scopo principale, ovvero l’esecuzione live da pendrive USB di un sistema piuttosto completo, Slax abbia una marcia in più rispetto ad altre soluzioni.

Supponete di avere in ufficio una workstation da diverso tempo, questione di qualche anno.
Supponete che questa workstation, un bel giorno, decida di non accendersi più.
Supponete però di averla acquistata, a suo tempo, con 3 anni di garanzia.
Supponete ora di avere un dubbio: ma sarà ancora in garanzia?
Supponete a questo punto di andare a controllare…
… e supponete di scoprire che la garanzia è scaduta esattamente DUE giorni prima.

Beh a questo punto potreste benissimo supporre la reazione, ma in realtà DELL ha deciso di intervenire ugualmente come se la workstation fosse ancora in garanzia. Una mossa intelligente, non gli costa praticamente nulla è ci fanno un’ottima figura. Tutto è bene ciò che finisce bene, ma dopo quest’ultimo evento si fa sempre più insistente il mio dubbio che nei vari prodotti vi sia un timer impostato alla scadenza delle relative garanzie… ma pensandoci meglio, dev’essere semplicemente la sfiga ad avere 12 decimi di vista.

Mercoledì mi è arrivato un access point La Fonera 2200 (ovvero l’ultimo modello attualmente disponibile) dopo averlo recuperato da una persona che ne aveva uno di troppo e non sapeva che farsene. Inutile dire che non sapevo cosa farne delle funzionalità offerte dal firmware originale Fon per cui ho provveduto a sostituirlo subito con DD-WRT. Non intendo soffermarmi su metodi e opzioni per flashare la vostra Fonera con firmware alternativi perché per internet potete trovare tanta documentazione da avere solo l’imbarazzo della scelta (per andare a colpo sicuro vi rimando a un articolo piuttosto recente di WiFi-ita inerente proprio DD-WRT), piuttosto vi racconto cosa mi è successo che può essere una casistica un po’ più interessante.

Partirò dalla morale della storia: se avete il modello 2200 con installata una delle ultime release di DD-WRT (v24 RC6 nel mio caso), prima di effettuare le operazioni di abilitazione e pulizia della partizione JFFS pensateci due volte perché parrebbero esserci problemi, una circostanza che posso confermarvi personalmente dal momento che si tratta dell’operazione che mi ha "consentito" di inchiodare La Fonera nel giro di 2 ore dal primo boot. Ciò che rende particolarmente noiosa questa condizione è che il vostro access point risulterà totalmente irraggiungibile via rete (non emette nemmeno pacchetti ARP verso la rete, per intenderci), per cui il ripristino è fattibile solamente attraverso il collegamento seriale per avere accesso diretto a RedBoot e quindi alle fasi iniziali di avvio del device. Vi è una quantità altrettanto nutrita di documentazione per poter accedere alla vostra Fonera via seriale, anche in questo caso vi indirizzo a un articolo completo e in italiano.

Riassumendo: mercoledì sera ho ricevuto La Fonera ma è stata inesorabilmente brickata dopo solamente 2 ore, giovedì ho studiato il problema con mio padre dal momento che è lui l’elettronico di famiglia (io non ci capisco molto e ogni tanto me ne pento), venerdì sono stati recuperati i pezzi necessari per la realizzazione dell’adattatore seriale (sono tutti componenti facilmente reperibili e il materiale necessario non dovrebbe costare più di 10€) e sempre in giornata è stata realizzata e infine sabato mattina è avvenuto il ripristino di quello che era diventato semplicemente un bel mattoncino bianco e grigio.

Una volta collegato il computer all’access point tramite l’interfaccia custom fresca di realizzazione e poi avviato ho capito subito il motivo per cui risultava del tutto irraggiungibile via rete anche nelle prime fasi di avvio di RedBoot: all’accensione, un avvertimento comunicava un errore di checksum dell’immagine sulla flash e subito dopo partiva alla ricerca di un server BOOTP che, dopo qualche secondo, falliva con il messaggio Can’t get BOOTP info for device interrompendo del tutto l’avvio di RedBoot a meno di non interagire in questa fase con la pressione di un tasto. In questo caso ricaricare l’immagine del firmware originale, come inizialmente ho tentato di fare, non serve a nulla perché in realtà bisogna inizializzare nuovamente la configurazione della flash attraverso il comando fconfig -i impostando i parametri che vi verranno richiesti. Riporto come esempio la mia configurazione:

1. Run script at boot: true     (deve essere true, altrimenti RedBoot non avvierà boot script)
2. Boot script:
3. Boot script timeout (1000ms resolution): 10     (ritardo prima dell’esecuzione di boot script)
4. Use BOOTP for network configuration: false    (impostiamo parametri statici per la rete, no BOOTP!)
5. Gateway IP address: 192.168.1.100
6. Local IP address: 192.168.1.206
7. Local IP address mask: 255.255.255.0
8. Default server IP address: 192.168.1.166
9. Console baud rate: 9600         (velocità per collegamento seriale, lasciate questo valore)
10. GDB connection port: 9000      (porta TCP per l’accesso telnet a RedBoot, lasciate questo valore)
11. Force console for special debug messages: false
12. Network debug at boot time: false

Il parametro boot script può essere lasciato vuoto perché a noi interessa semplicemente che si avvii normalmente RedBoot in modo da poter procedere con il flash di DD-WRT via ethernet tramite Ap51 (in questa fase il parametro verrà impostato automaticamente), opzionalmente potreste provare prima a lanciare manualmente il comando fis load -l vmlinux.bin.l7 seguito da exec per vedere se l’installazione di DD-WRT è ancora viva, io ho preferito ripartire da zero. Una volta salvate le impostazioni e riavviata La Fonera tramite il comando reset per verificare il normale funzionamento dell’avvio di RedBoot, potete spegnere e collegare access point e computer con il cavo ethernet e procedere alle normali operazioni di flashing tramite Ap51. Ecco un piccolo report fotografico dell’evento, tanto per documentare il tutto:

Ne approfitto per ringraziare mio padre (tanto so che mi legge) per la realizzazione della parte di interfacciamento seriale, costruita tra l’altro pensando alla compatibilità con l’NSLU2 il cui collegamento seriale, rispetto a La Fonera 2200, ha semplicemente TX e RX invertiti, ecco spiegati i due jumper visibili sulla schedina nella seconda foto.