Gimp 2.9 verso il 2.10

Splash Screen di Gimp 2.9

È da un po di tempo che sto usando Gimp 2.9 senza problemi di sorta.  Quindi penso che per gli utenti di questo software sarebbe bello da compilare.

Come compilare Gimp 2.9 su ArchLinux:

  • Per prima cosa bisogna compilare ed installare babl-git che può essere usato anche con gimp 2.8.
  • Dopo aver installato babl-git serve gegl-git, ovvero il nuovo motore grafico di Gimp 2.10, che va compilato ed installato.
  • Ora c’è tutto quello che serve, e si può procedere con Gimp 2.9, ed in questo serve il panchetto gimp-git ed una volta compilato va installato.

Tutto finito.

I pacchetti possono essere installati con yaourt, o meglio installandoli compilandoli a mano col makepkg. Unica cosa per la loro compilazione è necessario l’applicativo git. Se in fase di compilazione vi vengono richieste alcune dipendenze mancanti non dovete far altro che installarle, sono tutte presenti nei repo ufficiali.

Se tutto è andato bene, dando il comando gimp, o cercando la entry nel menu delle applicazioni partirà gimp 2.9.

Lo spashscreen (vedi sopra) non è molto rassicurante, ma nella pratica, al momento in cui scrivo l’applicativo è stabile ed usabile con un rischio molto basso di crash.

L’unico vero problema che ho è una integrazione coi la GUI dei filtri G’MIC ancora problematica.

Le maggiori novità che saltano subito all’occhio sono le funzioni gegl marcate con una G nei menu, la possibilita di usare una profondità di colore fino a 32 bit per canale e la funzione warp. Un altra novità di rilievo è sicuramente la possibilità di regolare la temperatura del colore. Inoltre alcuni filtri ora possono funzionare con OpenCL e la GPU.

Oltre a questo ci sono nuovi e più preformanti algoritmi per il rescaling delle immagini. E altre novità ….

In conclusione posso solo dire che l’attuale Gimp 2.9 funziona bene e per chi ha voglia di compilare è più che consigliabile.

Il mito della frammentazione del progetto GNU/Linux

L’utente che non consce il mondo Linux di regola come prima cosa va su distrowatch guarda la lista delle distro e scopre che ne sono state registrate 303,  se poi va a dare un occhiata alla pagina wikipedia http://it.wikipedia.org/wiki/Distribuzione_Linux  la situazione in apparenza è ancora più frammentata, creando un enorme dispersione di energie.

Ma guardiamo alla realtà, una distribuzione è solo l’ultimo tassello del progetto GNU / Linux  e prima di arrivare a questa sono necessari molti altri componenti software ed in genere molto più sofisticati di una distro:

Il Kernel Linux è gestito come progetto unico e molto centralizzato.
GCC è il compilatore standard ed è un progetto unico e senza reali concorrenti nel mondo GNU / Linux
systemd è ormai uno standard su Linux e è di fatto unico.
Xorg è lo standard e al momento non ha rivali.

e molti altri componenti fondamentali del sistema sono di fatto gestiti in modo centralizzato.

Resta la particolarità di KDE e GNOME e tutti gli altri WM, ma anche in questo caso oltre ai due progetti dominanti l’unico che riesce ad avere una base consistetene di utenti è Xfce. Oltre al fatto che questi 3 WM coprono differenti richiese ed esigenze degli utenti.

Nei software specifici la situazione è molto più frammentata, ma per l’appunto restano prodotti specifici e coprono le esigenze particolari degli utenti (nel mondo Win la situazione in questo settore è molto simile).

Ma se si torna alle distribuzioni, si scopre in poco tempo che di fatto  il 90% degli utenti Linux è coperto al massimo una decina di distribuzioni (Arch compresa).

Quindi anche in questo caso mi sembra che la maggior parte degli sforzi si concentrino su un numero molto limitato di distribuzioni, diciamo Ubuntu, Mint, Fedoda, OpenSuse, ArchLinux, Debian e poche altre. Che poi nella pratica sono tutte distribuzioni sviluppate con filosofie differenti fra di loro e che vanno a coprire richieste differenti.

E tutte le altre distro? Si tratta del mondo open source quindi ognuno può fare quello che vuole ed è libero di sperimentare le sue idee e se sono buone un giorno potrà entrare nella top-10 con la sua distro.

[Quando cominciai ad usare Arch  nel 2006, era considerata una distro minore e con pochissimi utenti, ma molto innovativa; il tempo gli ha dato ragione!].

Come unica conclusione posso solo dire che gli sforzi per lo sviluppo del progetto GNU/Linux sono di fatto uniti e ben distribuiti sui vari componenti; sfatando il mito della frammentazione.

Rekonq … sempre meglio.

Rekonq (2.3.2) nato come browser per l’ambiente KDE, si sta rivelando un ottimo browser (basato su WebKit) sempre più stabile, veloce e ricco di feauires. Il progetto nato grazie ad Andrea Diamantini ha un agguerrito gruppo di sviluppatori che stanno portando avanti un ottimo lavoro.

Fra le features notiamo il tab browsing (ormai assimilato da tutti), la navigazione in incognito e l’integrazione degli ad-block.

Di originale dobbiamo notare la preview sui tab (cosa che nessun altro browser offre) ed una pagina iniziale molto più dinamica e personalizzabile rispetto a quelle di firefox o chrome. La barra di navigazione non ha ancora tutte le funzionalità della concorrenza, in particolare manca ancora la possibilità di scrivere un termine di ricerca (ma non penso che dobbiamo aspettare ancora molto).

Che manca davvero a rekonq sono le estensioni, sopratutto non sarebbe male avere l’integrazione con quelle di altri browser. Ma anche su questo fronte si stanno muovendo verso il supporto delle estensioni di chrome: http://adjamblog.wordpress.com/2013/05/21/rekonq-working-on-extension-support/

Per quanto riguarda la navigazione e l’interpretazione delle pagine, posso solo dire che non si notano errori di rendering e la velocità è più che buona e che è migliorata di molto rispetto alle prime versioni.

Qualche problema persiste ancora con WebGl, in particolare con le demo di chromeexperimets, mentre con le demo ufficiali non ho notato problemi di sorta, ed in genere posso dire che con WebGl la velocità di rendering è migliore rispetto a firefox.

L’unica conclusione da fare è che  se va avanti cosi stiamo per avere un browser open-source indipendente  per piattaforma Linux che potrà affiancarsi senza complessi ai più blasonati firefox o chrome.

Per gli sviluppi futuri dobbiamo solo vedere se vorranno restare su WebKik o passare a quello che sembra essere il suo successore: Blink.

IDE per Python

Quale è il migliore editor per lavorare con Python?

Ce ne sono parecchi ed ognuno ha i suoi pregi e difetti, quindi con questo articolo provo a fare un confronto analizzandone alcuni.

Eclipse, con PyDev e EGit

http://www.eclipse.org/
http://pydev.org/

Fra tutti decisamente la coppia più forte, Eclipse è un IDE nativo per Java ma ormai adattato, grazie ad una serie di estensioni, a tutti i maggiori linguaggi di programmazione, compreso Python.

La GUI di Eclipse devo dire che le prime volte è un po ostica e richiede un minino di abitudine, ma alla fine funziona bene ed è molto pratica.

La visione del progetto mescola i file con class view, e questo modo di fare, almeno dal mio punto di vista è pratico, quindi lo vedo come positivo, ma forse per altri potrebbe essere meno pratico.

Il sistema di analisi on-line del codice funziona bene e tutti i Warning o errori di sintassi vengono segnalati immediatamente ed infine l’autofill individua immediatamente e correttamente tutte le librerie di Python.

Lamentele

Direi che il punto debole di Eclipse è forse la pesantezza di esecuzione, ed una certa osticità d’uso e di configurazione.  Inoltre l’estensione PyDev non prevede degli strumenti per l’editing dei file .rst, di fatto lo standard per la documentazione in Python.

Aggiunte

Si consiglia di installare pure EGit almeno  per tutti coloro che usano GIT come controllo di versione.

Komodo edit

http://www.activestate.com/komodo-edit

È la versione free del prodotto Komodo IDE, quindi piuttosto limitata rispetto alla versione commerciale, che non ho mai avuto modo di provare.

Comunque sia come editor e ambiente di sviluppo entry level si presenta bene e si caratterizza per un interfaccia ordinata ed intuitiva, quindi per uno sviluppatore tutto questo si trasforma in un immediata familiarità col sistema ed un uso intuitivo.

Il menu presenta un numero limitato di opzioni e comandi, ma la cosa non mi sembra che limiti le funzionalità, rispetto ad altre soluzioni, anzi per certi versi la cosa è sicuramente un vantaggio.

Inoltre rispetto a Eclipse ha il pieno supporto al formato .rst, cosa molto importante per chi sviluppa in Python.

Lamentele

La funzione di auto-riempineto e lettura delle librerie spesso presenta una lista delle funzioni limitata rispetto a quelle effettivamente presenti nel modulo (Mi auguro che questo limite sia stato coretto nelle versione commerciale), inoltre manca il supporto a GIT, ma che sembra essere presente nella versione commerciale.

Conclusione:

Un ottimo editor, semplice ed intuitivo, ed un buon biglietto da visita per la versione commerciale.

Geany

http://www.geany.org/

Come per Komodo edit si tratta più che altro di un editor, con qualche funzione da IDE, ma in questo caso è un progetto open source al 100%.

Il vantaggio di Geany è sicuramente la leggerezza dell’applicativo e  la semplicità d’uso, non presenta troppe opzioni e tutto quello che serve è disposto in modo logico e intuitivo, inoltre rispetto a Komodo edit ha un class view di base abbastanza pratico, ma ha i difetti di non avere un sistema di autofill e gli manca il supporto al formato .rst

Conclusione

Un editor facile da usare e molto leggero, ottimo per piccoli progetti e direi equivalente a Konodo edit.

eric5

http://eric-ide.python-projects.org/

E qui la nota negativa, devo dire che l’applicativo parte bene e fa tutto, infatti si tratta di un IDE completo, ma purtroppo, devo dire che fa tutto in modo mediocre. L’editor è mal impostato e spesso difficile da leggere, oltre al fatto che di base usa un editor senza colonne allineate, cosa parecchio scomoda nella programmazione [la cosa può essere rimossa con una delle innumerevoli opzioni] e il cursore spesso non è allineato col testo.

Inoltre l’auto-fill si basa su dei files statici molto limitati e difficili da costruire, cose che lo rende molto scomodo da usare.

I warning e gli errori di sintassi li segnala tutti, quindi direi che l’analisi del codice va bene, ma purtroppo i warning sono inseriti nel testo in modo troppo vistoso e a volte fastidioso, non ho trovato l’opzione per modificare questa situazione.

Il sistema di debug funziona bene e senza intoppi, e forse è più immediato di quello di Eclipse, e questo è sicuramente un punto positivo.

Conclusione

Il progetto è valido ma il risultato troppo confuso e spesso pesante da usare, come IDE direi che è meglio Eclipse.

Conclusione

Direi che Eclipse è quello che fa sicuramente meglio di tutti, ed è opensource, poi se si vuole un editor Geany o Komodo edit vanno benissimo. Nota leggermente negativa per eric5, dove la GUI è ancora troppo scomoda.

Python vs. Matlab il banchmark

 Dopo aver constato che python offre un ottima alternativa a matlab almeno dal punto di vista delle funzionalità, ora bisogna vedere chi è il più veloce.

Quindi ho messo in piedi un piccolo test per vedere chi fa meglio. Sul campo ci sono python con le librerie numpy compilate con le MKL e matlab 2012a il tutto su ArchLinux a 64bit e CPU Core i7 a 3.4 Ghz.

Il test si divide in 10 parti ed è costituito per la maggior parte  di operazioni di algebra lineare più alcune operazioni importanti.

La lista dei test

  1. EIG: Eigenvalues
  2. SVD: Single value decomposition.
  3. INV: Matrice inversa
  4. DET: determinante 
  5. DOT: Prodotto scalare
  6. FFT: Trasformata veloce di fourier su un vettore
  7. CONV: Convoluzione fra due vettori
  8. MatMult: Moltiplicazione di matrici 
  9. Sin: Eseguire l’operazione sin su una matrice.
  10. rand: generare una matrice di numeri random

Qui i sorgenti dei test; disponibili su gitorius
https://gitorious.org/python-vs-matlab/python-vs-matlab

I risultati

ogni test è stato eseguito 5 volte di fila e il tempo riportato è quello medio. Il test è stato fatto con python-numpy basato su MKL che sul numpy inserito nei repository ufficiali di Archlinux ovvero basato su LAPACK, e quello basato su ATLAS disponibile su AUR  per matlab ho pure provato ad attivare la funzione GPU, per vedere la differenza.
Le dimensioni rappresentano la dimensione delle matrici, e nel caso della FFT e della convoluzione dei vettori usati (nb. per la conv. sono necessari due vettori). Il tempo è misurato in secondi.

Dimensione python MKL Matlab python Lapack python ATLAS Matlab GPU
EIG 2000 x 2000 7.52 3.44 40.8 31.34 2.61
SVD 2000 x 2000 6.85 5.53 55.3 13.44 6.2
INV 4000 x 4000 2.25 1.74 54.3 3.6 1.96
DET 5000 x 5000 1.07 1.02 26.73 2.00 0.97
DOT 4000 x 4000 1.37 1.33 155.53 157.6 1.26
CONV 2*10^6&10000 3.15 1.25 16.32 16.20 0.23
FFT¹ 1 *10^7 0.26 0.13 0.26 0.26 0.034
MatMult 5000 x 5000 2.56 2.58 302.83 299.17 2.42
Sin 4000 x 4000 1.98 0.042 1.99 2.71 0.00028
Rand 10000×10000 1.09 0.92 1.09 1.09

Nota: np MKL, python LAPACK e python ATLAS sono tutti test fatti con numpy
¹La FFT è stata eseguita con le scipy.fftpack.fft che si è rilevata la funzione  più  performante rispetto alla fft presente in numpy.

Ed infine i grafici dei tempi e delle velocità con numpyMKL;  matlab e matlabGPU, dove si vede chiaramente che matlab da risultati migliori.

Il primo grafico riporta i tempi di matlab e numpy-MKL, escludendo il test sin. Con matlab che in genere è il più veloce

Il secondo Grafico è quello delle velocità poste su scala logaritmica dove ci sono numpy-MKL, matlab e matlab-GPU con tutti i test, in questo caso si vede chiaramente il problema del test sin e l’accelerazione che possono garantire le GPU.

Conclusione

Quello che si può dire è che la copia numpy e MKL va bene, ma non è ancora al livello di matlab, e purtroppo devo notare il mancato collegamento  della FFT a MKL e il disastroso risultato della operazione più banale, ovvero eseguire il seno su tutti gli elementi di una matrice. Comunque in molti test la velocità fra numpy e matlab è ormai equivalente.

Per quanto riguarda lapack, il risultato è veramente disastroso, mentre per ATLAS è contrastante, ma di sicuro molto inferiore a quello di MKL.

Infine matlab con GPU da risultati ottimi con la FFT e la convoluzione e col resto è circa uguale, ma non sempre migliore,  questo mostra che le GPU nel momento in cui lavorano in condizioni ottimali sono imbattibili ma col limite della memoria, che mi ha impedito di fare alcuni test con matrici troppo grandi, ed in alcuni casi diventa poco efficiente.

In conclusione python è sempre meglio, ma ha bisogno di essere ancora sviluppato e offre a tutti gli effetti un ottima alternativa a matlab.


Ps:
Nel fare i test ho preso in parte ispirazione da questo articolo

Per gli utenti ArchLinux, ho messo su AUR i PKGBUILD delle numpy e scipy basate su MKL.
https://aur.archlinux.org/packages.php?ID=62281
https://aur.archlinux.org/packages.php?ID=62572

Pacman, AUR helper e Front End

 Ma quanti ce ne sono:

https://wiki.archlinux.org/index.php/AUR_Helpers
https://wiki.archlinux.org/index.php/Pacman_GUI_Frontends

Sembra quasi che l’hobby preferito degli utenti ArchLinux sia scrivere un AUR helper o un pacman front-end.

Io devo dire che ne ho provati alcuni ma alla fine sono sempre tornato a pacman da linea di comando. Per la ricerca dei pacchetti c’è il sito di Archlinux e con google si trova tutto e meglio che con qualsiasi front end.
A cosa serve tutto il resto?
O forse non sarebbe male un front-end con interfaccia web che cerca i pacchetti su www.archlinux.org e installa il pacchetto della pagina web caricata.

Gli AUR helper sono utili per gestire i pacchetti AUR, ma nei casi di sotto-pachetti in genere gli helper non funzionano.

Quindi adesso uso pacman e sto provando packer come AUR helperma devo dire che l’helper veramente completo non c’è ancora.

IPython una shell per per python, che forse può competere con matlab.

Che python abbia raggiunto un ottima maturità di sviluppo è sicuro.

Ma uno degli sviluppi più interessanti di questo linguaggio è quello legato alle librerie matematiche ovvero  numpy e scipy, che per completezza e prestazioni possono ormai competere col più blasonato matlab.

Quello che ci vorebbe per completare l’opera è una shell che permetta all’utente di usare python direttamente e con tutte le funzioni matematiche in linea. Bene questa shell esiste ed è ipython se usata normalmente è una shell python normale, ma se si abilita la funzione pylab diventa un ottima shell matematica; che va lanciata col comando:

> ipython qtconsole --pylab


Una volta aperta la finestra la si potrà usare per fare grafici o calcoli quasi come se si fosse con matlab. Il vero limite di ipython è l’assenza di collegamenti verso librerie per i grafici 3D, infatti matplotlib supporta in modo ancora un po limitato il 3D.

Un altro vantaggio di matlab è quello di avere un gestore della shell più completo e flessibile, ma a veder bene se ne può anche fare a meno. Inoltre ipython ha delle caratteristiche non presenti in matlab.

Ultimo punto la velocità: chi è meglio, di certo numpy con MKL se la cava molto bene, e può anche andare meglio di matlab, ma non su tutto.