[Mostly Weekly #47] Because september never ended

Mostly Weekly #47

La newsletter omonima a margine del canale Telegram
(quella che esce quando è pronta)

A cura di Antonio Dini
Numero 47 ~ 26 gennaio 2020

“The past exists only in our memories, the future only in our plans. The present is our only reality." – Robert Pirsig

In questo numero:
- Head
- Body
- Vim Corner
- Tsundoku Regular
- Tsundoku Poetry Room

Sto lentamente modificando la struttura e il tipo di contenuti di Mostly Weekly, dando più spazio a cose più lunghe e personali. Come sempre, il vostro feedback è apprezzato. Così come l'opera di proselitismo: se vi piace, condividete con chi pensa possa essere interessato. Grazie.

SImmetrie – Foto © Antonio Dini

HEAD

"Microsoft è felice di annunciare che siamo il partner della trasformazione digitale della Petroleum Technology Conference".

Mentre i tre big della tecnologia, Amazon, Google e Microsoft, cercano di guidare il carro delle aziende virtuose che contribuiscono a salvare l'ambiente combattendo il riscaldamento globale, in realtà stanno facendo ben altro. Il cloud computing e l'intelligenza artificiale (le due cose sono strettamente collegate) hanno un insospettabile ma ovvio mercato per il settore petrolifero. Ovvio perché l'estrazione richiede un crescendo di investimenti tecnologici per continuare a sua volta a crescere, e le grazie aziende petrolifere adesso fanno ricorso all'informatica e al machine learning per capire dove e come scavare di più e meglio.

Vox in un video spiega bene cosa succede: da un lato ad esempio Microsoft dichiara di voler diventare "carbon negative", cioè cancellare la sua carbon footprint anche degli anni passati dalla sua fondazione (ma dicono cose simili anche Google e Amazon, tutti campioni dell'ambiente); dall'altro invece, secondo Vox e non solo, i tre aiutano i colossi del petrolio ad automatizzare le estrazioni. Non solo massimizzandole, ma addirittura facendole crescere. Automatizzano in realtà, cioè, il riscaldamento globale per consentire all'industria petrolifera di essere profittevole.

Attenzione: a mio avviso questo non solo è peggio del greenwashing a cui molte aziende in vari settori ci hanno abituato nel tempo, ma in realtà avvelena anche l'idea stessa di rispetto dell'ambiente.

La spinta ad azzerare la propria carbon footprint, iniziata in maniera radicale da Apple che tuttavia la persegue con serietà (non sono di parte: è vero), è innanzitutto una necessità per i grandi del cloud, cioè Amazon, Facebook, Google e Microsoft. A differenza di Facebook, che non vende a terzi la capacità dei suoi datacenter, gli altri tre big hanno costruito parte del loro modello di business più avanzato sulla crescita dei datacenter e la vendita di servizi cloud.

Questa tra l'altro è una cosa che sta avendo un impatto enorme sull'ambiente: tra pochi anni il cloud (e soprattutto l'addestramento di AI) peserà per il 10% sulla carbon footprint globale, superando abbondantemente quello dell'industria del trasporto aereo. Da qui il bisogno per Amazon, Google e Microsoft, di diventare virtuosi: azzerare la carbon footprint della propria azienda assumendo manager che si occupano di ambiente e portando avanti politiche intelligenti di ottimizzazione e riduzione dei consumi è una cosa buona. Questo anche se la crescita in valori assoluti ha comunque un impatto inequivocabilmente negativo. Infatti, puoi essere "verde" quanto vuoi, ma non stiamo certo parlando di una decrescita serena dell'informatica. Occhio che li riprendo nel Body più sotto.

Invece, se di giorno i big ottimizzano ––mettendo volti puliti di manager (spesso donne, che fanno più scena) a promuovere queste attività––, di notte "sporcano tutto" con il patto scellerato stretto con le compagnie petrolifere al fine di ottimizzare e anzi far crescere l'estrazione. Una industria che, tra petrolio, gas e carbone, pesa per l'85% del fabbisogno energetico globale. Nucleare e idroelettrico occupano poi i quattro quinti circa del restante 15%, mentre il quinto finale tocca alle rinnovabili.

Insomma, dichiararsi "verdi" per poi contribuire a peggiorare l'ambiente aiutando chi fa più danni di tutti, mi sembra una pratica irresponsabile e criminale. Alla pari o anche peggio del modo con cui sono trattati i dati degli utenti.

BODY

La decrescita felice è possibile, almeno per il software
Nei giorni scorsi mi sono baloccato con tre idee differenti che avrei voluto affrontare in questo numero di Mostly Weekly, ma non sapevo come metterle assieme. In realtà non c'è un modo se non facendo un percorso un po' destrutturato e che alla fine mostrerà anche una contraddizione da parte mia. Ma la vita è fatta così, non è un teorema in cui si può dimostrare tutto logicamente.

La prima parte, quella più esplicitamente legata alla decrescita del software, nasce dall'Head di questo numero. Risponde all'idea per cui è il software che oggi, secondo me, è il pezzo più grosso del problema.

Se vogliamo decrescere, e non solo dovremmo ma possiamo anche farlo, perché non farlo riducendo l'uso dei computer? Come si fa a ridurlo? Migliorando il software. Attenzione: non migliorarlo nel senso di fare Windows o Wordpress o Drupal con più funzioni. No, facendo un salto di qualità e tornando a pratiche di programmazione che, a fronte delle funzionalità richieste, riducano drasticamente la potenza di calcolo necessaria (evitando l'obsolescenza di intere generazioni di computer e apparecchi) e la dimensione del codice (trasparenza e manutenibilità). Perché abbiamo dei sistemi operativi, ad esempio iOs o Android, che richiedono fino a 6 GB di spazio (Windows agli esordi utilizzava 30 MB!) e non funzionano più con la tecnologia di smartphone prodotti cinque anni fa, senza peraltro aver introdotto alcuna funzione sostanzialmente nuova? Pensateci, perché dopotutto un telefono di cinque anni fa è comunque un apparecchio da fantascienza rispetto ai computer che ad esempio hanno portato l'uomo sulla Luna: possibile che non si riescano più ad utilizzare neanche per aprire la posta, mandare un messaggio, guardare un video?

Tema intoccabile ovviamente per i big della tecnologia, che peraltro stanno combattendo su tutt'altro fronte per evitare di affrontare i problemi legati alla privacy e all'uso dei dati degli utenti.

La decrescita felice del software
Invece l'idea della decrescita del software (l'espressione me la sono inventata io) parte da questo articolo di un programmatore che è arrabbiato (anzi, disenchanted) perché il software non migliora, anzi peggiora. Cioè: produciamo software fatto sempre peggio, legato a paradigmi molto discutibili o non più attuali, che funziona male, pesante, senza senso. Sistemi operativi giganteschi, lentissimi perché non scalano rispetto alle risorse hardware che oggi hanno a disposizione. Software incomprensibili e inutili.

Se usiamo, come ho fatto prima, la dimensione del codice, anche escludendo gli asset grafici, la sua è una crescita che semplicemente non ha senso. La decrescita sarebbe nel cominciare a scrivere software migliore, più piccolo e manutenibile, che aumenti le funzionalità ottimizzando l'uso delle risorse. Si potrebbero immaginare sistemi operativi, applicativi e software server side (back-end e front-end) minuscoli rispetto a quelli di oggi, efficienti e capaci di sfruttare l'hardware esistente molto meglio e molto di più. Anziché creare macchine virtuali che fanno girare container che poi devono essere gestiti con kubernetes, tre strati di astrazione per sopravvivere a paradigmi di programmazione inefficaci e inefficienti.

Si stava meglio con il Motorola 68030?
Sto scrivendo questa newsletter su un MacBook Pro 16 con un processore i9 da 2,3 GHz, 16 GB di Ram, 1 terabyte di SSD velocissimo, due schede grafiche. Talmente potente che per le attività di base c'è chi ha trovato un modo per renderlo più mansueto e aumentare l'autonomia del 50% grazie all'estensione del kernel Turbo Boost Switcher.

Il problema però è un altro. Al massimo delle sue prestazioni, qualsiasi browser utilizzi (Safari, Chrome e Firefox) ci sono siti che non si riescono a gestire, che quasi non si aprono o che diventano lentissimi e affogano il sistema. Ma non sono certamente solo i browser i software di cui occuparsi. Pensate al lag mentre si scrive. Sta succedendo anche a me usando iA Writer o Scrivener o MacVim o Vim con Zsh o BBEdit. Un lag che è più elevato di quello che avevo nel 1993 sul mio Mac Lc III con BBEdit. E non fraintendetemi, perché i programmi che citavo sono i migliori su piazza, secondo me: figuratevi gli altri. Non uso più Word da un decennio perché lo considero un incubo: per funzioni, scelte tecnologiche e anche per ragioni etiche. Il problema però resta: sono cinquant'anni che esiste la videoscrittura, venticinque che esiste il web. Possibile che da allora la performance del software sia solo peggiorata? (A riprova, in questo video un MacBook Pro 13 stampa una cartella di testo più o meno alla stessa velocità di un Commodore 64 con stampante ad aghi!)

In questo notevolissimo saggio breve Craig Mod dice una cosa molto semplice: il software veloce è il software migliore. Non perché sia fatto male tanto il processore è super-potente. No, il contrario: "Speed can be a good proxy for general engineering quality. If an application slows down on simple tasks, then it can mean the engineers aren’t obsessive detail sticklers. Not always, but it can mean disastrous other issues lurk." Una lezione che per esempio si è quasi persa nel mondo dei video game, una volta il regno dell'ottimizzazione per creare interi mondi su cartucce da pochi megabyte (i 18 mondi e tutti i puzzle di Super Mario 64 stanno in una rom da 6 MB)

Allora dobbiamo buttare a mare Unix e il C?
Uno degli argomenti più nerd che si può tirare fuori sul perché siamo arrivati a questo punto con i computer va oltre l'ingegneria del software e tocca la filosofia esistenziale che c'è dietro. In questo sorprendente video di Benno Rice alla Linux Conference che si è conclusa da poco in Australia, intitolato "What UNIX Cost Us", l'idea è semplice ma radicale: il modello mentale di Unix e la struttura del linguaggio di programmazione C sono nati cinquant'anni fa in un'epoca con tecnologie, usi e problemi molto differenti. Oggi queste tecnologie, che si sono imposte per un caso della storia, sono obsolete e anzi controproducenti: i processori vengono sviluppati per cercare di accomodare i costruiti del C e il C dà forma al modo con cui si cercano di affrontare dei problemi profondi e insolubili su quella architettura. Bisognerebbe fare un passo avanti e fare innovazione che qui stagna.

A tale of two cultures
Un altro approccio, che però riporto per criticare, è l'ultimo argomento che viene fuori da quelli che ho raccolto questa settimana. Forse perché ho comunque avuto poco tempo per metabolizzarlo, ma risulta più frammentario e comunque sbagliato. Alla fine però c'è una chiave di lettura. La storia per me inizia con questo articolo di Philip Guo (professore associato di scienze cognitive da qualche parte) nel quale l'accademico blasta il terminale: uno strumento inutilmente complicato per gli utenti del suo genere: "One of my highest-leverage activities when working with students on research is to help them install, set up, and configure software while overcoming the bullshittery of command-line interfaces." Andando avanti, il buon Guo aveva scritto anche questo articolo sulle due culture del computer nel quale sosteneva che: "Most computer users treat software as a tool for getting tasks done, while programmers hold conversations with their software. One big challenge when teaching programming, no matter in what language, is getting students used to a conversation-oriented programmer culture, which is very different than a tool-oriented user culture."

La posizione di Guo a mio avviso è criticabile, ma nasce da una frustrazione concreta: se il mondo sta diventando una software house, gli studenti e in generale i ricercatori di alcune facoltà spesso devono fare qualcosa di più, cioè ricerca quantitativa modellizzata con strumenti software. Si usa Python e R, oltre a LaTex per le eventuali pubblicazioni. Gli ultimi due sono pacchettizzati meglio. Python invece no: è un linguaggio di scripting e programmazione con un sistema di deployment più complesso e articolato. E spiazzante per molti versi. (Tra Python e R c'è anche un po' di guerra di religione).

Qui una volta erano tutti menu e finestre
A Guo questa cosa della shell che è una cosa complicata non va giù, e cerca di generalizzarla utilizzando un parallelo sull'idea di "due culture": "The Two Cultures originally referred to the schism between the sciences and humanities. However, I've noticed a similar schism in computing between users and programmers, which makes it hard to teach programming to beginners." Guo qui cerca di salire sulle spalle di un pensatore maggiore, cioè Joel Spolsky (aka: Joel on Software), che in un'altra epoca tecnologica pre-cloud e pre-mobile, ha scritto articoli interessanti. In questo del 2003, in particolare, mette in parallelo Windows e Unix per fare il mazzo a Unix.

Tuttavia, in maniera apparentemente del tutto involontaria (secondo me frutto di una mala interpretazione di cosa voglia dire programmare e cosa essere utenti), la contrapposizione tra la cultura degli utenti e la cultura dei programmatori può risultare utile. Ma ci sarà modo di parlarne nelle prossime settimane.

VIM CORNER

Il lato giusto del cavetto
Tra l'economia della decrescita e la devastazione completa, ci sono molte gradazioni. Nei giorni scorsi è rinata ad esempio la polemica (ne ho scritto anche io) tra l'Unione europea che vuole standardizzare i caricabatteria degli smartphone per ridurre i rifiuti elettronici (in pratica: si cambierebbe solo lo smartphone continuando a usare sempre il vecchio caricabatteria) e Apple, che viene messa in croce pur essendo sostanzialmente già compatibile (i caricabatterie dei suoi apparecchi ora sono tutti Usb-C, serve "solo" il cavetto giusto). Invece, dei fornitori di cloud al servizio dell'industria petrolifera, quella che più ha impatto sul gas serra, ne parlavo prima, in Italia c'è praticamente il silenzio stampa.

Due pesi e due misure
Tra l'altro, da quando con iOS 13 Apple ha aumentato ulteriormente i livelli di privacy, su quella piattaforma c'è stato un calo del 68% del tracking in background della posizione, cosa che ha un impatto diretto sulla monetizzazione dei profili degli utenti: anche di questo, praticamente non si parla. Oppure, quando se ne parla, si mette insieme a un'analoga iniziativa di Google, che però non è la stessa cosa: mentre da un lato Apple impedisce alle terze parti di estrarre informazioni dagli utenti se questi non vogliono, Google in realtà fa fuori la concorrenza ma continua a estrarle grazie per sé al suo conflitto di interessi come gestore della piattaforma Android da una parte e monetizzare di utenti dall'altra.

Il futuro di R (per non tacer di Rust)
C'è maretta dalle parti di Rust, con personaggi storici della community che sono in crisi. Ma non solo. In generale, tutti i linguaggi di programmazione evolvono. R, di cui si parlava prima, non è da meno. R è cambiato parecchio nelle varie iterazioni degli ultimi anni. Gli utenti più stagionati tentennano di fronte ai cambiamenti strutturali e di direzione che hanno reso il linguaggio un animale molto differente da quello degli esordi. Uno sviluppatore però ha un ruolo particolare: Hadley Wickham, il più conosciuto tra quelli che costruiscono i pezzetti di R: ha creato alcune delle librerie più importanti per l'analisi e la visualizzazione dei dati (tidyverse, se le conoscete). Quartz lo ha intervistato aprendo un bel ragionamento (un po' politico) sul rapporto tra R e Python. Wickham tra le altre cose ha in sintesi detto che i due linguaggi continuino a crescere in parallelo, ognuno per la sua nicchia d'utilizzo. E che R si integri di più nel flusso di lavoro della data science e che mantenga il focus sulla sua capacità di fare visualizzazione dei dati. Il tono è politico e amichevole, ma le ambizioni di chi modella lo sviluppo di R sono enormi. Pythonisti, siete avvertiti.

Oh My Zsh
Negli ultimi giorni ho, in maniera piuttosto estemporanea e direi situazionista, portato avanti la migrazione da Bash a Zsh. In particolare, visto che è uno dei due motivi per cui utilizzare la shell Z, ho studiato un pochino e installato il framework Oh My Zsh. A convincermi, a parte un po' di articoli e un po' di lavoro sul sito degli sviluppatori del progetto, è stato l'articolo che racconta la storia del progetto da parte del suo ideatore, Robby Russell, che per caso è diventato un fenomeno open source: su GitHub Oh My Zsh ha 102mila stelle, una comunità di 1.500 sviluppatori, più di 200 plugin, 140 temi, un sistema di aggiornamento automatico. E soprattutto, è la filosofia del progetto che mi piace, perché mi tranquillizza: "[...] it was I wanted to focus my attention on folks who weren’t too comfortable with the terminal and/or git."

TSUNDOKU REGULAR
Perché, quando si comprano libri e non si leggono ma si accumulano e basta, c'è una parola (giapponese) per dirlo

- Nausicäa della Valle del vento di Hayao Miyazaki è il manga dell'anime omonimo, che è anche il primo film "importante" di Miyazaki, assieme a Lupin III - Il Castello di Cagliostro e ovviamente Conan il ragazzo del futuro. Il film di Nausicäa è bellissimo, poetico e per una generazione intera avvolto dal mistero perché lo vedemmo una sola volta in televisione, quando la Rai lo trasmise, il 6 gennaio 1987. Da allora per una quindicina di anni nelle fumetterie di mezza Italia hanno girato delle versioni fatte da copie di copie di uno o più VHS (probabilmente due registrazioni differenti, forse tre) con il primo, storico doppiaggio. Il manga, arrivato anni dopo in una prima edizione incompleta, adesso è già da tempo disponibile in versione completa. È un'opera ancora più ampia e profonda dell'anime, anche se diversa nel tono della storia. Il suo sguardo sul nostro futuro remoto e sull'animo violento, ambizioso e militarista di chi vivrà dopo di noi, per me è sempre più attuale.
- I tre Adolf di Osamu Tezuka è, assieme a Buddha, forse l'opera politico-sociale più ambiziosa e riuscita del "dio dei manga". Sono tre volumi che raccontano la storia di tre persone che si chiamano Adolf: Kaufmann, figlio di un diplomatico tedesco e di una donna giapponese; Kamil, figlio di panettieri ebrei residenti in Giappone. E Hitler, ovviamente. Questa settimana che arriva c'è la giornata della Memoria: una lettura che ha senso. (Nel mio piccolo, ho scritto alcune cose su Tezuka).
- Lamù. Urusei yatsura di Rumiko Takahashi è una nuova edizione in più volumi del manga più famoso della Takahashi, che è stata anche un anime lunghissimo, ricchissimo, affascinante e fondamentale per la lunga stagione televisiva dei cartoni animati giapponesi in Italia. Il manga è godibilissimo, la serie televisiva di 195 puntate ha anche un piccolo mistero. È andata in onda su Telecapri e Retecapri in maniera "pirata" per la prima volta nel 1983 con una cosa strana: la prima sigla italiana è una canzone che non si sa chi l'ha scritta o chi la canta, ed è troncata bruscamente (probabilmente non era neanche nata per fare da sigla dell'anime) a metà di un verso. In rete cercano da tempo di capire chi possa averla fatta ma il mistero permane, irrisolto. Tra parentesi, è una bella canzone.

TSUNDOKU POETRY ROOM
La stanza della poesia di Mostly Weekly

Les Fleurs du mal di Charles Baudelaire. «Questo libro, il cui titolo dice tutto, è rivestito di una bellezza sinistra e fredda... È stato fatto con furore e pazienza», lo conoscete tutti. Ma l'avete poi mai letto? Perché non è un caso se I fiori del male sia quel che è nella nostra cultura e nella nostra letteratura. Sono 135 poesie in sei sezioni con le quali Baudelaire vuole "extraire la beauté du Mal". L'opera di un poeta maledetto che contempla misticamente il piacere e la bassezza della natura umana. Lirico, surreale, post-romantico. Enorme.

I link non hanno alcuna affiliazione, puntano solo all'oggetto culturale citato.

::END::

Ti è piaciuta? Inoltrala a chi potrebbe essere interessato.
Se l'hai ricevuta, qui puoi iscriverti
Se vuoi cancellarti (subito, rapidamente e per sempre) il collegamento invece è più sotto.
Qui invece c'è l'archivio dei numeri passati
Buona domenica!