OpenWRT: non solo un firmware

Recentemente ho avuto la possibilità di provare OpenWRT su un access point, e devo dire che sono rimasto impressionato dalle possibilità del suddetto sistema operativo. Ma prima spieghiamo qualche secondo cosa è e cosa dovrebbe fare un firmware, giusto per fare un confronto tra OpenWRT e un firmware.

Un firmware è un software generalmente all-in-one o quasi, in grado di gestire solo e soltanto il dispositivo nel quale è stato inserito e per il quale è stato programmato. E' un microprogramma, giusto le istruzioni da dare al microprocessore del dispositivo per fare quello che deve fare (nell'esempio dell'access point, il firmware è stato sviluppato per fare solo da access point wifi).

Tuttavia molte volte gli apparati vengono progettati per fare molte cose e vengono limitati via software (costa di meno). Chiamatelo "override" delle "limitazioni", ma avere la possibilità di riscrivere quel software per sfruttare quei dispositivi al massimo delle loro potenzialità è sempre meta ambita per smanettoni, poiché ti basta un po' di lavoro per rendere il tuo semplice access point anche firewall, limitatore di banda, router tra varie subnet, e addirittura centralino per le reti VoIP.

OpenWRT è un sistema operativo progettato per non essere un firmware, ma un vero e proprio sistema composto da kernel + utility, e spinto molto sulla pacchettizzazione degli applicativi. Anche se molti firmware (soprattutto di router e access point) sono basati su OpenWRT o simili, questo rimane comunque molto configurabile. Inoltre sfizio di molti smanettoni e sistemisti, la possibilità di avere un accesso tramite SSH è il massimo.

Maggiori informazioni: http://openwrt.org/

Enrico

Effetto Brunetta

Tempo fa, il Ministro della Pubblica Amministrazione e dell'Innovazione Brunetta ha lanciato quello che si più definire del "terrorismo" contro "i fannulloni", minacciando questi di tante brutte cose (come il licenziamento) se vengono pescati. Nulla di negativo, chi non produce dovrebbe andare a casa.

Qualche giorno fa mi trovavo a vagare un po' con la mente su come poter far funzionare quel codice per generare le statistiche grafiche (per esempio nei sondaggi) utilizzando un "modulo" (chiamata in gergo informatico "Libreria") che avrei potuto riutilizzare quando mi fosse servita. Mi sarei semplificato il lavoro di riscriverlo ogni volta, o di cercare e di adattare le tante librerie che già ci sono. E poi non sarebbe stata la "mia libreria" :-P

Mi serviva quindi un mucchio di dati da poter analizzare, possibilmente che avesse senso e che mi avrebbe consentito di divertirmi con grafici e statistiche. Preso una sera da una forma di "Brunettite acuta", ho recuperato tutte le delibere comunali del Comune di Latina (il mio comune) dall'ultima elezione ad oggi, quelle presenti sul sito internet, e ho provveduto ad analizzarle.

Molte di esse sono state analizzate con successo dal mio "programma", alcune sono state aggiunte manualmente, e quindi non escludo che da qualche parte ci possa essere qualche errore.

I dati in questione si riferiscono alle presenze (e conseguentemente alle assenze) nel primo appello nelle votazioni delle delibere del Consiglio Comunale e NON in tutta la "discussione" che precede la votazione poiché purtroppo sul sito non sono presenti altri tipi di informazioni (verbali completi del Consiglio, oppure verbali di Giunta, ecc.).

Altra nota: i dati utilizzati sono di dominio pubblico, recuperabili dal sito del Comune (a questo indirizzo). Li ho semplicemente presi e messi in un grafico per far evidenziare la situazione.





Maggiori informazioni qui: http://enrico204.dyndns.org/comune/

Virtualizzazione: Processor emulators VS hypervisors

Virtualizzazione. Scritta così, può significare tante cose. Vediamo di spiegare i diversi tipi di "virtualizzazione".

Generalmente con virtualizzazione in ambito SOHO si intende l'operazione di avviare, in un sistema "host" già avviato, un kernel con i relativi tools (generalmente un sistema operativo) come se fosse "un processo". Gli viene assegnato un quantitativo di memoria, eventualmente un certo "tempo di processore" (ovvero quanta potenza del processore può usare), le varie schede, ecc. L'hardware della macchina virtualizzata quindi dipende solo per una minima parte (anche se importante) dal sistema reale: solo il processore e le memorie (disco e RAM) sono effettivamente una parte di quelle reali: eventuali schede o periferiche aggiuntive possono essere completamente virtuali (più schede di rete, più lettori cdrom). Questo permette, ad esempio, di avere a portata di mano un sistema operativo "diverso" che si usa per una sola applicazione che non funziona con il sistema usato nella macchina reale (pensiamo ad esempio ad un'applicazione scritta per Windows: si può far girare in una macchina virtuale sotto Linux, o viceversa). Questo è quello che si chiama "virtualizzazione completa", ovvero l'emulazione completa (o quasi) dell'intero sistema "guest". Un esempio di prodotti di questo genere sono qemu, VirtualBox, VirtualPC, VMware Workstation/Player, ecc.)

Esiste anche un altro tipo di virtualizzazione, chiamata paravirtualizzazione, presente soprattutto in ambito Enterprise (o semi-Enterprise). Questo tipo particolare di virtualizzazione, al contrario di quella "completa", non emula il "sistema virtuale", ma bensì divide le risorse del sistema reale tra più kernel/sistemi operativi, mediante un kernel che gira "al di sopra delle parti", chiamato Hypervisor (supervisore appunto). Questo Hypervisor, a seconda delle configurazioni, farà girare con più o meno priorità i vari sistemi operativi avviati.
Di solito, un Hypervisor ha bisogno di un sistema di controllo: facendo l'esempio di Xen, c'è una macchina GNU/Linux avviata con "priorità alta", in grado di controllare e di fornire delle impostazioni al kernel supervisore. Questo di fatto vuol dire che ci sarà una macchina virtuale che, per forza di cose, avrà come scopo quello di interfacciarsi con il supervisore, e di solito è chi progetta l'Hypervisor che stabilisce quale può essere il sistema operativo da utilizzare (GNU/Linux, Windows, Mac OS X, ecc.).
Alcuni sistemi inoltre sono in grado di spostare le macchine virtuali accese "al volo", con un downtime di circa 300 ms al massimo, cioò vuol dire che per l'utente la differenza non esiste. Le connessioni non vengono resettate, quindi ogni trasferimento di dati (sessione terminale remota ad esempio) continuerà senza alcun rallentamento visibile o downtime.
Un esempio di tali soluzioni sono: Xen, Microsoft HyperV, VMware ESX.

Ma quali sono i vantaggi di una o dell'altra soluzione? Certo, la virtualizzazione completa ci da un controllo maggiore del sistema guest, poiché possiamo personalizzarlo pressoché totalmente e possiamo applicargli limitazioni tipiche di un processo (in ambito UNIX ad esempio), mentre in un sistema dove l'ipervisore, solo se tale software è stato progettato per lo scopo si riesce a limitare l'uso delle macchine virtuali ad un certo "tot" di tempo di CPU. I vantaggi sono visibili tuttavia in campo "prestazionale": non c'è dubbio che, dovendo passare per un programma che simula un processore, il sistema rallenti, cosa che non succede se il processo/sistema operativo viene eseguito direttamente nel processore "reale" (in condivisione con altri processi).

Possiamo quindi desumere che, dove le prestazioni e la ridondanza sono importanti (in ambito aziendale), soluzioni di virtualizzazione che puntano a maggiori prestazioni, uniti alla possibilità di migrare in tempo reale le macchine virtuali da un server ad un altro (per permettere ad esempio manutenzioni programmate), sono la scelta migliore. Per gli sviluppatori, gli "smanettoni", soluzioni di virtualizzazione completa possono essere la scelta migliore, poiché incidono poco sul sistema "ospitante", permettendo un'elevata possibilità di configurazione nel sistema "ospitato".

Enrico

La mia personale opinione su Windows 7 beta

Riporto direttamente dalla mail che ho scritto per il LUG locale.

Dunque, oggi ho avuto l'onore (e l'onere) di provare $Finestre 7 beta.

Vi posso riassumere tutto in 5 "blocchi":

* Boot loader e roba "nascosta": chiaramente kernel NT di Vista. Nulla
di più, nulla di meno (per quanto si può vedere). Vedere dopo per "alla
scoperta della partizione system perduta".

* Boot sequence, splash screen: ecco, forse l'unica novità è che ora il
logo di $Finestre pare muoversi... o forse è qualche problema con la
scheda video :-P

* Desktop Environment: beh, questa è davvero bella: avete presente KDE
3.5? Avete presente la grafica del Vista? Avete presente tutti quelli
che tentavano di trasformare KDE 3.5 in Windows Vista? Ecco. La massima
espansione dell'interfaccia grafica è una specie di KDE un po'
vecchiotto. Ah, pare che sia pure sparita la barra con i gadgets...
Un'ultima cosa: ora la barra delle applicazioni non mostra più il titolo
delle finestre, solo l'icona. Buona fortuna. In più, il mouse è tornato
quello di una volta (a parte nell'installer), o almeno a me è successo
così.

* Installer: chiaramente 100% Vista. L'unica cosa che cambia è che
(udite udite), ora pare che il "system" (che spero si riferisca al
kernel e quattro cose per l'avvio) sia su una partizione separata! Wow,
*nix da secoli che permette di spezzettare il file system in giro per le
partizioni (pure remote, vedi NFS).

* In generale: readyboost ora è "perfettamente integrato", nel senso che
non funziona, come il resto delle cose (ok, magari è beta...). Ora
"ripristino configurazione di sistema" è diventato Windows Backup (in
associazione con ntbackup.exe), che è una specie di snapshot per zfs o
di svn applicato all'intero file system (ok cosa positiva, ma lo storage
comincerà a non essere più sufficiente se abilitato di default...), un
po' come lo shadow copy, ma stavolta è l'utente a metter mano.
L'algoritmo per il grafico di utilizzo partizione è quello da millenni,
con i classici due colori "fucsia" e "blu" e una torta fatta con i Lego
(niente anti-aliasing, sfumature e compagnia). No, i file non si possono
ancora chiamare AUX, COM1 e altro (proviene dal DOS questo limite). In
compenso, UAC è meno aggressivo, nel senso che non mi ha mai rotto
durante i cambi dell'orario o dello sfondo.

Che dire? 4 giga di spazio buttato per l'ISO, una connessione stremata
da un download (che *si può fare solo installando un ActiveX*, ergo solo
da Windows) altri 9 giga per il sistema base (leggasi, NO applicativi,
SOLO sistema) + 200 MB per una partizione nascosta con "il sistema".
Ovviamente NON voglio sapere cosa sono tutti quei giga (tolto il sistema
base).

Giusto per curiosità poi, sono andato a vedere cosa c'era nella
partizione "system". A prima vista, nulla. Ma le proprietà dicono che
30-40 mega di roba c'è, ergo disabilito il "nascondimento dei file
nascosti". E scopro che "esegui" non esiste più (non posso lanciare
control.exe). E scopro anche che non mi fa vedere nulla di più, come se
fosse vuota. Ergo apriamo cmd.exe (ora si fa dalla stessa barra dove si
cercano i programmi) e diamo dir /A:SHR E:\ . Sorpresa, il backup
dell'mbr, e nulla più. Ovviamente le dimensioni non corrispondono,
quindi c'è qualcosa che mi nasconde. Riavvio con Slackware Linux Live
(che bello, durante lo shutdown c'è stata una BSOD), e scopro che c'è un
Cestino (forse perché l'ho de-nascosta e gli ho assegnato una lettera) e
il classico System Volume Information che non mi ha comunque fatto
vedere prima, sotto $Finestre. Wow, c'è anche una directory Boot/ ,
contenente un tool per il test della memoria (ma chissà da dove gli è
venuta quest'idea?) e pare che ci siano file del boot loader, anche
multilingua.

E per quanto NTFS faccia il vicino a file system evoluti come zfs,
reiserfs (IMHO ottimo per tanti file piccoli) o xfs, o all'imminente
ext4 (se rispetta quello che dice), i termini di paragone sono
nettamente diversi. Prestazioni, features, supporto. Provare per
credere.

Ovviamente ho dovuto dare alla macchina virtuale 700 mega di ram,
altrimenti non girava. E altrettanto ovviamente ho scoperto subito che
se la volevo usare, dovevo spremere fino a 1,5 giga. E per fortuna Linux
mi permette di arrivare fin lì, avendo 2 giga di ram. Dunque mi chiedo,
se è un mattone peggio di Windows Vista, vale la pena spendere altri
soldi per "aggiornare" il software e aggiornare per forza l'hardware?
Meglio tenersi Vista, oppure fare il salto diretto da Xp a Vista, o
meglio ancora Linux, visto che io ho continuato a leggere la posta e
navigare su internet mentre avevo un mattone che mi succhiava quasi
tutta la ram e quasi tutto il processore.

Mah... spero sia davvero una beta NON finale.

Enrico

Scrivere un protocollo di trasmissione dati

Dunque, mi son trovato diverse volte a "smanettare" con (ed a creare veri e propri client per) vari protocolli di comunicazione che si appoggiano al TCP/IP, e ci sono due diversi "filoni" che ho identificato e che uso spesso per pensare a come potrebbe essere architettato il "protocollo" di trasmissione delle informazioni del server e del client che sto sviluppando in uno dei tanti progetti.

In particolare, dal mio punto di vista, ci sono quelli "telnet-compatibile", e quelli non "telnet-compatible". Anche se la descrizione può sembrare "strana" (telnet è a se un protocollo), in realtà l'intenzione è quella di indicare due tipologie di cui una è molto simile a come telnet invia le informazioni.

In uno dei tanti che ho avuto modo di leggere/interpretare/studiare, l'IRC è uno di quelli che più mi piace, e il NAP (famoso per Napster) è l'altro. Sono due molto simili, ma anche molto diversi. In cosa differiscono?

Un protocollo "telnet-compatible", o meglio "text/plain", come l'IRC, prevede l'invio di un comando di testo ASCII, come ad esempio JOIN, PART, ecc. e l'invio di parametri, separati da uno spazio. L'invio effettivo di un comando si ha con un ritorno a capo. Un po' come un comando da terminale. Questo lo rende usabile anche con un "client grezzo" come telnet oppure netcat. Questo può essere un vantaggio per chi non ha un client installato, oppure per le prove, poiché tutti i sistemi hanno un qualcosa di simile ad un telnet che si può usare per collegarsi e "dialogare con il server".

Cosa diversa è il protocollo NAP. Tale protocollo prevede l'invio di 2 byte per indicare la lunghezza del terzo "campo" che sarebbero i dati, e una seconda coppia di byte (secondo campo) che identifica il codice del comando (tra l'altro queste prime coppie sono in formato little-endian, cioè "il byte meno significativo viene prima"). E poi ovviamente i dati in ASCII o giù di lì. Senza ritorni a capo, il terzo campo finisce infatti esattamente alla lunghezza inviata nei primi due byte. Come si può capire, questo protocollo è praticamente impossibile da utilizzare mediante netcat o telnet, poiché richiede l'inserimento di codici che probabilmente non saremo in grado di inserire con la tastiera.

Ora, avrebbe poco senso parlare di "protocollo migliore" in generale, ma ha molto senso se facciamo un'analisi approfondita di quello che sono i limiti dei due, e dove poterli applicare con sicurezza.

Un protocollo, come il NAP, che ha un valore che rappresenta la lunghezza, ha il grosso limite di avere una dimensione massima dell'intero pacchetto ad un valore ben preciso, nel caso del NAP si aggira intorno a 2^16, ovvero 64K (che, anche se può sembrare tanto, potrebbe essere poco delle volte) più ovviamente 4 che sono la coppia di byte della dimensione e la coppia di byte del codice del comando; anche i comandi sono limitati a 64K. Nel protocollo IRC invece, tale limite è fissato dalle specifiche a 510 caratteri (gli altri 2 sono per il ritorno a capo e l'avanzamento riga, CR-LF), ma nulla vieta di "derivare", aggiungendo praticamente infinite posizioni. E' ovvio però che a quel punto si "sovraccarica" il pacchetto di dati che potrebbe rallentare il server, fino a provocare malfunzionamenti: dare un limite di 100 mega al pacchetto infatti, può voler dire che quando 5 persone inviano un solo pacchetto (anche di login) il sistema debba allocare minimo 500 mega in RAM per gestire il buffer in ingresso. E se fossero 50 persone?

Il fatto di avere un terminatore "di pacchetto" (come la coppia CR-LF, ovvero l'invio, dell'IRC) inoltre, può portare diversi problemi: il principale è che tale carattere non deve essere presente nei parametri del comando, altrimenti il "parser" del messaggio finisce l'analisi lì. Si potrebbe allora sostituire tale carattere, in fase di invio, con un'altra sequenza, ma poi il destinatario non saprà (programma o utente) se la stringa XY era riferito ad un ritorno a capo (o qualsiasi carattere fosse il terminatore), oppure proprio a XY. Si perde insomma la possibilità di inviare il carattere che si usa come fine messaggio, amenoché creare diversi disagi all'utente, o complicazioni nel codice.

Tirando le somme, ogni protocollo ha dei limiti, e un'attenta valutazione prima di iniziare a sviluppare il codice può essere di aiuto nella fase implementativa, e per scongiurare spiacevoli sorprese.

Enrico

Collezionare dati in Java: database o classe serializzabile?

Eccomi qui, a scrivere di uno dei miei programmi (o librerie, ancora non so come strutturare la cosa) che è tanto in voga in questo periodo della mia vita (leggasi: quello che voglio fare nelle vacanze). Tanto per farla corta, si tratta di un server che accetta connessioni da client che si autenticano, e mantiene certe informazioni su di essi. Trattasi di server che, molto probabilmente, non gireranno sotto "cluster" o diavolerie del genere, ma in vecchi rottami casalinghi od ospitati su macchine virtuali, e quindi molto probabilmente non avranno la fortuna di avere un server database in una macchina "dedicata".

Tralasciando gli accrocchi strutturali dei vari protocolli, ecc., mi son trovato di fronte al problema di creare un sistema in grado di memorizzare questi dati, possibilmente anche molto "complicati", e di accederci in modo veloce. Questo mi lascia sostanzialmente di fronte a due "grandi" possibilità: database e "non database".

I vantaggi di una soluzione con database sono subito chiari: tali software sono scritti per compiere quel tipo di lavoro, quindi la possibilità che il codice sia ottimizzato è superiore. Inoltre, la ricerca è semplice, e soprattutto si demanda questa (come anche altre operazioni "semplici") ad un motore esterno (aka: ce ne freghiamo e ci concentriamo sul resto). Il che sostanzialmente è buona cosa, ma alcune volte non basta.

Immaginiamo di dover memorizzare una lista di utenti, e che tale lista contenga diversi campi, tra cui "nomeutente" (che guarda caso ci servirà per pescare la riga dell'utente all'autenticazione) e "prodottipreferiti" (una lista di prodotti diversa per ogni utente). Ora, un database sarà un po' più complicato da gestire con questo ultimo campo, visto che si tratta di una lista e non di un "normale dato". Questo infatti ci porta a creare una seconda tabella con i dati delle liste, e mediante dei campi "utente", collegarli all'utente (in uno dei tanti casi, alla fine comunque tutti rispecchiano questo concetto). Inoltre, in ambito di diffusione del prodotto, porta un grave problema: il motore del database, eccezion fatta per SQLite e soluzioni simili, va portato dietro, oppure va messo tra i prerequisiti, che non tutti potrebbero avere (e questo quindi complica la vita a chi deve utilizzare il programma).

Potremmo quindi creare una classe con i campi qui di sopra, e creare un vettore di oggetti di questa classe. Questo sarebbe un sistema molto più vicino al nostro utilizzo dei dati, ma deve essere implementato "in toto", e la possibilità di ottimizzazione è bassa. Inoltre, va previsto un modo per salvare gli oggetti in file, e qui per fortuna Java ci da una mano, grazie alla possibilità di serializzare gli oggetti.

Tirando le conclusioni, possiamo dire che, se da un punto di vista architetturale e algoritmico utilizzare un motore di database esterno porta vantaggi notevoli (escludiamo la possibilità di avere il database su macchine diverse dal server, come detto all'inizio), quando i dati cominciano ad essere complicati, il modello del vecchio database "a relazioni" non funziona poi tanto bene, o almeno diventa molto più complicato di costruirsi una sorta di mini-database interno a mano.

Enrico