Una breve panoramica semiseria di quegli aspetti che molti considerano «indispensabili» ad un vero «Unix H4x0r» ma che in realtà servono solo a far perdere tempo.

Mi capita spesso di rispondere, in IRC, via e-mail o di persona a chi mi chiede di risolvere problemi che sono facilmente risolvibili cambiando la propria linea di pensiero in una più moderna e meno «rinchiusa» dentro schemi classici, eppure queste persone non ne sono intenzionate.

Solitamente si tratta di utenti unices – Con «unices» voglio intendere tutti i dialetti Unix e Unix-like che sono disponibili attualmente, quindi Linux, *BSD, Darwin, Solaris… Unices è considerato il plurale di Unix per la maggior parte delle persone – che vogliono farsi vedere esperti agli occhi di utenti Windows.

Voglio tentare di smitizzare alcuni concetti che a volte sono radicati ad un punto tale da esser disposti a perdere più tempo per risolvere problemi futili che per fare qualcosa di buono davvero.

X non morde

Come già si vede dal sottotitolo che ho dato a questo articolo, il primo mito che voglio far cedere è quello che «il vero utente unices» non usa ambienti grafici.

Per quanto sia indiscutibilmente vero che X sia ormai un ambiente grafico assolutamente superato, in cui ogni supporto per concetti recenti come la ruota del mouse, la trasparenza delle finestre, le ombreggiature… viene reso tramite un’estensione aggiuntiva che appesantisce il sistema, non bisogna per forza starne alla larga. Specialmente, non è necessario starne alla larga a favore della console testuale.

A volte mi capita di parlare con persone che dicono che usare l’interfaccia grafica è da utonti. In realtà un’interfaccia grafica ben strutturata e bene organizzata è molto più comoda e più efficiente di una console testuale usata nel modo sbagliato. Per quanto ci siano logicamente delle cose che sono più semplici da fare in una console testuale, nessuna regola impone di utilizzare la console testuale per cose come ascoltare musica, guardare film, leggere la posta e navigare (quando se ne ha la possibilità, logicamente).

Cose come aalib – Libreria per il rendering grafico in ASCII art – e libcaca – Libreria per il rendering grafico a colori in ASCII art – sono esperimenti interessanti, ma la loro effettiva utilità è veramente bassa. Non credo ci sia veramente qualcuno che è interessato a guardarsi un film in ASCII art, tolta di mezzo la curiosità (in effetti ho provato una volta aatv, sotto debian dove veniva installato per forza di cose e avevo bruciato X, ma non è possibile riuscire a distinguere il video più che con una tv con un effetto neve molto pronunciato, quindi è pressoché inutile).

Le icone non fan venire le verruche

Al tempo stesso molta gente è convinta che se proprio si deve utilizzare un’interfaccia grafica, le icone sono il male assoluto, principalmente per il solo e unico motivo che Microsoft Windows è un sistema operativo ad icone.

Questo è un problema in realtà sottostimato, più grave di quello che appare. Molta gente è convintissima che l’idea stessa che sta dietro a Windows sia sbagliata. In realtà, per quanto la sua realizzazione tecnica lasci a desiderare, molti concetti che stanno dietro alla progettazione di Windows non sono del tutto errati. L’interfaccia grafica ad icone, che viene utilizzaa da Windows e MacOS, è stata ottimizzata e migliorata negli anni, fino a diventare un qualcosa di difficilmente sostituibile per l’utente medio, e di questo non si può fare una colpa a nessuno. Si tratta di un buon modo di gestire le cose in fondo, visto che funziona sicuramente meglio dei sistemi a schede perforate degli anni ‘60.

Riprenderò il discorso che riguarda direttamente Windows (e Mac) più avanti, nel frattempo vorrei aggiungere a riguardo delle icone, che anche le icone e i temi visivi in generale (sfondi, stili dei widget e via dicendo) possono aiutare nel lavoro, permettendo alle persone di rilassarsi, trovandosi di fronte un ambiente amichevole invece di una scarna console testuale.

Chiamarle cartelle non è reato

Per quanto io stesso sia abituato a chiamarle directories, chiamarle cartelle non è reato statale. Inoltre, se vogliamo scendere nei tecnicismi, se il termine directory è perfetto per indicare la singola struttura del filesystem, in molti ambienti grafici (perlomeno KDE e Gnome), e in taluni sistemi operativi (MacOSX e Windows), alle directory può essere associato un file contenente informazioni aggiuntive (metadata), che possono descrivere l’icona da utilizzare per rappresentare tale directory, informazioni su come visualizzarla nel navigatore …. In questo caso, la coppia di directory e file può benissimo chiamarsi cartella (folder).

Usare il mouse non fa venire l’artrite

Questa considerazione mi viene spontanea da fare dopo aver letto un vecchio thread sulla mailing list di KDE. C’era chi affermava che i veri «esperti» non usano mai il mouse per cancellare i file. In realtà, non è sempre così. Mi capita spesso di navigare sul disco semplicemente per guardare cosa ho dentro, e quindi mi risulta più comodo muovermi col mouse che con la tastiera. Quindi mi seccherebbe dover ogni volta che voglio cancellare qualcosa (non buttarla nel cestino), andare ad utilizzare la tastiera. Quindi non sottovalutate mai la possibilità di fare certe cose col mouse, è comodo, quando si ha fatto pratica.

Usare il cestino non fa rincretinire

Una delle novità più interessanti che sono uscite da FreeDesktop.org è la specifica per il supporto dei «cestini» (trashcan). Se prima era già disponibile una specie di cestino, all’interno della cartella home, era abbastanza inutilizzabile quando le homes fossero su una partizione diversa da dati che vengono spesso cancellati e creati, perché avrebbe richiesto molto più di una semplice modifica ai valori di posizione di un file: un vero e proprio trasferimento dei dati da una partizione all’altra (o addirittura da un disco all’altro), creando un rallentamento dell’operazione di cancellazione veramente ampio, inoltre, si sarebbe andati ad occupare spazio in una partizione che potrebbe essere, per esempio, limitata nelle dimensioni o nello spazio utilizzabile (cosa non rara per esempio nelle Università dove c’è a disposizione un’area scratch nel disco locale del computer con una quota molto più ampia di quella nelle home su NFS).

Per risolvere questo problema, la nuova specifica permette di utilizzare delle cartelle trash in ogni partizione, risolvendo i problemi della necessità di trasferimento e di occupazione dello spazio. Inoltre permette il salvataggio della posizione in cui un determinato file si trovava in precedenza, correggendo un altro grave difetto della precedente implementazione: l’impossibilità di recuperare un file direttamente.

Molti «esperti» potrebbero storcere il naso a riguardo di tale nuova funzione, pensando che sia solo un qualcosa utile per gli utonti. Al contrario, una funzione simile può venire molto utile specie quando si sta tentando di fare pulizia nel proprio disco, per evitare di cancellare dati importanti per una lieve distrazione.

Per coloro che ancora fossero pronti a storcere il naso ad una cosa «alla Windows» consiglio la lettura della sezione «Windows forse è il demonio, ma non le sue idee» più avanti.

Fare le cose da sé non sempre fa guadagnar tempo

Ci sono ancora quantità enormi di persone che utilizzano distribuzioni come, per esempio, Slackware, convinte che l’unico modo di essere veri «utenti esperti» sia imparare a far le cose completamente da soli. In realtà l’uso di Slackware come di ogni altra distribuzione o sistema operativo che non prevede alcuna gstione delle dipendenze, può diventare un vero problema, specie per workstation e computer quotidiani di tutti i giorni.

Rendiamoci conto che è inutile accendere un computer soltanto per passare tre ore a tentare di far funzionare una cosa da soli, come per esempio per sistemare una dipendenza di un pacchetto che non è più soddisfatta, quando ci sono distribuzioni come Gentoo, Debian, Fedora Core, Mandrake che gestiscono le dipendenze in modo automatico o semi automatico.

Chi non volesse la «pappa pronta» delle distribuzioni deb- o rpm-based, può benissimo scegliere una distribuzione come Gentoo che, per quanto lunga da installare, è automatizzata nella gestione degli aggiornamenti e delle dipendenze.
Per esempio passo spesso molto tempo a compilare, ma nel frattempo ho la possibilità di fare molte altre cose, compilo mentre sto chattando su IRC, compilo mentre guardo un DVD, compilo mentre guardo la TV. Non ho bisogno di passare le tre ore che il sistema mette a compilare guardando quello che fa e seguendo passo passo i problemi. Se vi intricate nei labirinti delle dipendenze dei sistemi operativi fai-da-te non è molto semplice venirne fuori senza perderci tempo e attenzione sopra.

Se ci possono essere ambienti unificati in cui una cosa del genere può essere utile, non credo proprio che una distribuzione come Slackware, nel ventunesimo secolo, sia adatta all’uso quotidiano.

Una delle repliche che mi viene fatta rispetto a questo mio pensiero è una citazione di Volkerding:

Besides, I think Slackware sounds better than 'Microsoft,' don't you?

Sicuramente Volkerding ha ragione da questo punto di vista, ma trovo, con molta sincerità, che quando si fa il salto di qualità, è inutile tenersi indietro e fare un salto minimo (di qualità, per quanto di comportamento, Windows e Slackware siano agli estremi opposti). Inoltre, non è raro che utenti Slackware cerchino aiuto per cose che in altre distribuzioni sono banali (problemi di compatibilità binaria sotto Debian non esistono, sotto Gentoo si possono risolvere utilizzando revdep-rebuild, che li risolve automaticamente, giusto per fare un esempio). Inoltre quando si tratta di persone che hanno effettivamente delle capacità che potrebbero essere impiegate per l’avanzamento del software libero, occupare il loro tempo per tentare di sistemare una macchina da soli, «da veri sysadmin», è uno spreco di energie che potrebbero essere meglio impiegate.

Programmare senza usare un editor non rafforza i vasi sanguigni

Un altro esempio che può essere portato, è la quantità di persone che pensano che programmare senza far uso di librerie di comodo, senza far uso di ambienti di sviluppo integrati (IDE), senza far uso di strumenti per la progettazione (CASE), e via dicendo sia l’unico vero modo di programmare.

In realtà l’uso di strumenti automatizzati per lo sviluppo di applicazioni può far sprecare molto meno tempo, che può essere utilizzato in maniere migliori.

Testi come «Il vero programmatore» sono divertenti, e di sicuro chi è capace di fare cose simili è bravo, ma questo non significa che sia il miglior modo di farle a questo mondo. C’è chi riesce a guidare a 300Km/h senza fare incidenti, bravissimo, ma questo non significa che debba farlo sulle strade urbane.

Windows forse è il demonio, ma non le sue idee

Come ho già accennato sopra, per quanto possa non piacere Windows, questo non significa che bisogna per forza di cose stare lontani da qualsiasi cosa che gli assomigli.

Nella realtà la maggior parte dei concetti e delle idee che stanno dietro a Widnows non sono il male in sé, e anzi sono ben pensati e ben strutturati. Tra l’altro molte cose che si reputano «di Windows» sono piuttosto prese prima da MacOS.

Idee come gli ActiveX, ripresi come dicevo dai KPart di KDE, le icone nella systray “nascondibili”, il cestino, l’automounting/umounting delle periferiche, il riconoscimento automatico dell’hardware, il browser integrato con il file manager, e altre idee simili sono state o stanno venendo ben integrate all’interno dei maggiori ambienti grafici e distribuzioni, e il loro supporto rende molto più semplice la gestione del sistema.

Anche il concetto di librerie dinamiche, che in Windows sono chiamate DLL, viene applicato sotto gli unices, anche se con estensioni diverse (abbiamo i .so di Linux e BSD e i .dylib di Darwin per esempio). Anche se qui è più Windows che riprende un’idea degli unices.

Allo stesso tempo, ci sono altre cose, come i programmi usati più recentemente (presenti in MacOS, KDE e solo per ultimo Windows XP), l’aggregazione delle entry nella barra delle applicazioni (presenti in KDE e GNOME e solo dopo in Windows XP), il blocco dei popup nel browser (presente in Mozilla prima che in IE), il tab-completition presente in quasi tutte le shell unices classiche e solo dopo su Windows XP, che la casa di Redmond ha usato dopo gli unices. Si tratta dell’ovvio scambio di ideee che c’è tra prodotti simili, siano essi liberi o meno (che viene ostacolato in questo caso non dalle leggi sul diritto d’autore, che non impediscono di sfruttare la stessa idea implementandola con codice differente, ma da quelle sui brevetti, quindi si potrebbe far notare a Microsoft che se anche il mondo libero avesse brevettato alcune cose, neanche loro potrebbero utilizzarle).

Per chi critica queste aggiunte alla stregua di bloat che non fanno altro che aggiungere codice senza aggiungere motivazioni, vorrei ricordare che la prima caratteristica degli unices è la modularità: è possibile creare un sistema disabilitando tutte queste funzionalità aggiuntive, in modo che resti funzionante su sistemi ormai vecchi ed obsoleti. In relazione a questo, anche moltissime funzionalità eye-candy, ovvero relative specificatamente alla «bellezza grafica» degli ambienti, possono essere tranquillamente rimosse, disabilitate o trascurate.

Postfazione

Questo articolo è sicuramente meno tecnico di tutti gli altri che ho scritto fin ora, e anche molto più «stringato», ma, come dicevo, voleva essere un testo semiserio. In verità penso che ognuno sia libero di decidere come vuole lavorare, questo testo vuole solo far notare come certe pratiche non siano da considerarsi da «veri h4x0r» e altre da «niubbi» ma semplicemente come diversi stili d’uso che hanno ognuno i suoi pro e i suoi contro.

L’unico consiglio che mi sento di dare, è di considerare quello che si sta facendo, se si passa più tempo a risolvere problemi banali che a fare qualcosa di utile, e di considerare l’idea di smettere di far le cose in modo arcaico, avendo più tempo a disposizione per aiutare il software libero.

Un’altra nota a margine di tutto questo che vorrei lasciare è rivolta a tutti gli utenti di queste pratiche a mio avviso astruse: se vi sentite in grado di fare queste cose perché siete «veri h4x0r», forse vi conviene non chiedere ogni 20 minuti aiuto perché c’è una cosa che è banalissima da fare per un utente normale, ma voi non riuscite a farla nel vostro modo di lavorare. Se lo sapete fare bene, altrimenti considerate l’idea di cambiare linea di pensiero.

This work by Diego Elio Pettenò is licensed under Creative Commons Attribution-ShareAlike 3.0 Unported License.
Based on a work at blog.flameeyes.eu.