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

1 commento

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

1 commento

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

3 commenti

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

0 commenti

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

4 commenti

Non se ne parla spesso, specie perché Google Go non ha avuto il successo che si aspettava. Il linguaggio non ha ancora compiuto un anno e sembra che la sua adozione si appresti ad avere un picco grazie all’inserimento in GCC. Mountain View non ha dovuto cambiare il nome di Go, ma l’accettazione del linguaggio in GCC (che pure risale al gennaio di quest’anno) è rimasta in sospeso, tanto che GCC 4.5.0 non lo supporta.

L’effettivo ingresso di Go in GCC potrebbe avvenire con la versione 4.6.0 della collezione di compilatori. Ian Taylor, che era già stato incaricato di lavorare al supporto per GCC, ha cominciato a discutere del frontend sulla mailing list del progetto. Ciò significa che nel corso del 2011 Google Go potrebbe finalmente essere compilato con GCC. Il condizionale è d’obbligo, perché non esiste ancora una release schedule.

Quando Go sarà in GCC è possibile che il linguaggio salga ancora nella classifica dei più utilizzati: lo spread dei primi mesi di vita potrebbe essere bissato e insidiare, oltre a Object-C, l’uso di C++ cui Google Go si rivolge espressamente. Tornando a parlare della struttura del linguaggio di programmazione in sé, Go propone una commistione tra Python (molto in voga a Mountain View) e C++. Avrà il successo di VP8?

Via | Phoronix

6 commenti

Nuitka è un progetto, rilasciato sotto licenza GPLv3, che vuole unire l’espressività di Python con la potenza dei linguaggi compilati, in questo caso C++.

Al momento supporta tutti i costrutti di CPython 2.6 e traduce il codice python in un programma c++ che poi esegue grazie alla libpython. Nuitka è già più veloce dell’interprete standard, ma il progetto è solo al primo stadio della sua tabella di marcia.

Ieri è stata rilasciata la versione 0.3.2 che corregge alcuni bug.

Via | kayhayen24×7

1 commento

Chris Lattner ha annunciato l’arrivo della versione 2.8 di LLVM (Low-Level Virtual Machine).

Il lavoro degli ultimi 6 mesi si è concentrato particolarmente sul supporto per Clang C++ che ora è stato definito usabile e sull’arrivo dei due sottoprogetti libc++ e LLDB di cui vi abbiamo parlato qualche tempo fa. La prima è una libreria per supportare il futuro standard C++’0x, mentre il secondo è un nuovo debugger che sfrutta appieno le tecnologie del progetto LLVM.

Tra le altre novità un nuovo assemblatore, un disassemblatore ARM e miglioramenti nella generazione del codice per ARM.

Via | LLVM

0 commenti

LLVM è un progetto in continua evoluzione: benché non sia proprio la sua prima applicazione, è facile averci a che fare compilando i driver per la scheda video. Più in generale, per chi ancora non lo sapesse, si tratta di una macchina virtuale per compilare disparati linguaggi: C/C++, CLang, ecc. anche come plugin per GCC 4.5 o, superiore. Come tale è potenzialmente soggetto all’inserimento di codice malevolo.

Ed è così che ClamAV, popolare antivirus open source, ha pensato d’inserire nell’ultima versione il supporto al compilatore LLVM JIT. ClamAV 0.96 può ora indagare anche i sorgenti in C gestiti da LLVM alla ricerca di pericoli per il sistema. Per ottenere il supporto occorre necessariamente rimuovere ogni versione di ClamAV installata e compilarne i sorgenti. Un’ottima guida è presente sul blog di Sourcefire.

Un passo avanti importante per ClamAV. Certo, LLVM non è un’infrastruttura di massa e pure tra gli sviluppatori stenta a decollare perché ancora (parzialmente) instabile. Eppure il fatto che un’applicazione come ClamAV presti attenzione alle vulnerabilità di LLVM è un aggiornamento degno di nota. Molto bene così.

Via | LLVM

8 commenti

L’ultima parte di codice protetto dalla Sun RPC è stata “liberata” da Oracle e GLibC è finalmente free software al 100%. Non tutto il male viene per nuocere, parrebbe: un limite risalente al 1985 è stato risolto solo con l’acquisizione di Sun Microsystems da parte di Oracle. Una delle librerie fondamentali per Linux è diventata FLOSS a venticinque anni dal suo concepimento. È rilasciata sotto la nuova licenza BSD.

Il problema è che, quando la licenza per GLibC è stata concepita nel 1984, non esisteva ancora il concetto di free software come siamo abituati a intenderlo con la FSF e la GPL. Per quanto possa sembrare paradossale, la Sun RPC per l’epoca era già una licenza molto permissiva. Il processo d’apertura ha richiesto tanto tempo perché la soluzione migliore è apparsa quella di ridistribuire il codice con una licenza diversa.

Sun Microsystems non ha mai risolto il conflitto, forse persino per incuria. Alcuni tentativi per ripristinare una sorta d’omogeneità sulle licenze di distribuzione per i componenti di GLibC erano stati fatti nel 2009, ma soltanto oggi è stato possibile intervenire. Ed è stato grazie a Oracle. Tom Callaway ha dato la notizia sul suo blog e il codice è sui server di Red Hat. Restano da appianare solo alcune questioni su krb5.

Via | The H Open

2 commenti