Debian multiarchitettura amd64 e ia32

Chi sta sul ramo Sid di Debian amd64 avrà notato che da un po' di giorni è "impossibile" aggiornare dei pacchetti di software per via di dipendenze non soddisfatte. Il tentativo di forzare le dipendenze con apt-get o aptitude quasi sicuramente si risolverà nella disinstallazione di wine, skype e le librerie di supporto ai programmi a 32bit. Cosa succede? All'interno dei processori a 64bit di AMD e Intel, praticamente tutti i moderni processori a singolo e doppio core, esiste un cosiddetto "compatibility mode" grazie al quale è possibile eseguire programmi a 32bit in un sistema operativo a 64bit, purché si abbiano le relative librerie. Fino ad ora, chi aveva installato una Debian amd64, cioé l'architettura che supporta sia i veri e propri AMD64 sia gli Intel Core 2 Duo, trovava all'interno dell'albero del filesystem la cartella /emul che contiene le librerie che fanno funzionare una manciata di programmi a 32bit. Nella mailing list degli sviluppatori Debian è stato deciso che è superfluo e difficoltoso mantenere delle librerie separate a 32bit per il funzionamento di questi programmi all'interno dell'architettura amd64, quando esiste un intera architettura a 32 bit dedicata che è disponibile da sempre per i processori i386. Questa decisione riguarda anche Ubuntu e un wiki che la spiega può essere letto qui. Le librerie che Debian ha deciso di abbandonare si chiamano ia32-libs e ia32-libs-gtk[¹]. Le ragioni principali di questa scelta sono che la loro compilazione e memorizzazione occupa CPU e spazio su disco dei server Debian e che è ormai un inferno mantenerle aggiornate. Questi pacchetti infatti sono in realtà una collezione di librerie a 32bit e quando cambia un singolo elemento bisogna rifare tutto da capo. Probabilmente questa soluzione che è ora alle corde è stata adottata a suo tempo perché si pensava che, prima o poi, tutto il software sarebbe stato portato a 64bit, consentendo di fare a meno di programmi non nativi e relative librerie. Purtroppo questa transizione completa non c'è stata e due programmi di largo uso quali skype e wine sono ancora lì. Che in tre anni non sia uscita una versione di skype, non dico a 64bit, ma che tenga il passo con le versioni per Windows è solo colpa della trascuratezza di skype. Dal canto suo wine replica le API di windows a 32bit e temo che non abbia senso portarlo a 64bit. Fin quando avremo bisogno di far girare programmi a32bit per Windows sul nostro sistema, ce lo terremo così.
Veniamo alla transizione. Una volta che in Debian si è stabilito che usare ia32-libs e ia32-libs-gtk era deprecato, come si poteva procedere? Come si poteva evitare che le librerie a 32bit e quelle a 64bit, così come i programmi, non si confondessero e sovrascrivessero tra loro? La risposta è stata ia32-apt-get. Con questo sistema voi installate una versione di apt-get che attinge direttamente dai pacchetti contenuti nell'architettura i386 e automaticamente li converte per amd64 separandoli nella directory /lib32 e /usr/lib32 anziché in /lib e /usr/lib come accadrebbe normalmente. Inoltre rimuove tutti i file che sono doppi delle rispettive versioni a 64bit come le pagine di man, README, note di rilascio e compagnia. È ora di mettere mano a questo sistema innovativo.
Innanzitutto si deve installare ia32-apt-get, questo porterà via le librerie attualmente deprecate e programmi associati. Va bene così, dopo si reinstallerà tutto. Vi sarà anche chiesto se volete limitare la presenza di pacchetti a 32bit alle sole librerie oppure estenderla a tutto. Nonostante il messaggio sia abbastanza allarmistico, chiederete tutto "All". Dopo configureremo il sistema in modo da evitare i pericoli segnalati da questo messaggio. Subito dopo, la lista /etc/apt/source.list sarà convertita per ia32-apt-get e la troveremo in /etc/ia32-apt/. Molto semplice. Procediamo come ci viene indicato dalla pagina di README.debian del pacchetto ia32-apt-get. Le fasi successive sono le seguenti:

• modificare la lista dei repository Debian /etc/apt/source.list D'ora in avanti ogni voce all'interno del file viene trattata come valida per entrambe le architetture. ia32-apt-get scaricherà gli indici dei pacchetti sia da amd64 sia da i386. apt-get invece continuerà a comportarsi "normalmente" e scaricherà sempre da amd64. Se si vuole modificare il comportamento di ia32-apt-get, bisogna usare questa sintassi nelle voci di source.list:
  deb [arch=xxx] uri ecc...
  Per esempio: deb [arch=i386] http://ftp.it.debian.org/debian/ ecc..
• Fare spazio nella memoria cache di apt. Probabilmente avrete degli errori come Dynamic MMap ran out of room. Editate il file /etc/apt/apt.conf in modo che contenga una linea cosi:
  APT::Cache-Limit "50000000"
  La misura del limite è in byte, quindi la mia corrisponde a circa 50MB. Dato che gli indici scaricati raddoppiano, è una quantità opportuna.
• Convertire a "manina" la lista /etc/apt/source.list. Andate in /usr/share/ia32-apt-get/ e con sudo ./convert-all-sources.list riconvertite la lista dei repository Debian. Questo vi serve ogni volta che editate /etc/apt/source.list per sincronizzare la versione in /etc/ia32-apt/source.list
• Stabilire la priorità dei pacchetti, il cosiddetto pinning, in modo da evitare che apt-get "preferisca" i pacchetti dell'architettura i386 e succeda quanto premesso dall'avvertimento. Editate quindi /etc/apt/preferences in modo che contenga queste righe:
  
  Package: *
  Pin: release a=unstable-i386
  Pin-Priority: 400
  
  Package: *
  Pin: release a=testing-i386
  Pin-Priority: 300
  
  Modificatele a secondo che preferiate testing ad unstable. Naturalmente la Pin-Priority deve essere molto più bassa di quella dei pacchetti provenienti dai repository che per voi hanno la precedenza. Nel mio caso, i pacchetti amd64 hanno di default una Pin-Priority superiore a 900.
  

Ora lanciate ia32-apt-get (sudo ia32-apt-get update) e vedrete che scarica gli indici dei pacchetti sia da amd64 sia da i386 e alla fine "fonde" questi indici. Se lo avete impostato bene, quando gli chiedete di installare un pacchetto, prima vede se è disponibile per amd64, se non c'è lo scarica da i386. Nel caso in cui presenti una indecisione si può specificare così:
sudo ia32-apt-get install ia32-nome_pacchetto [²]
Come suo solito ia32-apt-get risolverà automaticamente le dipendenze.
Facciamo due esempi pratici: skype e wine
Scaricate skype direttamente dal sito skype.com perché i repository attualmente consigliati nel README.Debian non sembrano funzionare. Spostatevi nella cartella dove si trova skype_qualcosa.deb e installatelo con:
sudo ia32-dpkg -i skype_qualcosa.deb.
Come si vede, esiste una versione di ia32 di dpkg che vi lascerà delle dipendenze irrisolte. Le metterete a posto con:
sudo ia32-apt-get -f install
Installate wine, provate con:
sudo ia32-apt-get install wine vi dirà che ci sono delle dipendenze rotte :)
Bene, allora:
sudo ia32-apt-get install ia32-wine. Questo funzionerà.

L'ultimo esempio serviva a far capire che fin quando esisteranno programmi a 32bit pacchettizzati per amd64 il nome da usare non va preceduto da ia32. Se invece questa pacchettizzazione per amd64 non c'è o ci sono dipendenze incomplete/rotte si usa mettere il prefisso ia32-nome_pacchetto per specificare a ia32-apt-get di prendere il pacchetto dall'architettura i386. Da questo momento in poi si potrà usare apt-get per aggiornare e installare programmi per la parte amd64 del sistema, e ia32-apt-get per aggiornare e installare programmi da entrambe le architetture(amd64, i386). A voi la scelta.


[1] Pare che qualcuno si farà carico di mantenere ancora queste librerie, ma il vecchio sistema sarà incompatibile con quello nuovo.
[2] Dovete digitare il comando completamente perché l'autocompletion di ia32-apt-get non funziona ancora.

Software in libertà vigilata

Quando non si capisce l'essenza di una cosa, ma si pretende ugualmente di parlarne il risultato è uno solo: merda. GNU/Linux è il soggetto preferito da tutti quelli che vogliono scrivere cose tecniche, ma non ne capiscono un'acca[¹]. Non parlo di programmazione, ma della filosofia che c'è dietro che è comprensibile pure da chi non ha competenze per scrivere "Hello World!" in C. Due esempi sono questi articoli di Renai LeMay e Mitch Wagner(1,2) sull'annuncio che Google produrrà un proprio sistema operativo basato su Linux, che si chiamerà Chrome OS, e che sarà accessibile a livello sorgente da ottobre prossimo. Lasciamo perdere che uno dei due articolisti mette in dubbio che Google sia capace di produrre un sistema operativo in un anno. Non stanno partendo da zero e conoscendo Google, direi che a occhio e croce questo sistema operativo c'è già e a ottobre prossimo si ufficializzerà la cosa rendendo disponibili i sorgenti. Voglio invece focalizzarmi sul punto su cui entrambi concordano riguardo a Chrome OS: sarebbe un sistema di troppo se non addirittura un potenziale alleato della Microsoft! Questa frase contiene ben due preposizioni demenziali che si sentono dire quando una nuova distribuzione di GNU/Linux esce e si presenta al resto del mondo.
La prima preposizione demenziale è che una nuova distribuzione Linux danneggi il mondo dell'open source e GNU/Linux stesso. Cioè che una cosa che arricchisce il panorama del software libero nello spirito di fornire qualcosa in più, in realtà lo danneggia. L'appiglio apparentemente razionale è che così si frammenta la base utenti/sviluppatori. Io non ho mai sentito parlare di un fantomatico ufficio risorse che dispone come suddividere il capitale umano del software libero. Stando a questi due signori un tale ufficio sembra esistere e ultimamente ci ha comunicato: ne è saltata fuori un'altra, pregasi di stringersi un po'! Ogni distribuzione nasce con la voglia di dire la propria e chi si imbarca in uno specifico progetto lo fa perché o non ha mai trovato nulla che lo soddisfacesse appieno oppure pensa che così potrà esprimersi personalmente al meglio, cioè fare qualcosa che gli altri non fanno. In un quadro del genere, il gioco può solo avere risultati positivi o al peggio spostare un po' le cose. In compenso, se il prodotto piace perché azzecca quello che hanno mancato gli altri, ci saranno un sacco di nuovi utenti in più interessati a GNU/Linux. Ma la cosa davvero bella è che essendo questo il mondo dell'open source tutti potranno copiare la nuova idea e migliorarsi. La storia di Ubuntu, che a quanto pare è la distribuzione preferita da LeMay che nel titolo del suo articolo sinteticamente dice: "No thanks Google, we've got Ubuntu"; è proprio un esempio di quanto ho detto. Ubuntu è nata da Debian, che è sempre stata considerata la distribuzione per i "Sub-Genius", per avere un un ambiente GNU/Linux facile e adatto a tutti. Il finale lo sappiamo: Ubuntu ha avuto un successo che Debian non ha mai visto e mai vedrà, perché Debian non si è mai focalizzata sulla facilità d'uso. Secondo l'ottica di LeMay, 5 anni fa Ubuntu non sarebbe dovuta nascere per non danneggiare Debian.
La seconda preposizione demenziale, questa più in bocca a Mitch Wagner, è che una nuova distribuzione possa aiutare indirettamente Microsoft. C'è una componente umana del software libero che quando si masturba, fantasticando di abbattere la Microsoft, perde di vista il motivo per cui esiste il software libero. A questi signori faccio presente che la Microsoft ancora non aveva prodotto DOS, quando Stallman pensava ad uno Unix libero. Stallman voleva mantenere intatto lo spirito di collaborazione e scambio di idee che aveva caratterizzato il lavoro dei primi hacker. Uno spirito che gli Unix proprietari stavano distruggendo. Insomma, sembra strano ricordarlo: il software libero è nato per dare più libertà a tutti, non per distruggere la Microsoft. A parte il fatto che mi sembra che sia un cattivo uso della libertà indirizzarla non al godersi delle cose belle, ma a odiare qualcuno. Non lo condivido, ma se ti piace, fallo. Tuttavia non dirmi che io dovrei essere meno libero perché così, tutti insieme, compatti, distruggiamo la Microsoft. Perché stai tentando di farmi rinunciare al motivo principale per cui uso GNU/Linux.
Detto questo, auguri a Google e al suo Chrome OS. Se avrà successo sarà a beneficio di tutta la comunità open source. Anche di quelli che ancora non hanno capito perché si chiama software libero.


[1] Il mondo dell'open source, avendo una propria filosofia oltre che una componente tecnica, si presta allo stesso livello di chiacchiericcio della metafisica.