<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/" xml:lang="it-it">

  <title>Ossblog.it</title>
  <subtitle>Programmi free: scopri il mondo dell'Open Source</subtitle>
  <rights type="html"><![CDATA[2005-2011 Blogo.it]]></rights>
  <updated>2012-05-21T03:42:47+00:00</updated>
  <id>http://www.ossblog.it</id>
  <link rel="alternate" type="text/html" hreflang="it-it" href="http://www.ossblog.it" />
  <generator uri="http://lightpress.org/" version="1.1.0">Lightpress</generator>

  
  <entry>
    <title type="html">Rilasciato nginx 1.2.0, il secondo web server più utilizzato</title>
    <link rel="alternate" type="text/html" href="http://www.ossblog.it/post/9869/rilasciato-nginx-120-il-secondo-web-server-piu-utilizzato" />
    <id>http://www.ossblog.it/post/9869/rilasciato-nginx-120-il-secondo-web-server-piu-utilizzato/</id>
    <author>
      <name>Giacomo Picchiarelli</name>
    </author>
    <published>2012-04-26T11:00:51+00:00</published>
    <updated>2012-04-26T11:00:51+00:00</updated>
    <dc:subject>bsd</dc:subject><dc:subject>open-source</dc:subject><dc:subject>cc</dc:subject><dc:subject>alternative apache</dc:subject><dc:subject>lemp vs lamp</dc:subject><dc:subject>nginx php</dc:subject><dc:subject>nginx vs apache</dc:subject><dc:subject>nginx web server</dc:subject>
    <summary type="text"><![CDATA[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[...]]]></summary>
    <content type="html" xml:lang="it-it" xml:base="http://www.ossblog.it/post/9869/rilasciato-nginx-120-il-secondo-web-server-piu-utilizzato"><![CDATA[<p><img src="http://static.blogo.it/ossblog/800pxNginxlogo.svg.png" class="post" border="0" width="586" height="127" alt="" /><br clear="all" /> </p>
<p>Appena tre giorni fa è stata rilasciata la versione 1.2.0 di NGINX (<em>engine x</em>), 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 <a href="http://news.netcraft.com/archives/2012/04/04/april-2012-web-server-survey.html">Netcraft</a> la sua quota di mercato è di circa il 10%. Questo risultato ne fa il secondo web server più utilizzato.</p>
<p>Di fatto si sta trasformando nella <em>killer app</em> 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&#8217;è da sottolineare che nginx non è progettato per fornire il maggior numero di <em>features</em>, 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 <em>data center</em>.</p>
<p>nginx è nato con l&#8217;intento di risolvere il problema <a href="http://www.kegel.com/c10k.html">C10K</a>, 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 <strong>asincrona</strong> 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.</p>
 <p>
La diffusione di nginx ha dato vita a <em>stack</em> alternativi al consueto LAMP, sostituendo la componente Apache per avere degli ambienti LEMP. A mio avviso la crescita di questo web server ha un&#8217;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&#8217;approccio tradizionale sembra perdere terreno, in particolar modo nelle applicazioni <em>mission critical</em>. Inoltre questo modello sembra prendere piede anche in altre aree e la presenza di Node.js ne è un esempio.</p>
<p>Sulla stessa scia, c&#8217;è da sorvegliare anche l&#8217;andamento di <a href="http://www.lighttpd.net/">lighttpd</a> che per ora si attesta al 1,2% ma che può vantare &#8220;clienti&#8221; del calibro di YouTube, Wikipedia e meebo. La conclusione di tutto ciò è l&#8217;affermarsi di una risposta efficace e soprattutto efficiente alla sfida più grande dell&#8217;attuale Internet: i carichi esponenziali. E la fondazione Apache farebbe bene a prendere provvedimenti.</p>
<p>Via | <a href="http://nginx.org/en/CHANGES">NGINX</a></p>
]]></content>
    

  </entry>
  
  <entry>
    <title type="html">Debian può compilare su LLVM/Clang il 92% dei pacchetti in archivio</title>
    <link rel="alternate" type="text/html" href="http://www.ossblog.it/post/9617/debian-puo-compilare-su-llvmclang-il-92-dei-pacchetti-in-archivio" />
    <id>http://www.ossblog.it/?p=9617</id>
    <author>
      <name>Federico Moretti</name>
    </author>
    <published>2012-03-06T08:00:09+00:00</published>
    <updated>2012-03-06T08:00:09+00:00</updated>
    <dc:subject>debian</dc:subject><dc:subject>cc</dc:subject><dc:subject>archivi delle distribuzioni</dc:subject><dc:subject>linguaggi di programmazione</dc:subject><dc:subject>pacchetti precompilati</dc:subject><dc:subject>strumenti di sistema</dc:subject>
    <summary type="text"><![CDATA[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[...]]]></summary>
    <content type="html" xml:lang="it-it" xml:base="http://www.ossblog.it/post/9617/debian-puo-compilare-su-llvmclang-il-92-dei-pacchetti-in-archivio"><![CDATA[<p><img src="http://static.blogo.it/ossblog/llvm.jpg" class="post" border="0" align="left" width="280" height="210" alt="LLVM" /><a href="http://www.debian.org/">Debian</a> 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.</p>
<p>Sul totale di 15.658 pacchetti, appena 1.381 hanno fallito la compilazione: Ledru ha fornito una spiegazione dettagliata del tipo d’errore in <a href="http://clang.debian.net/">una sezione dedicata</a> 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.</p>
<p>Ledru è convinto che, nei prossimi anni, LLVM e Clang sostituiranno GCC nella <em>toolchain</em> 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 <em>governance</em>. LLVM non è un progetto di GNU.</p>
<p>Via | <a href="http://www.phoronix.com/scan.php?page=news_item&amp;px=MTA2NjQ">Phoronix</a></p>
 ]]></content>
    

  </entry>
  
  <entry>
    <title type="html">LLVM/Clang potrebbero supportare OpenMP da un prossimo aggiornamento</title>
    <link rel="alternate" type="text/html" href="http://www.ossblog.it/post/9301/llvmclang-potrebbero-supportare-openmp-da-un-prossimo-aggiornamento" />
    <id>http://www.ossblog.it/?p=9301</id>
    <author>
      <name>Federico Moretti</name>
    </author>
    <published>2012-01-17T10:00:29+00:00</published>
    <updated>2012-01-17T10:00:29+00:00</updated>
    <dc:subject>programmazione</dc:subject><dc:subject>cc</dc:subject><dc:subject>clang 3.1</dc:subject><dc:subject>gcc 4.7</dc:subject><dc:subject>llvm 3.1</dc:subject><dc:subject>openmp 3.1</dc:subject>
    <summary type="text"><![CDATA[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,[...]]]></summary>
    <content type="html" xml:lang="it-it" xml:base="http://www.ossblog.it/post/9301/llvmclang-potrebbero-supportare-openmp-da-un-prossimo-aggiornamento"><![CDATA[<p><img src="http://static.blogo.it/ossblog/openmp.jpg" class="post" border="0" align="left" width="280" height="210" alt="OpenMP" /><a href="http://openmp.org/">OpenMP</a>, l’Application Programming Interface (API) per il <em>parallel programming</em> 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.</p>
<p>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. <a href="http://clang.llvm.org/">Clang</a>, ad ogni modo, non permetterebbe la compilazione di tutti i linguaggi supportati da OpenMP.</p>
<p>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 <em>multi-threading</em> per Fortran resterebbe legato all’utilizzo di GCC e <a href="http://dragonegg.llvm.org/">DragonEgg</a> sarebbe comunque fondamentale per OpenMP.</p>
<p>Via | <a href="http://www.phoronix.com/scan.php?page=news_item&#038;px=MTA0Mzc">Phoronix</a></p>
 ]]></content>
    

  </entry>
  
  <entry>
    <title type="html">hello, world: The New York Times celebra la storia di Dennis Ritchie</title>
    <link rel="alternate" type="text/html" href="http://www.ossblog.it/post/9159/hello-world-the-new-york-times-celebra-la-storia-di-dennis-ritchie" />
    <id>http://www.ossblog.it/post/9159/hello-world-the-new-york-times-celebra-la-storia-di-dennis-ritchie/</id>
    <author>
      <name>Federico Moretti</name>
    </author>
    <published>2011-12-27T11:00:40+00:00</published>
    <updated>2011-12-27T11:00:40+00:00</updated>
    <dc:subject>programmazione</dc:subject><dc:subject>cc</dc:subject><dc:subject>dennis ritchie</dc:subject><dc:subject>hello world</dc:subject><dc:subject>the c programming language</dc:subject><dc:subject>the lives they lived</dc:subject>
    <summary type="text"><![CDATA[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[...]]]></summary>
    <content type="html" xml:lang="it-it" xml:base="http://www.ossblog.it/post/9159/hello-world-the-new-york-times-celebra-la-storia-di-dennis-ritchie"><![CDATA[<p><img src="http://static.blogo.it/ossblog/helloworld.jpg" class="post" border="0" align="left" width="280" height="210" alt="hello, world" /><a href="http://www.nytimes.com/interactive/2011/12/22/magazine/the-lives-they-lived.html">The Lives They Lived</a> (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 <a href="http://www.ossblog.it/post/8409/dennis-ritchie-e-morto">è morto</a> nella prima metà dell’ottobre di quest’anno. Una delle grandi personalità che ci hanno lasciati.</p>
<p>Il titolo assegnato al numero su Ritchie non poteva essere che <code>hello, world</code>: 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.</p>
<p>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 <a href="http://www.downloadblog.it/post/15813/e-morto-alleta-di-novantanni-jacob-goldman-fondatore-di-xerox-lab">Jacob Goldman</a> — il creatore di Xerox Lab, morto settimana scorsa. Ritchie e Goldman sono legati da UNIX, il sistema operativo che ha stimolato la nascita dell’<em>open source</em>.</p>
<p>Via | <a href="http://bits.blogs.nytimes.com/2011/12/23/hello-world-the-inventor-of-c/">The New York Times</a></p>
 ]]></content>
    

  </entry>
  
  <entry>
    <title type="html">Mono inaugura il supporto all’interoperabilità con C++ grazie a CXXI</title>
    <link rel="alternate" type="text/html" href="http://www.ossblog.it/post/9119/mono-inaugura-il-supporto-allinteroperabilita-con-c-grazie-a-cxxi" />
    <id>http://www.ossblog.it/?p=9119</id>
    <author>
      <name>Federico Moretti</name>
    </author>
    <published>2011-12-21T09:00:43+00:00</published>
    <updated>2011-12-21T09:00:43+00:00</updated>
    <dc:subject>mono</dc:subject><dc:subject>cc</dc:subject><dc:subject>compilazione dei sorgenti</dc:subject><dc:subject>interoperabilità del codice</dc:subject><dc:subject>librerie dinamiche</dc:subject><dc:subject>linguaggi di programmazione</dc:subject>
    <summary type="text"><![CDATA[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[...]]]></summary>
    <content type="html" xml:lang="it-it" xml:base="http://www.ossblog.it/post/9119/mono-inaugura-il-supporto-allinteroperabilita-con-c-grazie-a-cxxi"><![CDATA[<p><img src="http://static.blogo.it/ossblog/monobyxamarin.jpg" class="post" border="0" align="left" width="250" height="188" alt="Mono by Xamarin" /><a href="https://github.com/mono/cxxi">CXXI</a> è 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 <em>binding</em> e dei test per Qt. CXXI sostituisce gli espedienti utilizzati da Mono per il dialogo con C++.</p>
<p>Ad esempio, in passato i manutentori di Mono avevano realizzato un <em>binding</em> 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.</p>
<p>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.</p>
 <p>
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 <code>.dll</code> in C# o .NET. Questo è il meccanismo più semplice.</p>
<p>Quando i sorgenti prevedono il <em>parsing</em> 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<code> .dll</code>. Un meccanismo abbastanza complicato per le esigenze attuali.</p>
<p>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.</p>
<p>Via | <a href="http://tirania.org/blog/archive/2011/Dec-19.html">Miguel De Icaza</a></p>
]]></content>
    

  </entry>
  
  <entry>
    <title type="html">nVidia ha approvato la distribuzione del codice sorgente di CUDA 4.1</title>
    <link rel="alternate" type="text/html" href="http://www.ossblog.it/post/9071/nvidia-ha-approvato-la-distribuzione-del-codice-sorgente-di-cuda-41" />
    <id>http://www.ossblog.it/?p=9071</id>
    <author>
      <name>Federico Moretti</name>
    </author>
    <published>2011-12-15T09:00:16+00:00</published>
    <updated>2011-12-15T09:00:16+00:00</updated>
    <dc:subject>driver</dc:subject><dc:subject>cc</dc:subject><dc:subject>cuda 4.1</dc:subject><dc:subject>gpgpu</dc:subject><dc:subject>nvidia</dc:subject><dc:subject>parallel computing</dc:subject>
    <summary type="text"><![CDATA[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à[...]]]></summary>
    <content type="html" xml:lang="it-it" xml:base="http://www.ossblog.it/post/9071/nvidia-ha-approvato-la-distribuzione-del-codice-sorgente-di-cuda-41"><![CDATA[<p><img src="http://static.blogo.it/ossblog/nvidia_01.jpg" class="post" border="0" align="left" width="280" height="210" alt="nVidia" />L’aggiornamento di Compute Unified Device Architecture (<a href="http://www.nvidia.com/object/cuda_home_new.html">CUDA</a>), l’infrastruttura di nVidia per il <em>parallel computing</em> sui processori grafici, include un nuovo compilatore basato su LLVM. Già distribuito nel <em>toolkit</em> per i driver proprietari, quest’ultimo avrà una licenza <em>open source</em> — perché possa essere applicato ad altri processori.</p>
<p>È 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 <em>open source</em> da comunicare. Non significa che CUDA funzionerà su Nouveau.</p>
<p>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’<a href="http://developer.nvidia.com/content/cuda-platform-source-release">un modulo</a> per qualificare gli sviluppatori.</p>
<p>Via | <a href="http://pressroom.nvidia.com/easyir/customrel.do?easyirid=A0D622CE9F579F09&#038;version=live&#038;releasejsp=release_157&#038;xhtml=true&#038;prid=831864">nVidia</a></p>
 ]]></content>
    

  </entry>
  
  <entry>
    <title type="html">Rilasciato LLVM 3.0</title>
    <link rel="alternate" type="text/html" href="http://www.ossblog.it/post/8881/rilasciato-llvm-30" />
    <id>http://www.ossblog.it/?p=8881</id>
    <author>
      <name>Giacomo Picchiarelli</name>
    </author>
    <published>2011-12-05T12:00:34+00:00</published>
    <updated>2011-12-05T12:00:34+00:00</updated>
    <dc:subject>programmazione</dc:subject><dc:subject>cc</dc:subject><dc:subject>llvm 3.0</dc:subject><dc:subject>llvm compiler</dc:subject><dc:subject>llvm developer group</dc:subject>
    <summary type="text"><![CDATA[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&amp;#8217;occasione per eliminare qualche vecchio[...]]]></summary>
    <content type="html" xml:lang="it-it" xml:base="http://www.ossblog.it/post/8881/rilasciato-llvm-30"><![CDATA[<p><img src="http://static.blogo.it/ossblog/llvm.jpg" class="post" border="0" align="left" width="280" height="210" alt="LLVM" />Dopo <a href="http://www.ossblog.it/post/8761/llvm-30-in-ritardo-di-due-settimane-chiude-llvm-gcc-per-dragonegg">la lunga attesa</a>, finalmente arriva la versione 3.0 di <a href="http://llvm.org/">LLVM</a>. Di fatto questo è un rilascio incrementale, ma gli sviluppatori non hanno perso l&#8217;occasione per eliminare qualche vecchio modulo. Sono stati necessari sei mesi di sviluppo dalla versione 2.9 per introdurre importanti novità: un nuovo <em>register allocator</em> per migliorare ulteriormente le prestazioni, il supporto completo per operazioni atomiche e il nuovo <em>memory model</em> per C++.</p>
<p>Avevamo già trattato l&#8217;abbandono di <code>llvm-gcc</code> in favore di CLang e DragonEgg. E proprio CLang offre numerose correzioni e migliorie: ridotta lunghezza nei messaggi di errore, ricavando così un&#8217;informazione più immediata e suggerimenti in caso di errori di digitazione. Quest&#8217;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 <em>warning</em>, il tutto a beneficio dell&#8217;espressività della diagnostica.</p>
<p>Lo sforzo degli sviluppatori si è concentrato non solo nelle prestazioni, migliorate rispetto alla precedente versione, ma anche per quanto riguarda l&#8217;aderenza ai recenti standard per C/C++. Ad esempio sono state introdotte molte caratteristiche del <a href="http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=50372">C++11</a> come il supporto agli <code>alias</code>, i cicli <code>for</code> basati su intervalli e le espressioni <code>noexcept</code>. Infine per quanto riguarda il <em>plugin</em> <a href="http://dragonegg.llvm.org/">DragonEgg</a>, non sarà più necessario apportare la <em>patch</em> ed effettuare la compilazione di GCC. La versione 4.6 è pienamente supportata.</p>
<p>Via | <a href="http://www.phoronix.com/scan.php?page=news_item&#038;px=MTAyMjE">Phoronix</a></p>
 ]]></content>
    

  </entry>
  
  <entry>
    <title type="html">Programmazione parallela con OpenMP</title>
    <link rel="alternate" type="text/html" href="http://www.ossblog.it/post/8539/programmazione-parallela-con-openmp" />
    <id>http://www.ossblog.it/?p=8539</id>
    <author>
      <name>Giacomo Picchiarelli</name>
    </author>
    <published>2011-10-27T11:00:13+00:00</published>
    <updated>2011-10-27T11:00:13+00:00</updated>
    <dc:subject>programmazione</dc:subject><dc:subject>cc</dc:subject><dc:subject>gcc programmazione parallela</dc:subject><dc:subject>parallel programming</dc:subject><dc:subject>programmazione parallela</dc:subject><dc:subject>programmazione parallela linux</dc:subject>
    <summary type="text"><![CDATA[OpenMP è una specifica API che consente l&amp;#8217;esecuzione parallela di task secondo il modello a memoria condivisa. Questo consente di creare programmi che implementano la programmazione parallela[...]]]></summary>
    <content type="html" xml:lang="it-it" xml:base="http://www.ossblog.it/post/8539/programmazione-parallela-con-openmp"><![CDATA[<p><img src="http://static.blogo.it/ossblog/openmp.png" class="post" border="0" align="left" width="250" height="250" alt="OpenMP" />OpenMP è una specifica API che consente l&#8217;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 <em>cluster</em>, se usato in combinazione di MPI, sia su normali computer desktop. I linguaggi supportati sono CC++ e Fortran.</p>
<p>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 è <code>-fopenmp</code>. 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&#8217;esecuzione parallela.</p>
<p>Un classico esempio, per questo genere di programmazione, è la parallelizzazione dei cicli: il comando è <code>#pragma omp parallel for</code>. Sono inoltre disponibili diversi metodi di sincronizzazione per sezioni critiche, variabili condivise e <em>race condition</em>: <code>critical</code>,<code> atomic</code>, <code>ordered</code>, <code>barrier</code> e <code>nowait</code>. Inoltre si può specificare il numero di <em>thread</em> da console, in fase di compilazione, con la variabile d&#8217;ambiente <code>OMP_NUM_THREADS=n°thread</code>.</p>
<p>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&#8217;è una sola &#8220;pecca&#8221; degna di nota, a mio parere: non può essere utilizzata per le GPU. Una lacuna che si spera venga colmata presto. </p>
<p>Via | <a href="http://www.linuxjournal.com/content/big-box-science">Linux Journal</a></p>
 ]]></content>
    

  </entry>
  
  <entry>
    <title type="html">Dennis Ritchie è morto</title>
    <link rel="alternate" type="text/html" href="http://www.ossblog.it/post/8409/dennis-ritchie-e-morto" />
    <id>http://www.ossblog.it/?p=8409</id>
    <author>
      <name>Giacomo Picchiarelli</name>
    </author>
    <published>2011-10-13T14:30:17+00:00</published>
    <updated>2011-10-13T14:30:17+00:00</updated>
    <dc:subject>unix</dc:subject><dc:subject>cc</dc:subject><dc:subject>creatore linguaggio c</dc:subject><dc:subject>creatore unix</dc:subject><dc:subject>morte dennis ritchie</dc:subject>
    <summary type="text"><![CDATA[Ci ha lasciati, all&amp;#8217;età di 70 anni. Dennis Ritchie è uno di quei giganti dell&amp;#8217;informatica a cui tutti dobbiamo qualcosa. Insieme a Ken Thompson creò il linguaggio C e il sistema[...]]]></summary>
    <content type="html" xml:lang="it-it" xml:base="http://www.ossblog.it/post/8409/dennis-ritchie-e-morto"><![CDATA[<p><img src="http://static.blogo.it/ossblog/lc.jpg" class="post" border="0" align="left" width="250" height="250" alt="" />Ci ha lasciati, all&#8217;età di 70 anni. Dennis Ritchie è uno di quei giganti dell&#8217;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.</p>
<p>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 <em>IEEE Richard W. Hamming Medal</em>, nel 1998 ricevette la Medaglia Nazionale della Tecnologia consegnata dal Presidente USA Bill Clinton per poi concludere con il <em>Japan Prize for Information and Communications</em>. Continuò a lavorare instancabilmente fino al 2007, anno della pensione.</p>
<p>L&#8217;estrema semplicità e l&#8217;eleganza della logica di UNIX hanno attraversato i decenni senza invecchiare. Un&#8217;eredità tanto importante quanto attuale che Dennis Ritchie ha lasciato al mondo dell&#8217;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&#8217;Informatica più che averla studiata ha contribuito a crearla. Grazie.</p>
<p>Via | <a href="http://blog.tagxedo.com/rip-dennis-ritchie-father-of-unix-and-c-58975">Tagxedo</a><br />
Foto | <a href="http://www.flickr.com/photos/believekevin/6239216961/">Flickr</a></p>
 ]]></content>
    

  </entry>
  
  <entry>
    <title type="html">Google ha aggiunto l&#039;utilizzo di C/C++ a Chrome 15 via Native Client</title>
    <link rel="alternate" type="text/html" href="http://www.ossblog.it/post/7904/google-ha-aggiunto-lutilizzo-di-cc-a-chrome-15-via-native-client" />
    <id>http://www.ossblog.it/?p=7904</id>
    <author>
      <name>Federico Moretti</name>
    </author>
    <published>2011-08-12T11:00:07+00:00</published>
    <updated>2011-08-12T11:00:07+00:00</updated>
    <dc:subject>google</dc:subject><dc:subject>cc</dc:subject><dc:subject>chrome dev</dc:subject><dc:subject>native client</dc:subject><dc:subject>pepper plugin</dc:subject><dc:subject>web audio</dc:subject>
    <summary type="text"><![CDATA[Chrome 15 è in grado d&amp;#8217;eseguire del codice in C/C++ attraverso il Native Client: la novità apre interessanti prospettive allo sviluppo d&amp;#8217;applicazioni web per il browser.[...]]]></summary>
    <content type="html" xml:lang="it-it" xml:base="http://www.ossblog.it/post/7904/google-ha-aggiunto-lutilizzo-di-cc-a-chrome-15-via-native-client"><![CDATA[<p><img src="http://static.blogo.it/ossblog/googlechromedev.png" class="post" border="0" align="left" width="280" height="210" alt="Google Chrome Dev" /><a href="http://www.google.com/chrome/eula.html?extra=betachannel">Chrome 15</a> è in grado d&#8217;eseguire del codice in C/C++ attraverso il <a href="http://code.google.com/intl/it/chrome/nativeclient/">Native Client</a>: la novità apre interessanti prospettive allo sviluppo d&#8217;applicazioni web per il browser. L&#8217;esecuzione del codice è soggetta a delle restrizioni, simili a quelle già previste per JavaScript. <a href="http://code.google.com/p/ppapi/">Pepper</a> è il plugin responsabile dei <em>binding</em> di C/C++ per HTML5.</p>
<p>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&#8217;implementazione delle <a href="https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html">Web Audio API</a>.</p>
<p>Insieme all&#8217;attivazione del Native Client con la possibilità d&#8217;eseguire il codice in C/C++, Chrome 15 include l&#8217;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 <a href="http://chromium.googlecode.com/svn/trunk/samples/audio/index.html">degli esempi riproducibili</a> con Chrome 15.</p>
<p>Via | <a href="http://chrome.blogspot.com/2011/08/building-better-web-apps-with-new.html">Google</a></p>
 ]]></content>
    

  </entry>
  
  <entry>
    <title type="html">È ripreso lo sviluppo di Resynthesizer per The GIMP da Photoshop CS5</title>
    <link rel="alternate" type="text/html" href="http://www.ossblog.it/post/7638/the-gimp-resynthesizer-2011" />
    <id>http://www.ossblog.it/?p=7638</id>
    <author>
      <name>Federico Moretti</name>
    </author>
    <published>2011-04-17T11:00:13+00:00</published>
    <updated>2011-04-17T11:00:13+00:00</updated>
    <dc:subject>grafica</dc:subject><dc:subject>cc</dc:subject><dc:subject>adobe photoshop cs5</dc:subject><dc:subject>content-aware fill</dc:subject><dc:subject>resynthesizer</dc:subject><dc:subject>the gimp</dc:subject>
    <summary type="text"><![CDATA[Com&amp;#8217;è 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[...]]]></summary>
    <content type="html" xml:lang="it-it" xml:base="http://www.ossblog.it/post/7638/the-gimp-resynthesizer-2011"><![CDATA[<p><img src="http://static.blogo.it/ossblog/thegimp28.png" class="post" border="0" align="left" width="280" height="235" alt="The GIMP 2.8" />Com&#8217;è 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&#8217;arte di quest&#8217;ultimo è rimasto a nove anni fa: Lloyd Konneker ha pensato di riprendere lo sviluppo di Resynthesizer e d&#8217;adattarlo alle nuove necessità.</p>
<p>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 <em>alpha</em>: risolvendo alcuni bug, <a href="http://registry.gimp.org/node/25219">ha rilasciato</a> Resynthesizer come 1.0. Questa versione riparte direttamente dalla 0.16 degli autori originali.</p>
<p>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 <a href="https://github.com/bootchk/resynthesizer">è mantenuto</a> su GitHub.</p>
<p>Via | <a href="http://libregraphicsworld.org/news.php?readmore=765">Libre Graphics World</a></p>
 ]]></content>
    

  </entry>
  
  <entry>
    <title type="html">Angry Birds si basa su Box 2D, il motore fisico creato da Erin Catto</title>
    <link rel="alternate" type="text/html" href="http://www.ossblog.it/post/7464/angry-birds-box-2d" />
    <id>http://www.ossblog.it/post/7464/angry-birds-box-2d/</id>
    <author>
      <name>Federico Moretti</name>
    </author>
    <published>2011-03-03T09:00:49+00:00</published>
    <updated>2011-03-03T09:00:49+00:00</updated>
    <dc:subject>giochi</dc:subject><dc:subject>cc</dc:subject><dc:subject>android market</dc:subject><dc:subject>angry birds</dc:subject><dc:subject>box 2d</dc:subject><dc:subject>rovio mobile</dc:subject>
    <summary type="text"><![CDATA[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[...]]]></summary>
    <content type="html" xml:lang="it-it" xml:base="http://www.ossblog.it/post/7464/angry-birds-box-2d"><![CDATA[<p><img src="http://static.blogo.it/ossblog/angrybirdsbox2d.gif" class="post" border="0" align="left" width="280" height="235" alt="Angry Birds - Box 2D" />Angry Birds, il popolare videogioco di Rovio Mobile, è basato su <a href="http://www.box2d.org/">Box 2D</a>: si tratta di un <em>physical engine</em> creato da Erin Catto e rilasciato sotto licenza <em>open source</em>. 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.</p>
<p>In occasione del <a href="http://www.gamesblog.it/cerca/gdc+11">Game Developer Conference 2011</a>, 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.</p>
<p>Soddisfatto della risposta, Catto ha rivelato la propria identità e al termine dell&#8217;intervento si è trattenuto a parlare con Vesterbacka. È un&#8217;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.</p>
<p>Via | <a href="http://www.mobilecrunch.com/2011/02/28/creator-of-angry-birds-physics-engine-calls-out-rovio-for-not-giving-him-credit/">MobileCrunch</a></p>
 ]]></content>
    

  </entry>
  
  <entry>
    <title type="html">Boost, come essere più produttivi in C++</title>
    <link rel="alternate" type="text/html" href="http://www.ossblog.it/post/7461/boost-come-essere-piu-produttivi-in-c" />
    <id>http://www.ossblog.it/?p=7461</id>
    <author>
      <name>Lpt on fire!</name>
    </author>
    <published>2011-03-02T13:00:35+00:00</published>
    <updated>2011-03-02T13:00:35+00:00</updated>
    <dc:subject>open-source</dc:subject><dc:subject>cc</dc:subject><dc:subject>boost</dc:subject><dc:subject>boost 1.46</dc:subject><dc:subject>boost c++</dc:subject>
    <summary type="text"><![CDATA[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[...]]]></summary>
    <content type="html" xml:lang="it-it" xml:base="http://www.ossblog.it/post/7461/boost-come-essere-piu-produttivi-in-c"><![CDATA[<p><img src="http://static.blogo.it/ossblog/boost_01.jpg" class="post-h" border="0" width="432" height="137" alt="" /><br clear="all" /></p>
<p><a href="http://www.boost.org">Boost</a> è una comunità di programmatori C++ che sviluppano una serie di librerie utili per espandere il linguaggio e per semplificare la programmazione in C++.</p>
<p>Alcune delle librerie già implementate sono state proposte al C++ Standards Committee per l&#8217;inclusione come standard nella prossima versione del linguaggio che va sotto il nome di C++0x. Alcune di queste sono già presenti nella <a href="http://en.wikipedia.org/wiki/C%2B%2B_Technical_Report_1">Library Technical Report (TR1)</a>.</p>
<p>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.</p>
<p>Alcune delle librerie più utili semplificano l&#8217;uso di smart pointer, array, programmazione funzionale, generic programming, grafi, immagini, regex, serializzazione, thread, file, file system.</p>
<p>Via | <a href="http://www.boost.org/users/download/version_1_46_0">Boost</a></p>
 ]]></content>
    

  </entry>
  
  <entry>
    <title type="html">ZFS non dipende più da Python su Illumos e D&#039;Amore interroga FreeBSD</title>
    <link rel="alternate" type="text/html" href="http://www.ossblog.it/post/7147/zfs-non-dipende-piu-da-python-su-illumos-e-damore-interroga-freebsd" />
    <id>http://www.ossblog.it/post/7147/zfs-non-dipende-piu-da-python-su-illumos-e-damore-interroga-freebsd/</id>
    <author>
      <name>Federico Moretti</name>
    </author>
    <published>2010-12-03T11:00:25+00:00</published>
    <updated>2010-12-03T11:00:25+00:00</updated>
    <dc:subject>cc</dc:subject><dc:subject>file-system</dc:subject><dc:subject>illumos</dc:subject><dc:subject>python</dc:subject><dc:subject>pyzfs</dc:subject><dc:subject>zfs</dc:subject>
    <summary type="text"><![CDATA[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[...]]]></summary>
    <content type="html" xml:lang="it-it" xml:base="http://www.ossblog.it/post/7147/zfs-non-dipende-piu-da-python-su-illumos-e-damore-interroga-freebsd"><![CDATA[<p><img src="http://static.blogo.it/ossblog/illumos_01.png" class="post" border="0" align="left" width="250" height="188" alt="Illumos" />Quello delle dipendenze è un annoso problema dei sistemi UNIX-<em>like</em>. 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&#8217;eliminazione di Python dal comando <code>zfs</code>. Il <em>commit</em> è stato effettuato mercoledì da Alexander Stetsenko. Il significato è quello di rendere quanto più <em>cross-platform</em> sia possibile l&#8217;utilità per gestire il <em>file system</em>.</p>
<p>Non è certo in discussione Python come linguaggio in sé o, PyZFS: l&#8217;intento è stato quello di ridurre all&#8217;osso le dipendenze e il fatto che <code>zfs</code> sia in C al 100% non presuppone alcuna scelta di merito. Una scelta obbligata, insomma. Garret D&#8217;Amore di Nexenta, tra i più attivi nel riportare i progressi di Illumos, nel dare la notizia ha chiesto esplicitamente dei riscontri sull&#8217;implementazione da parte degli sviluppatori di FreeBSD.</p>
<p>Nonostante <a href="http://www.ossblog.it/post/7100/zfs-per-linux-e-disponibile-al-pubblico-richiesta-una-registrazione">la beta pubblica di ZFS per Linux</a> sia stata rilasciata settimana scorsa è normale che D&#8217;Amore non abbia pensato di interpellare la comunità del pinguino. L&#8217;uso di ZFS in <em>userspace</em> presuppone tutt&#8217;altra infrastruttura e in generale il file system è poco sfruttato su Linux. È interessante aspettare un&#8217;eventuale risposta da parte del team di Debian (e Gentoo?) GNU/kFreeBSD. Intanto gli sviluppatori sono avvisati.</p>
<p>Via | <a href="http://gdamore.blogspot.com/2010/12/zfs-should-not-depend-on-python-and.html">Garret D&#8217;Amore</a></p>
 ]]></content>
    

  </entry>
  
  <entry>
    <title type="html">Tar, Gentoo e la soluzione di Daniel Robbins ai problemi di compilazione</title>
    <link rel="alternate" type="text/html" href="http://www.ossblog.it/post/6973/tar-gentoo-e-la-soluzione-di-daniel-robbins-ai-problemi-di-compilazione" />
    <id>http://www.ossblog.it/post/6973/tar-gentoo-e-la-soluzione-di-robbins-ai-problemi-di-compilazione/</id>
    <author>
      <name>Federico Moretti</name>
    </author>
    <published>2010-11-02T10:00:58+00:00</published>
    <updated>2010-11-02T10:00:58+00:00</updated>
    <dc:subject>gentoo</dc:subject><dc:subject>cc</dc:subject><dc:subject>errori di compilazione</dc:subject><dc:subject>problemi del compilatore</dc:subject><dc:subject>tar 1.24</dc:subject><dc:subject>virtualizzazione con linux</dc:subject>
    <summary type="text"><![CDATA[Introducendo Funtoo, la nuova creatura di Daniel Robbins, avevo parlato di «software instabile e ultra-aggiornato». L&amp;#8217;affermazione è valida solo in parte, perché rispetto al portage[...]]]></summary>
    <content type="html" xml:lang="it-it" xml:base="http://www.ossblog.it/post/6973/tar-gentoo-e-la-soluzione-di-daniel-robbins-ai-problemi-di-compilazione"><![CDATA[<p><img src="http://static.blogo.it/ossblog/gentoo_02.png" class="post" border="0" align="left" width="250" height="250" alt="Gentoo" />Introducendo <a href="http://www.ossblog.it/post/6900/daniel-robbins-incassa-altri-consensi-funtoo-e-in-crescita">Funtoo</a>, la nuova creatura di Daniel Robbins, avevo parlato di «software instabile e ultra-aggiornato». L&#8217;affermazione è valida solo in parte, perché rispetto al <em>portage</em> standard di Gentoo alcuni componenti sono mantenuti a versioni stabili che il team di sviluppo ritiene più affidabili. Ciò prescindendo dall&#8217;uso di <em>overlay</em> che sovrascrivano le impostazioni predefinite. <a href="http://www.gnu.org/software/tar/">Tar</a> è uno di questi: vediamo subito perché.</p>
<p>Negli ultimi giorni, chi utilizza una distribuzione Gentoo o, derivata avrà certamente riscontrato dei problemi nell&#8217;aggiornamento di applicazioni, librerie ecc. che dipendono da Tar. Quest&#8217;ultimo è proposto dal portage di Gentoo nella versione 1.24, che è affetta da <a href="http://bugs.gentoo.org/show_bug.cgi?id=343245">un bug molto fastidioso</a>. Sebbene gli sviluppatori abbiano già provveduto a risolvere il primo problema, ne è emerso un secondo addirittura peggiore.</p>
<p>Il bug risolto da Gentoo riguarda il riconoscimento dell&#8217;opzione <code>-C</code> nella compilazione di Tar 1.24-R1. Il portage standard offre ora Tar 1.24-R2, che corregge gli errori del compilatore&#8230; ma non i conflitti con <a href="http://www.ossblog.it/tag/openvz">OpenVZ</a> e soprattutto <a href="http://www.funtoo.org/en/metro/tutorial/">Metro</a> (l&#8217;<em>utility</em> 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.</p>
<p>Via | <a href="http://blog.funtoo.org/2010/10/tar-124-ouchies.html">Daniel Robbins</a></p>
 ]]></content>
    

  </entry>
  
</feed>

