Linux visto da InformationWeek -quarta ed ultima puntata-

Nella quarta ed ultima puntata di questa serie di post InformationWeek pone la sua attenzione su due aspetti importanti in GNU/Linux, il “Native file versioning” e l’audio.

Per quanto mi riguarda trovo la seconda questione di vitale importanza in un sistema, quando ero alle prime armi con il mondo GNU/Linux mi è capitato sovente di piallare l’hdd da una distribuzione proprio perchè non vi era modo di far funzionare l’audio.

Questo succedeva molto tempo fa quando i live-cd erano solo un miraggio lontano e l’interfaccia grafica considerata come un optional, di strada ne è stata fatta e l’audio è forse una di quelle cose che difficilmente non funziona sul pinguino, magari sono necessari degli aggiustamenti ma spesso l’hardware è correttamente riconosciuto.

Sentiamo il parere di InformationWeek:

Native File Versioning

Il Native file versioning è una di quelle caratteristiche che può essere aggiunta con facilità ad un kernel Linux ma la quale ancora non trova spazio nelle impostazioni di default del sistema.

Se ad esempio un file viene corrotto e semplicemente presenta dei problemi un sistema windows è in grado di recuperare la versione precedente dello stesso documento grazie a questo sistema che usa delle copie di tipo shadow.

Anche se tutto pronto nel mondo GNU/Linux questo metodo non è diventato standard e di fatto va attivato ad opera dell’utente visto che non impostato di default.

Vi sono diversi progetti che si occupano di implementare questa funzionalità e sono: Wayback, ext3cow, copyfs, Tux3 solo per citarne alcuni ma avere uno standard approvato per il kernel fornirà sicuramente strumenti più potenti una maggiore efficienza rispetto a soluzioni di tipo add-on.

Audio ed interfacce di programmazione delle applicazioni

Troppe implementazioni audio in Linux sono come una zuppa nella quale troppi cuochi hanno messo le mani, alla fine risulterà un mediocre brodaglia.

La possibilità di scegliere server audio e server grafico è una importante opportunità di personalizzazione del proprio sistema al fine di renderlo il più vicino possibile alle vostre esigenze ma allo stesso tempo può essere fonte di problemi di compatibilità.

E’ possibile citare i progetti più famosi ed usati a livello di API audio, troviamo ALSA, PulseAudio e Jack ognuno con le proprie caratteristiche più o meno evolute poi ci sono gli strumenti per sviluppatori e tra di loro Gstreamer, PortAudio ed altri.

Molto significativa è la frase di Don Marti il quale, alla conferenza Linux Plumber’s svoltasi in Settembre ha detto:

<< Se uno sviluppatore di chiedesse: “Voglio scrivere una applicazione audio, quali api devo usare??” io non avrei proprio una buona risposta >>

Anche se le API audio colpiscono più i programmatori che l’utenza finale quest’ultima avrà sempre prodotti non all’altezza in campo audio.

PulseAudio sembra essere il progetto più promettente in ambito general-purpose ma nel lungo periodo è auspicabile un kernel-up unico pr la parte audio che non costringa ogni sviluppatore ad una analisi approfondita della casistica che vuole affrontare per poi scegliere le sua API di lavoro.

Conclusioni personali

Ritengo che InformationWeek abbia in qualche modo centrato la questione, non si tratta di codice o di mancanze nei sistemi GNU/Linux ma solo di standard.

Regolamentare i sistemi è alla base di ogni successivo sviluppo di un progetto e certamente l’ambito informatico non fa eccezione, una maggiore uniformità porterebbe aziende pioniere ad i primi software proprietari per il pinguino che in questo modo potrebbe godere di una maggiore visibilità seguiti da maggiore diffusione.

Anche se la strada del proprietario non è quella sperata da molti certamente è una delle vie più veloci da seguire ed i grado di dare maggiori soddisfazioni, in questo contesto però è indispensabile avere un potere forte, magari quello delle comunità, che eviti l’imbarbarimento del codice libero e la sua migrazione verso soluzioni sempre più chiuse.

Purtroppo quando di mezzo ci sono interessi economici molto spesso le convinzioni personali che una volta reggevano la morale di un uomo possono venir meno e questo è uno scenario che non vogliamo e non dobbiamo vedere all’interno dei mondo OpenSources.

Ciao a tutti.