Cinque falsi miti su Arch Linux

Soprattutto in questi ultimi tempi, si è fatto un gran parlare di Arch Linux su alcuni media (specialmente Twitter e Google+) relativamente alla cerchia solita dei Linux user italiani - nonché alcuni blog. Questo mi ha convinto a rispolverare un grande classico per pubblicarlo, ossia i cinque più grandi falsi miti su Arch Linux. Arch è una distribuzione inflazionata, infatti, e col tempo è stata testata praticamente sulle macchine di chiunque: alcuni hanno avuto l'onestà intellettuale di dire "non è una distro che fa per me"; altri hanno semplicemente messo in giro FUD diffondendo opinioni squisitamente personali spacciate come fatti oggettivi, cosa che per il modus operandi dialettico del sottoscritto trasforma queste affermazioni in cazzate.

Dato che sempre più spesso capita di farsi il sangue amaro su persone che non hanno ben chiari filosofia e obiettivi del progetto Arch Linux, ho pensato quindi di stilare, e qui concludo con il preambolo, questo piccolo Bignami che spero torni utile a ciascuno di noi, in un qualsiasi thread di Google+, una conversazione di Twitter, o quando pensiamo di stare per pronunciare (si, noi arcieri) un'offesa marcata contro gli stessi sviluppatori. Ché non sono mica solo quelli che se la prendono facilmente, a scagliarsi contro Arch Linux.

È una rolling release quindi è meno sicura/stabile

Sbagliato. Per due motivi: essenzialmente tutto il lavoro di sicurezza sul software open source viene svolto upstream. Le patch che vengono applicate ad esempio dal ramo Security di Debian sono backport di codice che rende l'applicazione maggiormente sicura ad una versione meno recente, in modo che venga tappata la falla in quella specifica versione del pacchetto. Una distribuzione rolling release, invece, ha cura di fornire all'utente, bene o male, sempre l'ultima versione del pacchetto disponibile; per questo motivo, possiamo dire che le distro rolling release sono orientativamente sicure quanto le distro a ciclo di rilascio periodico - se non di più, ove il patching e il backport del codice non avvengano in tempi ragionevolmente brevi.

Per la stabilità il discorso è lo stesso: l'ultima versione di un software upstream incorpora anche patch provenienti da tutte le distribuzioni. Quelle poche volte che il lavoro di aggiornamento riguardo un bug di stabilità non viene svolto upstream, nulla vieta agli sviluppatori (o agli utenti, dato che è assunto che gli utenti di Arch Linux abbiano tale capacità), se non vogliono attendere, di applicare la patch di un'altra distro al pacchetto e rilasciarlo subito.

Se invece si tratta di bug chiusi upstream, la nuova versione sarà migliore. Le distribuzioni a rilascio periodico invece dovranno attendere che il ramo instabile diventi stabile; per bug non gravi che affliggono un numero moderato di persone, questo può essere un problema.

Inoltre, Arch Linux dispone di un repository Testing, dove vengono testati moltissimi pacchetti prima del rilascio nel ramo stabile. A volte vengono persino creati dei repository ex-novo per impedire che nuove release di un software contaminino la stabilità dell'ecosistema dei package che "vivono" all'interno di Core ed Extra (i due repository che essenzialmente costituiscono il ramo stabile di Arch Linux).

Pacman non è all'altezza di APT/RPM

Falso. Pacman implementa meccanismi largamente in voga nelle distribuzioni Linux, ma in maniera più semplice. Ad esempio il signing dei pacchetti: viene fatto in maniera meno complessa di APT, e molto più user-centrica. È il tool chiave di Arch Linux, e se è vero che non è da meno a gestori di pacchetti più blasonati fornendone le stesse funzionalità, un buon argomento di conversazione potrebbero essere gli innumerevoli miglioramenti di cui Pacman avrebbe bisogno. Dire semplicemente che "Pacman fa schifo" è una goliardata che merita di finire nell'Olimpo delle frasi stupide del panorama Linux.

Un aggiornamento può distruggere il sistema

Falso. Anche se molte persone hanno pensato che fosse vero vista la loro pervicacia nel forzare alcuni aggiornamenti nonostante fosse scritto ovunque di non usare assolutamente l'opzione --force su uno specifico package. Nonostante ci sia stato quest'ultimo caso eclatante (l'ultimo, epico, aggiornamento di glibc), avevo sentito più volte l'affermazione legata anche ad altri aggiornamenti critici. Il punto è che Pacman (per scelta, non ce lo scordiamo) non gestisce i file di configurazione e gli aggiornamenti da fare a questi ultimi. Questo compito in Arch Linux è lasciato all'utente il quale ha come assistenti un ottimo wiki, e soprattutto le indicazioni non appena un pacchetto viene installato.

Utenti che aggiornavano alla cieca quindi si sono visti scomparire il sistema in stato consistente da sotto i piedi, semplicemente perché prima di un reboot non hanno letto il log di Pacman che diceva di aggiungere una banale opzione, una voce aut similia ad un file di configurazione.

Con chi te la vuoi prendere in casi come questi? Ma coi developer naturalmente. I quali avevano l'impegno morale e l'imperativo categorico di telefonarti a casa per avvisarti. Seh.

Di solito l'argomento più efficace contro le persone che affermano una cosa del genere è che forse potrebbero uscire dall'analfabetismo e leggere il log di Pacman, specialmente dopo un aggiornamento ciccione da centinaia di megabyte - o peggio, qualche giga.

Gli utenti di Arch Linux sono spocchiosi

Sbagliato. In realtà, se le cose vengono chieste con cortesia ed educazione, è possibile trovare negli utenti di Arch Linux una risorsa inestimabile in termini di case study, bug affrontati, bug risolti, ecosistema open source, e soprattutto bei birrozzi in compagnia.

Quello che amo della comunità di Arch Linux, allo stesso tempo, è quel latente senso di MIT anni '70 per cui se dici una cavolata, nel giro di trenta secondi lo sapranno tutti (stile condominio con comari annesse) - e comincerà a breve una serie di battute sarcastiche nei tuoi confronti. Niente di cui lamentarsi riguardo la cattiveria comunque: di solito sono prese in giro bonarie (o binarie?) di chi si diverte a ostentare un po' la sua superiorità nei termini della questione che viene discussa sul momento.

Ci sono persone che percepiscono questa cosa come una barriera, e me ne dispiaccio perché ho incontrato spesso persone conosciute sul canale italiano di Arch Linux, o sulla board nazionale, e non mi sono mai trovato male. Mai e poi mai.

In coda, un monito: se un utente Arch Linux - specialmente di quelli della vecchia guardia - sta dicendo che avete torto durante un dibattito su Linux, di solito è bene rivedere le proprie posizioni. Perché state effettivamente, al 90%, avendo torto; e se continuate a dare addosso a questo genere di persone, che sono abituate a dimostrare che quello che dicono è vero coi fatti, è probabile che vi sbugiardino su tutta la linea con una serie di prove schiaccianti. Alla faccia della spocchia: abbiamo solo sempre ragione :D

Gli sviluppatori di Arch Linux sono pazzi e inseriscono nuove feature a caso e in maniera improvvisa

Sbagliato. O meglio: gli sviluppatori di Arch Linux inseriscono nuove feature in maniera improvvisa ma non sono né pazzi, tantomeno lo fanno a caso. In Arch Linux la necessità di aggiornamento è completamente a carico dell'utente, e può capitare, come sopra, che alcuni update siano leggermente più difficili da gestire che premere il tasto y sulla tastiera.

È un rischio potenziale per qualsiasi aggiornamento, ma ci si può accorgere di questo con dei piccoli trucchetti: uno è tenere d'occhio le news, che informano gli utenti di qualsiasi aggiornamento farraginoso. L'altro piccolo trick è guardare la lista dei pacchetti in aggiornamento prima di fare un update casuale a tutto quanto l'ambaradan: di solito pacchetti come glibc possono essere leggermente più pericolosi ed è consigliato prestare attenzione quando si aggiorna il core del sistema. Questo comprende pacchetti come systemd (si, avete letto bene, systemd), kmod, il kernel Linux, o Pacman.

Inoltre, personalmente ci sono alcune settimane in cui ho necessità di essere più produttivo che in altre. In quei periodi evito di toccare lo stack software della mia macchina, perché so che anche un piccolo cambiamento potrebbe inficiare la mia produttività e il mio workflow. Sono piccoli consigli, metterli in pratica non costa veramente niente e la vostra vita da arcieri ne guadagnerà.

Tradotto, questo pistolotto può essere sintetizzato in: se aggiorni alla membro di segugio non è colpa mia.

Arch Linux non è un sistema pensato per rispondere ad esigenze brainless. A soddisfare i vostri bisogni dovete pensarci voi, ed il sistema vi mette a disposizione tutto ciò che serve per farlo. Quindi, quando accendete la vostra macchina, verificate di aver acceso prima anche il cervello. È gratis.

Image courtesy of Jason Ryan