Archivi tag: software libero

VP8: Apple contro tutti

Rispondi
Google I/O

Pat Hawks via Flickr

Sembrerà male, sarà poco elegante, ma lasciatemelo dire: “l’avevo detto”. Qualche tempo fa’, all’epoca dell’acquisizione di On2 da parte di Google ed in piena battaglia sulla questione dei codec (con Mozilla che all’ora si schierava apertamente a favore di Theora e contro H.264), si discuteva dei possibili sviluppi allo scenario dell’informatica (e di Internet in particolare) che questo passo avrebbe portato. Il maggior valore di On2 infatti (quello che Google voleva verosimilmente acquistare), sta decisamente nel codec VP7 (del quale viene oggi annunciato il successore, VP8 per l’appunto) ed era facilmente prevedibile che Google preparasse una mossa “ad effetto” rilasciando questo codec sotto una licenza libera (nella fattispecie si tratta della licenza BSD) e senza “royalties”, andando così a dichiarare guerra aperta ad Apple (su tutti) ed al codec H.264 all’interno delle specifiche video di HTML5.

Cos’è un codec?

Ok, mi rendo conto, troppe sigle. Urge una spiegazione per chi non mastica pane e bit da mattina a sera. La rappresentazione di immagini su uno schermo (sia questo quello della televisione o quello di un pc, o di un telefonino poco importa), necessita senza eccezione alcuna della definizione di una “rappresentazione informatica” dei dati che si vogliono far apparire. Questa rappresentazione (che può assumere molte, moltissime forme), viene definita “codec“. Per chiarire il concetto di “codec”, facciamo un esempio pratico: ci troviamo nella condizione di voler visualizzare sullo schermo di un pc un’immagine completamente bianca (il caso più semplice); il meccanismo più semplice per rappresentare digitalmente questa immagine è quello di descrivere pixel per pixel i colori che la compongono; assegneremo quindi una scala di colori (dal bianco al nero, passando per tutti i vari colori), partendo da 0 (bianco) ed arrivando, ad esempio, a 255 (nero); dopodiché inseriremo in un file le codifiche di ogni singolo pixel che compone la nostra immagine, uno di fianco all’altro; nel momento in cui (dotandoci di un apposito programma che sia capace di “decodificare” il nostro codec), andremo a visualizzare l’immagine, sarà sufficiente leggere i codici colori e “colorare” i pixel dello schermo sulla base dei colori indicati.
Naturalmente un codec così semplice ha delle limitazioni notevoli

  • prima di tutto non è in grado di mostrare immagini in movimento (potremmo però comporre più rappresentazioni in successione, creando il movimento)
  • secondariamente è molto poco efficace: un’immagine 1920×1080 pixel (il formato del “Full HD” ci costringerà a definire 2.073.600 pixel, anche se fossero tutti bianchi. Un’idea potrebbe essere quella di indicare le sequenze di pixel colorati allo stesso modo in versioni “ridotte”, o assegnare “codici” a sequenze definite e ripetitive di pixel…
  • c’è poi la questione del codice colore: 256 colori sono decisamente pochi per rappresentare con un’immagine di buona qualità. L’aumento del numero dei colori possibili però (e quindi della dimensione della rappresentazione del singolo pixel), fa crescere proporzionalmente la dimensione dell’immagine finale: se posso rappresentare 256 colori con 32bit (e quindi la nostra immagine di cui sopra da 2.073.600 pixel “peserà” 8.2 megabytes), rappresentarne solo 512 (il doppio) necessiterà di 64bit (e quindi arriveremo a 16.4Mb). Una “profondità di colore” che consenta immagini realistiche si aggira intorno ai 16.7 milioni di colori, portando la nostra immagine a dimensioni spropositate (svariate migliaia di gigabytes).

Ecco quindi il perché del fiorire di codec differenti: ottimizzazione delle prestazioni a parità di dimensione della rappresentazione digitale (con algoritmi di codifica più o meno complessi), velocità di codifica e decodifica e via dicendo. Anche la semplicità dell’algoritmo del codec stesso è un fattore molto importante: un algoritmo molto  complesso è difficilmente implementabile “in hardware” (dedicandogli quindi un chip che faccia il lavoro di decodifica), con ripercussioni notevoli sul consumo di batteria (un chip dedicato consuma meno del processore che esegue il software di decodifica) e sulla velocità di decodifica.

Di fronte a tutti questi codec, ci sono come al solito due vie per “standardizzare” l’uso di un codec piuttosto che l’altro: la via “de jure”, che prevede l’inserimento di un ben specifico codec all’interno di un formato, oppure la via “de facto” in cui è l’adozione massiccia (solitamente per via di caratteristiche tecnica inconfutabili) a dettare la standardizzazione del formato. Nel mondo reale, una “specifica” consente spesso di adottare codec diversi all’interno del “contenitore”: la sezione video delle specifiche HTML5 (la nuova versione delle specifiche HTML che consentono di creare pagine web “arricchite” senza bisogno di ricorrere ad “aiuti esterni” come Flash o player dedicati) è definito che si possano usare codec differenti sia per quanto riguarda il canale audio che quello video, il che ha portato fino ad oggi all’adozione di H.264 (codec video) e AAC (codec audio). Purtroppo il formato H.264 è proprietario e (soprattutto) gravato dalla necessità di pagare una “tassa” (royalty) al proprietario del codec stesso, cosa non possibile nel caso di software libero (sviluppato cioè, semplificando, sotto la spinta di una comunità di sviluppatori e non di un’azienda che possa farsi carico del pagamento della royalty stessa).

Dicevamo…

Tornando alla discussione iniziale, la scelta di Google di rendere il successore del codec VP7 (acquisito attraverso l’acquisto On2), detto VP8, libero ed esente da royalty, oltre che prevedibile, apre un nuovo scenario, consentendo l’implementazione delle specifiche HTML5 attraverso codec liberi e royalty-free (affidando la parte audio all’ottimo codec Theora). Purtroppo VP8 è al momento ancora un codec incompleto (e le specifiche sembrano essere ancora poco precise) ed apparentemente coperto da una serie di “software patents” (i brevetti software che in Europa si cerca di scongiurare da svariati anni ma che sono da anni legge negli Stati Uniti) che renderebbero Google un soggetto facilmente attaccabile sul fronte giudiziario. Visto che però a Mountain View non sono degli sprovveduto, ritengo che abbiano in mente tempi e modi per risolvere queste problematiche.

Il motivo per cui questa scelta da parte di Google porta tanto scalpore, è da ricercarsi nella particolare congiuntura in cui il mondo del web si trova oggi:

  • il ruolo sempre più importante del video nel web (ed il particolar modo il fenomeno YouTube, acquisito da Google qualche anno fa) e la scarsa adattabilità di Flash nel ruolo di player più usato (per via sia della parte software, proprietaria e ormai vecchiotta, sia del codec scelto), portano particolare attenzione sulle nuove specifiche HTML5 ed in particolare proprio sul frangente di audio e video.
  • il sempre maggior affermarsi di Firefox come vero antagonista di Internet Explorer sul panorama dei browser, con una percentuale di “market-share” non più trascurabile (oltre il 25%), rende necessaria un’attenzione particolare alle tematiche del software libero, che Google ha sempre ascoltato in modo favorevole.
  • il sempre maggior diffondersi di “device mobili” (iPhone, smartphone, palmari, netbook, tablet e chi più ne ha più ne metta) con caratteristiche computazionali spesso inadatte a fare computazione pesante ma orientati sopratutto alla fruizione di contenuti web, tra cui per l’appunto i video, impone un occhio di riguardo alla tematica dell’implementabilità in hardware.
  • è in corso da parecchio tempo un braccio di ferro tra Adobe (proprietaria di Flash) ed Apple in quanto sugli iPhone non c’è il supporto a Flash. Apple si è giustificata dicendo che il player Flash è un software di scarsa qualità (cosa sulla quale potrebbero trovarmi parzialmente d’accordo, per altro) e che le specifiche del codec sono tali da rendere difficoltosa e costosa l’implementazione in hardware, fondamentale per una maggior durata delle batterie delle device mobili. Apple ha poi presentato, qualche tempo fa, una propria proposta per risolvere il problema, Gianduia (che sarebbe un’alternativa non solo a Flash ma anche a Silverlight, di Microsoft), che non ha però visto alcuna reazione da parte di Google, che evidentemente preparava il lancio di VP8.

Andiamo allora ad analizzare le reazioni dei “player” più importanti di fronte all’annuncio di Google:

  • I proprietari di Flash (Adobe per l’appunto) sono stati i primi a replicare all’annuncio di Google, affermando che il formato VP8 sarà immediatamente supportato dal player Flash. Per Adobe l’orizzonte sembra piuttosto scuro: l’arrivo di HTML5 comporterebbe il progressivo abbandono di Flash come colonna portante dell’animazione sul web, della quale oggi è l’unico indiscusso interprete. L’implementazione di VP8 potrebbe consentire di mantenere un certo respiro per via della “backward compatibiliy” (i siti consentiranno l’accesso ai propri contenuti sia tramite Flash, per i browser più vecchi, sia attraverso HTML5). Andare a braccetto con Google significa inoltre garantirsi l’enorme visibilità legata a YouTube (che costituisce una parte preponderante del video online) e mette Adobe in una posizione dominante, sebbene riflessa.
  • Dopo il sostanziale “flop” di SilverLight e Bing, Microsoft cerca una via d’uscita per tornare ad essere un player importante del mondo del web a prescindere dalle (sempre minori) quote di mercato di Internet Explorer. L’orientamento alla “compatibilità” è già stato dimostrato con la maggior attenzione alle specifiche HTML e CSS delle ultime release del browser “made in Redmond” ed in Microsoft non devono essersi lasciati sfuggire il fatto che se Google va verso VP8, il web va verso VP8. Prendere la palla al balzo era fondamentale e l’annuncio del supporto a VP8 da parte di Internet Explorer 9 non ha tardato (così come non aveva tardato l’annuncio del supporto a H.264 non troppo tempo fa).
  • La posizione di Apple sulla questione VP8 era attesa da giorni e solo questa mattina si è appreso del parere “contrario” di Cupertino. Apple afferma che le royalty su H.264 non sono tali da renderle fastidiose (purtroppo nel mondo del software libero, costose o meno, non si possono pagare perché non c’è un ente preposto al pagamento stesso ed espone critiche tecniche sul formato VP8 stesso, considerato espressamente concepito per il web ed incapace di offrire contenuti di alta qualità, soprattutto se comparato al più prestante e complesso codec MPEG-4.

Si instaura (o meglio, si ravviva) così un braccio di ferro tra il crescente mercato delle device mobili targate “Apple” (numericamente non trascurabile) e quello del software libero, che certo non farà bene ad una crescita “sana” del web. Purtroppo per Apple, in questo caso, la posizione di Google non sarà verosimilmente una posizione “d’attesa”, e “tagliare fuori gli iPhone dai contenuti video di Youtube” potrebbe essere una minaccia in grado di smuovere non poche poltrone, a Cupertino…

Dei rischi del Cloud Computing

8 Repliche
chrys via Flickr

chrys via Flickr

Trovo (colpevolmente) tempo solo oggi di leggere questo articolo di Luca Annunziata che su Punto Informatico riprende le posizioni di Richard Stallman riguardo al Cloud Computing.
Vale forse la pena, prima di inoltrarci nella discussione, di spiegare brevemente ed in termini facilmente comprensibili il concetto: si parla di Cloud Computing riferendosi al diffondersi delle “Web Application”, della disponibilità di dati in remoto ed accessibili da device diverse; l’esempio più lampante è sicuramente costituito dal sistema delle Google Apps: posta elettronica, rubrica, calendario, feed reader, suite per l’ufficio e storage documentale accessibili da qualsiasi pc, telefonino, smartphone dotato di connessione ad internet, con analogo accentramento di tutte le funzionalità e configurazioni delle varie applicazioni (filtri antispam, regole di catalogazione di posta ed eventi, dettagli dei contatti, indirizzi degli appuntamenti…)

I rischi che Stallman sottolinea nell’intervento ripreso dall’articolo di Luca sono indubbiamente rischi concreti (e non tengono conto del non indifferente fattore privacy!): nell’ottica del software libero, spostare dati e computazione lato server significa perdere il controllo su codice sorgente e dati, segnando una importante vittoria per il software proprietario. Purtroppo quello che ci troviamo ad affrontare, è un problema ben più complesso di quello del semplice controllo del software che gira sul nostro computer: in un’ottica non più di “uno a uno” (io ed il mio portatile) ma di “uno a molti” (un “application provider” ed i suoi innumerevoli utenti), anche l’uso di tecnologie “libere” lato server è difficilmente verificabile e controllabile. Su questo fronte, la differenza tra software libero e software proprietario decade (a favore del software proprietario) in quanto l’utente non ha più la possibilità di verifica.

In un mondo dell’informatica che passa sempre più dall’elaborazione locale all’elaborazione online, è questo un problema che va analizzato, compreso ed affrontato, non negato o “ignorato” come Stallman propone di fare. Il guru del software libero infatti suggerisce: “fate il vostro lavoro con il vostro computer usando software libero”.
Bello, figo, ma se non ho il computer con me? Se volessi davvero non dover accendere il portatile, magari in auto, per recuperare l’indirizzo di un contatto con il quale ho appuntamento per poterlo impostare nel navigatore satellitare? Rinunciare ai progressi della tecnologia non credo sia la risposta giusta al problema.

Quando Stallman si trovò di fronte al dominio dei sistemi operativi proprietari, suggerì forse di ricorrere all’uso di carta e penna? No.
Ho l’impressione che con gli anni Stallman si stia arrugginendo ed arroccando su posizioni non difendibili, e questo fa molto, molto male al movimento dell’opensource…

Guardiamoci in faccia e contiamoci

10 Repliche
MIKELECSS via Flickr

MIKELECSS via Flickr

E’ ormai un po’ di tempo che mi dedico all’attivismo legato al Software Libero. Ne ho fatte un po’ di cotte e di crude ma sono “sul fronte” ormai da 6-7 anni e ho visto il panorama cambiare con il tempo. Qualche giorno fa, scambiando due chiacchiere con un amico, mi sono trovato a confrontare come questa evoluzione abbia influito sul movimento stesso, sulla sua composizione, sulle sue potenzialità ed ho sentito il bisogno di buttare giù quattro parole, nella speranza che possano magari servire come spunto, come punto di partenza per una discussione più articolata che porti, perché no, perlomeno ad una presa di coscienza da parte degli attivisti (considerando che a breve si terrà la ConfSL a Bologna…)
Inutile (ma doveroso) precisare che si tratta solo e solamente di pensieri a ruota libera, frutto della mia mente malata e non imputabili a nessun altro al di fuori di me.

Per cominciare, credo sia necessario esprimere il mio punto di vista sulla strutturazione dell’attivismo del Software Libero in Italia (ma non solo in realtà): si tratta di un movimento essenzialmente legato a due tipologie di raggruppamenti, quella “tematica” e quella “geografica”.

  • I (pochi, pochissimi) gruppi “tematici” si ritrovano quasi interamente su internet, spesso via mailing-list: entità come ILS (Italian Linux Society) o l’Associazione Software Libero hanno l’obiettivo di porsi come punti di riferimento a livello nazionale, abbracciando l’intero territorio italiano, e trovandosi quindi costretti a concentrare le discussioni in un luogo “virtuale” (una o più mailing-list tematiche). Questi gruppi raccolgono al loro interno molti attivisti (quasi sempre gli stessi, per altro), anche di notevole spessore (tecnico ma non solo) e le discussioni che prendono vita in queste mailing-lists sono spesso e volentieri interessanti, argomentate, quasi “utili”.
    Il problema principale di questo genere di entità è duplice e legato alla “virtualità” intrinsecamente legata alla loro stessa natura stessa: da un lato non si “accede” se non iniziati a queste mailing-list (naturalmente non in quanto rifiutati, ma in quanto “non interessati”, “non coinvolti”), dall’altro non si riesce ad ottenere una efficace risposta operativa, da parte dei raggruppamenti “territoriali”, alle proposte/idee che vengono promosse (salvo qualche caso eccezionale), proprio in quanto i membri di questi raggruppamenti non sono “coinvolti” o “interessati” alla discussione in atto. Spesso è sucesso, inoltre, che il tentativo di “forzare” la risposta da parte dei raggruppamenti più legati alle realtà geografiche fosse da queste interpretato come una spinta autoritaria ed ha suscitato (più o meno giustificatamente) una reazione antagonista, facendo perdere ulteriore credibilità (e quindi “presa”) a queste realtà, in un ambiente che fà dell’autorevolezza il proprio motore trainante.
  • La componente “territoriale” dell’attivismo del software libero sono essenzialmente LUG (Linux User Group) et simili. Si tratta di realtà molto diverse tra loro per organizzazione e numero, ma con fini sostanzialmente identici: diffondere il software libero ed al contempo fare da punto di riferimento per gli utenti Linux delle immediate vicinanze geografiche. Per loro intrinseca natura, questi gruppi vedono una parte attiva (gli attivisti veri e propri) ed una parte meno attiva, interessata a partecipare solamente ad alcune sporadiche iniziative (magari solamente ai corsi che vengono spesso organizzati da questi gruppi); se il gruppo degli attivisti è sufficientemente ampio, è facile che la realtà in questione abbia forze a sufficienza per intraprendere propositivamente alcune iniziative a livello territoriale (contatti con gli enti locali, organizzazione di incontri ed eventi, partecipazione agli eventi nazionali che di tanto in tanto vengono organizzati). Altrimenti il gruppo resta sostanzialmente informale, poco più che un appuntamento fisso tra amici e conoscenti davanti a pizza e/o birra.

Ciò detto, la prima cosa che voglio constatare (e che mi viene confermata di anno in anno dall’esperienza sul campo= è che nonostante la sempre maggiore diffusione del software libero (e di Linux in particolar modo) tra i “non addetti ai lavori”, l’attivismo del software libero sta attraversando una crisi a dir poco profonda (in certi casi mortale): vuoi per ritrosia al ricambio generazionale, vuoi per scarso interesse da parte di coloro che si avvicinano al software libero con un concetto “utilitaristico” e non più “utopico” o “tecnico”, fatto sta che il numero degli attivisti tende a ridursi piuttosto che ad aumentare, con ovvie e spesso notevoli ripercussioni sulla capacità di agire dei gruppi stessi (indipendentemente dalla tipologia).
Si può ipotizzare che in quest’ottica vi sia una incapacità comunicativa di fondo, da parte degli attuali membri dei LUG, nel motivare ed invitare alla partecipazione attiva coloro che si avvicinano per i motivi più disparati al software libero; si potrebbe persino tirare in ballo una crisi socio-culturale e dei valori che spiegherebbe la diffusione dello stesso fenomeno anche in altri ambienti dell’attivismo, non strettamente legati al software libero.
Fatto sta che le reltà (territoriali e non) attive nel campo del software libero sono ormai in seria difficoltà e faticano a trovare forze per essere propositive ed efficaci, ma spesso anche solo per essere in grado di rispondere alla domanda di conoscenza ed informazione che il passaparola va ormai ingenerando: proprio in questi giorni mi sto scontrando con la necessità da un lato di organizzare una serie di corsi (gratuiti) sull’uso di Linux che ci sono stati chiesti e sollecitati da molti nostri “utenti”, e l’impossibilità dall’altro di individuare docenti e spazi adeguati all’erogazione di questo genere di corsi.

Un’altra considerazione è legata all’incapacità degli attivisti “di lunga data”, membri sia dei LUG che delle associazioni di respiro nazionale (gli “iniziati”, potremmo dire), di trasferire il patrimonio di idee, proposte, voglia di partecipazione e di attività dalle une alle altre. L’osmosi autorevole che dovrebbe (a mio avviso) essere il motore dell’attivismo del software libero si scontra quotidianamente con motivi spesso futili, che hanno però ricadute pesantissime sull’intero movimento; potrei portare qualche esempio pratico in questo senso ma non credo gioverebbe alla discussione.

A tutto questo si va ad aggiungere l’irrazionale ostruzionismo dei “fondamentalisti” del software libero: coloro che rifiutano a priori qualsiasi cosa non sia “libera al 100%” o abbia in qualche modo a che vedere con il mondo del denaro (aziende, sponsor…). Nonostante possa condividere la bontà di alcuni ragionamenti, trovo assolutamente irragionevole pensare di poter arrivare ad un risultato senza aver prima percorso a piccoli passi la distanza che ci separa da questo: come posso pensare di proporre a qualcuno l’installazione di Linux come sistema operativo quando mi sono sempre rifiutato di fargli provare Firefox ed OpenOffice.org sull’installazione di Windows che ha presente? O ancora più precisamente: come posso anche solo lontanamente pensare di rendere “interessante” un sistema come Linux se poi mi trovo ad impedire il funzionamento delle principali periferiche sul mercato perché impedisco (non “non installo di default”, badate) il caricamento di firmware binari?
Purtroppo il fondamentalismo è un problema con cui conviviamo da parecchio tempo (e ha già causato danni non indifferenti al movimento nel suo insieme), ma con la riduzione del numero generale di attivisti finiscono con l’incidere ancora maggiormente in percentuale. A fare da ciliegina sulla torta troviamo il fatto che questi “fondamentalisti” in genere sono anche spesso parte delle associazioni di respiro nazionale ed è li che mietono i danni maggiori, bloccando (od ostacolando) iniziative che sarebbero invece interessanti ed utili (anche qui, avrei esempi da fare ma mi limiterò a citare il Festival della Creatività…).

L’incapacità di coordinarsi tra gruppi territoriali, funzione che potrebbe essere splendidamente espletata dalle associazioni a carattere nazionale se riuscissero a fungere, autorevolmente e non autoritariamente, da “coordinamento” (prendete la parola con le pinze), è infine motivo di un ulteriore grave problema: senza arrivare alle dispute tra gruppi, quest’incapacità comunicativa porta banalmente a:

  • non condividere, promuovere o organizzare eventi: sarebbe tanto comodo poter contare sugli altri gruppi di un territorio nel cercare di organizzare eventi o iniziative, nella loro promozione…
  • moltiplicare inutilmente gli sforzi: ogni gruppo sufficientemente numeroso si trova di fronte alla necessità di preparare del materiale promozionale, informativo, formativo (testi dei corsi), ed ogni gruppo finisce con il farlo da se. Sarebbe tanto comodo poter contare sulla stessa filosofia alla base del software libero al fine di riprendere, migliorare ed adattare il materiale già realizzato dagli altri gruppi (Creative Commons questa sconosciuta), in un meccanismo virtuoso di review tra pari…
  • non avvalersi delle figure professionali che in alcuni gruppi possiamo trovare: pubblicitari, esperti di marketing, blogger e giornalisti, contatti con politici… sono tutte risorse di inestimabile valore, che se ben sfruttate potrebbero aiutare molti, moltissimi gruppi a promuovere le proprie iniziative in modo coerente ed organico.

Invece ci troviamo di fronte ad una comunità in crisi, spesso sopravvalutata da noi stessi in termini numerici ed organizzativi: alla LugConference di Roma di svariati anni fa questa questione era già stata sollevata e dibattuta; ci si era trovati d’accordo nella volontà di correre ai ripari, cercare di organizzarsi. Dopo tutti questi anni non solo la situazione non è migliorata, ma si è incancrenita al punto che oggi mette a repentaglio la sopravvivenza stessa delle realtà di cui ho detto.

I miei due centesimi… nella speranza che qualcuno mi smentisca…

Ebbene si, sono ancora vivo

1 Replica
Francesco Federico via Flickr

Francesco Federico via Flickr

Sono giorni che non scrivo. Per chi mi sta intorno i motivi sono chiari ed evidenti: lavoro, impegni, appuntamenti, rogne di vario genere (nulla di grave, fortunatamente)… soprattutto Fa La Cosa Giusta 2009 (scrivo dallo stand) che ha richiesto un pesante impegno per l’organizzazione e la partecipazione dell’Associazione LIFOS.

Ormai la manifestazione volge al termine (si chiude alle 18:00) e qualche considerazione vorrei spenderla, soprattutto riguardante due aspetti: la Crisi e la tematica del software libero.

Per quel che riguarda il software libero, avendo partecipato a tutte le edizioni della manifestazione (dal 2004 ad oggi), ho visto crescere l’attenzione su questo tema: i primi anni ci veniva chiesto se “linux si potesse mangiare”, poi si è cominciato a trovare qualcuno che ne avesse già sentito parlare, successivamente qualcuno che l’avesse già provato, oggi si comincia a parlare di business legato al software libero. Una crescita davvero impensabile fino a pochi anni fa, considerando soprattutto la tipologia di affluenza a questo genere di manifestazioni.

Sotto il profilo della crisi, invece, la forte affluenza all’edizione 2009 di Fa La Cosa Giusta può avere due diverse chiavi di lettura:  da un lato si potrebbe leggerla come un segno della crisi, con la ricerca del risparmio, della sostenibilità. Alternativamente lo si può leggere in positivo, come un segno di vitalità, di reazione, di ripresa o comunque di fiducia in settori che cercano nell’ecologia e nella sostenibilità una via per uscire dalla brutta situazione in cui versa il nostro paese…

Se qualcuno fosse interessato a questi argomenti (o semplicemente vuole passarci a trovare allo stand SL08), invito a fare un salto in Fiera Milano City, davvero 🙂

Aita aita, Sun chiude Mysql!

2 Repliche

Sales.Il mondo del software libero è qualcosa di davvero strano. Tutti hanno ben chiare le regole del gioco, tutti hanno ben chiaro il perché si faccia fatica a fare i furbi, eppure di tanto in tanto (a cadenza per altro piuttosto regolare) qualcuno se ne esce con storie al limite dell’inverosimile, che sollevano il panico tra gli utenti meno esperti e costringono sviluppatori e CEO a fornire inutili spiegazioni sulla direzione che vogliono prendere nello sviluppo.

L’ultima storia della serie, è senza dubbio rappresenta ta dall’annuncio che Sun Microsystem, dopo aver acquistato MySQL per oltre 1 miliardo di dollari qualche tempo fà, avrebbe deciso di rendere proprietario il prodotto. Ora, anche volendo per un attimo credere alla storia, ci sono alcune cose che dovrebbero far quantomeno venire la puzza sotto il naso:

  • Pare logico che Sun spenda 1 miliardo di dollari per comprare un software leader del mercato (proprio per il fatto di essere libero) e poi lo snaturi al punto da impedirne di fatto l’uso? La cosa funzionerebbe se Sun avesse tra le mani una valida alternativa da proporre, ma visto che non ce l’ha…
  • Se il codice sorgente della versione 5.0 di Mysql viene rilasciato sotto GPL, non c’è modo che venga chiuso. Sun potrebbe decidere di proseguire lo sviluppo sotto licenze proprietarie da un certo punto in poi, ma non potrebbe chiudere il codice precedentemente rilasciato, a partire dal quale un team di sviluppatori potrebbe tranquillamente proseguire il lavoro (esattamente come successo con XFree e Xorg, per chi non ricordasse).
    E’ il software libero, è così, non si scappa.

Come da prassi, negli ultimi giorni è giunta la smentita ufficiale, direttamente per bocca di Marten Mickos, ex CEO di Mysql AB (l’azienda che possedeva di fatto mysql) ed attuale SVP di Mysql per conto di Sun, il quale ha dichiarato che la decisione è stata presa ben prima dell’acquisto da parte di Sun (la quale anzi starebbe spingendo in direzione opposta) e riguarda solo ed esclusivamente lo sviluppo di add-on professionali dedicati ai clienti Enterprise (sulla cui licenza di rilascio non sono per altro ancora state prese decisioni formali), al punto che le nuove funzionalità avanzate di backup saranno incluse nella versione rilasciata sotto GPL.

Il mio parere è che ancora una volta si gridi “aita aita” ogni qual volta un’azienda si avvicini (anche se con le migliori intenzioni) al software libero. E’ davvero ora che la “comunità” prenda coscienza che il software libero è maturo per entrare nel mondo del business, mentre la comunità stessa non lo è, per certi versi…

Una licenza “guida” per la Pubblica Amministrazione?

Rispondi

Pubblico in calce uno stralcio di una mia risposta ad una mail che mi chiedeva un commento su un interessante post dell’avvocato Laura Garbati sul forum del CNIPA . Pubblico perché il tema è delicato e sono conscio che andrebbe affrontato in maniera più articolata ed argomentata delle poche righe che riporterò. Mi pareva interessante però tentare di fornire uno spunto di riflessione condivisa sull’argomento…

[…]
Concordo pienamente con la necessità di fare chiarezza nel mondo del software libero, e non solo nei confronti della pubblica amministrazione. La libertà di scelta, se da un lato è un valore fondamentale, dall’altro spaventa: la PA e gli utenti finali.

Il mondo del software libero ha un disperato bisogno di marketing, di tralasciare i numeri di licenza e di crescere con l’offerta che abbia una presa commerciale (naturalmente mantenendo “dietro la scorza” tutte le qualità tipiche del software libero), perché solo così sarà possibile sostenerlo efficacemente.

La mia paura più grande è che il “talebanesimo” di alcuni esponenti della comunità porti ad una spaccatura molto più profonda e radicale di quella che già conosciamo da anni tra “software libero” e “opensource” proprio all’interno del mondo del “software libero” stesso.

La presa di coscienza che esistono molte alternative, ma che il cliente (fosse anche la PA) debba essere “guidato” nella sua scelta da persone esperte che possano tradurre le grandi opportunità del software libero in vantaggi tangibili per l’utente (che ne apprezzerà poi anche gli aspetti più nascosti e spesso maggiormente importanti) è una necessità sempre più forte in questo mondo, che però fatica a cambiare…
[…]

Arriva OpenOffice.org 2.4!

1 Replica

Libertà condizionata E’ un periodi ricco di grandi novità nel mondo del software libero. Con l’uscita di Firefox 3 ormai imminente (si parla al più di un paio di mesi al massimo d’attesa), e l’appropinquarsi della release 8.04 di Ubuntu, “Hardy Heron” (che sarà per altro la prossima “Long Term Support”) al punto che il team di sviluppo già pensa al nome e alle novità della 8.10, gli appassionati e gli utilizzatori di software libero hanno di che stupirsi e meravigliarsi.

Particolarmente significativo però, è l’annuncio delle novità presenti in OpenOffice.org versione 2.4, che dopo aver incrementato stabilità velocità e compatibilità con i formati proprietari di Microsoft Office (innovazioni che certo non avevano fatto lanciare urla di stupore agli utilizzatori della suite per l’ufficio libera per antonomasia) non ci tiene ad accumulare polvere.
Una recente analisi di AlFresco sull’uso dell’opensource ci dice peraltro che la percentuale di adozione di OpenOffice.org sta continuando a salire negli ultimi mesi, facendo sprofondare il monopolista di Microsoft al 66% del mercato, rendendo di fatto le novità di OpenOffice.org ancora più importanti, nell’ottica di rendere più semplice, funzionale e gradevole l’uso di un così diffuso strumento.

Una sintesi delle novità previste per OpenOffice.org 2.4 ce la mette a disposizione Oooninja, con una serie di approfonditi articoli.

Alle migliorie apportate a Calc (dalla gestione dei grafici, con l’introduzione di assi invertiti e side-by-side axis, alla gestione dei dati, con la possibilità di passare da una cella di testo csv alla visualizzazione in colonne), a Writer (con l’introduzione della selezione per blocchi e le back references nelle sostituzioni) ed alla gestione dei PDF (con l’introduzione del supporto per i formati d’archiviazione PDF/A e di notevli miglioramenti nell’esportazione), si aggiunge una novità di quelle davvero importanti, di quelle che fanno decidere se continuare ad usare il proprio software o cambiarlo: le transizioni 3d (basate su Opengl) nelle presentazioni di Impress, adeguatamente dimostrato dal video che Oooninja ci mette a disposizione.

L’approccio del software libero al mercato del desktop incassa così una nuova importante vittoria. Vedremo se anche in questo caso i numeri confermeranno i risultati del duro lavoro degli sviluppatori.

Munin: monitorare macchine remote senza SNMP

3 Repliche

cpu-munin.pngLa gestione remota di un sistema server è una delle grandi problematiche di chi si occupa di fornitura di servizi informatici. Soprattutto quando i sistemi in gestione sono molti, e magari dislocati in aree diverse del territorio, il tener monitorata la situazione di tutti i sistemi senza dover passare la propria giornata lavorativa con questo unico scopo, comporta l’uso di una serie di tecnologie.

Per anni, uno dei modi più utilizzati per questo scopo è stato il protocollo SNMP, che consente (oltre alla gestione remota di apparati) l’analisi prestazionale di server ed apparecchiature di rete. I problemi di sicurezza intrinsechi del protocollo però (anche semplicemente la possibilità di gestire remotamente un apparato che esponga un servizio SNMP), hanno reso sempre piuttosto diffidenti i sistemisti nella massiccia adozione di questa tecnologia, pur efficace. Inoltre la non banale configurazione degli strumenti OpenSource in grado di dialogare con SNMP per generare dei grafici che consentano di capire e monitorare l’andamento dei sistemi (MRTG), non ha certo semplificato il lavoro.

Per ovviare a questo problema, è nato un interessante pacchetto applicativo, munin, il cui preciso scopo è quello di rendere semplice ed intuitiva la gestione del monitoraggio remoto anche di numerosi sistemi. In grado di interfacciarsi all’occorrenza anche con periferiche SNMP (per includere nel monitoraggio anche apparecchiature di rete limitando comunque l’esposizione dei servizi SNMP alla rete locale), munin si avvale di una struttura modulare e di un protocollo testuale piuttosto semplice, oltre che di una strutturazione client-server piuttosto semplice da configurare.

Strutturazione

Come si accennava, munin ha una struttura “client-server”: sui nodi da monitorare verrà installata la parte server, che dialoga con l’hardware e raccoglie le informazioni su richiesta del client; questi invece si occupa di contattare i vari server, collezionare i dati e generare delle paginette web con i grafi statistici risultanti dai dati raccolti, tracciati grazie all’uso di RRD Tool.

Installazione e configurazione (debian)

L’installazione, in debian perlomeno, è resa banale dal fatto che sia la parte client che la parte server di munin sono già pacchettizzate. Sarà sufficiente installarli per avere già una prima parte di monitoraggio, che comprende alcuni dati standard quali uso dei filesystem e della memoria, carico del sistema, carico di rete, monitoraggio delle connessioni entranti, entropia disponibile sul sistema, numero di processi e “fork rate”. Il pacchetto “server” si chiama “munin-node”, e viene avviato automaticamente al momento della sua installazione, mentre il pacchetto client andrà configurato adeguatamente come vedremo. Per installare sia il client che il server, daremo il comando

# apt-get install munin munin-node

Potete dare un’occhiata al file di configurazione della parte server di munin, /etc/munin/munin-node.conf che è comunque piuttosto semplice e scarno. L’unico dato eventualmente da modificaere, potrebbe essere il nome dell’host da comunicare al/ai client, che trovate commentato nella versione originale del file di configurazione e che porta quindi munin ad utilizzare i nomi riportati in /etc/hosts per questo aspetto. Altro parametro che potrebbe risultare importante da modificare è l’elenco degli host dai quali accettare connessioni (di default il solo 127.0.0.1), aggiungendoli (sotto forma di espressioni regolari) all’ultima riga del file citato.
La configurazione del nodo è in parte automatizzata dall’applicativo munin-node-configure incluso nel pacchetto e che analizza tutti i plugins installati(che trovate in /usr/share/munin/plugins/) alla ricerca di quelli che hanno un senso sul sistema locale. Questo viene fatto grazie ad un sistema di autoconfigurazione che viene implementato dai vari plugins, i quali rispondono dovrebbero rispondere ad una loro esecuzione con il parametro “autoconf” con un “yes” o con un “no” (o addirittura con dei suggerimenti sulla configurazione) a seconda che il plugin possa funzionare o meno sul sistema. Per aggiungere un plugin a quelli da far utilizzare a munin, sarà sufficiente farne un link simbolico (eventualmente componendone adeguatamente il nome) all’interno della directory /etc/munin/plugins/. Ad esempio, per aggiungere il monitoraggio dell’uptime di sistema e del traffico dell’interfaccia di rete ‘eth1’, sarà sufficiente dare i seguenti comandi:

# ln -s /usr/share/munin/plugins/uptime /etc/munin/plugins/
# ln -s /usr/share/munin/plugins/if_eth1 /etc/munin/plugins/

Al termine della configurazione, basterà riavviare munin per applicare le modifiche richieste

# /etc/init.d/munin-node restart

Alcuni plugins richiedono una configurazione particolare per funzionare: ad esempio i plugin di analisi del traffico, dei processi e del volume di dati scambiato dal server web apache, richiedono che venga attivato, sul server web, una particolare pagina (server-status) che riporta questi dati. Le eventuali configurazioni necessarie al funzionamento dei plugins sono solitamente indicate all’interno dell’intestazione del plugin stesso. Per verificare il funzionamento di un plugin, può essere utile eseguirlo e verificare che stampi a video dati numerici (e non stringhe di errore, o il valore ‘U’)

root@giotto:/etc/munin# /etc/munin/plugins/cpu
user.value 24249601
nice.value 26903
system.value 2823798
idle.value 582652748
iowait.value 287010
irq.value 96008
softirq.value 104576

Per quanto riguarda invece al configurazione della parte client, il discorso non è poi molto più complicato. Mettendo le mani nel file /etc/munin/munin.conf, potremo definire l’elenco degli host che il client dovrà contattare ad ogni esecuzione (che dovrebbe essere automaticamente inclusa in cron al momento dell’installazione del pacchetto client), il “nome host” che dovrà richiedere (uno stesso server può gestire, come vedremo, diversi host), l’indirizzo ip da contattare (o il nome fqdn), ed eventualmente il parametro “use_node_name”, che limita, se impostato ad un valore positivo (“yes”, “y” o “1”), il fetch dei dati ai soli configurati per il nodo (escludendo ad esempio macchine monitorate in snmp da quel nodo).

Non troverete username ne passwords: il protocollo di munin, estraendo solamente dati (non è pensato per fare gestione remota dell’apparato come invece è possibile fare con SNMP), non prevede una fase di autenticazione. Per questo motivo può essere interessante configurare munin per accettare connessioni solamente da localhost ed utilizzare ssh per mappare (sotto cifratura) la porta di munin-node (di dafault la 4949) sul sistema che fa il fetch dei dati (dedicherò alla questione un post ad-hoc, nei prossimi giorni).

Il risultato

Una volta che avrete terminato la configurazione del server e del client, quest’ultimo comincerà a generare (di default il /var/www/munin/) delle pagine html che riportano i dati raccolti. Un esempio del risultato, potete trovarlo direttamente sul sito di Munin. Un aspetto interessante di questa interfaccia web, oltre a consentire una comoda visualizzazione dei dati (eventualmente raccolti anche per gruppi, modificando adeguatamente munin.conf), è che nella pagina di riepilogo colora diversamente le sezioni dei vari nodi a seconda dei risultati raccolti: se ad esempio uno dei dischi di un sistema si sta riempiendo, oltre ad inviare una mail all’indirizzo riportato in munin-node.conf (sempre che lo abbiate decommentato) apparirà dapprima in giallo, poi in rosso, nella pagina web, richiamando la vostra attenzione.

GPLv3: pensieri volanti

Rispondi

Ieri sera notte, mentre cercavo di convincere Danilo che era ampiamente ora di andare a dormire (tentativo fallito, visto che alla fine ha dormito su un tavolo), mi sono trovato a fare quattro interessanti chiacchiere in materia di “GPLv2 vs. GPLv3” insieme a Guido Serra, Marco Bertorello, Matteo Flora e Daniel Donato, dell’HackLab 81100.
Dal discorso (nonostante i fumi dell’alcool che non risparmiavano probabilmente nessuno dei partecipanti ed astanti) sono venute fuori una serie di considerazioni interessanti che mi sono annotato e riproposto di elencare qui, a memoria d’uomo.

Tanto per cominciare, GPLv3, a differenza della GPLv2, richiede (con l’obiettivo di combattere la TiVo-izzazione) il rilascio della “tool-chain”. Questo non significa che debbano essere rilasciati tutti gli apparati a contorno del software (ad esempio script dello sviluppatore che aiutano nella customizzazione del software, ad esempio), ma semplicemente che l’utente finale, che ha il sorgente a disposizione, deve essere in grado (non è detto che debba poterlo fare comodamente) di ricompilare e reinstallare il software a sua disposizione. L’obiezione di Guido, in ogni caso, rimane pienamente valida: questa ulteriore ristrettezza rispetto alla GPLv2, peggiora il ritorno dell’investimento commerciale che lo sviluppatore potrebbe aver affrontato.
Questo è probabilmente dovuto ad una scelta di fondo, che ad un certo punto si è posta e doveva essere necessariamente affrontata: il rapporto tra software commerciale e software libero. La mia opinione è che con la GPLv2, i “lavoratori del software libero” potevano essere anche sviluppatori, investitori, scrivendo del codice da zero, rilasciaro sotto GPL e vedere comunque un rientro economico tale da coprire l’investimento fatto, perchè veniva sfruttata una “zona grigia”: si tratta di un equilibrio piuttosto delicato del quale qualcuno (Novell ad esempio, nell’ambito dell’accordo con Microsoft di cui tanto si è parlato, ma non è certo la sola) ha abusato, portando ad una revisione di questo argomento nell’ambito dello sviluppo della GPLv3.

La scelta a questo punto era tra mantenimento e garanzia delle “libertà digitali” del software e dei suoi utilizzatori, e attrattiva commercial-industriale dello stesso, è la strada presa dalla GPLv3 è piuttosto palese, nonché ovvia conoscendo i personaggi che ne guidano la filosofia. Questa scelta non è di per sé negativa, ma va preso atto che rende il software libero poco attraente da un punto di vista prettamente commerciale.

Un’interessante osservazione è poi nata dalla discussione, ed è quella sul rilascio dei diritti sui brevetti, che da quel che ricordo la GPLv3 richiede; mentre la GPLv2 non citava in alcun modo i brevetti, lasciando un’alone di indecisione che poteva (forse) essere sfruttato per implementare algoritmi coperti da brevetti software dei quali non si possiedono i diritti (non essendo questi validi in alcune legislazioni, come quelle europee), la GPLv3 ne richiede l’esplicito rilascio, che nonè possibile effettuare se non si possiedono i diritti in questione, ponendo un’ulteriore limitazione alle possibilità di sviluppo, questa volta in senso molto più largo di quello prettamente commerciale.

Infine, si esprimevano dubbi sulla localizzazione della licenza: la GPL è scritta per la legislazione americana. In Italia, è valida? Non va forse a contraddire qualche articolo di qualche legge sui contratti commerciali, o simili, che potrebbero portarla ad essere invalidata? Sotto questo aspetto (il solito paradosso della legislazione e dell’informatica, fatto di frontiere fisiche che esistono nel mondo reale ma non nel mondo digitale), il discorso andrebbe approfondito con persone competenti, perchè io rischio solo di fare inutili congetture ed illazioni 🙂