In questi giorni, una news scritta per MegaLab.it mi dà l’opportunità di scrivere una mia piccola riflessione qui su AC Magazine. La news in questione è “Richard Stallman attacca Apple e Snow Leopard“, in cui, in sostanza, scrivo dell’ennesima critica del padre del software libero verso Apple ed il mondo del software proprietario.

Mentre scrivevo, non ho potuto fare a meno di pensare: “Ma Apple, quanto collabora con la comunità Open Source?“. In molti eventi Cupertino ha presentato software o tecnologie poi rilasciate sotto licenza open. A cominciare dall’ultimo arrivato, Grand Central Dispatch, “l’algoritmo” che Snow Leopard usa per gestire dinamicamente  i processi di un’applicazione, i cui sorgenti sono pubblici. Passiamo poi all’importante Darwin, la base di Mac OS X, anche questo scaricabile direttamente dal sito Apple, e altrettanto liberamente modificabile e ripubblicabile. E, per finire, anche WebKit: il famosissimo motore di rendering open source, derivato dall’incredibile KHTML.

Molti nella rete sono dell’opinione che Apple sia una “sfruttatrice” di software open, nel senso che prende programmi liberi, li modifica a suo piacimento (e fin qui sono nel giusto) ma che poi li includono in altre applicazioni chiuse oppure, nel caso questi fork vengano rilasciati con licenza libera, che la collaborazione che Apple da alla comunità sia pari a zero.

Prendiamo dunque i tre progetti che vi ho elencato sopra (GCD, Darwin e Webkit) e vediamo quanto Cupertino collabori col mondo open source.

Nel primo caso, Grand Central Dispatch, chiamato anche libdispatch, è presente in Snow Leopard ed è disponibile pubblicamente sotto licenza open. Fantastico, direte voi, così possiamo implementarlo in altri sistemi, come Linux!?!? Magari, rispondo io, magari. Perché, come scrive il formidabile ArsTechnica, potrebbero sorgere diversi problemi nella sua implementazioni in altre piattaforme.

In primo luogo, GCD utilizza diverse estensioni del linguaggio C sviluppate da Apple stessa e che non sono disponibili nel GCC originale (o vanilla), e quindi non facilmente compilabili ed applicabili su Linux a meno di non integrare tali tecnologie nel compilatore stesso. Infatti, Apple ha il suo fork di GCC compatibile con tutta ’sta roba.

Sappiate che è comunque una cosa fattibile, visto che queste estensioni sono rilasciate con la licenza MIT, compatibile con la GPL del GCC. Quello che non è compatibile, invece, è proprio libdispatch che, essendo rilasciata con licenza Apache, non è compatibile con la GPLv2 utilizzata dal kernel Linux (è invece utilizzabile in software GPLv3, ndr). Torvalds è sempre stato irremovibile nel non adottare l’ultima versione della General Public License, quindi, bisogna sperare che venga fuori una GPLv4 che “piaccia” a Linus e compatibile con la licenza Apache per poter parlare di GCD su Linux. Un bel casino, no?

Parliamo ora di Darwin, il cuore di Mac OS X: un cocktail tra XNU/Match e FreeBSD, che però funziona a meraviglia per il sistema di Apple. Anche questo rilasciato sotto licenza pubblica (Apple Public Source License).  Tempo fa, alcuni temerari sviluppatori, diedero vita al progetto openDarwin, che potremmo definire come una distribuzione GNU/Darwin. Purtroppo però, il progetto fallì. Come ma? Semplice: c’erano pochissime persone disposte a dare una mano (test, sviluppo, ecc..) ed Apple non ha mai (o quasi) collaborato tecnicamente, in termini di aiuti, chiarimenti, documentazione aggiuntiva, qualche sviluppatore, e così via.

Infine, c’è Webkit, il famoso motore di rendering utilizzato da Safari e Chrome (tanto per fare qualche nome), nato come fork di KHTML, il rendering engine di KDE, il famoso ambiente desktop per Linux. Ora credo non si possa più parlare di fork vista la grandezza del progetto, ma di un vero e proprio software a parte. Il progetto è veramente libero, rilasciato sotto LGPL (obbligatoriamente, visto che KHTML è sotto GPL) e la prova si vede nella collaborazione di varie aziende, QtSoftware/Nokia in primis. Tutti possiamo collaborare, Apple collabora pure ed anche parecchio, visto che è nei suoi interessi e visse (per ora) felice e contento. Addirittura, non mi ricordo però dove l’ho letto, sembra che Cupertino mandi (o mandasse) una copia delle patch agli sviluppatori di KDE/KHTML per analizzarle, commentarle ed eventualmente integrarle.

Allora, quanto collabora Apple con la comunità open? Beh, poco, rispetto ad altre aziende (ma è nella norma), e si limita principalmente a collaborare coi progetti che utilizza lei stessa o che possono interessare al suo business. Detto questo, il mio messaggio non vuole essere “boicottate Cupertino”, i suoi prodotti sono magnifici e se vi piacciono, usateli. Semplicemente, non paragonate Apple alla salvatrice del mondo libero.

Il nuovo CEO si è già messo all’opera su diversi fronti, ma quello che mi ha interessato di più è la nascita e lo sviluppo di un SDK ufficiale di KDE, in maniera da non disperdere programmatori nella miriade di pacchetti vari, editor e altra roba necessaria alla creazione di una applicazione Qt/KDE.

Inutile dire che l’iniziativa di Schumacher (potremo chiamarlo Schumy?) è molto interessante e coinvolgente. Per tutti i dettagli, date un’occhiata a questo post sul suo blog. Buona lettura.

Tra i miglioramenti degni di nota, segnaliamo:

• Maggiore stabilità per KRunner, l’utilissima utility di ricerca di applicazioni e documenti che si appoggia al noto Nepomuk
• Aumento della velocità e delle prestazioni complessive per KHTML, motore di rendering famoso in quanto è “il padre” del noto WebKit
• Maggiore efficenza per KMail, il client email di KDE, soprattutto nel gestire account IMAP

Come al solito, KDE 4.2.2 è disponibile sul sito ufficiale e distribuito per l’upgrade in molte distribuzioni Linux.

Pat Wolkerding ha recentemente pubblicato un considerevole numero di aggiornamenti per il ramo current di Slackware. Più di 200 elementi, per quello che viene considerato il più grande update della storia (molto lunga) della distro.

Tra questi pacchetti si trova il nuovo compilatore GCC 4.3.3, nuove glibc (v 2.9/2.10), il kernel linux 2.6.28.7 e XFCE 4.6.0. Ma la vera notizia di questo aggiornamento è il definitivo pensionamento di KDE 3.5.x, che dopo anni di onorata e meritata carriera in Slackware (e non solo) può godersi una lunga vacanza nell’album dei ricordi più belli.

A sostituirlo è KDE 4.2.1, la nuova ammiraglia del K Desktop Environment, e questa è l’ennesima prova che questa versione del popolare ambiente deskop è diventata ormai pronta, stabile ed elegante per essere usata tranquillamente a casa, in ufficio e in distribuzioni come Slackware.

Leggendo i volantini di varie catene di articoli elettronico-informatici, capita spesso di notare computer con un elevato quantitativo di RAM: 3 o 4 Gbyte, non di meno.  A parte che si potrebbe parlare per ore del paradosso di vendere 4GB di RAM e un sistema operativo a 32bit (al 90% dei casi sono soldi buttati, perché il sistema vedrà “solo” 3GB),  vorrei ribadire che così tanta RAM non serve in vari modi di utilizzare il PC, e se proprio serve la quantità non è l’unica cosa da tenere conto.

Cosa intendo dire? Semplice, intendo dire che è assurdo montare 3-4GB di RAM per poi ritrovarsi il sistema più lento di prima (specie quando si fa un upgrade della memoria). Assurdo, direte, eppure non ho sempre torto.

Aumentare la RAM serve per poter dare al sistema operativo maggior quantitativo di memoria da poter fornire a programmi vari, non aumenta la velocità con cui i dati entrano ed escono da tale memoria.

Ad aumentare la velocità, semmai, è l’abilitazione di una certa tecnologia, che entra in gioco quando sono montati due banchi di RAM esattamente uguali, nella capienza e nella frequenza. Sto parlando del Dual Channel.

Tale tecnologia raddoppia la velocità di trasferimento dati, facendo passare quest’ultimi per due canali da 128 bit anziché uno solo da 64bit. Solo e solamente in questo caso abbiamo un aumento della velocità di sistema aggiornando la RAM.

Se non siete ancora convinti, vi porto un esempio personale. Ho aggiunto due banchi di RAM da 1GB l’uno a Ottobre 2008 portando la memoria totale a 3GB (precedentemente avevo 2×512MB). Preciso che il mio processore è un AMD Athlon 64 3500+. Affrontando un esperimento che metteva a dura prova le prestazioni di sistema (stavo installando una distribuzione GNU/Linux, Gentoo, che come molti sapranno non ha pacchetti precompilati ma bisogna compilarsi tutto da codice sorgente), sono incappato in tempi lunghissimi per eseguire varie operazioni (8 ore per compilare KDE), troppo lunghi per imputare tutta la colpa alla mia CPU.

Dopo qualche giorno ho cominciato a dubitare sulla disattivazione del dual channel dopo l’upgrade della RAM. Ho perciò eseguito due benchmark, con dual channel e “solo” 2GB di RAM, e senza dual channel con 3GB di RAM. I test erano due e consistevano nel compilare una serie di programmi (precisamente PHP e MySQL) ed eseguire una serie di operazioni per definire le velocità in lettura e scrittura.

Ecco i risultati:

Dual channel

Senza Dual Channel

Con il dual channel attivo la velocità si è duplicata, come previsto.

Morale della favola: aumentare la RAM si, ma attenzione a non provocare colli di bottiglia.

La divisione australiana di ZDNet, popolare webzine conosciuto a livello internazionale, ha voluto mettere alla prova alcuni utenti intervistati per strada mostrando loro KDE 4 e affermando che era la versione Beta di Windows 7.

Ecco il video: