Appena tre giorni fa è stata rilasciata la versione 1.2.0 di NGINX (engine x), il web e reverse/mail proxy server, creato da Igor Sysoev. Sono passati sette anni dal rilascio iniziale e mese dopo mese continua a guadagnare terreno; secondo Netcraft la sua quota di mercato è di circa il 10%. Questo risultato ne fa il secondo web server più utilizzato.

Di fatto si sta trasformando nella killer app dei web server, tanto che compagnie come Hulu, Facebook e Automattic (per wordpress.com) lo utilizzano per le sue eccellenti doti di scalabilità, stabilità e gestione di carichi molto elevati. C’è da sottolineare che nginx non è progettato per fornire il maggior numero di features, ma piuttosto per supportare un limitato insieme di caratteristiche con prestazioni di classe superiore e soprattutto con un ottimo grado di determinismo. Caratteristica fondamentale per la progettazione di data center.

nginx è nato con l’intento di risolvere il problema C10K, ossia poter servire 10000 client simultanei per ogni istanza server con un consumo di risorse veramente limitato. I confronti con installazioni Apache Web Server sono spesso imbarazzanti e questo è dovuto al diverso approccio utilizzato dai due. nginx ha adottato una strategia asincrona ad eventi, che consente di scalare in maniera molto efficiente, evitando di replicare risorse ad ogni richiesta, come invece avviene per i server multi-processo o multi-thread.

La diffusione di nginx ha dato vita a stack alternativi al consueto LAMP, sostituendo la componente Apache per avere degli ambienti LEMP. A mio avviso la crescita di questo web server ha un’importanza che va molto oltre il semplice dato numerico, che se preso da solo sarebbe poco significativo rispetto ad una quota del 60% di Apache. La questione è il diverso paradigma utilizzato. Dopo anni di servizio, l’approccio tradizionale sembra perdere terreno, in particolar modo nelle applicazioni mission critical. Inoltre questo modello sembra prendere piede anche in altre aree e la presenza di Node.js ne è un esempio.

Sulla stessa scia, c’è da sorvegliare anche l’andamento di lighttpd che per ora si attesta al 1,2% ma che può vantare “clienti” del calibro di YouTube, Wikipedia e meebo. La conclusione di tutto ciò è l’affermarsi di una risposta efficace e soprattutto efficiente alla sfida più grande dell’attuale Internet: i carichi esponenziali. E la fondazione Apache farebbe bene a prendere provvedimenti.

Via | NGINX

Rilasciato nginx 1.2.0, il secondo web server più utilizzato é stato pubblicato su Ossblog.it alle 13:00 di giovedì 26 aprile 2012.

Debian può sostituire GCC con LLVM/Clang per il 92% dei pacchetti del proprio archivio: è il risultato delle prove di Sylvestre Ledru. Più precisamente, la percentuale dei pacchetti compilati con successo è del 91,2% — contro l’85,5% della versione 2.9 di LLVM/Clang. Una cifra confortante per chi intende utilizzare il compilatore.

Sul totale di 15.658 pacchetti, appena 1.381 hanno fallito la compilazione: Ledru ha fornito una spiegazione dettagliata del tipo d’errore in una sezione dedicata a Clang sul portale di Debian. Nella maggioranza dei casi, i problemi possono essere risolti con facilità: spesso il fallimento non sarebbe neppure dovuto al compilatore.

Ledru è convinto che, nei prossimi anni, LLVM e Clang sostituiranno GCC nella toolchain di Linux e *BSD: a supporto di questa tesi, Ledru sottolinea la maggiore specificità del compilatore nel debugging e i progressi delle soluzioni correlate da Xcode a Chromium. Il problema è legato alla governance. LLVM non è un progetto di GNU.

Via | Phoronix

Debian può compilare su LLVM/Clang il 92% dei pacchetti in archivio é stato pubblicato su Ossblog.it alle 10:00 di martedì 06 marzo 2012.

OpenMP, l’Application Programming Interface (API) per il parallel programming già implementata con successo da GCC, potrebbe essere supportata al più presto da LLVM/Clang. Al momento, l’infrastruttura di LLVM-IR non permette l’utilizzo delle specifiche di OpenMP: l’unica soluzione è compilare i sorgenti ottimizzati da LLVM con GCC.

Questa situazione sembra essere destinata a cambiare: tuttavia, non è ancora stata definita la tabella di marcia per l’integrazione di OpenMP. Il supporto potrebbe essere escluso da LLVM 3.1, l’imminente aggiornamento della piattaforma. Clang, ad ogni modo, non permetterebbe la compilazione di tutti i linguaggi supportati da OpenMP.

Mi riferisco, in particolare, a Fortran. Previsto da OpenMP e supportato da GCC, il linguaggio è escluso da Clang — che prevede soltanto C/C++ e Obj-C/Obj-C++. Quando OpenMP dovesse essere implementato da LLVM, il multi-threading per Fortran resterebbe legato all’utilizzo di GCC e DragonEgg sarebbe comunque fondamentale per OpenMP.

Via | Phoronix

LLVM/Clang potrebbero supportare OpenMP da un prossimo aggiornamento é stato pubblicato su Ossblog.it alle 12:00 di martedì 17 gennaio 2012.

The Lives They Lived (lett. “le vite che hanno vissuto”) è una rubrica del magazine di The New York Times: il numero domenicale, pubblicato a Natale, ha proposto un riassunto della vita di Dennis Ritchie. È il creatore di C, che è morto nella prima metà dell’ottobre di quest’anno. Una delle grandi personalità che ci hanno lasciati.

Il titolo assegnato al numero su Ritchie non poteva essere che hello, world: il testo stampato a video dal primissimo esempio di The C Programming Language, il libro scritto a quattro mani da Ritchie e Brian Kernighan. Quella frase – spesso, con una sintassi diversa – è diventata il simbolo ricorrente degli esempi di programmazione.

Il 2011 porta via con sé un intero “mondo” di persone che hanno contribuito alla realizzazione delle tecnologie del presente. L’ultima in ordine di tempo è stata Jacob Goldman — il creatore di Xerox Lab, morto settimana scorsa. Ritchie e Goldman sono legati da UNIX, il sistema operativo che ha stimolato la nascita dell’open source.

Via | The New York Times

hello, world: The New York Times celebra la storia di Dennis Ritchie é stato pubblicato su Ossblog.it alle 13:00 di martedì 27 dicembre 2011.

CXXI è un nuovo progetto di Mono che colma la mancanza d’interoperabilità per C Sharp e .NET con C++. È stato realizzato grazie a due anni consecutivi di finanziamento da parte della Google Summer of Code e, al momento, include dei binding e dei test per Qt. CXXI sostituisce gli espedienti utilizzati da Mono per il dialogo con C++.

Ad esempio, in passato i manutentori di Mono avevano realizzato un binding del PhyreEngine di Sony per dimostrare le potenzialità di C# coi sorgenti ad alto livello dei videogiochi per PlayStation 3. PhyreEngine# è stata una soluzione di compromesso, inadatta a supportare l’interoperabilità con C++. CXXI è il presente — e il futuro.

La tecnologia di CXXI, di per sé, riassume le funzionalità d’altre tre soluzioni temporanee di Mono per elaborare i sorgenti in C++. Rispettivamente, Platform Invoke, COM Interop e MarshalByRefObject di Microsoft. Tre complessi escamotage per tradurre e compilare il codice scritto per C++ con C# e .NET. Ormai – di fatto – superati.

Quanto alle funzionalità, CXXI propone una doppia compilazione dei sorgenti nella creazione di librerie dinamiche. Partendo dal codice in C++, CXXI utilizza GCC per compilare la libreria col metodo tradizionale e – in parallelo – il proprio generatore interno per realizzare le .dll in C# o .NET. Questo è il meccanismo più semplice.

Quando i sorgenti prevedono il parsing di XML, la procedura è un po’ più complessa. GCC-XML genera il markup dai sorgenti in C++, quindi CXXI li traduce in Visual C#: perciò, sono integrate le ottimizzazioni proprie di C Sharp ed è generata la corrispondente libreria .dll. Un meccanismo abbastanza complicato per le esigenze attuali.

Per quanto mi riguarda trovo che lo sviluppo di Mono sia costantemente più lontano dai trend della programmazione contemporanea. Il ricorso a tanti passaggi può essere giustificato in un numero molto ridotto di situazioni: soprattutto sui dispositivi portatili – il target di Xamarin – è preferibile la creazione di applicazioni web.

Via | Miguel De Icaza

Mono inaugura il supporto all’interoperabilità con C++ grazie a CXXI é stato pubblicato su Ossblog.it alle 11:00 di mercoledì 21 dicembre 2011.

L’aggiornamento di Compute Unified Device Architecture (CUDA), l’infrastruttura di nVidia per il parallel computing sui processori grafici, include un nuovo compilatore basato su LLVM. Già distribuito nel toolkit per i driver proprietari, quest’ultimo avrà una licenza open source — perché possa essere applicato ad altri processori.

È giusto evidenziare che l’“apertura” di CUDA 4.1 – almeno, giudicando il comunicato stampa di nVidia – riguarda soltanto il compilatore. In pratica, nVidia C/C++ Compiler (NVCC) è sostituito da una nuova soluzione basata su LLVM e distribuito sotto una licenza open source da comunicare. Non significa che CUDA funzionerà su Nouveau.

Nouveau può utilizzare il compilatore, esteso ai processori grafici o centrali di AMD/ATI e Intel. Le librerie accelerate previste da CUDA, però, resteranno vincolate ai driver proprietari di nVidia. Inoltre, la disponibilità dei sorgenti del compilatore è subordinata alla compilazione d’un modulo per qualificare gli sviluppatori.

Via | nVidia

nVidia ha approvato la distribuzione del codice sorgente di CUDA 4.1 é stato pubblicato su Ossblog.it alle 11:00 di giovedì 15 dicembre 2011.

Dopo la lunga attesa, finalmente arriva la versione 3.0 di LLVM. Di fatto questo è un rilascio incrementale, ma gli sviluppatori non hanno perso l’occasione per eliminare qualche vecchio modulo. Sono stati necessari sei mesi di sviluppo dalla versione 2.9 per introdurre importanti novità: un nuovo register allocator per migliorare ulteriormente le prestazioni, il supporto completo per operazioni atomiche e il nuovo memory model per C++.

Avevamo già trattato l’abbandono di llvm-gcc in favore di CLang e DragonEgg. E proprio CLang offre numerose correzioni e migliorie: ridotta lunghezza nei messaggi di errore, ricavando così un’informazione più immediata e suggerimenti in caso di errori di digitazione. Quest’ultima si rivela utile nel caso di errori di digitazione: maiuscole/minuscole nella battitura dei tipi. Gli sviluppatori potranno inoltre fare affidamento nei nuovi messaggi di warning, il tutto a beneficio dell’espressività della diagnostica.

Lo sforzo degli sviluppatori si è concentrato non solo nelle prestazioni, migliorate rispetto alla precedente versione, ma anche per quanto riguarda l’aderenza ai recenti standard per C/C++. Ad esempio sono state introdotte molte caratteristiche del C++11 come il supporto agli alias, i cicli for basati su intervalli e le espressioni noexcept. Infine per quanto riguarda il plugin DragonEgg, non sarà più necessario apportare la patch ed effettuare la compilazione di GCC. La versione 4.6 è pienamente supportata.

Via | Phoronix

Rilasciato LLVM 3.0 é stato pubblicato su Ossblog.it alle 14:00 di lunedì 05 dicembre 2011.

OpenMP è una specifica API che consente l’esecuzione parallela di task secondo il modello a memoria condivisa. Questo consente di creare programmi che implementano la programmazione parallela da poter eseguire sia nei cluster, se usato in combinazione di MPI, sia su normali computer desktop. I linguaggi supportati sono CC++ e Fortran.

In concreto OpenMP è implementata come estensione di un compilatore, quindi è sufficiente aggiungere un opportuno parametro al comando di compilazione: ad esempio, nelle ultime versioni di GCC il parametro è -fopenmp. OpenMP non necessita di librerie esterne, i comandi vengono forniti sotto forma di commenti speciali. Una caratteristica estremamente utile, se si vuole utilizzare lo stesso codice senza imporre un’esecuzione parallela.

Un classico esempio, per questo genere di programmazione, è la parallelizzazione dei cicli: il comando è #pragma omp parallel for. Sono inoltre disponibili diversi metodi di sincronizzazione per sezioni critiche, variabili condivise e race condition: critical, atomic, ordered, barrier e nowait. Inoltre si può specificare il numero di thread da console, in fase di compilazione, con la variabile d’ambiente OMP_NUM_THREADS=n°thread.

OpenMP dispone di una lunga esperienza come standard (la prima versione è del 1998) e di un consorzio composto da nomi di tutto rispetto come Intel, AMD, Fujitsu, Oracle e molti altri. C’è una sola “pecca” degna di nota, a mio parere: non può essere utilizzata per le GPU. Una lacuna che si spera venga colmata presto.

Via | Linux Journal

Programmazione parallela con OpenMP é stato pubblicato su Ossblog.it alle 13:00 di giovedì 27 ottobre 2011.

Ci ha lasciati, all’età di 70 anni. Dennis Ritchie è uno di quei giganti dell’informatica a cui tutti dobbiamo qualcosa. Insieme a Ken Thompson creò il linguaggio C e il sistema operativo UNIX, entrambi pilastri fondamentali dei sistemi informatici. E ancora oggi il linguaggio C è tra i più utilizzati dopo decenni di onorato servizio; persino sistemi come OSX, *BSD e Linux che sono basati su UNIX non esisterebbero senza i contributi di Ritchie.

Nel 1984 i suoi meriti gli consentirono di ricevere il Premio Turing per la teoria generica sui sistemi operativi, sette anni dopo fu il turno della IEEE Richard W. Hamming Medal, nel 1998 ricevette la Medaglia Nazionale della Tecnologia consegnata dal Presidente USA Bill Clinton per poi concludere con il Japan Prize for Information and Communications. Continuò a lavorare instancabilmente fino al 2007, anno della pensione.

L’estrema semplicità e l’eleganza della logica di UNIX hanno attraversato i decenni senza invecchiare. Un’eredità tanto importante quanto attuale che Dennis Ritchie ha lasciato al mondo dell’informatica. Un mondo che continuerà a far tesoro delle sue creazioni ma che ha irrimediabilmente perso un pioniere, uno di quelli veri, uno di quelli che l’Informatica più che averla studiata ha contribuito a crearla. Grazie.

Via | Tagxedo
Foto | Flickr

Dennis Ritchie è morto é stato pubblicato su Ossblog.it alle 16:30 di giovedì 13 ottobre 2011.

Chrome 15 è in grado d’eseguire del codice in C/C++ attraverso il Native Client: la novità apre interessanti prospettive allo sviluppo d’applicazioni web per il browser. L’esecuzione del codice è soggetta a delle restrizioni, simili a quelle già previste per JavaScript. Pepper è il plugin responsabile dei binding di C/C++ per HTML5.

Appoggiandosi alle possibilità offerte da OpenGL, ecc. il browser di Google consentirà agli sviluppatori di portare in HTML5 sul web le prestazioni tipiche del desktop. Il percorso per arrivare a un sostanziale pareggio delle performance, però, è ancora lungo. A questo proposito è interessante l’implementazione delle Web Audio API.

Insieme all’attivazione del Native Client con la possibilità d’eseguire il codice in C/C++, Chrome 15 include l’ultima bozza delle specifiche per la riproduzione di flussi audio via HTML5 e JavaScript. Non si tratta ancora di uno standard (Mozilla ha una proposta diversa), comunque esistono degli esempi riproducibili con Chrome 15.

Via | Google

Google ha aggiunto l'utilizzo di C/C++ a Chrome 15 via Native Client é stato pubblicato su Ossblog.it alle 13:00 di venerdì 12 agosto 2011.

Com’è noto Adobe Photoshop CS5 ha introdotto nel 2010 il Content-Aware Fill, una funzionalità presente su The GIMP già dal 2002 grazie a Resynthesizer. Purtroppo, però, lo stato dell’arte di quest’ultimo è rimasto a nove anni fa: Lloyd Konneker ha pensato di riprendere lo sviluppo di Resynthesizer e d’adattarlo alle nuove necessità.

Konneker ha riscritto Resynthesizer in C, separando il core dalla User Interface (UI) e aggiornando una serie di plugin in Python che ne facevano uso. Inoltre, ha aggiunto il supporto al canale alpha: risolvendo alcuni bug, ha rilasciato Resynthesizer come 1.0. Questa versione riparte direttamente dalla 0.16 degli autori originali.

Resynthesizer 1.0 è disponibile soltanto per Linux, tuttavia è in fase di realizzazione anche il porting per The GIMP su Windows. Il plugin e i relativi script sono raggiungibili da tre sotto-menù della voce Filtri: Miglioramento, Mappa e Render nella localizzazione italiana. Lo sviluppo per Resynthesizer 1.0 è mantenuto su GitHub.

Via | Libre Graphics World

È ripreso lo sviluppo di Resynthesizer per The GIMP da Photoshop CS5 é stato pubblicato su Ossblog.it alle 13:00 di domenica 17 aprile 2011.

Angry Birds, il popolare videogioco di Rovio Mobile, è basato su Box 2D: si tratta di un physical engine creato da Erin Catto e rilasciato sotto licenza open source. Questo è il motivo per cui torniamo a parlarne. Box 2D è un progetto scritto in C++, portato su numerosi altri linguaggi di programmazione da una comunità di volontari.

In occasione del Game Developer Conference 2011, Peter Vesterbacka (il creatore di Angry Birds) e Catto sono stati protagonisti di un divertente “siparietto”. Catto, seduto in platea, ha chiesto a Vesterbacka quale fosse il motore di Angry Birds e se Rovio intendesse riconoscerne i crediti al creatore. La risposta è stata positiva.

Soddisfatto della risposta, Catto ha rivelato la propria identità e al termine dell’intervento si è trattenuto a parlare con Vesterbacka. È un’ottima notizia per il software libero sui videogame: Box 2D è un progetto volontaristico, Angry Birds ha un solido modello di business. I protagonisti smentiscono le polemiche sulle licenze.

Via | MobileCrunch

Angry Birds si basa su Box 2D, il motore fisico creato da Erin Catto é stato pubblicato su Ossblog.it alle 11:00 di giovedì 03 marzo 2011.

Boost è una comunità di programmatori C++ che sviluppano una serie di librerie utili per espandere il linguaggio e per semplificare la programmazione in C++.

Alcune delle librerie già implementate sono state proposte al C++ Standards Committee per l’inclusione come standard nella prossima versione del linguaggio che va sotto il nome di C++0x. Alcune di queste sono già presenti nella Library Technical Report (TR1).

Queste librerie possono essere utilizzate su qualsiasi sistema operativo moderno e sono testate compilando il sorgente con decine di compilatori differenti. La qualità del codice è altissima e vi consente di velocizzare lo sviluppo introducendo meno bug e diventando complessivamente più produttivi.

Alcune delle librerie più utili semplificano l’uso di smart pointer, array, programmazione funzionale, generic programming, grafi, immagini, regex, serializzazione, thread, file, file system.

Via | Boost

Boost, come essere più produttivi in C++ é stato pubblicato su Ossblog.it alle 15:00 di mercoledì 02 marzo 2011.

Quello delle dipendenze è un annoso problema dei sistemi UNIX-like. Ne è consapevole il team di Illumos (a proposito, quello a lato è il nuovo logo del progetto) ed è per questo che gli ultimi giorni hanno portato all’eliminazione di Python dal comando zfs. Il commit è stato effettuato mercoledì da Alexander Stetsenko. Il significato è quello di rendere quanto più cross-platform sia possibile l’utilità per gestire il file system.

Non è certo in discussione Python come linguaggio in sé o, PyZFS: l’intento è stato quello di ridurre all’osso le dipendenze e il fatto che zfs sia in C al 100% non presuppone alcuna scelta di merito. Una scelta obbligata, insomma. Garret D’Amore di Nexenta, tra i più attivi nel riportare i progressi di Illumos, nel dare la notizia ha chiesto esplicitamente dei riscontri sull’implementazione da parte degli sviluppatori di FreeBSD.

Nonostante la beta pubblica di ZFS per Linux sia stata rilasciata settimana scorsa è normale che D’Amore non abbia pensato di interpellare la comunità del pinguino. L’uso di ZFS in userspace presuppone tutt’altra infrastruttura e in generale il file system è poco sfruttato su Linux. È interessante aspettare un’eventuale risposta da parte del team di Debian (e Gentoo?) GNU/kFreeBSD. Intanto gli sviluppatori sono avvisati.

Via | Garret D’Amore

ZFS non dipende più da Python su Illumos e D'Amore interroga FreeBSD é stato pubblicato su Ossblog.it alle 13:00 di venerdì 03 dicembre 2010.

Introducendo Funtoo, la nuova creatura di Daniel Robbins, avevo parlato di «software instabile e ultra-aggiornato». L’affermazione è valida solo in parte, perché rispetto al portage standard di Gentoo alcuni componenti sono mantenuti a versioni stabili che il team di sviluppo ritiene più affidabili. Ciò prescindendo dall’uso di overlay che sovrascrivano le impostazioni predefinite. Tar è uno di questi: vediamo subito perché.

Negli ultimi giorni, chi utilizza una distribuzione Gentoo o, derivata avrà certamente riscontrato dei problemi nell’aggiornamento di applicazioni, librerie ecc. che dipendono da Tar. Quest’ultimo è proposto dal portage di Gentoo nella versione 1.24, che è affetta da un bug molto fastidioso. Sebbene gli sviluppatori abbiano già provveduto a risolvere il primo problema, ne è emerso un secondo addirittura peggiore.

Il bug risolto da Gentoo riguarda il riconoscimento dell’opzione -C nella compilazione di Tar 1.24-R1. Il portage standard offre ora Tar 1.24-R2, che corregge gli errori del compilatore… ma non i conflitti con OpenVZ e soprattutto Metro (l’utility per creare gli stage di Funtoo). Perciò Robbins ha deciso di bandire Tar 1.24 da Funtoo, ritornando alla versione 1.23-R4 finché non saranno risolti tutti i problemi esistenti.

Via | Daniel Robbins

Tar, Gentoo e la soluzione di Daniel Robbins ai problemi di compilazione é stato pubblicato su Ossblog.it alle 12:00 di martedì 02 novembre 2010.