Patetici.

Ho detto: «Guardate che, con i mezzi odierni, con la rete e con i computer che abbiamo oggi, potreste agevolmente costruirvi una Internet 2.0».

La risposta è stata:

«Sì, basterebbe una legge».

Eh?

No.

Non serve alcuna cazzo di legge.

La legge significa che tu piagnucoli con la mamma, spieghi alla mamma che una cosa non ti piace, e aspetti che la mamma stabilisca che da oggi si farà diversamente.

La ribellione significa un'altra cosa.

Significa che tu, da oggi, fai diversamente.

Non chiedi il permesso. Non aspetti che qualcuno trasformi la tua protesta in regolamento. Non deleghi a un'autorità il compito di cambiare il mondo al posto tuo.

Cominci a comportarti come se quel cambiamento fosse già avvenuto.

E questa è una differenza enorme.

Prendete la storia dei DNS. Tempo fa, quando in alcuni paesi c'erano rivolte, repressioni o semplicemente blocchi governativi, e certi domini non governativi venivano fatti sparire attraverso i DNS degli operatori locali, era diventato abbastanza comune fare una cosa molto semplice: scrivere 8.8.8.8 sul cellulare o sul computer e usare i DNS pubblici di Google. Era una cosa abbastanza diffusa da diventare quasi una procedura standard: «non ti risolve il sito? Cambia DNS». E in alcuni paesi questa cosa è stata fatta in massa. Quindi, se volete lanciare un nuovo dominio, che so io .narnia, il problema tecnico non è affatto quello che molti sembrano immaginare. Dovete “solo” mettere in piedi una root DNS alternativa, magari trovare un sodale che ne metta in piedi una seconda, replicare le zone e poi far circolare l'informazione:

Se volete vedere gli host della nostra associazione, cliccate qui e aggiungete a.b.c.d alla lista dei vostri DNS.

Da quel momento, per chi usa quei resolver, .narnia esiste.

Per il resto di Internet no.

Ma questa è esattamente la questione: non avete chiesto il permesso a nessuno perché esistesse.

E già: ci fu un precedente. E funzionò.

Forse non avete mai sentito parlare di AlterNIC.

AlterNIC nacque a metà degli anni Novanta, quando Network Solutions godeva sostanzialmente del monopolio sulla registrazione dei principali domini Internet. Eugene Kashpureff e soci decisero che, invece di protestare perché qualcuno cambiasse il sistema, avrebbero semplicemente costruito un sistema diverso.

Misero quindi in piedi una propria root DNS.

La cosa interessante è che non crearono una “Internet parallela”. Nei loro DNS continuarono ad inserire .com, .net, .org e tutti i domini della root ufficiale, ma aggiunsero anche i propri TLD.

Per esempio .xxx, .med, .nic, .ltd, .lnx, .exp.

Se usavate i DNS normali, quei domini non esistevano.

Se usavate quelli di AlterNIC, esistevano.

Tutto qui.

E al massimo della diffusione, secondo le loro stime, qualcosa come il 3% di Internet utilizzava quella root alternativa.

Che non sembra molto finché non ricordate una cosa: nessuno aveva obbligato quelle persone a cambiare configurazione. Avevano deliberatamente deciso che, per loro, la root DNS sarebbe stata quella.

Poi la storia finì male, ma per una ragione che va tenuta distinta.

Kashpureff decise di fare il passo più lungo della gamba.

Nel luglio del 1997 sfruttò una vulnerabilità dei DNS dell'epoca per avvelenare le cache di parecchi nameserver e fare in modo che www.internic.net puntasse al sito di AlterNIC. Chi cercava InterNIC finiva quindi sulla sua pagina di protesta.

Quello non era più “costruisco il mio DNS”.

Quello era mettere le mani sul DNS degli altri.

Network Solutions lo portò in tribunale, intervenne l'FBI, Kashpureff venne arrestato in Canada ed estradato negli Stati Uniti.

AlterNIC da quel momento perse progressivamente importanza e scomparve.

Ma attenzione al dettaglio.

Non fallì perché una root DNS alternativa fosse tecnicamente impossibile.

Quella funzionava.

Fallì perché il sistema ufficiale cominciò nel frattempo ad aprirsi alla concorrenza e ai nuovi TLD e, soprattutto, perché il suo fondatore trasformò una ribellione tecnica perfettamente legale in un attacco informatico contro il sistema concorrente. Ma nel frattempo, la “concorrenza/monopolio” americana comincio' a capire che gli alternic sarebbero spuntati come i funghi, e decise di aprirsi ai tld alternativi.

Sono due cose molto diverse.

AlterNIC aveva già dimostrato la cosa che interessa a noi.

AlterNIC fallì anche perché il sistema ufficiale, nel frattempo, cominciò ad aprirsi alla concorrenza e ai nuovi TLD e, soprattutto, perché il suo fondatore trasformò una ribellione tecnica perfettamente legittima in un attacco informatico contro il sistema concorrente.

Ma nel frattempo il messaggio era arrivato.

E lo ricordo bene, perché c'ero.

In quegli anni diversi piccoli ISP cominciavano a offrire due cose diverse: Internet e una specie di Internet allargata, spesso come servizio aggiuntivo a pagamento.

La differenza era semplice: con il DNS normale vedevate la Internet ufficiale. Con i resolver alternativi vedevate anche i domini delle root alternative.

Quella roba era sovversiva il giusto.

Perché a quel punto non stavamo più parlando di quattro hacker che giocavano con il DNS. Stavamo parlando di operatori commerciali che potevano vendere ai propri clienti un namespace più grande di quello ufficiale.

E quando questo comincia a succedere, il problema per chi controlla il sistema diventa abbastanza evidente.

Se continui a tenere chiusa la root, se continui a decidere tu quali TLD possano esistere e quali no, qualcun altro può semplicemente costruirne una diversa.

Poi un altro.

Poi un altro ancora.

E a quel punto di AlterNIC ne spuntano come funghi.

Altroché se capirono l'antifona.

La possibilità che qualcun altro rifacesse la stessa cosa, magari meglio, magari con l'appoggio di ISP veri e con una massa critica più grande, era precisamente il genere di minaccia che poteva trasformare il DNS da infrastruttura globale unica in una collezione di namespace concorrenti.

E infatti il sistema ufficiale cominciò ad aprirsi.

Nuovi registrar. Nuovi TLD. Più concorrenza.

Non perché qualcuno avesse improvvisamente scoperto le virtù filosofiche del pluralismo.

Ma perché era diventato evidente che il monopolio sul namespace esisteva soltanto finché la gente accettava di usarlo.

Oggi il 1995 è lontano, e non ricordate più la ribellione.

Non ricordate più quando si andavano a cercare i domini .xxx per vedere le foto — perché allora di video praticamente non si parlava nemmeno — porno.

Era un'altra Internet, ma soprattutto era un altro atteggiamento.

Se non vi piace il monopolio americano, oggi ci sono moltissime cose che potreste fare.

Tecnicamente.

Fare.

Non protestare perché diventi obbligatorio farle. Non chiedere una legge che costringa qualcuno a costruirle per voi. Non aspettare che un'autorità stabilisca che da domani si cambia.

Farle e basta.

L'esempio di una darknet per un'organizzazione che ha moltissimi soci, come Autistici/Inventati, è soltanto uno dei tanti.

Non sarebbe nemmeno un'idea particolarmente esotica.

Nell'ambiente del Chaos Computer Club e degli hackerspace tedeschi esiste da anni ChaosVPN, una rete overlay pensata precisamente per collegare hacker, hackerspace, server, laptop e intere reti attraverso Internet. È costruita su tinc, usa collegamenti cifrati e una topologia distribuita, senza un singolo punto centrale dal quale debba necessariamente passare tutto il traffico.

In altre parole: Internet viene usata semplicemente come trasporto.

Sopra, ci costruite la vostra rete.

I vostri indirizzi.

I vostri servizi.

Le vostre regole di routing.

E nessuno deve promulgare una legge perché possiate farlo.

La tecnologia esiste già.

La differenza sta tutta tra chi dice:

«Bisognerebbe obbligare qualcuno a costruire una rete indipendente».

e chi dice:

«Abbiamo costruito una rete indipendente. Se vuoi entrarci, installa questo».

Nel primo caso, state protestando.

«Mamma, mamma, voio, voio».

Nell'altro caso, avete costruito la vostra casa sull'albero.

È diverso.

Il mondo non lo hanno mai cambiato le proteste. Lo hanno cambiato le ribellioni. Quelli che dicevano:

«Me ne sbatto, e faccio lo stesso come dico io».

O ancora meglio, quelli che dicevano:

«Adesso creo il mio spazio e faccio come dico io».

Protestare significa chiedere a qualcun altro il permesso di fare qualcosa, ma urlando.

Ribellarsi significa decidere di fare qualcosa, e chi se ne fotte delle autorità.

Questa è la parte che è morta in voi.

Internet e il mondo dell'open source vi danno possibilità IMMENSE di crearvi spazi vostri, autonomi, DAVVERO autogestiti e immuni da interferenze.

E no, non quel progetto fatto dalla US Navy che è Tor.

Parlo della VOSTRA rete overlay.

La vostra.

Costruita da voi, gestita da voi, con i vostri nodi, i vostri servizi e le vostre regole.

Ma non lo farete.

La strategia di rallentare le cose è una vecchia strategia democristiana.

Prendere l'opposizione per stanchezza.

Attrito.

Frizione.

Vecchiaia.

• «Sì, ma guarda che io penso che tu abbia ragione. Solo che per questi cambiamenti ci vuole tempo. Forse fra venti, trent'anni».
• «Tu sei troppo avanti coi tempi, con le tue idee».
• «Ma io non dico mica che sbagli. Dico solo che è troppo presto. Devi avere pazienza».
• «Il problema di voi giovani è che volete tutto e subito».

E invece noi volevamo tutto e subito.

Erano gli anni Ottanta. Il telefono era SIP, in regime di monopolio — nel 1980 aveva già circa dodici milioni di abbonati — e non compravi semplicemente una linea sulla quale fare quello che ti pareva: sottoscrivevi un abbonamento a un servizio telefonico disciplinato da condizioni d'uso piuttosto rigide. La concessione SIP dell'epoca fu formalizzata, tra l'altro, con il D.P.R. 13 agosto 1984, n. 523.

E nelle condizioni di abbonamento c'erano limitazioni sull'uso della linea, comprese quelle relative ad attività e comunicazioni che oggi considereremmo perfettamente normali.

A noi, naturalmente, non fregava assolutamente niente.

Prendevamo il modem, lo attaccavamo alla linea SIP e ci mettevamo sopra una BBS.

Una macchina chiamava un'altra macchina.

Poi un'altra.

Poi qualcuno metteva su FidoNet.

Non abbiamo aspettato che la SIP introducesse il tariffario «BBS», che il ministero decidesse cosa fosse una BBS o che qualche commissione parlamentare stabilisse se fosse opportuno consentire ai cittadini di trasformare il telefono in una rete dati.

Abbiamo fatto le BBS.

Se avessimo aspettato il permesso, Internet sarebbe arrivata e sarebbe passata prima ancora che qualcuno avesse finito di discutere il regolamento. Invece le abbiamo fatte.

E non valeva soltanto per le BBS.

Le ragazze non hanno aspettato vent'anni perché qualcuno concedesse loro il diritto di divertirsi.

Si organizzavano feste private, e ci si divertiva.

Erano atti osceni, secondo qualche articolo del codice penale sulla moralità pubblica e il buon costume?

Oooooh.

Non si pagava la SIAE per la musica?

In culo alla SIAE.

Era roba contraria alla morale?

In culo alla morale.

Non potevi servire birra a uno sotto i sedici anni?

Ooooh, che dispiacere che ti daremo quando un amico piu' vecchio andra' a comprare gli alcoolici al supermarket e ci sfonderemo anche noi quattordicenni.

E attenzione: non sto usando questi termini per modo di dire.

Negli anni Ottanta “atti osceni”, “moralità pubblica”, “buon costume” erano realmente categorie del codice penale. La SIAE aveva realmente qualcosa da dire sulla musica eseguita fuori dalla strettissima cerchia familiare. E l'articolo 689 del codice penale vietava realmente agli esercenti di somministrare alcolici ai minori di sedici anni.

Non erano fantasmi che ci inventavamo per sentirci ribelli.

Le regole c'erano davvero.

Semplicemente, ce ne sbattevamo.

Non andavamo in piazza per il diritto delle ragazze di fare pompini.

Non andavamo in piazza per il diritto di fare questo o di fare quello.

Lo facevamo e basta.

E questa è la differenza tra ribellione e protesta.

Se protestate, troverete resistenza.

Se fate il cazzo che volete e ve ne infischiate, la legge vi corre dietro.

E tutte quelle cose che facevamo oggi sono legali. Ma non perché siamo andati in piazza a chiedere alcool ai quattordicenni: perché ce ne sbattevamo il cazzo e andavamo a comprarlo.

I rave party sono nati in quel periodo, perché ce ne sbattevamo il cazzo. Gli anni Novanta hanno goduto della libertà che avevamo creato.

Poi siete arrivati voi codardi, e avete deciso che ribellarsi significa protestare.

E qui avete perso tutto.

E perderete anche di più.

Volete una rete libera?

• Avete tinc.
• Avete Yggdrasil, che vi costruisce una rete IPv6 cifrata e decentralizzata sopra Internet, con routing proprio.
• Avete cjdns, da cui nasce parte della stessa famiglia di idee: indirizzamento crittografico, IPv6 e routing mesh.
• Avete I2P, se volete una vera overlay network anonima con servizi interni.
• Avete Lokinet, se volete una rete decentralizzata onion-routed capace di trasportare direttamente traffico IP e di ospitare servizi raggiungibili soltanto dall'interno della rete.
• Avete Nebula, open source e self-hosted, che crea una rete Layer 3 peer-to-peer con tunnel cifrati, NAT traversal e discovery dei nodi.
• Avete WireGuard, se volete costruirvela quasi a mano.
• Avete Headscale, se volete un control plane open source e self-hosted per una rete compatibile con Tailscale, invece di consegnare il controllo della rete a Tailscale.
• Avete NetBird, che costruisce reti peer-to-peer sopra WireGuard e può essere self-hostato.
• Avete Netmaker, che prende WireGuard e vi automatizza full mesh, partial mesh, routing, gateway e gestione dei peer.
• Avete ZeroTier, se volete una LAN virtuale distribuita.

E poi avete GRE, VXLAN, IPsec, OpenVPN, SSH tunneling, routing dinamico, bridge, namespace Linux, container, VPS da cinque euro e tutto il resto della ferramenta che negli ultimi trent'anni è stata inventata precisamente per collegare macchine che fisicamente non stanno sulla stessa rete.

Potete usarne uno.

Potete usarne tre insieme.

Potete forkare quello che non vi piace.

Potete scrivere il vostro.

Potete distribuire una configurazione con uno script.

Potete fare un'immagine Docker.

Potete mettere un QR code sul sito e dire:

«Vuoi entrare nella nostra rete? Installa questo».

Non dovete convincere Google.

Non dovete convincere ICANN.

Non dovete convincere Cloudflare.

Non dovete convincere il governo americano.

Non dovete convincere Bruxelles.

Non dovete andare in piazza a chiedere che qualcuno vi conceda una rete libera.

La rete ve la fate.

È software.

È questo il particolare che continuate a dimenticare.

Ma voi siete codardi, e al rischio della ribellione preferite la sconfitta: dolorosa, sì, ma non troppo, della protesta.

Perché la protesta ha un vantaggio enorme.

Vi permette di perdere senza aver mai davvero rischiato.

La verità è che fate gli hacker, fate gli hackerspace, fate la cybersecurity, vi riempite la bocca di decentralizzazione, autonomia, crittografia, indipendenza.

Neuromante is the new Il Maestro e Margherita.

Ma quando vi si mette davanti un compilatore e vi si dice:

«Fate».

allora salta fuori il poco che siete.

Perché lì non basta più avere l'estetica dell'hacker.

Non basta la felpa, non basta il nickname, non basta il talk al congresso, non basta spiegare quanto sia cattivo il monopolio di turno.

Bisogna costruire qualcosa.

Bisogna rischiare che non funzioni.

Bisogna metterci macchine, tempo, codice, errori, responsabilità.

Bisogna decidere che una cosa esiste prima che qualcuno vi abbia dato il permesso di farla esistere.

E allora tornate bambini.

Bambini che chiedono alla mamma il permesso di fare qualcosa.

O meglio:

protestano perché la mamma continua a dire di no.

E la internet libera che volete l'avrete, forse, il 32 febbraio duemilamai.

O se preferite, coi tempi della UE. Si comincia nel 2034, poi va in vigore nel 2040, e nel 2050 e' obbligatorio.

Ma nel 2050 forse non ci sarete neppure.

Che ci crediate o meno, per un sysadmin minimamente decente non è un'operazione particolarmente difficile.

Benvenuti in una rete mesh chiamata Yggdrasil.

Yggdrasil è una rete mesh overlay IPv6 cifrata: ogni nodo riceve un proprio indirizzo IPv6 e può comunicare con gli altri nodi passando, quando serve, attraverso altri peer.

Non esiste un server centrale. Ogni macchina conosce uno o più peer Yggdrasil, e da questi collegamenti nasce automaticamente il grafo della rete e il relativo routing.

Se configurate soltanto i vostri peer, ottenete una mesh privata tra le vostre macchine. Se invece vi collegate anche a peer pubblici, entrate nella rete Yggdrasil pubblica.

Non è Tor: non nasce per anonimizzarvi, ma per creare connettività cifrata, distribuita e resiliente tra nodi.

Siccome non state commettendo crimini, ma volete semplicemente sottrarvi alla dipendenza dai registrar, dal DNS e dalle varie autorità che possono intervenire su quella catena, dovrebbe essere sufficiente. Se invece vi serve anche l'anonimato, allora dovrete guardare a qualcosa come I2P, che personalmente considero ormai molto più macchinoso di quanto valga. Tor, invece, io non lo userei nemmeno a morire se il problema fosse evitare qualcosa di simile a quanto accaduto ad Autistici/Inventati.

Non perché Tor “non funzioni”. Il problema è un altro.

L'onion routing nasce negli anni Novanta nei laboratori dello U.S. Naval Research Laboratory, cioè all'interno della Marina militare americana; Tor deriva direttamente da quella linea di ricerca. Questo non è complottismo: lo racconta tranquillamente lo stesso Tor Project nella propria storia ufficiale.

Successivamente Tor è diventato un progetto open source e il Tor Project un'organizzazione indipendente, ma il rapporto economico con il governo statunitense non è esattamente marginale. Nell'esercizio fiscale 2023-2024, per esempio, circa il 35% delle entrate del Tor Project proveniva dal governo degli Stati Uniti; nel 2021-2022 era addirittura il 53,5%. Il Tor Project stesso pubblica questi numeri e dichiara esplicitamente di voler ridurre nel tempo questa dipendenza.

E se il mio problema specifico fosse proprio costruire un'infrastruttura che non dipenda, politicamente o amministrativamente, dagli Stati Uniti, diciamo che questo sarebbe sufficiente a farmi cercare altrove.

Ma diciamo che vogliamo usare Yggdrasil. Allora ci servono alcuni amici smanettoni, o comunque dei sysadmin decenti, e diciamo tre VPC distribuite su cloud europei. Volendo possono anche essere tre macchine a casa: il punto è semplicemente avere tre nodi abbastanza stabili, possibilmente su reti diverse. Su ciascuno installiamo Linux e Yggdrasil. Diciamo che usiamo Debian. I comandi sono questi:

sudo apt-get update
sudo apt-get install -y dirmngr gnupg

sudo mkdir -p /usr/local/apt-keys

gpg --fetch-keys \
https://neilalexander.s3.dualstack.eu-west-2.amazonaws.com/deb/key.txt

gpg --export 1C5162E133015D81A811239D1840CDAC6011C5EA \
| sudo tee /usr/local/apt-keys/yggdrasil-keyring.gpg >/dev/null

echo 'deb [signed-by=/usr/local/apt-keys/yggdrasil-keyring.gpg] https://neilalexander.s3.dualstack.eu-west-2.amazonaws.com/deb/ debian yggdrasil' \
| sudo tee /etc/apt/sources.list.d/yggdrasil.list

sudo apt-get update
sudo apt-get install -y yggdrasil

sudo systemctl enable --now yggdrasil

A questo punto Yggdrasil ha già creato la sua configurazione in:

/etc/yggdrasil.conf

e il demone è attivo. Potete verificarlo con:

systemctl status yggdrasil

e vedere l'indirizzo IPv6 Yggdrasil assegnato alla macchina con:

ip addr

Da qui in poi comincia la parte interessante: fare in modo che i tre nodi si conoscano fra loro e diventino l'ossatura della nostra piccola rete.

Il vostro indirizzo IPv6 Yggdrasil viene derivato dalla vostra chiave pubblica crittografica. Finché conservate la stessa coppia di chiavi, quindi, conserverete anche lo stesso indirizzo. La probabilità che due normali indirizzi Yggdrasil /128 collidano accidentalmente è talmente bassa da poterla, per i nostri scopi, considerare irrilevante. Adesso però ricordate una cosa: Yggdrasil cifra il traffico, ma non è un firewall. Se una porta è aperta sull'interfaccia Yggdrasil, chi può raggiungere il vostro nodo può tentare di collegarcisi. La documentazione stessa raccomanda quindi esplicitamente di usare un firewall IPv6. Diciamo che l'interfaccia si chiami ygg0 e che, per il momento, vogliamo accettare soltanto SSH sulla porta 22.

Con nftables possiamo fare, per esempio:

sudo nft add table inet yggdrasil
sudo nft 'add chain inet yggdrasil input { type filter hook input priority 0; policy accept; }'

sudo nft add rule inet yggdrasil input iifname "ygg0" ct state established,related accept
sudo nft add rule inet yggdrasil input iifname "ygg0" tcp dport 22 accept
sudo nft add rule inet yggdrasil input iifname "ygg0" drop

A questo punto, dall'interfaccia Yggdrasil entra soltanto SSH e il traffico appartenente a connessioni già stabilite. Il resto viene buttato via.

Forse la vostra interfaccia avrà un altro nome: dipende dalla versione, dal packaging e dalla configurazione. Controllate con ip addr e usate il nome effettivo. Adesso dovete entrare nella mesh, o almeno cominciare a costruirne una. Per farlo avete bisogno degli indirizzi IP “normali” dei vostri amici — cioè gli IPv4 o IPv6 con cui le loro macchine sono raggiungibili su Internet — e della porta TCP o TLS sulla quale Yggdrasil ascolta. Poi li inserite nel file di configurazione, /etc/yggdrasil.conf, nella sezione Peers. Per esempio:

Peers:
  - tls://203.0.113.10:443
  - tls://198.51.100.27:443

Naturalmente quegli indirizzi sono solo esempi. E chiaramente, la porta deve essere aperta e deve girarci Yggdrasil.

Volendo potreste usare anche degli hostname al posto degli indirizzi IP. Ma, se il motivo per cui state facendo tutto questo è proprio sottrarvi alla dipendenza da DNS, registrar e hostname revocabili, sarebbe abbastanza buffo reintrodurre il problema dalla finestra dopo averlo cacciato dalla porta.

Quindi, per questa configurazione, usiamo direttamente gli IP.

A questo punto il vostro nodo proverà a collegarsi direttamente a quei peer. E se anche loro hanno configurato almeno uno degli altri nodi, comincia a formarsi la mesh.

Non serve che ogni macchina conosca tutte le altre: basta che il grafo rimanga connesso.

Naturalmente quegli indirizzi sono soltanto esempi. E, altrettanto naturalmente, sui nodi remoti quella porta deve essere raggiungibile attraverso il firewall e Yggdrasil deve essere configurato per ascoltarvi. Mettere tls://203.0.113.10:443 dentro Peers non fa comparire magicamente un peer dall'altra parte: su 203.0.113.10:443 deve esserci davvero un'istanza Yggdrasil in ascolto.

Se abbiamo tre macchine:

A = 11.12.13.14
B = 21.22.23.24
C = 31.32.33.34

sulla macchina A possiamo avere, dentro /etc/yggdrasil.conf :

Peers: [
  tls://21.22.23.24:443
  tls://31.32.33.34:443
]

Listen: [
  tls://[::]:443
]

sulla macchina B:

Peers: [
  tls://11.12.13.14:443
  tls://31.32.33.34:443
]

Listen: [
  tls://[::]:443
]

e sulla C:

Peers: [
  tls://11.12.13.14:443
  tls://21.22.23.24:443
]

Listen: [
  tls://[::]:443
]

Ovviamente la 443 dovrebbe essere esposta su internet.

Adesso le vostre macchine creeranno una mesh. E se mettete una configurazione compatibile su altre macchine Linux con Yggdrasil installato, queste potranno collegarsi alla stessa rete.

A quel punto emerge un problema molto terra-terra: gli indirizzi IPv6 Yggdrasil non sono esattamente il genere di cosa che volete ricordare a memoria.

Vi serve un DNS.

Quindi voi tre compari che avete dato inizio alla cosa potete anche mettere in piedi tre server DNS autoritativi interni alla mesh.

Diciamo che decidiate di usare:

.narnia

.narnia, al momento, non è un TLD delegato nella root pubblica. Quindi, dentro la vostra rete, potete tranquillamente comportarvi come se foste gli dei del namespace.

Avete tre nodi Yggdrasil, diciamo con questi indirizzi IPv6:

200:1111:2222:3333:4444:5555:6666:7777
200:8888:9999:aaaa:bbbb:cccc:dddd:eeee
200:1234:5678:9abc:def0:1234:5678:9abc

Su tutti e tre installate BIND.

Uno sarà il primary della zona narnia, gli altri due saranno secondary.

Non serve multicast: BIND possiede già il suo sistema per mantenere sincronizzate le zone, attraverso NOTIFY e trasferimenti IXFR o AXFR.

Sul primary, dentro la configurazione di named, avrete qualcosa del genere:

zone "narnia" {
    type primary;
    file "/etc/bind/db.narnia";

    allow-transfer {
        200:8888:9999:aaaa:bbbb:cccc:dddd:eeee;
        200:1234:5678:9abc:def0:1234:5678:9abc;
    };

    also-notify {
        200:8888:9999:aaaa:bbbb:cccc:dddd:eeee;
        200:1234:5678:9abc:def0:1234:5678:9abc;
    };
};

Sugli altri due:

zone "narnia" {
    type secondary;

    primaries {
        200:1111:2222:3333:4444:5555:6666:7777;
    };

    file "/var/cache/bind/db.narnia";
};

Quando cambiate la zona sul primary e aumentate il seriale del record SOA, il primary avvisa i secondary e questi si aggiornano automaticamente.

In pratica avete appena costruito il vostro piccolo DNS interno, che vive interamente dentro Yggdrasil e non ha bisogno né di registrar né del DNS pubblico.

Domanda avanzata: per sincronizzare i DNS dovrei usare anche TSIG?

No. In questo caso sarebbe sostanzialmente ridondante.

Gli indirizzi Yggdrasil derivano già dall'identità crittografica dei nodi, e le comunicazioni tra quei nodi sono già autenticate e cifrate dalla rete stessa. Se state permettendo i trasferimenti di zona soltanto verso gli indirizzi Yggdrasil dei vostri secondary, avete già un'identità crittografica sottostante sulla quale basare l'ACL.

Aggiungere TSIG significherebbe sovrapporre un secondo meccanismo di autenticazione a uno che, per questo specifico threat model, avete già.

Non aggiungereste sostanzialmente niente, se non altre chiavi da distribuire e gestire.

A questo punto, sui client della vostra rete, dovete dire al resolver di usare i tre DNS della mesh. In un sistema che usa direttamente /etc/resolv.conf, avrete qualcosa del genere:

nameserver 200:1111:2222:3333:4444:5555:6666:7777 nameserver 200:8888:9999:aaaa:bbbb:cccc:dddd:eeee nameserver 200:1234:5678:9abc:def0:1234:5678:9abc

Da quel momento, quando chiedete per esempio:

git.narnia chat.narnia files.narnia

la risoluzione avviene usando i DNS che vivono dentro la vostra rete Yggdrasil.

Se non volete vivere solo dentro Narnia, allora dovete fare una cosa piu' lunga:

Lasciare /etc/resolv.conf per i fatti suoi e se usate systemd-resolved, potete fare una cosa molto più elegante: dire al sistema che soltanto il dominio .narnia deve essere risolto attraverso i DNS Yggdrasil.

Supponiamo che l'interfaccia si chiami ygg0:

sudo resolvectl dns ygg0 \
  200:1111:2222:3333:4444:5555:6666:7777 \
  200:8888:9999:aaaa:bbbb:cccc:dddd:eeee \
  200:1234:5678:9abc:def0:1234:5678:9abc

sudo resolvectl domain ygg0 '~narnia'

Quel ~narnia significa: tutte le query per .narnia devono passare da questa interfaccia.

Il resto del DNS continua invece a funzionare normalmente attraverso la vostra connessione Internet ordinaria.

Quindi:

git.narnia
chat.narnia
files.narnia

andranno ai DNS della mesh, mentre:

debian.org
wikipedia.org
kernel.org

continueranno a essere risolti attraverso i DNS normali.

Questo è esattamente lo split-DNS che ci serve.

Una volta fatto questo, avete una rete , diciamo “organization-wise”.

Cosa potete fare? Potete decidere che esiste chat.narnia , e assegnarlo all' IP di un server (magari un raspberry o un odroid da due lire, che fanno girare irc a casa di qualcuno), oppure decidere che avete smtp.narnia , per inviare posta, o imap4.narnia per scaricarla.

Siete voi tre i regnanti di .narnia, e quindi potete, se vi fidate di qualcuno, assegnare quel che volete a chi volte.

Vi servono certificati? No. non davvero. Il traffico e' gia' criptato, gli indirizzi IPv6 che usate sono gia' validati per via crittografica. Potete liberarvi di questa ridondanza.

Voi direte adesso:

si, ma non e' che milioni di persone adesso si mettono una debian e poi installano tutta la baracca: anche senza i DNS da gestire, per l'utente medio e' davvero troppo.

Vero. Infatti io parlavo di una rete molto privata e molto “organization-wise”. Significa che se vi cacciano fuori dalla internet regolare, almeno gli amministratori dei vari sistemi (forum, mailing list, eccetera) potrebbero pur sempre parlare sul forum.narnia o usare la posta sui server smtp/imap di Narnia. Almeno per decidere sul da farsi.

Potreste sempre continuare ad inviare messaggi sulla mailing list: se il sistema che fa da mailing list sta su una macchina che serve sia internet che yggdrasil, la posta in uscita dovrebbe venire consegnata normalmente.

E quindi potreste avvisare i vostri utenti.

Ma non esiste proprio un modo per far accedere il pubblico a .narnia?

Non del tutto.

Nel senso che un membro di .narnia, qualcuno di cui vi fidate, potrebbe mettere in piedi un proxy su una macchina che abbia contemporaneamente accesso a Internet normale e alla rete Yggdrasil.

Per esempio, uno Squid su un piccolo computer sempre acceso.

Quella macchina avrebbe quindi due gambe:

Internet normale
       |
       |
     Squid
       |
       |
   Yggdrasil
       |
       |
    .narnia

Squid può essere configurato per usare resolver DNS specifici. Quindi il proxy può sapere come risolvere forum.narnia, chat.narnia, files.narnia e gli altri nomi interni, anche se il computer dell'utente che lo sta usando non sa assolutamente nulla di Yggdrasil. In pratica avete costruito un gateway applicativo.

L'utente normale non entra realmente nella mesh e non possiede un indirizzo Yggdrasil. Dice semplicemente al proprio browser:

usa questo proxy

e sarà il proxy, dall'altra parte, a raggiungere i servizi .narnia.

Quindi uno Squid con un piede su Internet e uno su Yggdrasil può fare da ponte tra il pubblico e quella parte della vostra infrastruttura che avete deciso di rendere accessibile. E lato utente la cosa può essere resa abbastanza semplice. Esistono molte estensioni per browser che permettono di scegliere automaticamente un proxy in base al dominio richiesto. Per esempio FoxyProxy, SwitchyOmega o estensioni analoghe basate su regole per dominio. In pratica potete dire:

*.narnia  -> usa il proxy
tutto il resto -> connessione normale

Quindi l'utente continua a navigare normalmente su Internet, ma quando apre:

forum.narnia
files.narnia
wiki.narnia

il browser manda automaticamente quelle richieste attraverso il proxy Squid. Non deve configurare Yggdrasil, non deve conoscere gli IPv6 della mesh e non deve modificare il proprio DNS di sistema.

Per lui .narnia diventa semplicemente un'altra porzione del Web, raggiungibile attraverso quel proxy.

Se volete, potete anche distribuire direttamente un file .pac, cioè un Proxy Auto-Configuration file, evitando persino di chiedere agli utenti di installare un'estensione.

Per esempio:

function FindProxyForURL(url, host) {
    if (host == "narnia" || shExpMatch(host, "*.narnia")) {
        return "PROXY 11.12.13.14:3128";
    }

    return "DIRECT";
}

La regola significa semplicemente:

*.narnia  -> proxy 11.12.13.14:3128
tutto il resto -> Internet normale

E ho usato direttamente l'indirizzo IP del proxy per una ragione abbastanza ovvia: se stiamo costruendo tutto questo proprio per sopravvivere alla perdita di domini e registrar, sarebbe piuttosto stupido distribuire un PAC contenente:

PROXY proxy.qualcosa.org:3128

e ritrovarci nuovamente dipendenti dal DNS pubblico quando gli americani ti droppano qualcosa.org

Il file .pac può essere distribuito agli utenti e configurato nei browser o nel sistema operativo come configurazione automatica del proxy. A quel punto l'utente digita:

https://forum.narnia/

e il browser manda quella connessione a Squid.

Squid, che conosce i DNS di .narnia e possiede anche un'interfaccia Yggdrasil, risolve forum.narnia e raggiunge il server attraverso la mesh.

Per tutto il resto, il browser continua tranquillamente a usare Internet come prima.

Direte: e' sempre troppo complicato per un utente bestia.

Vero. Ma dovete capire una cosa.

Se volete una cosa sicura e robusta, l'utente bestia e' esattamente la parte piu' pericolosa. Tutti gli attacchi sul layer 8 passano, infatti, dall'utente bestia.

L'utente bestia e' quello che clicca sui link di phishing. L'utente bestia e' quello che da' le credenziali del suo home banking al primo che telefona. L'utente bestia e' quello che da' i suoi risparmi da gestire a Wanna Marchi.

L'utente bestia e' quello che risponde al Principe Nigeriano cui serve solo il vostro conto corrente per poggarci 800.000 euro.

L'utente bestia e' pericoloso. Quindi, se non riesce nemmeno a configurare un proxy nel browser, teletelo fuori.

Questa rete privata e' per gli amministratori della rete mesh, per chi vuole aggiungervi i servizi , per chi vuole gestire dei servizi che stanno dentro.

Il pubblico li leggera' tramite internet, ma gli amministratori, in caso di attacco, potranno pur sempre incontrarsi telematicamente e parlare. E decidere come reagire.

In Italia, per quanto risulta pubblicamente, Autistici/Inventati non è invece classificato come organizzazione terroristica. E non stiamo parlando di un paese privo di strumenti in materia: l'Italia possiede una legislazione antiterrorismo stratificata e particolarmente sviluppata, costruita in buona parte durante e dopo gli anni di piombo, quando il terrorismo politico non era precisamente un'ipotesi accademica.

Insomma: se le autorità italiane, che sul terrorismo interno hanno accumulato una discreta esperienza storica, non trattano Autistici/Inventati come un'organizzazione terroristica, mentre Washington decide di classificarla come tale perché avrebbe fornito servizi informatici anche a soggetti che gli USA considerano terroristi, una certa differenza di metro appare quantomeno evidente.

Ma, appunto, questo non è ancora il problema interessante.

Negli USA, a volte, sembra funzionare così: o sei un tipo simpatico, oppure da qualche parte esiste già una casella nella quale possono scrivere “pericoloso terrorista”.

Il punto, però, è un altro. Questo gruppo gestiva — e gestisce — tra le altre cose un sistema di blogging distribuito sotto il dominio noblogs.org, oltre naturalmente ai servizi legati ad autistici.org.

E qui entra in gioco una parte dell'infrastruttura di Internet della quale normalmente nessuno si occupa, perché finché funziona sembra quasi una legge naturale.

I domini .org, infatti, non sono semplicemente delle stringhe che galleggiano magicamente su Internet. Come tutti i generic Top Level Domain, fanno parte di una struttura gerarchica regolata da ICANN. Ma il registro vero e proprio del .org, quello che materialmente mantiene la zona e decide quali domini esistano dentro di essa, è gestito da Public Interest Registry, o PIR.

E PIR è un'organizzazione statunitense.

Questo dettaglio, che normalmente interessa soltanto amministratori di sistema particolarmente annoiati, improvvisamente diventa molto interessante.

Perché il 28 agosto autistici.org è stato messo in stato serverHold nel registro .org. Non è stato spento il server. Non è stata sequestrata una macchina in Italia. Non è stato ordinato a un provider italiano di staccare una spina. I server continuavano ad esistere.

È stato tolto il nome.

serverHold significa, in pratica, che il registry smette di pubblicare quel dominio nella zona .org. Da quel momento il normale DNS mondiale non sa più come raggiungerlo. Potete avere i vostri server in Italia, Germania, Svizzera, Islanda o dentro una grotta del Carso: se qualcuno che controlla il livello superiore della gerarchia cancella il collegamento fra il vostro nome e Internet, per quasi tutti gli utenti siete spariti.

Ed è precisamente questo il punto interessante.

Il registrar di autistici.org era Gandi, cioè un'azienda francese. Ma sopra Gandi c'è il registry del .org, Public Interest Registry, che si trova negli Stati Uniti e opera all'interno del sistema contrattuale di ICANN. Il record pubblico del dominio mostra infatti uno stato imposto lato server, non semplicemente dal client o dal proprietario del dominio.

Quindi abbiamo un'organizzazione italiana, con servizi e utenti prevalentemente europei, sottoposta alla legge italiana, che per quanto risulta pubblicamente in Italia non è accusata di terrorismo né condannata per terrorismo, e alla quale tuttavia può essere sottratto uno dei principali strumenti con cui esiste su Internet perché una parte fondamentale dell'infrastruttura mondiale dei nomi di dominio ricade materialmente sotto la giurisdizione statunitense.

Non serve mandare l'FBI a Milano.

Non serve sequestrare i server.

Non serve ottenere una sentenza da un tribunale italiano.

È sufficiente agire abbastanza in alto nella gerarchia del DNS.

Ed ecco la parte della storia sulla quale, secondo me, bisognerebbe cominciare a perdere un po' di più il sonno.

I francesi, in questo caso, non sembrano avere colpe particolari perché Gandi era soltanto il registrar, cioè l'intermediario presso cui il dominio era stato registrato e attraverso il quale il titolare ne gestiva gli aspetti amministrativi.

Il potere effettivo di togliere un .org dalla zona DNS, però, non appartiene al registrar: appartiene al registry del .org, Public Interest Registry, che è statunitense.

Questo significa che le autorità USA potevano intervenire a monte di Gandi, direttamente sul soggetto che controlla il registro del dominio di primo livello. Non serviva quindi ottenere un ordine da un tribunale francese, né chiedere alle autorità francesi di sequestrare qualcosa, né costringere Gandi a collaborare.

Dal punto di vista tecnico e giuridico, la Francia poteva semplicemente essere scavalcata.

Ed è proprio questo il punto: avere un registrar europeo non protegge necessariamente da un intervento statunitense, se il dominio di primo livello che avete scelto è amministrato da un registry sottoposto alla giurisdizione degli Stati Uniti.

Ecco alcuni esempi di rilievo. Ci ho messo .uno perche' sui social avevo risposto che sembrava sotto influenza diretta di ICANN, mentre investigando meglio ho visto he l'influenza e' limitata. Possono essere soggetti a forte pressione, si, ma come agiranno dipende dalla pressione e da come la pensano loro di Radix.

Legenda:

• Totale: il registry è direttamente soggetto alla giurisdizione statunitense.
• Elevata: il registry o il gruppo societario ha una presenza statunitense significativa, tale da creare una forte esposizione legale o operativa.
• Limitata: il registry è formalmente soggetto a una giurisdizione non statunitense, anche se può avere rapporti contrattuali o infrastrutturali con soggetti USA.
• Scarsa: registry e struttura operativa sono principalmente fuori dalla giurisdizione statunitense, con pochi punti diretti di pressione legale dagli USA.

Il fatto che un TLD faccia parte del sistema ICANN non significa automaticamente che il suo registry sia sotto giurisdizione statunitense. Il punto decisivo è quale soggetto gestisce materialmente il registry e a quale ordinamento giuridico è sottoposto.

Visto che si parla di sovranita' digitale europea, la domanda e' “ommioddio, sono sotto il tallone americano”. Per esempio, sono coscente che il .net sia sotto il dominio americano, cosi' come sono cosciente di tutto il resto dello stack da cui dipendo. D'altro canto, tutto cio' che gestisco e' generato da file di configrazione dichiarativi, quindi mi basterebbe cambiare dominio, andare nel folder dei docker compose, e poi dire

perl -pi -e 's/keinpfusch\.net/nuovodominio.eu/g' *.yml

diverso e' il problema se siete un ente come autistici/inventati e offrite cose al pubblico, tipo mailing list, servizi di blog, eccetera

Se siete una simile organizzazione, dove di conviene aprire il vostro dominio, la prossima volta?

Partiamo da quelli meno influenzabili, di solito europei:

• .de — DENIC, Germania
• Giuridico: diritto tedesco; registry fuori dalla giurisdizione diretta USA.
• Tecnico: DNSSEC; infrastruttura Anycast molto estesa e fortemente ridondata.
• Valutazione: ECCELLENTE.
• .eu — EURid, Unione Europea / Belgio
• Giuridico: regolato dal diritto UE.
• Tecnico: DNSSEC; infrastruttura DNS distribuita e ridondata; registry grande e maturo.
• Valutazione: ECCELLENTE.
• .it — Registro .it / IIT-CNR, Italia
• Giuridico: diritto italiano/europeo; registry pubblico nazionale.
• Tecnico: DNSSEC; infrastruttura DNS ridondata; registry storico e maturo.
• Valutazione: ECCELLENTE.
• .ch — SWITCH, Svizzera
• Giuridico: diritto svizzero; fuori da USA e UE.
• Tecnico: DNSSEC; infrastruttura DNS professionale, distribuita e molto resiliente.
• Valutazione: ECCELLENTE.
• .is — ISNIC, Islanda
• Giuridico: diritto islandese.
• Tecnico: DNSSEC; registry piccolo ma storico e tecnicamente solido.
• Valutazione: MOLTO BUONO.
• .se — Internetstiftelsen, Svezia
• Giuridico: diritto svedese.
• Tecnico: DNSSEC; registry molto maturo; infrastruttura DNS robusta e distribuita.
• Valutazione: ECCELLENTE.
• .nl — SIDN, Paesi Bassi
• Giuridico: diritto olandese.
• Tecnico: DNSSEC; registry di grandi dimensioni; infrastruttura molto ridondata.
• Valutazione: ECCELLENTE.
• .at — nic.at, Austria
• Giuridico: diritto austriaco.
• Tecnico: DNSSEC; nameserver globalmente distribuiti e ridondanti.
• Valutazione: ECCELLENTE.
• .fi — Traficom, Finlandia
• Giuridico: diritto finlandese.
• Tecnico: DNSSEC; infrastruttura stabile e requisiti tecnici rigorosi.
• Valutazione: MOLTO BUONO.
• .no — Norid, Norvegia
• Giuridico: diritto norvegese.
• Tecnico: DNSSEC; mix Anycast/Unicast; server distribuiti geograficamente e su reti diverse.
• Valutazione: ECCELLENTE.
• Nota: registrazione più restrittiva rispetto ad altri ccTLD.
• .li — SWITCH, Liechtenstein
• Giuridico: diritto del Liechtenstein.
• Tecnico: DNSSEC; infrastruttura professionale collegata all’ecosistema SWITCH.
• Valutazione: ECCELLENTE.
• .dk — Punktum dk, Danimarca
• Giuridico: diritto danese.
• Tecnico: DNSSEC; infrastruttura DNS stabile e ridondata.
• Valutazione: MOLTO BUONO.
• .be — DNS Belgium, Belgio
• Giuridico: diritto belga/europeo.
• Tecnico: DNSSEC; infrastruttura DNS robusta e ben gestita.
• Valutazione: MOLTO BUONO.
• .fr — AFNIC, Francia
• Giuridico: diritto francese/europeo.
• Tecnico: DNSSEC; infrastruttura DNS molto matura e distribuita.
• Valutazione: ECCELLENTE.
• .es — Red.es, Spagna
• Giuridico: diritto spagnolo/europeo.
• Tecnico: DNSSEC; infrastruttura nazionale solida.
• Valutazione: MOLTO BUONO.
• .pt — .PT, Portogallo
• Giuridico: diritto portoghese/europeo.
• Tecnico: DNSSEC; infrastruttura DNS moderna e ridondata.
• Valutazione: MOLTO BUONO.
• .cz — CZ.NIC, Repubblica Ceca
• Giuridico: diritto ceco/europeo.
• Tecnico: DNSSEC; registry tecnicamente molto avanzato; forte cultura DNS e sicurezza.
• Valutazione: ECCELLENTE.
• .sk — SK-NIC, Slovacchia
• Giuridico: diritto slovacco/europeo.
• Tecnico: DNSSEC; infrastruttura DNS stabile.
• Valutazione: BUONO.
• .pl — NASK, Polonia
• Giuridico: diritto polacco/europeo.
• Tecnico: DNSSEC; registry nazionale maturo e infrastruttura robusta.
• Valutazione: ECCELLENTE.
• .ee — Estonian Internet Foundation, Estonia
• Giuridico: diritto estone/europeo.
• Tecnico: DNSSEC; infrastruttura moderna e orientata alla resilienza.
• Valutazione: MOLTO BUONO.
• .lv — NIC.LV, Lettonia
• Giuridico: diritto lettone/europeo.
• Tecnico: DNSSEC; infrastruttura stabile.
• Valutazione: BUONO.
• .lt — DOMREG / Kaunas University of Technology, Lituania
• Giuridico: diritto lituano/europeo.
• Tecnico: DNSSEC; registry accademico/nazionale maturo.
• Valutazione: MOLTO BUONO.
• .ie — .IE, Irlanda
• Giuridico: diritto irlandese/europeo.
• Tecnico: DNSSEC; infrastruttura DNS professionale e ridondata.
• Valutazione: MOLTO BUONO.
• .gr — FORTH / Grecia
• Giuridico: diritto greco/europeo.
• Tecnico: DNSSEC; infrastruttura nazionale consolidata.
• Valutazione: BUONO.
• .hr — CARNET, Croazia
• Giuridico: diritto croato/europeo.
• Tecnico: DNSSEC; infrastruttura nazionale stabile.
• Valutazione: BUONO.
• .si — ARNES, Slovenia
• Giuridico: diritto sloveno/europeo.
• Tecnico: DNSSEC; registry accademico/nazionale affidabile.
• Valutazione: MOLTO BUONO.
• .ro — RoTLD, Romania
• Giuridico: diritto rumeno/europeo.
• Tecnico: DNSSEC; infrastruttura nazionale matura.
• Valutazione: BUONO.
• .bg — Register.BG, Bulgaria
• Giuridico: diritto bulgaro/europeo.
• Tecnico: DNSSEC; infrastruttura DNS nazionale.
• Valutazione: BUONO.
• .lu — RESTENA, Lussemburgo
• Giuridico: diritto lussemburghese/europeo.
• Tecnico: DNSSEC; infrastruttura solida e professionale.
• Valutazione: MOLTO BUONO.*

Io, personalmente, andrei con .eu.

Non perché sia magicamente immune da pressioni esterne, ma perché cambia il livello dello scontro. Se gli Stati Uniti facessero quello che fanno spesso — pressioni diplomatiche, minacce, richieste di collaborazione — non starebbero più parlando con una singola azienda o con un singolo paese.

Andrebbero a provocare direttamente l'Unione Europea, proprio sul terreno della sovranità digitale, cioè su una politica che Bruxelles sostiene ormai apertamente.

Un singolo paese europeo può anche piegarsi. L'intera UE avrebbe molti più problemi politici a farlo, perché significherebbe ammettere che tutta la retorica sulla sovranità digitale vale soltanto finché Washington non alza il telefono.

Sapete bene che io non parteggio normalmente per gruppi come Autistici/Inventati. Ma qui è irrilevante: il problema riguarda tutti.

Riguarda chi gestisce servizi Internet, chi possiede domini, e soprattutto riguarda Internet stessa come infrastruttura globale.

Ho parlato spesso di splinternet. Forse è arrivato il momento di smettere di chiedersi se accadrà, e cominciare a chiedersi quanto sia ormai inevitabile.

Perché quando una crescita appare sproporzionata perfino rispetto alla razionalità finanziaria — che già di per sé non è esattamente sinonimo di razionalità — diventa difficile capire quale evento, o quale semplice cambiamento di aspettative, possa essere sufficiente a invertirla.

Ma dal punto di vista del pinco pallino che ha investito in Borsa i soldi della pensione, il problema non è tanto sapere quando e perché scoppierà la bolla. Il problema vero è riuscire a individuare dei predittori: segnali osservabili che dicano che qualcosa sta cambiando prima che il mercato se ne accorga tutto insieme.

Un pochino come nell'Apocalisse, dove prima della fine dell'universo intero compaiono comunque dei segnali abbastanza vistosi: angeli che suonano la tromba, il mare che diventa sangue, stelle che cadono dal cielo e altra discreta segnaletica di emergenza cosmica.

Così proverò a fare un esercizio: chiedermi quali potrebbero essere, nel caso della bolla dell'AI, i segni della fine. Non necessariamente le cause dello scoppio, e nemmeno una data precisa, ma quei fenomeni che potrebbero funzionare da predittori, indicando che il meccanismo che sostiene la crescita sta cominciando a rompersi.

Per arrivare ai segni del disastro, però, occorre prima capire bene quali siano le cose che costano e quali, invece, siano i prodotti che queste aziende riescono effettivamente a vendere.

Il fatto che oggi molte aziende del settore non siano in utile, preso da solo, conta relativamente poco. Una società può continuare per anni a bruciare capitale se gli investitori ritengono credibile la crescita futura, o semplicemente se credono che qualcun altro continuerà a finanziarla.

Twitter, per esempio, è stata fondata nel 2006 e ha chiuso il primo intero esercizio annuale in utile soltanto nel 2018; nel quarto trimestre del 2017 aveva raggiunto per la prima volta la profittabilità GAAP trimestrale. Quindi non proprio quindici anni, ma circa dodici anni dalla fondazione al primo bilancio annuale positivo. Nel frattempo è stata finanziata prima dal venture capital e, dopo l'IPO del 2013, anche dal mercato azionario.

Essere in perdita, quindi, non è di per sé il segnale che una bolla stia per scoppiare. La domanda interessante è un'altra: che cosa deve continuare a succedere affinché qualcuno continui a pagare quei costi?

Proviamo a vedere, a grandi linee, come funziona un'azienda di AI. Il design del modello, sulla scala del loro cash flow, non è necessariamente la cosa che costa di più. La parte realmente costosa è la costruzione del modello: raccogliere e preparare enormi quantità di dati, addestrarlo, ripetere gli esperimenti, scartare quelli che non funzionano e soprattutto mettere a disposizione le risorse hardware necessarie. E questo costo, cosa importante, non cresce in maniera lineare rispetto al miglioramento ottenuto. Proviamo a ragionarci con un esempio molto più semplice.

Mettiamo di dover fare una misura, e di voler misurare qualcosa lungo 20 centimetri. Quando faremo la misura, a meno di non possedere strumenti infinitamente precisi — che non esistono — otterremo qualcosa del tipo:

20 cm ± X

dove X rappresenta l'incertezza della misura.

Quanto è grande questo X?

Se continuiamo a ripetere la misura, assumendo di aver eliminato o controllato gli errori sistematici e che gli errori residui siano indipendenti e casuali, l'incertezza statistica della media diminuisce approssimativamente come l'inverso della radice quadrata del numero delle misure:

X ~ 1 / √N

Ed è qui che comincia il problema.

Per dimezzare X, cioè l'errore, non basta raddoppiare il numero delle misure: dobbiamo quadruplicarlo. Se vogliamo ridurre l'errore a un terzo, dobbiamo idealmente fare nove volte il numero delle misure. Per ridurlo a un decimo, cento volte.

Non è quindi una funzione ERF: la error function compare nella matematica della distribuzione normale, ma la legge che ci interessa qui è la classica dipendenza 1/√N dell'errore statistico.

Il punto però rimane esattamente quello: ottenere un miglioramento progressivamente più piccolo può richiedere una quantità di lavoro progressivamente molto più grande.

Adesso supponiamo, per semplicità, che per un certo prompt esista una “risposta perfetta”.

Se chiediamo a una AI quanto sia lungo qualcosa, e immaginiamo che esista una risposta esatta, possiamo pensare alla risposta prodotta dal modello come a qualcosa che si trova a una certa distanza X dalla risposta ideale. Questa distanza può rappresentare un errore numerico, una discrepanza semantica, una risposta incompleta o semplicemente una qualità inferiore a quella che consideriamo perfetta.

A questo punto viene spontaneo pensare che, per ridurre X, occorra aumentare la quantità e soprattutto la qualità dei dati usati durante l'addestramento, oltre alla capacità del modello e al calcolo impiegato.

Qui però bisogna stare attenti all'analogia con gli strumenti di misura.

Per una misura fisica ripetuta, sotto ipotesi abbastanza precise, l'errore statistico può diminuire come 1/sqrt(N). Per i modelli linguistici non esiste invece una legge universale che dica che la distanza dalla “risposta perfetta” debba diminuire esattamente nello stesso modo.

Quello che si osserva empiricamente sono piuttosto delle scaling laws: aumentando dati, parametri e calcolo, la loss del modello tende a diminuire secondo leggi di potenza. In forma molto semplificata: errore ~ N^(-alpha)dove N può rappresentare la quantità di dati, il compute o qualche altra risorsa, e alpha è normalmente minore di uno.

Il risultato pratico è comunque quello che ci interessa: rendimenti sempre decrescenti.

Per ottenere un miglioramento sempre più piccolo bisogna spendere quantità sempre maggiori (E NON PROPORZIONALI) di dati e di calcolo.

Ed è qui che entra in gioco la natura probabilistica dei modelli linguistici. Un LLM non possiede una tabella contenente “la risposta corretta”: durante la generazione produce, passo dopo passo, una distribuzione di probabilità sui token possibili e sceglie da quella distribuzione secondo il metodo di decoding utilizzato.

Potete immaginarlo come una specie di paradosso di Zenone applicato all'AI: più ci si avvicina alla risposta perfetta, più ogni ulteriore miglioramento diventa piccolo, mentre il costo necessario per ottenerlo continua ad aumentare.

I passi verso l'obiettivo diventano sempre più brevi, ma ciascun passo richiede più dati, più calcolo, più energia e più hardware del precedente.

Non perché esista davvero una legge di Zenone dentro un LLM, naturalmente, ma perché le scaling laws osservate mostrano proprio questo genere di rendimento decrescente: migliorare ancora è possibile, ma ogni incremento marginale di qualità tende a costare sempre di più.

Quindi, punto primo: la parte più costosa per creare un nuovo modello di frontiera è normalmente l'addestramento che lo produce, non la singola esecuzione dell'LLM.

Qui però occorre distinguere bene due cose. Il training concentra enormi costi in una fase relativamente breve: GPU, energia, dati, esperimenti, fine-tuning, valutazioni. L'inference, cioè l'uso del modello già addestrato, costa molto meno per singola richiesta, ma può diventare a sua volta una voce enorme quando viene moltiplicata per milioni o miliardi di richieste. Quindi non è affatto gratuita: semplicemente ha una struttura di costo diversa.

E, soprattutto, nessuno paga per “possedere un LLM” in astratto. Si paga per usarlo.

Lo si paga sotto forma di abbonamento a un chatbot, consumo di API, generazione di testo, immagini o codice, oppure come componente di un agente che svolge qualche attività concreta. In altre parole, il modello è l'infrastruttura; il prodotto venduto è quasi sempre l'accesso alla sua capacità di produrre qualcosa.

Ed è questa distinzione che ci interessa, perché da una parte abbiamo costi enormi per costruire e migliorare il modello, e dall'altra dobbiamo chiederci quanto denaro il suo utilizzo riesca effettivamente a generare.

L'idea che sta alla base di tutto, quindi, è abbastanza semplice: le aziende spendono un botto per produrre i modelli, cosa che richiede enormi quantità di calcolo e quindi infrastrutture HPC gigantesche; dopodiché cercano di recuperare quei costi vendendo l'accesso al modello.

E anche qui l'hardware torna immediatamente in scena, perché non basta costruire il modello una volta sola: bisogna poi farlo girare per milioni di utenti, continuamente. Quindi servono altri data center, altre GPU, altra memoria, altra rete e altra energia per sostenere l'inference, cioè il servizio vero e proprio che viene venduto.

In forma molto brutale:

Uscite: hardware HPC, energia, rete e infrastruttura per addestrare i modelli e per farli girare. Entrate: i soldi che gli utenti spendono per usare quei modelli, direttamente o indirettamente, spesso attraverso API fatturate a token, abbonamenti ai chatbot o servizi agentici.

La semplificazione “si vendono token” non vale per ogni prodotto commerciale, perché molti servizi vengono venduti a forfait o in abbonamento. Ma dal punto di vista industriale il succo non cambia: l'azienda investe capitale in capacità di calcolo e cerca poi di monetizzare il consumo di quella capacità.

E siccome ci stiamo finalmente avvicinando ai predittori, adesso possiamo chiederci quale sia il pericolo mortale di questo modello economico. Il pericolo è abbastanza semplice: che persone e aziende decidano di far girare i modelli in casa, o, nel gergo aziendale, on premise.

Questo rischio nasce dal fatto che i modelli nuovi arrivano prima dei servizi costruiti sopra di essi. Se un modello disponibile oggi è già abbastanza buono per il lavoro quotidiano di un programmatore, di un'azienda o di un reparto tecnico, allora quell'utente potrebbe semplicemente decidere che non gli serve inseguire ogni nuovo upgrade.

A quel punto può cominciare a fare un altro ragionamento: invece di continuare a pagare token per sempre, compro l'hardware una volta sola e faccio girare il modello per conto mio.

E qui il rischio diventa concreto, perché esistono ormai molti modelli open-weight, cioè modelli dei quali è possibile scaricare direttamente i pesi ed eseguire l'inference sulla propria infrastruttura. Molti dei protagonisti di questa tendenza sono cinesi — per esempio le famiglie Qwen e DeepSeek — ma la pressione competitiva ha spinto anche aziende occidentali nella stessa direzione. OpenAI stessa distribuisce oggi modelli gpt-oss scaricabili, eseguibili localmente e utilizzabili anche su infrastruttura privata.

Questo non significa che tutti questi modelli siano “gratis” in senso assoluto: l'hardware, l'energia e la gestione continuano a costare. Ma significa che il produttore del modello non viene necessariamente pagato ogni volta che il modello viene usato.

Ed è precisamente questo il punto pericoloso.

Perché se la qualità di un modello locale diventa “abbastanza buona”, allora il cliente può smettere di comprare continuamente inference dal produttore e trasformare una spesa ricorrente in un investimento una tantum in hardware.

E da qui, arriviamo al discorso “i segni della fine”.

E da qui arriviamo finalmente al discorso dei segni della fine.

Uno dei motivi per cui oggi persone e aziende non si stanno semplicemente installando l'AI on premise è che l'hardware necessario costa cifre esorbitanti. Ma costa così tanto anche perché una parte enorme della capacità produttiva disponibile viene assorbita dalla costruzione dei data center per l'AI.

E qui bisogna chiarire bene una cosa: non funziona come quando andate in un negozio e comprate quello che trovate sullo scaffale.

Non è che Microsoft, Google, Meta o OpenAI vadano da NVIDIA, SK Hynix o TSMC e dicano: «Non è che avete per caso un miliardo di chip in magazzino?».

No.

Quei chip devono ancora essere fabbricati. E le fabbriche hanno una capacità finita: numero di wafer lavorabili, linee produttive, packaging avanzato, disponibilità di HBM, macchinari, energia, personale. Oggi, peraltro, proprio memoria HBM e capacità produttiva avanzata continuano a essere colli di bottiglia importanti; SK Hynix dichiara una domanda superiore alla propria capacità produttiva, mentre TSMC continua ad aumentare gli investimenti proprio per inseguire una domanda AI che descrive come strutturale e pluriennale.

Per questo è più corretto dire che le grandi aziende dell'AI prenotano capacità produttiva futura.

Si assicurano allocazioni, firmano contratti, fanno ordini con largo anticipo e, in sostanza, si mettono in coda davanti agli altri compratori. NVIDIA stessa deve assicurarsi in anticipo capacità sufficiente presso la propria supply chain per sostenere la crescita prevista.

Quindi quando diciamo che «le aziende di AI stanno comprando tutte le GPU e tutta la memoria», stiamo usando una scorciatoia linguistica. Più precisamente, stanno occupando una quota enorme della produzione futura.

Le aziende di AI stanno quindi prenotando, ma non necessariamente comprando nell'immediato, enormi quantità di chip.

La distinzione è importante. Una parte della capacità produttiva futura viene impegnata con ordini, accordi di fornitura, prepagamenti o contratti pluriennali: in pratica, si riserva posto nella coda industriale. Il denaro può anche cominciare a muoversi prima, ma i chip fisici ancora non esistono.

Dire semplicemente che “li hanno comprati” dà l'idea di magazzini già pieni di GPU pronte all'uso. In realtà, una parte sostanziale di quella domanda è domanda futura già impegnata sulla capacità produttiva futura.

Ed è proprio questo che ci interessa, perché una prenotazione può essere un segnale economico molto diverso da un chip già prodotto, consegnato e messo in servizio.

E questa differenza, come vedremo, è importante.

Questo meccanismo — cioè il fatto che una parte enorme delle supply chain sia già oberata di prenotazioni — contribuisce a tenere molto alti i prezzi di memorie, acceleratori e GPU.

Per esempio, io posso già far girare localmente un modello più che sufficiente per le mie necessità: editing, generazione di immagini e anche programmazione di software OSS. Il problema è che la macchinetta che un anno fa avrei potuto immaginare intorno ai 1000 euro oggi, a parità di classe di hardware utile, può facilmente costarne 2000 o 2500.

Niente di incredibile, in assoluto. Ma quando il prezzo più che raddoppia, l'acquisto smette di essere una curiosità tecnica e diventa una decisione economica vera.

E questo gigantesco aumento dei prezzi scoraggia persone e aziende dal costruirsi l'AI in casa.

Anche perché il ragionamento spontaneo è sempre lo stesso:

«Sì, ma l'anno prossimo con questo hardware non riuscirò più a far girare l'ultimo modello.»

Vero.

Ma questo ragionamento ha senso soltanto finché si presume che l'ultimo modello sia sempre indispensabile.

Se invece i modelli progrediscono a passi sempre più piccoli — alla Zenone, per continuare con la metafora — allora a un certo punto qualcuno può perfettamente dire:

«Ehi. Fissiamo che il modello X ci basta. Fa già quello che ci serve, e continuerà a bastarci per i progetti che abbiamo in coda almeno per i prossimi tre anni.»

A quel punto il problema cambia completamente.

Non si tratta più di inseguire ogni generazione successiva, ma di fare un normale calcolo industriale: conosciamo il costo dell'hardware, conosciamo quanto spendiamo oggi in API o abbonamenti, possiamo stimare il ROI e il break-even.

E allora la domanda diventa inevitabile: possiamo pensare di farcelo in casa?

E qui siamo arrivati al nostro primo predittore.

Se il ragionamento fatto finora è corretto, allora uno dei segnali che potrebbero precedere lo scoppio della bolla sarà un calo generalizzato e persistente del prezzo di memorie, GPU e acceleratori, fino a riportarli verso livelli più vicini a quelli precedenti alla corsa all'AI.

Non basta, naturalmente, vedere una scheda video scendere di prezzo del 20% per gridare all'Apocalisse. I prezzi dell'hardware possono diminuire per moltissime ragioni: aumento della capacità produttiva, miglioramento dei processi industriali, nuove generazioni di chip, concorrenza, normalizzazione delle scorte.

Il segnale interessante sarebbe un altro: un calo ampio, contemporaneo e non spiegabile soltanto con il normale progresso tecnologico, specialmente se accompagnato da una diminuzione dei tempi di consegna e da una maggiore disponibilità di memoria e acceleratori.

Perché significherebbe che qualcosa sta cambiando nella coda.

Le aziende di AI stanno prenotando meno capacità, oppure stanno ridimensionando gli ordini futuri, oppure l'offerta sta finalmente raggiungendo — o superando — quella domanda gigantesca che fino a quel momento aveva tenuto la supply chain sotto pressione.

E a quel punto succederebbe anche la cosa più pericolosa per chi vende inference: l'hardware necessario per far girare i modelli localmente comincerebbe a costare molto meno.

Il primo angelo, insomma, potrebbe non avere una tromba.

Potrebbe avere un listino prezzi.

Questo calo di prezzo potrebbe essere sia la causa dello scoppio della bolla, sia una conseguenza.

Potrebbe esserne la causa se il calo dei prezzi fosse dovuto all'entrata in produzione di nuove fabbriche, nuove linee e maggiore capacità produttiva. In quel caso diventerebbe progressivamente più economico costruirsi l'AI in casa, facendo girare modelli pubblici o open-weight su hardware proprio.

E allora le grandi aziende di AI rischierebbero di rimanere con il cerino in mano: continuerebbero a spendere quantità immense di denaro per progettare, addestrare e distribuire modelli sempre nuovi, mentre una parte crescente degli utenti potrebbe smettere di pagarli secondo il modello ad abbonamento o a consumo.

In altre parole, il problema non sarebbe che il modello non funziona. Il problema sarebbe che funziona abbastanza bene anche senza continuare a pagare chi lo ha prodotto.

Ma il calo dei prezzi potrebbe anche essere una conseguenza.

Se a un certo punto il cash flow non fosse più sufficiente a sostenere la corsa agli investimenti, le aziende comincerebbero inevitabilmente a ridurre gli ordini e le prenotazioni di hardware futuro. Per quanto una dirigenza possa essere ottimista, prima o poi arrivano i financial controller, i limiti di spesa, il costo del capitale e qualcuno che dice che oltre una certa cifra non si va.

A quel punto la pressione sulla supply chain diminuirebbe, le code si accorcerebbero e i prezzi di memoria, GPU, acceleratori e storage potrebbero cominciare a scendere.

Quindi il rapporto causale può andare in entrambe le direzioni.

Ma ai fini del nostro esercizio importa relativamente poco.

Che sia la causa o che sia la conseguenza, rimane un predittore.

Se osservate nel tempo i prezzi di memorie, GPU e storage, e vedete un calo sensibile, generalizzato e persistente, accompagnato magari da disponibilità crescente e tempi di consegna più brevi, allora significa che qualcosa di importante sta cambiando nell'economia della corsa all'AI. A quel punto, almeno secondo questa ipotesi, sapete che la festa sta finendo. Quindi, parlando di predittori, direi questo:

Tenete sott'occhio i prezzi dell'hardware

Proprio di quell'hardware i cui prezzi sono esplosi insieme alla corsa all'AI. Se memorie, GPU, acceleratori e storage cominciano a calare sensibilmente di prezzo, e non per una promozione momentanea o per il normale ricambio generazionale, ma in maniera ampia e persistente, allora il segnale diventa interessante. Perché può voler dire che la domanda futura si sta sgonfiando, che le prenotazioni stanno diminuendo, che la capacità produttiva sta raggiungendo la domanda oppure che il modello economico sta iniziando a perdere pressione.

La festa è finita.

E da quel momento...

FUGGITE, SCIOCCHI!!!!

Il problema è che Twitter — e finalmente ve ne siete accorti — è un pozzo di tossicità.

E non soltanto perché è centralizzato, oppure perché a un certo punto è finito nelle mani di questo o quell'altro proprietario. Il problema è più profondo: ci sono MOLTE cose nel design stesso di Twitter, nel modo in cui sono costruite le interazioni, che spingono gli utenti verso la tossicità.

Se quindi prendete Twitter, togliete l'azienda centrale e distribuite il sistema su migliaia di server, avete certamente risolto un problema molto importante.

Ma non avete necessariamente risolto gli altri.

Così, ho deciso che Xenomorph continuerà a federare normalmente con il resto del Fediverso e manterrà, grosso modo, lo stesso insieme di funzioni essenziali di snac, al quale si ispira per filosofia di semplicità e leggerezza.

Ma non sarà semplicemente un altro snac scritto in Ada.

L'idea è precisamente quella di approfittare del fatto che sto scrivendo tutto da zero per modificare alcune delle scelte che, a mio avviso, il Fediverso ha ereditato quasi automaticamente dal modello Twitter.

Perché se il problema è anche nel design delle interazioni, allora non basta cambiare il protocollo di trasporto, decentralizzare i server o distribuire la moderazione.

Bisogna cambiare anche come gli utenti vengono spinti a comportarsi.

Ed è qui che cominciano le modifiche.

Il meccanismo del blocco istanza

È stato pensato, ovviamente, con una delle idee più tossiche del mondo in testa: la cancel culture.

Non intendo dire che storicamente il domain block sia nato dalla cancel culture: tecnicamente nasce da un'esigenza reale di moderazione, cioè poter isolare in blocco un server che produce spam, molestie, contenuti illegali o comunque una quantità di problemi tale da rendere assurdo intervenire utente per utente. Mastodon, infatti, consente agli amministratori di limitare o sospendere interi domini proprio per questo motivo.

Il problema è il modello mentale che ne deriva.

Perché appena mettete nelle mani di qualcuno un grosso pulsante con scritto, metaforicamente, “cancella quella gente dal mio universo”, state anche creando un ruolo che attira tutti gli aspiranti sceriffi del mondo: gente che vuole diventare admin anche per il piacere di poter bloccare Tizio, Caio, Sempronio e magari l'intera città dalla quale provengono, sentendosi nel frattempo investita di un qualche potere morale.

È una feature necessaria in certi casi. Ma è anche una feature potenzialmente tossica.

Xenomorph, invece, prova a togliere il più possibile questa dinamica dalle mani dell'admin.

Ha un proprio meccanismo automatico di rilevamento: se scopre che un'istanza remota lo ha bloccato, reagisce bloccandola a sua volta. Non per ripicca, ma perché continuare a tentare di federare con qualcuno che ha già deciso di non ricevere le vostre attività significa semplicemente sprecare traffico, code, retry e risorse.

La cosa interessante è che il blocco non viene trattato come una sentenza eterna.

Se l'istanza remota ricomincia successivamente a mandare attività valide, Xenomorph interpreta il fatto come un segnale che la federazione è nuovamente possibile e rimuove automaticamente il proprio blocco.

Quindi niente liste nere da amministrare religiosamente, niente vendette che sopravvivono per anni, niente archeologia diplomatica per capire perché nel 2024 qualcuno abbia bloccato qualcun altro.

Soprattutto: niente peso per l'admin.

Va tutto in automatico.

Poi esiste naturalmente il caso eccezionale. Quello nel quale non state semplicemente ricevendo un block remoto, ma avete davvero bisogno di interrompere immediatamente ogni rapporto con un'istanza: per esempio perché sta distribuendo materiale illegale, oppure perché sta causando un problema abbastanza grave da non poter aspettare i normali automatismi.

In quel caso esiste il pulsante Nuke.

Il nome è intenzionale: deve essere perfettamente chiaro che non state facendo ordinaria amministrazione. State usando l'opzione nucleare.

È disponibile soltanto all'admin.

Ma anche dal Nuke si può uscire.

Perché un sistema di moderazione che sa soltanto accumulare blocchi, senza avere anche un meccanismo per dimenticarli quando non servono più, prima o poi non diventa più sicuro.

Diventa semplicemente fossile.

Il blocco degli utenti remoti

Per molti utenti, il blocco finisce per diventare un altro meccanismo tossico: quello che permette di pensare di aver zittito qualcuno.

Solo che non sentire più qualcuno e averlo zittito sono due cose completamente diverse.

Quella persona continua a parlare. Parla con gli altri, scrive, viene letta, continua tranquillamente a esistere. Semplicemente, voi non la sentite più.

Pensare il contrario è un meccanismo abbastanza infantile: è il bambino che si tappa le orecchie e comincia a dire lalalala, non ti sento.

Il problema è che, quando questa cosa viene trasformata in una funzione dell'interfaccia, rischia di nutrire a dismisura proprio quella sensazione: io ho premuto il bottone, quindi tu sei sparito. Una piccola gratificazione di potere che, in realtà, non corrisponde affatto a quello che sta succedendo.

Xenomorph mantiene comunque il blocco degli utenti. ActivityPub prevede infatti l'attività Block, e Mastodon la usa anche tra server: quando un utente locale blocca un account remoto, può inviare al server remoto una Block activity.

Curiosamente, lo stesso standard ActivityPub raccomanda invece che queste attività non vengano normalmente consegnate all'oggetto del blocco nel caso server-to-server; Mastodon ha scelto di farlo ugualmente come estensione del comportamento federato.

Ed è proprio questa informazione che Xenomorph può sfruttare.

Quando qualcuno vi blocca e il server remoto comunica il Block, Xenomorph se ne accorge. Internamente esiste anche una notifica dell'evento, sebbene normalmente non ci sia alcun motivo per sbattervela in faccia: sapere che Tizio vi ha bloccato, nella maggior parte dei casi, non migliora in alcun modo la vostra giornata.

Xenomorph semplicemente blocca di rimando.

Non come vendetta, ma come conseguenza tecnica: se quell'account ha dichiarato di non voler più interagire con voi, non c'è una particolare ragione per continuare a spendere risorse nel tentativo di interagire con lui.

E anche questo blocco non deve necessariamente diventare eterno.

Se successivamente arriva un Undo Block, oppure l'account remoto torna in una condizione nella quale l'interazione è nuovamente valida secondo le regole di Xenomorph, il blocco automatico può essere rimosso. Mastodon stesso prevede esplicitamente Undo anche per annullare un precedente Block.

Il blocco manuale continua quindi a esistere, perché ovviamente ci sono situazioni nelle quali serve davvero. Anche Mastodon distingue il semplice mute, che serve sostanzialmente a non vedere qualcuno, dal block, che modifica anche la relazione tra i due account e impedisce follow e altre interazioni.

Ma in Xenomorph il blocco manuale dovrebbe essere soprattutto uno strumento per le situazioni nelle quali siete voi ad avere bisogno di interrompere un rapporto.

Per tutti quelli che invece decidono di bloccare voi, non c'è bisogno di trasformare la cosa in un piccolo evento diplomatico.

Non dovete controllare chi vi ha bloccato.

Non dovete compilare liste.

Non dovete ricambiare manualmente.

Non dovete nemmeno interessarvene.

Se non volete occuparvi di chi vi blocca, semplicemente non fatelo.

Lasciate fare a Xenomorph.

Niente stress, nemmeno qui.

Il numero di follower

Poi c'è il numero di follower.

È la continuazione digitale del vecchio: sono il ragazzo o la ragazza più popolare del liceo. Un meccanismo competitivo, tossico e abbastanza bullistico, molto da scuola superiore americana: la popolarità trasformata in una quantità numerica, visibile a tutti, e quindi utilizzabile come misura del valore sociale di una persona.

A che serve?

A monetizzare la popolarità? A stabilire quanto vale un influencer? A vendere pubblicità?

Perfetto. Allora nel Fediverso non serve.

Il problema non è nemmeno teorico. Abbiamo avuto esempi quasi caricaturali di questo modo di ragionare.

Nel 2012 Maurizio Gasparri rispose a un utente che lo criticava facendo notare che aveva soltanto 48 follower: prima «Seguito da 48, imbarazzante», poi «Con 48 non arrivi neanche all'angolo», e infine il magnifico «Non sei nessuno». Il

Corriere dell'epoca riassunse la faccenda parlando, molto appropriatamente, di Twitter «tanto al peso».

Per la serie: io so' io, e tu non sei un cazzo.

Gasparri.

Ed è precisamente questo il problema del contatore pubblico. Non misura soltanto una proprietà dell'account: finisce inevitabilmente per diventare una gerarchia. Uno ne ha cento, uno diecimila, uno un milione, e improvvisamente sembra perfettamente naturale pensare che il terzo conti più del primo.

In Xenomorph, quindi, il proprietario dell'account può vedere il proprio numero reale di follower quando è autenticato.

Le istanze federate, invece, vedranno sempre un numero falso e volutamente spropositato.

Non serve a simulare popolarità. Serve esattamente al contrario: a rendere il numero inutilizzabile come segnale di status.

Se ogni account dichiara di avere una quantità assurda di follower, il dato smette di servire per costruire classifiche, confronti, prestigio, ansia da prestazione e gerarchie sociali.

Quando tutti sono star, nessuno è una star.

E abbiamo eliminato un altro piccolo pezzo di liceo americano dal social network.

E con questo voglio dire una cosa.

Passando da un sistema centralizzato a uno federato avete risolto una parte del problema. Una parte importante, certamente: avete eliminato il singolo proprietario, il singolo algoritmo, il singolo centro di potere che può decidere per tutti.

Ma l'altra parte del problema è rimasta lì.

Perché è insita nel design del servizio.

Se conservate gli stessi meccanismi sociali, le stesse metriche di prestigio, gli stessi pulsanti pensati per gratificare il conflitto e la stessa architettura delle interazioni, la decentralizzazione da sola non basta.

Avete cambiato chi controlla il sistema, ma non necessariamente quello che il sistema induce le persone a fare.

E adesso io ho deciso di attaccare proprio quella parte.

Xenomorph si trova qui: https://git.keinpfusch.net/loweel/xenomorph

L'immagine Docker già pronta si trova qui:

https://hub.docker.com/r/loweel/xenomorph

Le istruzioni per l'installazione normale e per Docker/Docker Swarm si trovano direttamente nel repository, nei file INSTALL.md e DOCKER.md.

È già abbastanza stabile per ospitare pochi utenti e per essere usato sul serio. Il README lo definisce attualmente utilizzabile per test reali su piccole istanze e per il normale dogfooding, anche se è ancora in fase di hardening e non viene ancora presentato come scelta conservativa per istanze pubbliche lasciate incustodite.

Il resto verrà provandolo, rompendolo, correggendolo e soprattutto continuando a chiedersi una domanda che, secondo me, nel mondo dei social network viene fatta troppo raramente: questa feature serve davvero agli utenti, oppure serve soltanto a riprodurre un comportamento tossico che ci siamo abituati a considerare normale?

ENGLISH VERSION

Writing Xenomorph from scratch, in a niche programming language like SPARK/Ada, gave me quite a lot of satisfaction, but at the same time it gave me a degree of creative freedom that I simply never had with the other forks.

And so, at some point, I had to ask myself a question: OK, you can change whatever you want. But what?

What would you change, exactly, if you had to design some kind of Fediverse 2.0?

The interesting thing is that Mastodon was born, in 2016, explicitly in the microblogging world as a decentralized alternative to Twitter. Eugen Rochko was a Twitter user dissatisfied with the direction the platform was taking, and he described Mastodon precisely as a federated alternative to Twitter.

So saying that Mastodon imitated Twitter's model is basically correct, even though the purpose was specifically to eliminate centralized control over the system.

And it does that well.

The problem is that Twitter — and finally you noticed — is a cesspool of toxicity.

And not only because it is centralized, or because at some point it ended up in the hands of this or that owner.

The problem goes deeper: there are MANY things in Twitter's design itself, in the way interactions are constructed, that push users toward toxic behavior.

So if you take Twitter, remove the central corporation and distribute the system across thousands of servers, you have certainly solved one very important problem.

But you have not necessarily solved the others.

So I decided that Xenomorph will continue to federate normally with the rest of the Fediverse, and will retain roughly the same essential set of features as snac, which inspired its philosophy of simplicity and lightweight design.

But it will not simply be another snac written in Ada.

The whole point of writing everything from scratch is precisely that I can take advantage of this freedom to modify some of the choices that, in my opinion, the Fediverse inherited almost automatically from the Twitter model.

Because if part of the problem lies in the design of the interactions themselves, then changing the transport protocol, decentralizing the servers, or distributing moderation is not enough.

You also have to change the way users are encouraged to behave.

And this is where the changes begin.

Instance blocking

It was designed, obviously, with one of the most toxic ideas in the world in mind: cancel culture.

I am not saying that domain blocking historically originated from cancel culture. Technically, it exists because of a real moderation requirement: sometimes you need to isolate an entire server that produces spam, harassment, illegal material, or simply so many problems that dealing with its users one by one would be ridiculous.

Mastodon therefore allows administrators to limit or suspend entire domains for exactly this reason.

The problem is the mental model that comes with it.

Because the moment you put a big button into someone's hands which metaphorically says “delete those people from my universe”, you are also creating a role that attracts every aspiring sheriff on the planet: people who want to become admins partly for the pleasure of being able to block Tom, Dick, Harry, and perhaps the entire town they come from, while feeling invested with some kind of moral authority.

It is a necessary feature in some cases.

But it is also a potentially toxic feature.

Xenomorph instead tries to remove as much of this dynamic as possible from the administrator's hands.

It has its own automatic detection mechanism: if it discovers that a remote instance has blocked it, it reacts by blocking that instance in return.

Not out of spite, but because continuing to attempt federation with someone who has already decided not to receive your activities simply means wasting traffic, queues, retries, and resources.

The interesting part is that the block is not treated as an eternal sentence.

If the remote instance later starts sending valid activities again, Xenomorph interprets this as a signal that federation is possible again and automatically removes its own block.

So there are no blacklists to maintain religiously, no grudges surviving for years, no diplomatic archaeology required to discover why somebody blocked somebody else in 2024.

Most importantly: no administrative burden.

It all happens automatically.

Then, of course, there is the exceptional case.

The case where you are not merely receiving a remote block, but genuinely need to cut off all relations with an instance immediately: for example because it is distributing illegal material, or because it is causing a problem serious enough that you cannot wait for the normal automatic mechanisms.

In that case, there is the Nuke button.

The name is intentional: it must be perfectly clear that this is not routine administration.

You are using the nuclear option.

It is available only to the administrator.

But even a Nuke can be reversed.

Because a moderation system that only knows how to accumulate blocks, without also having a mechanism for forgetting them when they are no longer necessary, does not eventually become safer.

It simply becomes fossilized.

Blocking remote users

For many users, blocking eventually becomes another toxic mechanism: the mechanism that makes them think they have silenced someone.

Except that not hearing someone anymore and having silenced them are two completely different things.

That person keeps talking.

They talk to other people, they write, they are read, they continue to exist perfectly well.

You simply do not hear them anymore.

Thinking otherwise is a rather childish mechanism: it is the child putting their hands over their ears and going lalalala, I can't hear you.

The problem is that when this behavior is turned into an interface feature, it risks feeding exactly that feeling to absurd proportions:

I pressed the button, therefore you disappeared.

A tiny gratification of power which, in reality, does not correspond to what is actually happening.

Xenomorph still supports user blocking.

ActivityPub defines the Block activity, and Mastodon also uses it between servers: when a local user blocks a remote account, it can send a Block activity to the remote server.

Interestingly, the ActivityPub standard itself recommends that these activities not normally be delivered to the object of the block in server-to-server communication; Mastodon chose to do so anyway as an extension of federated behavior.

And this is precisely the information Xenomorph can use.

When somebody blocks you and the remote server communicates the Block, Xenomorph notices.

Internally, there is even a notification for the event, although there is normally no reason to shove it into your face: knowing that some random person blocked you will, in most cases, not improve your day in any way.

Xenomorph simply blocks them back.

Not as revenge, but as a technical consequence: if that account has declared that it no longer wants to interact with you, there is little reason to keep spending resources attempting to interact with it.

And this block does not need to become eternal either.

If an Undo Block later arrives, or the remote account returns to a state in which interaction is valid again according to Xenomorph's rules, the automatic block can be removed.

Mastodon itself explicitly supports Undo to reverse a previous Block.

Manual blocking therefore still exists, because obviously there are situations where it is genuinely necessary.

Mastodon itself distinguishes a simple mute, which essentially means that you no longer see somebody, from a block, which also changes the relationship between the two accounts and prevents follows and other interactions.

But in Xenomorph, manual blocking should mainly be a tool for situations in which you need to terminate a relationship.

For everyone who decides to block you instead, there is no reason to turn the event into a miniature diplomatic crisis.

You do not have to check who blocked you.

You do not have to maintain lists.

You do not have to retaliate manually.

You do not even have to care.

If you do not want to deal with people who block you, simply don't.

Let Xenomorph handle it.

No stress here either.

Follower counts

Then there is the follower count.

It is the digital continuation of the old:

I am the most popular boy or girl in high school.

A competitive, toxic, fairly bullying mechanism, very much in the style of an American high school: popularity transformed into a number, visible to everyone, and therefore usable as a measurement of somebody's social value.

What is it for?

Monetizing popularity?

Establishing how much an influencer is worth?

Selling advertising?

Perfect.

Then we do not need it in the Fediverse.

And this problem is not merely theoretical.

We have seen almost caricatural examples of this kind of thinking.

In 2012, Maurizio Gasparri replied to a user who criticized him by pointing out that the user had only 48 followers.

First:

“Followed by 48 people, embarrassing.”

Then:

“With 48 you don't even make it around the corner.”

And finally the magnificent:

“You are nobody.”

The Corriere at the time summarized the affair, quite appropriately, as Twitter being valued “by weight.”

Or, to quote the Roman expression:

io so' io, e tu non sei un cazzo.

Roughly:

I'm somebody, and you're fucking nobody.

Gasparri.

And that is precisely the problem with the public counter.

It does not merely measure a property of the account: inevitably, it becomes a hierarchy.

One person has a hundred followers, another has ten thousand, another has a million, and suddenly it seems perfectly natural to assume that the third person somehow matters more than the first.

So in Xenomorph, the owner of an account can see their real follower count while authenticated.

Federated instances, however, will always see a fake and deliberately ridiculous number.

The purpose is not to simulate popularity.

Quite the opposite: the purpose is to make the number useless as a status signal.

If every account claims to have an absurd number of followers, then the metric stops being useful for rankings, comparisons, prestige, performance anxiety, and social hierarchies.

When everybody is a star, nobody is a star.

And we have removed yet another small piece of American high school from the social network.

And with all this, I want to make one point.

By moving from a centralized system to a federated one, you solved part of the problem.

An important part, certainly: you removed the single owner, the single algorithm, the single center of power capable of deciding for everyone.

But the other part of the problem remained exactly where it was.

Because it is built into the design of the service.

If you preserve the same social mechanisms, the same prestige metrics, the same buttons designed to reward conflict, and the same architecture of interactions, decentralization alone is not enough.

You changed who controls the system.

You did not necessarily change what the system encourages people to do.

And now I have decided to attack precisely that part.

Xenomorph is here:

https://git.keinpfusch.net/loweel/xenomorph

The ready-to-use Docker image is here:

https://hub.docker.com/r/loweel/xenomorph

Instructions for normal installation and for Docker/Docker Swarm are available directly in the repository, in INSTALL.md and DOCKER.md.

It is already stable enough to host a small number of users and to be used for real.

The README currently describes it as suitable for real-world testing on small instances and normal dogfooding, although it is still undergoing hardening and is not yet presented as the conservative choice for unattended public instances.

The rest will come from trying it, breaking it, fixing it, and above all from continuing to ask a question which, in my opinion, is asked far too rarely in the world of social networks:

does this feature actually serve the users, or does it merely reproduce a toxic behavior that we have become accustomed to considering normal?

O, se preferite una formulazione meno brutale: è essenzialmente una questione liberal, nel significato americano del termine. Riguarda soprattutto battaglie culturali, linguistiche, identitarie e accademiche che appartengono alla tradizione politica liberal statunitense. Il problema è che tutto questo ha ben poco a che vedere con le tradizionali istanze socialdemocratiche europee: salari, lavoro, pensioni, sanità, scuola, casa, welfare, redistribuzione e sicurezza economica. Che sono poi, molto più concretamente, il genere di aspettative che una larga parte degli italiani continua ad avere quando pensa alla politica e, soprattutto, quando pensa a ciò che dovrebbe fare una sinistra.

Chi invoca la questione “woke”, invece, dimentica spesso due grossi convitati di pietra storici.

1. Quando una sinistra sposta il proprio baricentro dal conflitto sociale alla battaglia culturale, la destra radicale tende molto spesso a beneficiarne. Forse non sempre, ma il meccanismo ricorre con una regolarità abbastanza inquietante: quando la sinistra comincia a parlare soprattutto il linguaggio di minoranze politicizzate, ambienti universitari e avanguardie culturali, lasciando alla destra il linguaggio del lavoro, dell’ordine, della sicurezza e della vita quotidiana, la destra finisce spesso per raccogliere precisamente gli elettori che la sinistra ha smesso di rappresentare. E qualche volta, storicamente, il risultato è stato molto peggiore di una semplice sconfitta elettorale.
2. Il meccanismo del comunicare-tramite-fastidio può forse funzionare negli Stati Uniti, ma in Italia ha pochissimo senso, e storicamente ha quasi sempre funzionato male. L’idea è quella di ottenere visibilità provocando deliberatamente una reazione: modificare il linguaggio, violare convenzioni, imporre continuamente nuovi codici sociali, costringere l’interlocutore a prendere posizione. Negli Stati Uniti, dove politica, università, media e industria culturale sono fortemente intrecciati e dove la polarizzazione stessa produce pubblico, denaro e mobilitazione, una strategia del genere può perfino avere una sua razionalità.

In Italia, molto meno. Qui il fastidio raramente viene interpretato come pedagogia politica: viene interpretato come fastidio. E quando una forza politica dà l’impressione di voler educare, correggere o disciplinare linguisticamente persone che non le hanno chiesto nulla, queste persone non diventano automaticamente più progressiste. Molto più facilmente, smettono di ascoltarla oppure votano qualcun altro.

Certo, dopo anni di Trump, gli americani voterebbero forse per chiunque. Ma bisogna ricordarsi una caratteristica abbastanza curiosa dell’elettorato americano: le elezioni di Mid-Term vengono usate molto spesso per punire il presidente in carica, senza che questo significhi necessariamente volerlo cacciare due anni dopo.

Anzi, storicamente è quasi la norma che il partito del presidente perda terreno alle Mid-Term. È successo in 20 delle ultime 22 elezioni di metà mandato a partire dal 1938.

E gli esempi più recenti sono piuttosto istruttivi.

Nel 1982 i repubblicani di Reagan persero 26 seggi alla Camera. Due anni dopo Reagan venne rieletto travolgendo Walter Mondale e conquistando 49 Stati su 50.

Nel 1994 arrivò la famosa Republican Revolution di Newt Gingrich: i democratici di Bill Clinton persero 54 seggi alla Camera e il controllo del Congresso. Sembrava quasi il certificato di morte della presidenza Clinton. Nel 1996, invece, Clinton venne rieletto comodamente.

Nel 2010 arrivò un’altra catastrofe: i democratici di Obama persero 63 seggi alla Camera, una delle peggiori sconfitte di Mid-Term dell’epoca moderna. Due anni dopo Obama batté comunque Mitt Romney e rimase alla Casa Bianca.

Questo perché Mid-Term e presidenziali sono elezioni diverse, con elettorati parzialmente diversi e soprattutto con una funzione politica diversa. Alle Mid-Term l’americano può permettersi di dire al presidente: “mi stai sulle palle, adesso ti tolgo il Congresso”. Alle presidenziali, due anni dopo, la domanda diventa invece: “bene, ma tra questi due chi voglio alla Casa Bianca?”

Sono due giudizi che possono tranquillamente produrre risultati opposti.

Perciò una possibile sconfitta repubblicana alle Mid-Term non sarebbe, da sola, la dimostrazione dell’esistenza di una gigantesca conversione ideologica dell’America. Potrebbe essere semplicemente l’ennesima applicazione di un comportamento elettorale che gli americani praticano da decenni: bastonare il presidente a metà mandato, e poi eventualmente rieleggerlo.

Ma il problema, ripeto, rimane essenzialmente americano.

È negli Stati Uniti che stanno vincendo candidati definibili, dentro le coordinate politiche americane, come “woke”. È lì che questa categoria descrive realmente una corrente politica, un elettorato, un pezzo del mondo universitario e mediatico e, in alcuni casi, candidati che su quelle battaglie costruiscono una parte consistente della propria identità politica.

In Italia, semplicemente, non sta succedendo la stessa cosa.

Se anche volessimo forzare l’analogia e considerare le elezioni locali italiane come una specie di equivalente delle Mid-Term americane, bisognerebbe poi andare a vedere chi si presenta davvero alle elezioni. E di questa fantomatica ondata “woke”, tra i candidati italiani, se ne vede piuttosto poca.

E nemmeno la presidenza del PD fornisce un grande sostegno alla tesi. Elly Schlein è certamente molto più sensibile ai temi dei diritti civili rispetto a parecchi suoi predecessori, ma il resto del PD gioca un gioco diverso. Chi sarebbero “woke” del PD?

Se poi allarghiamo il cosiddetto “campo progressista” e ci mettiamo dentro anche il Movimento 5 Stelle, la faccenda diventa ancora più evidente. Le priorità che il M5S sta discutendo per il proprio programma riguardano sanità, lavoro, welfare, crescita economica, piccole imprese, disabilità, agricoltura, scuola, evasione fiscale, giustizia e politica europea. Potrà piacere o non piacere Conte, ma chiamare tutto questo “woke” richiede ormai una definizione della parola talmente larga da renderla praticamente inutile.

E quanto agli altri cespugli della sinistra italiana: se è lì che dovrebbe nascondersi la grande avanzata politica del woke, beh, auguri.

Perché a quel punto non stiamo più descrivendo una forza politica capace di conquistare il paese. Stiamo descrivendo qualche percentuale elettorale, qualche assemblea universitaria e parecchie discussioni sui giornali.

Che è precisamente il mio punto: abbiamo importato dagli Stati Uniti persino il dibattito sull’esistenza di un fenomeno politico che, nelle dimensioni nelle quali viene raccontato, in Italia praticamente non esiste.

E ripeto: praticamente.

E se pensate il contrario, allora facciamo una cosa semplice: indicatemi chi sarebbero, concretamente, i politici “woke” del PD.

Nomi e cognomi, possibilmente. Non impressioni, non aggettivi, non il fatto che qualcuno abbia partecipato a un Pride o abbia parlato di diritti civili.

Perché se dentro questa categoria ci mettete automaticamente anche Elly Schlein, allora abbiamo un problema molto semplice: la parola “woke” non significa più nulla.

Schlein può essere definita progressista, liberal sui diritti civili, ecologista, socialdemocratica su molte questioni economiche. Ma se basta questo per diventare “woke”, allora “woke” finisce per significare semplicemente “politico di sinistra che non piace alla destra”.

E a quel punto non è più una categoria politica: è un insulto generico.

E come se non bastasse, il woke tende spesso ad adottare una tattica politica che, storicamente, ha dimostrato di funzionare molto male da almeno un secolo: grosso modo dalla rivolta spartachista in poi.

Non sto dicendo che il woke sia marxista-leninista in senso dottrinario. Sto dicendo che il meccanismo politico della provocazione e dell’escalation assomiglia molto a quello della tradizione rivoluzionaria novecentesca.

Funziona più o meno così:

• Una parte comincia alzando deliberatamente il livello dello scontro. Il linguaggio diventa militante, aggressivo: lotta, rivoluzione, resistenza, combattere. Anche le manifestazioni cercano esplicitamente di essere provocatorie, disturbanti, oltraggiose.
• La controparte reagisce e comincia a usare un linguaggio altrettanto violento.
• A quel punto la tensione sale ancora, e questa sinistra scende in piazza nella maniera più provocatoria possibile.
• Prima o poi qualcuno, dall’altra parte, cede alla violenza.
• A quel punto si denuncia la violenza subita, si alza ulteriormente il volume dello scontro e contemporaneamente si presenta la propria provocazione come qualcosa di “allegro, colorato e pacifico”.
• Lo scontro verbale diventa scontro fisico.
• Qualcuno, prima o poi, ci lascia la pelle.
• E nella mitologia rivoluzionaria dovrebbe essere proprio quella la scintilla: il morto che rende intollerabile la situazione, mobilita le masse e fa partire qualcosa di molto più grande.

È uno schema che ha un precedente reale nella politica rivoluzionaria europea, ma bisogna stare attenti a non trasformarlo in una caricatura della Rivoluzione russa: i bolscevichi non abbatterono lo zar semplicemente irritando abbastanza la controparte. Nel 1917 c’erano una guerra mondiale, un esercito allo sfascio, carestie, una crisi dello Stato e una rivoluzione già in corso. Insomma, condizioni leggermente più sostanziose di qualche slogan particolarmente irritante.

Il problema è che, quando questo modello incontra una destra organizzata e disposta a usare una violenza molto superiore, il finale cambia completamente.

La rivolta berlinese del gennaio 1919 — quella tradizionalmente chiamata “spartachista”, anche se gli storici discutono quanto sia corretto attribuirne la direzione agli spartachisti — finì nel giro di pochi giorni sotto i colpi dell’esercito e dei Freikorps. Rosa Luxemburg e Karl Liebknecht vennero poi assassinati.

In Italia il fenomeno fu ancora più evidente nel passaggio dal Biennio Rosso al Biennio Nero. Scioperi, occupazioni e retorica rivoluzionaria non produssero la rivoluzione socialista: produssero anche una reazione organizzata, finanziata e armata, cioè lo squadrismo fascista, che attaccò sistematicamente sedi sindacali, cooperative, amministrazioni socialiste e organizzazioni della sinistra.

I fatti di Parma del 1922, a essere precisi, sono un caso particolarmente interessante proprio perché localmente andarono al contrario: gli Arditi del Popolo e gli abitanti dei quartieri popolari riuscirono a respingere migliaia di squadristi fascisti e costrinsero Italo Balbo alla ritirata. Fu una vittoria militare antifascista.

Solo che due mesi dopo ci fu la Marcia su Roma.

Ed è proprio questo il dettaglio istruttivo: puoi anche vincere la battaglia di strada. Non significa affatto che tu stia vincendo politicamente il paese.

La Spagna di Franco costituisce poi una prova a fortiori: quando la polarizzazione politica sfocia nella logica secondo cui lo scontro definitivo è ormai inevitabile, e dall’altra parte esistono esercito, milizie, apparati e forze politiche perfettamente disposte a combatterlo davvero, non è affatto garantito che la “scintilla rivoluzionaria” accenda la rivoluzione che avevi ordinato dal catalogo. Può benissimo accendere quella degli altri.

Nella realtà, quindi, il processo tende a rompersi circa a metà.

A un certo punto entra in campo una controparte che non considera più la provocazione un gioco comunicativo, e risponde con una violenza sproporzionata. Oppure intervengono gli apparati dello Stato con manganelli, arresti e repressione. In Italia repubblicana questo ruolo verrà svolto, in altri contesti e in un’altra epoca, anche dai reparti celeri della polizia: ma la Celere appartiene al dopoguerra e non va confusa con lo squadrismo fascista.

Ed è lì che le velleità rivoluzionarie normalmente finiscono: non nella presa del Palazzo d’Inverno, ma in qualche cassonetto incendiato, qualche vetrina sfondata, qualche ferito e una gigantesca caciara televisiva nella quale nessuno ricorda più quale fosse il problema iniziale.

Con un ulteriore dettaglio: quasi sempre, a quel punto, la maggioranza della popolazione non vede la “rivoluzione”.

Vede il caos.

E al potere vanno i fascisti, promettendo di riportare ordine.

Ci-cascano-sempre.

Su questo si innesta un altro problema grave del woke: la perdita del senso del ridicolo, o forse del patetico. Cioè l’incapacità di distinguere tra una rivendicazione ragionevole e una formulazione talmente esagerata da rendere ridicola perfino la rivendicazione originaria.

Per fare un esempio.

Un conto è dire che le persone trans non devono essere aggredite, picchiate o discriminate per strada. Su questo, direi, qualsiasi persona ragionevole può aderire senza bisogno di una teoria politica particolarmente sofisticata: non si picchiano le persone perché sono trans. Fine.

Un altro conto è sostenere che, siccome la biologia della riproduzione sessuata è complessa e presenta eccezioni, varianti dello sviluppo sessuale e casi che non rientrano perfettamente nelle classificazioni più semplici, allora la scienza direbbe che non esistono differenze tra maschi e femmine.

La scienza non dice questo.

La biologia distingue normalmente il sesso sulla base dell’organizzazione riproduttiva: produzione di gameti grandi o piccoli, insieme alle strutture anatomiche e fisiologiche collegate. Il fatto che esistano condizioni intersessuali, anomalie cromosomiche o variazioni dello sviluppo sessuale rende la realtà biologica più complessa; non rende inesistente la distinzione sessuale.

Allo stesso modo, bisogna stare molto attenti a frasi come “la scienza dice che i maschi possono rimanere gravidi”. Un uomo trans può certamente rimanere incinto se conserva utero e ovaie funzionanti: questo è un fatto medico. Ma questo non significa che un organismo maschile, nel significato biologico e riproduttivo del termine, abbia acquisito improvvisamente la capacità di gestare. Significa che stiamo usando “uomo” come categoria di identità di genere e “maschio” come categoria biologica, e che confondere deliberatamente i due piani produce soltanto rumore.

Sono due cose diverse.

Ed è precisamente qui che nasce il problema politico: una battaglia perfettamente comprensibile — non aggredite e non discriminate le persone trans — viene appesantita da affermazioni pseudoscientifiche o da giochi semantici che non sono necessari per sostenerla.

E quando per difendere una posizione moralmente semplice siete costretti a pretendere che la biologia dica qualcosa che non dice, non state rendendo più forte quella posizione.

La state rendendo più facile da ridicolizzare.

Anche il fatto che, sui temi più delicati, si tenda a estremizzare tutto è devastante.

Prendiamo l’aborto. La destra americana, su questo tema, riesce tranquillamente a produrre posizioni deliranti: divieti quasi assoluti, attacchi all’autonomia delle donne, legislazioni costruite come se una gravidanza fosse una questione astratta e non una faccenda medica, personale e spesso traumatica.

Ma proporre come alternativa culturale Lena Dunham che dice “I still haven’t had an abortion, but I wish I had” non è esattamente un modo meno delirante di affrontare la questione.

La frase è autentica. Dunham la pronunciò nel 2016, durante il suo podcast Women of the Hour, in un episodio dedicato allo stigma sull’aborto. Il contesto era questo: raccontava di essersi resa conto di provare lei stessa una specie di imbarazzo nel precisare di non avere mai abortito, nonostante fosse attivista pro-choice. Da lì arrivò quella frase, che voleva essere una provocazione contro lo stigma.

Il problema è che la provocazione divorò completamente il messaggio.

Tanto che Dunham stessa, il giorno dopo, si scusò definendola una “distasteful joke”, precisando di non voler banalizzare le difficoltà fisiche ed emotive legate all’interruzione di gravidanza.

E infatti la domanda rimane: per chi parlava Lena Dunham?

Perché io non ho mai sentito una donna che abbia davvero dovuto affrontare un aborto dire: “bella esperienza, facciamo un altro giro?”. E naturalmente le esperienze individuali sono diversissime: per alcune donne può prevalere il sollievo, per altre il dolore, per altre ancora entrambe le cose. Ma proprio per questo trasformare l’aborto in una specie di distintivo identitario, qualcosa che quasi si dovrebbe desiderare per dimostrare di essere abbastanza emancipati, è una caricatura persino della posizione pro-choice.

La posizione ragionevole sarebbe molto più semplice: una donna deve poter interrompere una gravidanza quando decide che quella è la scelta giusta per lei, senza che lo Stato, una chiesa o qualche invasato politico glielo impediscano.

Non occorre desiderare un aborto.

Non occorre celebrarlo.

Occorre poterlo scegliere.

Ma quando il bisogno di essere provocatori diventa più importante del tema di cui state parlando, riuscite nel piccolo miracolo politico di prendere una posizione largamente difendibile e trasformarla in qualcosa che persino molte persone favorevoli al diritto all’aborto trovano grottesco.

E ancora una volta il problema diventa quello di prima: il senso del ridicolo.

E quello della misura, anche.

Infine, il problema del femminicidio offre a Vannacci la possibilità di attaccare tutto il tema, nonostante dovrebbe essere, per la sinistra, un ariete politico formidabile.

Chiunque sia sano di mente riconoscerà che uccidere una donna approfittando anche della propria maggiore forza fisica e della maggiore capacità di infliggere violenza letale sia qualcosa da reprimere con estrema decisione.

Eppure Vannacci riesce comunque a qualificarsi politicamente su questo argomento.

Come fa?

Anche perché una parte della sinistra cosiddetta woke riesce a trasformare il problema in una questione principalmente nominalistica, come se il punto decisivo fosse stabilire come debba chiamarsi il reato. “Femminicidio” oppure “omicidio”? Una fattispecie autonoma oppure un’aggravante? Il nome descrive correttamente il fenomeno oppure introduce una distinzione artificiale?

Dategli pure il contentino al botolo militare.

Chiamatelo “omicidio misogino”, se proprio il termine femminicidio gli procura l’orticaria. Oppure trovate un’altra formulazione giuridicamente sensata. Il nome, rispetto al problema concreto, è secondario.

Perché il problema importante non è vincere una gara terminologica.

Il problema importante è capire quali omicidi di donne costituiscano un fenomeno specifico, quali siano davvero le cause di quel fenomeno e quali strumenti funzionino realmente per impedirli.

Ed è proprio qui che la discussione dovrebbe diventare interessante.

Invece, se passate il tempo a litigare sulla parola da stampare sull’etichetta, regalate alla destra il terreno ideale. La discussione non riguarda più donne morte, cause, prevenzione, efficacia delle leggi o capacità delle istituzioni di intervenire.

Riguarda un vocabolo.

E su un vocabolo Vannacci può fare quello che vuole: può costruire paradossi, analogie, battute, casi-limite e tutta la consueta artiglieria retorica.

Perché i fascisti, quando si tratta di retorica, sono storicamente piuttosto allenati.

Casomai nessuno lo avesse notato.

E su questo tema si innesta un’altra ideologia zombie. Zombie nel senso letterale del termine: morta, putrefatta, ma ancora perfettamente capace di mangiarti il cervello. Secondo questa lettura, lo schema sarebbe più o meno questo:

DONNA SE NE VA –> IDEOLOGIA MASCHILISTA –> PATRIARCATO / POSSESSO / CONTROLLO –> VIOLENZA –> UCCISIONE

Il maschio, cioè, ucciderebbe la donna perché non ne accetta l’autonomia, l’indipendenza, la libertà di andarsene; e questa incapacità di accettarla sarebbe a sua volta il prodotto del patriarcato.

Il problema è che presentare questo schema come la spiegazione della violenza maschile è una puttanata.

Non perché controllo, possesso, gelosia o modelli tradizionali di genere non possano entrare in gioco. La ricerca trova associazioni anche con questi fattori. Ma trova contemporaneamente rabbia, gelosia, paura dell’abbandono, umiliazione, stress relazionale e, soprattutto, difficoltà nella regolazione delle emozioni. Una meta-analisi su 62 campioni trova infatti un’associazione significativa, da piccola a moderata, fra difficoltà di regolazione emotiva e violenza di coppia; altre revisioni mostrano che gelosia, rabbia, bisogno di controllo e disregolazione emotiva possono coesistere nello stesso meccanismo.

Ed è proprio per questo che ridurre tutto a “patriarcato e possesso” produce immediatamente l’abbandono di gran parte del pubblico maschile.

Perché moltissimi uomini non si riconoscono affatto in quello schema.

Se volete costruire un modello che almeno descriva una parte importante di ciò che succede nella testa di un uomo quando una relazione collassa, lo schema può essere molto più banalmente questo:

DONNA SE NE VA –> SOFFERENZA –> NON RIESCO A GESTIRE LA SOFFERENZA –> RABBIA / DISREGOLAZIONE –> VIOLENZA –> UCCISIONE

Questo, almeno, descrive un meccanismo psicologico riconoscibile.

Essere lasciati, sentirsi umiliati, sentire certe parole, vedere la persona con qualcun altro, percepire di aver perso definitivamente una relazione: tutto questo può produrre gelosia, certo, ma la gelosia stessa non è una sostanza misteriosa. È un impasto di rabbia, tristezza, paura, vergogna, senso di perdita, impotenza e umiliazione. La letteratura psicologica sulla gelosia romantica descrive infatti proprio questa combinazione di emozioni, e collega gelosia e sospetta infedeltà a un aumento del rischio di violenza di coppia.

Il punto, quindi, non è assolvere chi diventa violento perché “stava soffrendo”. La sofferenza può essere comprensibile oppure assurda, proporzionata oppure patologica: non giustifica comunque la violenza.

Il punto è capire quale meccanismo si debba interrompere.

Perché se il percorso reale, almeno in molti casi, passa attraverso l’incapacità di gestire perdita, rifiuto, rabbia, umiliazione e dolore emotivo, allora una politica di prevenzione che parli soltanto di “decostruire il patriarcato” rischia di mancare una parte enorme del bersaglio.

Ed è qui che arriviamo alla famosa educazione affettiva.

Che io, peraltro, penso sia utile e che andrebbe fatta.

Ma dovrebbe comprendere molto più esplicitamente qualcosa che potremmo chiamare educazione alla gestione della sofferenza: cosa succede quando vieni lasciato; cosa fai quando non dormi perché continui a ripeterti in testa una conversazione; cosa fai quando senti salire rabbia e umiliazione; come riconosci il momento in cui stai perdendo il controllo; come ti allontani fisicamente dalla situazione; come chiedi aiuto prima di trasformare una crisi emotiva in violenza.

Questo sarebbe un linguaggio nel quale molti uomini potrebbero riconoscersi.

Dire invece a un ragazzo:

“Potresti diventare violento perché sei stato educato dal patriarcato a considerare la donna una tua proprietà”

può magari descrivere alcuni individui e alcuni contesti, ma se viene proposto come spiegazione universale produce un problema ovvio: la maggioranza degli uomini non riconosce la propria esperienza interiore in quella descrizione.

E quando una teoria pretende di spiegare le persone meglio di quanto quelle persone riescano a riconoscersi nella teoria, forse vale la pena chiedersi se non sia la teoria ad avere bisogno di una revisione.

La vecchia spiegazione del possesso e dell’onore aveva certamente molto più senso in una società nella quale il delitto d’onore era persino riconosciuto dall’ordinamento e nella quale la sessualità e il comportamento della moglie erano considerati anche socialmente parte dell’onore maschile. Ma non possiamo semplicemente prendere il modello culturale di due o tre generazioni fa, sostituire la parola “onore” con “patriarcato” e presumere che spieghi automaticamente ogni omicidio di coppia contemporaneo.

La realtà sembra essere molto più sporca e molto meno ideologicamente elegante. E la disregolazione emotiva (cosi' la scienza chiama quello che ho descritto come “eccesso di sofferenza”) è effettivamente un fattore documentato nella violenza di coppia.

E proprio per questo la famosa educazione affettiva, se significa soltanto spiegare ai maschi che devono rispettare l’autonomia femminile, rischia di funzionare poco. Non perché rispettare l’autonomia femminile sia sbagliato — evidentemente — ma perché non basta a insegnare cosa fare quando il dolore diventa ingestibile.

Il mondo femminista woke, invece, tende troppo spesso a partire da una spiegazione ideologica già pronta e a trattarla come verità assoluta.

E il risultato politico è prevedibile: moltissimi uomini ascoltano la descrizione che viene fatta di loro e pensano semplicemente:

“Io non funziono così.”

Dopodiché smettono di ascoltare anche tutto il resto.

Infine, c’è il concetto di purezza ideologica.

Pietro Nenni lo riassunse in una frase diventata proverbiale:

“C’è sempre un puro più puro che ti epura.”

La frase gli viene attribuita da decenni ed è entrata stabilmente perfino nel linguaggio parlamentare italiano.

Nenni è morto nel 1980. Insomma, questa cosa avremmo dovuto impararla parecchio tempo fa.

E invece siamo qui a parlarne nel 2026.

Perché una delle caratteristiche più autodistruttive di certa cultura woke è precisamente questa: la politica viene sostituita dall’esame di purezza.

Non basta essere d’accordo sull’obiettivo. Bisogna essere d’accordo anche sulle parole, sulle definizioni, sui simboli, sulle sfumature, sulla genealogia corretta dell’argomento e possibilmente persino sulle motivazioni interiori per le quali siete arrivati alla conclusione giusta.

Non basta dire che non bisogna discriminare una persona trans: bisogna dirlo usando il vocabolario corretto.

Non basta essere favorevoli al diritto all’aborto: bisogna avere anche il giusto atteggiamento culturale nei confronti dell’aborto.

Non basta voler ridurre la violenza contro le donne: bisogna accettare anche la spiegazione ideologica corretta delle sue cause.

E se per caso siete d’accordo sul risultato ma non sulla dottrina che dovrebbe giustificarlo, comincia immediatamente il processo.

Non siete abbastanza informati.

Non avete ancora “decostruito” qualcosa.

State riproducendo qualche struttura.

Dovete educarvi.

Dovete ascoltare.

Dovete fare un percorso.

E soprattutto, prima o poi, arriva qualcuno ancora più puro di quello che vi stava facendo l’esame, e comincia a fare l’esame a lui.

Nenni aveva già descritto perfettamente il meccanismo.

C’è sempre un puro più puro che ti epura.

Il risultato politico è devastante, perché una coalizione dovrebbe funzionare esattamente al contrario: mettere insieme persone che hanno motivazioni, culture e perfino valori differenti, ma che su alcuni obiettivi concreti riescono comunque a votare dalla stessa parte.

La purezza ideologica, invece, restringe continuamente il recinto.

Ogni nuovo requisito serve a espellere qualcuno.

Ogni nuova definizione produce un eretico.

Ogni nuova parola d’ordine crea immediatamente qualcuno che la pronuncia male.

E alla fine rimangono in pochi.

Purissimi.

E sconfitti.

E se volete una conferma di questo meccanismo, basta ricordare che cosa successe con il DDL Zan.

Perché anche lì comparve immediatamente il problema del puro più puro.

Il disegno di legge nasceva per estendere le tutele contro discriminazione e violenza motivate da sesso, genere, orientamento sessuale, identità di genere e disabilità. E ci si aspetterebbe che, almeno dentro il campo progressista, una legge del genere incontrasse soprattutto il problema di come farla approvare.

Invece cominciò anche una guerra intestina sulle definizioni.

Una parte del femminismo contestò in particolare il concetto di “identità di genere”, sostenendo che potesse entrare in conflitto con la categoria politica e giuridica di sesso. E questa discussione arrivò anche dentro il PD: la senatrice dem Valeria Valente, allora presidente della Commissione parlamentare sul femminicidio, chiese modifiche al testo e propose, tra le altre cose, di eliminare sia il riferimento alle donne sia quello all’identità di genere. Paola Concia sostenne posizioni analoghe.

Ora, attenzione: dire che “le femministe del PD hanno cassato la legge Zan” sarebbe troppo semplice, perché tecnicamente non sappiamo chi votò cosa. Il DDL venne fermato al Senato il 27 ottobre 2021 con la cosiddetta tagliola, approvata a scrutinio segreto con 154 voti contro 131. Il centrosinistra perse parecchi voti rispetto ai numeri teoricamente disponibili, ma proprio perché il voto era segreto non possiamo distribuire con certezza le responsabilità individuali.

Il punto politico, però, rimane.

Una legge nata per proteggere omosessuali, transessuali, donne e altre categorie dalla discriminazione si trovò sotto il fuoco non soltanto della destra, ma anche di persone appartenenti allo stesso campo politico che avrebbero dovuto sostenerla, perché la definizione usata non era ideologicamente abbastanza pura.

E qui torna Nenni.

Non basta avere davanti una legge che, magari imperfetta, va nella direzione che dici di volere.

Bisogna che sia formulata con le categorie corrette.

Bisogna che la definizione di donna sia quella corretta.

Bisogna che la definizione di genere sia quella corretta.

Bisogna che nessun pezzo della propria teoria venga contaminato da quella dell’altro.

E se il compromesso necessario per far passare la legge implica concedere qualcosa all’altra corrente, allora improvvisamente il compromesso diventa tradimento.

Il risultato?

La destra presenta la tagliola.

Il testo cade.

E tutti tornano a casa con la propria purezza teorica perfettamente intatta.

Tranne la legge, che non esiste più.

C’è sempre un puro più puro che ti epura.

A volte epura anche la legge che diceva di voler approvare.

E quindi il problema non è nemmeno discutere se il woke, in Italia, vada abbandonato oppure no.

Un sistema ideologico del genere, costruito in modo tale da respingere il consenso attraverso la ricerca continua della purezza, da riproporre schemi politici nei quali non si riconosce quasi più nessuno, e da usare l’irritazione come tattica comunicativa nella speranza che l’escalation produca mobilitazione, semplicemente non può funzionare.

O, quantomeno, non può funzionare come strategia per conquistare una maggioranza.

Volete pensare che esista davvero, questo woke italiano?

Fatelo.

E allora lo vedrete prima o poi disintegrarsi sotto il peso della propria antipatia, delle proprie contraddizioni interne e della propria capacità quasi scientifica di cacciare chiunque non superi l’ennesimo esame di purezza.

Volete invece sostenere che non esista affatto?

Fatelo pure.

Ma allora dovrete almeno spiegare perché, ogni volta che qualcuno riconducibile a quel linguaggio apre bocca, una parte consistente del pubblico sviluppa immediatamente l’orticaria.

Perché qualcosa, evidentemente, sta reagendo.

Può essere un movimento politico vero e proprio, può essere una sottocultura universitaria e mediatica, può essere un insieme di tic linguistici, categorie importate dagli Stati Uniti e comportamenti sociali. Possiamo anche discutere per giorni su quale sia il nome corretto.

Ma torniamo sempre allo stesso punto.

In Italia, politicamente, il problema è irrilevante. Il woke”

• Non sta conquistando il paese.
• Non sta producendo una nuova maggioranza.
• Non sta sostituendo la socialdemocrazia come domanda politica degli italiani.
• Sta soprattutto occupando spazio nella discussione pubblica, spesso grazie a chi lo combatte con più entusiasmo di quanto venga praticato da chi dovrebbe sostenerlo.

E così finiamo ancora una volta per discutere di un problema americano come se fosse il centro della politica italiana.

Che, guarda caso, era esattamente il punto da cui eravamo partiti.

Il problema di base e' che in un sistema sovietico l'economia era completamente pianificata. Era un periodo nel quale i computer (sia in URSS che in occidente) li facevano le universita', in occidente magari con la cooperazione di un'azienda tipo IBM, e quindi erano vastamente finanziati dallo stato. Di conseguenza, si faceva ogni cinque anni una pianificazione e si decideva cosa finanziare, e specialmente CHI finanziare: essendo che l'intero sistema teoricamente doveva servire chi lavorava, avreste ottenuto macchine per fisici, per ingegneri, per militari, per controllo industriale.

In Occidente ha vinto storicamente più o meno questa successione: von Neumann → CPU general purpose → byte → registri → C → Unix → RISC/x86 → enormi quantità di software sopra.

In alcuni filoni sovietici invece troviamo continuamente tentativi di dire:

“Perché devo fare una macchina generica? Qual è la struttura matematica del problema? Costruiamo direttamente quella, fatta per quelli che ci lavoreranno.”

Da lì vengono:

• ternario perché matematicamente ha proprietà interessanti;
• stack perché le espressioni sono alberi;
• tagged memory perché i valori hanno un tipo;
• hardware per linguaggi ad alto livello;
• SIMD perché molti problemi scientifici sono vettori;
• macchine specializzate per algebra simbolica;
• parallelismo esplicito invece di fingere che tutto sia una sequenza di istruzioni.

Ed è proprio questo che le rende “aliene”: non partono necessariamente dalla CPU come oggetto fondamentale. Partono dal calcolo che vuoi fare e cercano una macchina che gli assomigli.

Se volete andare ancora più nel weird, ce n'è un secondo strato decisamente più oscuro: M-9 di Kartsev, macchine di Glushkov, sistemi macro-pipeline, REFAL, SKIF, Kronos, le architetture recursive/tagged di Akademgorodok.

Lì cominciano veramente le cose da “la storia del computing avrebbe potuto andare da un'altra parte”.

E ce ne sono parecchie che, viste oggi, sembrano provenire da una linea evolutiva alternativa del calcolo. Non tutto era esclusivamente sovietico — spesso c'erano idee parallele anche in Occidente — ma in URSS alcune furono portate molto più avanti o assemblate in modi davvero strani.

Quelle che secondo me meritano di più sono queste:

1. Setun / Setun-70 — calcolo ternario bilanciato Non 0,1, ma −1, 0, +1. Quindi un numero può essere rappresentato senza bit di segno separato e la negazione è banalmente lo scambio + ↔ −. Inoltre in ternario alcune operazioni aritmetiche hanno meno riporti rispetto al binario. Il primo Setun fu costruito alla Moscow State University nel 1958 e ne vennero prodotti circa 50. La cosa veramente aliena però è Setun-70. Non era semplicemente “Setun più veloce”: era una macchina nuova, organizzata intorno a tryte di 6 trit, istruzioni a lunghezza variabile e una architettura a due stack. Il programma veniva espresso sostanzialmente in una forma di notazione polacca inversa e l'architettura era pensata per rendere naturali le strutture del programma. Quindi qui abbiamo già qualcosa di concettualmente folle: non una CPU che “esegue istruzioni”, nel senso moderno, ma una macchina progettata intorno all'algebra delle espressioni e alla struttura del programma.
2. MIR — il computer che capiva matematica La serie MIR di Viktor Glushkov, dalla metà degli anni Sessanta, era progettata apposta per ingegneri e matematici. Non era semplicemente una macchina con BASIC o FORTRAN sopra: parte del suo linguaggio ad alto livello era supportata direttamente dall'architettura.
   MIR poteva lavorare simbolicamente su frazioni, polinomi, derivate e integrali.
   

3. In altre parole, l'idea non era:

   CPU generica → sistema operativo → programma di algebra.

   ma qualcosa più simile a:

   computer = macchina matematica interattiva.

   È una genealogia abbastanza diversa da quella PC/Unix. Se Mathematica avesse avuto dei nonni hardware, MIR sarebbe uno di quelli.

4. Elbrus-1 / Elbrus-2 — il tipo dei dati è proprietà della memoria Questa è una delle mie preferite. Ogni parola di memoria aveva un tag hardware che diceva che cosa quella parola era. Il processore quindi non vedeva soltanto 48/64 bit da interpretare secondo l'istruzione corrente: aveva informazione hardware sul tipo dell'oggetto. Conseguenza: molte cose che oggi affidiamo al compilatore, al runtime o alla sicurezza della memoria erano controllate dalla macchina. E ancora più stranamente, su Elbrus non esisteva realmente l'assembler nel senso tradizionale. Sistema operativo, compilatori e software di sistema venivano scritti in EL-76, un linguaggio ad alto livello imparentato concettualmente con ALGOL 68. Va detto che qui i sovietici non partirono dal nulla: l'influenza delle macchine Burroughs B5000/B6500 è importante. Ma svilupparono l'idea in una direzione propria. Vista nel 2026, la cosa fa pensare immediatamente a tagged memory, capability architectures, CHERI, managed runtimes e memory safety.

5. Elbrus e le procedure come oggetti hardware Collegato al punto precedente: la CPU era progettata sapendo che esistevano procedure, stack, tipi e strutture del linguaggio. Il modello dominante che abbiamo ereditato è:

   CPU stupida, compilatore intelligente.

   La filosofia Elbrus/Burroughs era molto più:

   CPU che conosce la semantica fondamentale del linguaggio.

   Quindi chiamate di procedura, stack e protezione non erano convenzioni inventate dal compilatore sopra un ISA di registri: entravano direttamente nell'architettura. È probabilmente uno dei più grandi “what if?” della storia dei computer.

6. PS-2000 — 64 processori che fanno la stessa cosa su dati diversi, nel 1981
   Qui comincia a sembrare familiare per una ragione inquietante.
   PS-2000 aveva fino a 64 processing elements, ciascuno con memoria locale, governati da una unità comune che inviava loro le operazioni. Era una macchina SIMD. Vale a dire:

   stessa istruzione → moltissimi elementi di dati contemporaneamente.

   Ti ricorda qualcosa? Una GPU. Non era una GPU naturalmente, ma la filosofia è proprio quella. E non era un giocattolo sperimentale: ne furono prodotti 242 esemplari, usati fra l'altro per elaborazione sismica e telemetria spaziale in tempo reale. Il motivo era molto sovietico: avevano enormi flussi di dati geofisici, radar, telemetrici e scientifici, quindi invece di chiedersi “come facciamo una CPU general purpose più veloce?” si chiedevano:

   come facciamo a masticare 64 flussi dello stesso tipo contemporaneamente?

7. M-10 — parallelismo su istruzioni E dati negli anni Settanta Mikhail Kartsev progettò M-10 per il sistema sovietico di early warning antimissile. Era una macchina multiprocessore, vector-parallel, progettata per sfruttare parallelismo sia a livello delle istruzioni sia dei dati. Nel 1972. Aveva circa 5 MB di memoria e dell'ordine di 5 milioni di operazioni al secondo; per certi modelli fisici poteva essere enormemente più veloce di BESM-6. E anche qui il contesto cambia completamente l'architettura. Non:

   computer general purpose che occasionalmente fa calcolo parallelo.

   ma:

   oggetto matematico parallelo al quale attacco un problema fisico.

8. BESM-6 — una CPU stranissima anche se binaria BESM-6 vale la pena guardarlo proprio perché corregge l'equivoco iniziale: era binario, ma comunque molto poco “PC-like”. Parole da 48 bit, memoria word-addressed, due pipeline separate per controllo e aritmetica, piccoli buffer associativi per istruzioni, operandi e risultati, look-ahead di diverse istruzioni. Nel paper sull'hardware viene descritta una ALU toroidale, costruita intorno a nuclei magnetici e logiche abbastanza diverse dalla struttura che immaginiamo pensando a una CPU moderna. Non è concettualmente aliena quanto Setun, ma è un ottimo esempio del fatto che la microarchitettura non aveva ancora prodotto la nostra grammatica attuale.

9. DSSP — il software diventa continuazione della CPU ternaria Quando Setun-70 sparì come macchina fisica, la sua architettura sopravvisse sotto forma di DSSP, Dialogue System of Structured Programming. Ed è una cosa filosoficamente interessante: invece di portare un linguaggio su una nuova CPU, fecero in pratica il contrario, emulando il modello astratto della vecchia macchina sulle macchine binarie successive. Cioè l'ISA smette quasi di essere hardware e diventa un modello computazionale persistente. È molto vicino all'idea moderna di VM, bytecode e abstract machine.

E fin qui siamo ancora al bizzarro. Ma col comunismo, nella job description arriva qualcosa di ancora piu' bizzarro. Il mondo sovietico si proponeva una “scienza sovietica” che doveva essere non solo piu' avanzata, ma completamente diversa, al punto da diventare identitaria. E con essa, una tecnologia sovietica. E questo, unito al “cosmismo”, una strana filosofia iperpositivista scientificista che in confronto Elon Musk e' uno che leggeva superman e ci credeva, portava i sovietici a finanziare progetti “perche' questa e' scienza sovietica e voi occidentali non potete capire”.

Insomma, il sistema comunista consentiva che venissero finanziate cose infinanziabili in occidente. I financial controller avrebbero sbattuto la testa sul tavolo gridando “pecche? pecche?”, e la riunione di risks assessment sarebbe finita in una sessione di taranta sotto LSD. Ma loro potevano.

E uscirono robe davvero aliene, possibili solo in sistemi che non badano a “successo sul mercato” ma a “idea interessante e superiore a quelle occidentali”.

Qui entriamo nella parte davvero interessante: non più semplicemente “computer sovietici strani”, ma vere e proprie famiglie di idee che provavano a ridefinire che cosa fosse una macchina.

Prima però una correzione rispetto alla carrellata precedente: avevo mescolato scuole ed epoche diverse. SKIF non appartiene davvero all'archeologia sovietica classica: è un progetto russo-bielorusso nato dopo la dissoluzione dell'URSS, all'inizio degli anni 2000. Lo terrei quindi come discendente tardivo di certe idee, non come membro della stessa famiglia storica.

Il nucleo veramente alieno passa soprattutto attraverso Kartsev, Glushkov, Turchin e Akademgorodok.

M-9 di Kartsev: l'operando non è un numero, è una funzione

M-9 è probabilmente uno dei progetti più strani dell'intera storia dell'informatica sovietica.

Mikhail Kartsev lo propose nella seconda metà degli anni Sessanta per problemi nei quali occorreva elaborare enormi quantità di dati, in particolare segnali radar.

L'idea fondamentale era questa:

Per certi problemi scientifici non ha molto senso considerare l'operando elementare come un numero. L'operando naturale può essere direttamente una funzione.

Immaginiamo, per esempio, una funzione di due variabili:

f(x,y)

campionata su una griglia 32 x 32.

Su una macchina convenzionale penseremmo qualcosa del genere:

for x
    for y
        risultato[x,y] = operazione(f[x,y])

Kartsev invece dice, in sostanza:

No. f è l'operando.

E progetta una matrice di 32 x 32 unità aritmetiche, quindi 1024 elementi di calcolo capaci di lavorare contemporaneamente sui punti della funzione.

Una rappresentazione molto semplificata potrebbe essere:

                    FUNZIONE F(x,y)
                           |
                           v
        +--------------------------------------+
        |                                      |
        |        32 x 32 PROCESSING ELEMENTS   |
        |                                      |
        |   PE  PE  PE  PE  PE  ...  PE       |
        |   PE  PE  PE  PE  PE  ...  PE       |
        |   PE  PE  PE  PE  PE  ...  PE       |
        |   .   .   .   .   .        .        |
        |   .   .   .   .   .        .        |
        |   PE  PE  PE  PE  PE  ...  PE       |
        |                                      |
        +--------------------------------------+
                           |
                           v
                    FUNZIONE G(x,y)

La semantica della macchina diventa concettualmente qualcosa del tipo:

G := sin(F)

H := F + G

K := derivata_x(H)

e non:

LOAD elemento 17
ADD  elemento 18
STORE elemento 19

È una differenza enorme.

Non stai semplicemente costruendo una CPU molto veloce.

Stai costruendo una macchina nella quale l'oggetto matematico del problema coincide quasi con l'oggetto hardware della computazione.

Il progetto M-9 prevedeva inoltre componenti specializzati differenti, destinati a classi diverse di operazioni:

              +----------------------+
              |  PROCESSORE CONTROLLO |
              +----------+-----------+
                         |
       +-----------------+------------------+
       |                 |                  |
       v                 v                  v

+-------------+    +-------------+    +-------------+
| FUNCTIONAL  |    | NUMERICAL   |    | ASSOCIATIVE |
| OPERATOR    |    | COMPUTER    |    | COMPUTER    |
+-------------+    +-------------+    +-------------+

                         |
                         v

                  +-------------+
                  | PERIPHERAL  |
                  | COMPUTER    |
                  +-------------+

L'obiettivo teorico era arrivare nell'ordine del miliardo di operazioni al secondo, in un'epoca nella quale macchine come BESM-6 stavano nell'ordine del milione.

Il progetto completo non entrò in produzione, ma diverse idee confluirono poi nell'M-10.

Oggi ciò che gli assomiglia di più non è una CPU tradizionale.

È una specie di incrocio fra:

• GPU;
• array processor;
• SIMD;
• tensor accelerator;
• domain-specific architecture.

E siamo intorno al 1967.

M-9 e il parallelismo esplicito

Nel progetto M-9 compare anche un'altra idea interessante.

La macchina prevedeva operazioni relativamente semplici, ma parole di comando molto larghe capaci di specificare contemporaneamente attività su più unità funzionali.

Una visione semplificata potrebbe essere:

              UNA PAROLA DI COMANDO
                       |
        +--------------+--------------+
        |              |              |
        v              v              v

   [ operazione ] [ operazione ] [ operazione ]
        |              |              |
        v              v              v

      UNIT A          UNIT B         UNIT C

Il parallelismo non deve essere scoperto faticosamente dalla CPU osservando una sequenza di istruzioni.

È già dichiarato nella struttura del comando.

Retrospettivamente, alcuni storici hanno paragonato certi aspetti di questa impostazione a concetti che in seguito avremmo chiamato RISC e VLIW.

Sarebbe naturalmente anacronistico dire che Kartsev “inventò RISC” o “inventò VLIW”.

Ma la domanda è sorprendentemente moderna:

Perché costruire una ISA estremamente complicata, se posso usare operazioni semplici e rendere esplicito il parallelismo?

Questo è un tratto ricorrente in molti dei progetti sovietici più interessanti:

prima viene il problema matematico, poi si costruisce l'architettura che gli assomiglia.

Glushkov: aboliamo proprio la macchina di von Neumann

Viktor Glushkov andò ancora oltre.

Negli anni Settanta sviluppò l'idea di un recursive computer, una macchina pensata esplicitamente per superare alcuni limiti fondamentali dell'architettura von Neumann.

Una macchina tradizionale viene concettualmente vista così:

                PROGRAMMA
                    |
                    v
          SEQUENZA DI ISTRUZIONI
                    |
                    v
                 +-----+
                 | CPU |
                 +--+--+
                    |
                    |
              +-----+-----+
              |           |
              v           v
          MEMORIA       I/O

Il programma viene trasformato in una sequenza:

istruzione 1
     |
     v
istruzione 2
     |
     v
istruzione 3
     |
     v
istruzione 4
     |
     v
    ...

Ma molte espressioni matematiche reali non hanno affatto questa forma.

Assomigliano molto più a un albero:

                    F
                  /   \
                 /     \
                G       H
               / \     / \
              A   B   C   D

Allora nasce una domanda ovvia, ma estremamente radicale:

Perché trasformare artificialmente questa struttura in una sequenza lineare di LOAD, STORE, CALL e JUMP?

La recursive machine cercava di fare della struttura ricorsiva del problema la struttura stessa della computazione.

Invece di:

LOAD A
LOAD B
CALL G
STORE X
LOAD C
LOAD D
CALL H
STORE Y
LOAD X
LOAD Y
CALL F

l'idea diventa qualcosa di molto più vicino a:

                    [ F ]
                   /     \
                  /       \
              [ G ]       [ H ]
              /   \       /   \
             A     B     C     D

e la macchina cerca di valutare direttamente quella struttura.

La versione completa di questa architettura non fu mai realizzata nella forma immaginata da Glushkov.

La tecnologia dell'epoca semplicemente non rendeva economico costruire tutto ciò che serviva.

Ma parecchie idee confluirono in progetti più concreti.

Macro-pipeline: pipeline di algoritmi, non di istruzioni

Il termine “pipeline” può trarre in inganno.

Una CPU convenzionale può avere una pipeline del tipo:

FETCH
  |
  v
DECODE
  |
  v
EXECUTE
  |
  v
MEMORY
  |
  v
WRITEBACK

Ogni stadio manipola singole istruzioni.

Nel macro-pipeline sviluppato dalla scuola di Glushkov, invece, ogni stadio può rappresentare un pezzo consistente dell'algoritmo.

Immaginiamo di avere molti oggetti:

X1  X2  X3  X4  X5  X6  ...

e una computazione composta da:

A(X) -> B(X) -> C(X) -> D(X)

Possiamo assegnare:

CPU1 = A
CPU2 = B
CPU3 = C
CPU4 = D

e ottenere una situazione del genere:

tempo --->

             CPU1        CPU2        CPU3        CPU4
              A           B           C           D

X1         [ A ]

X2         [ A ] ------> [ B ]

X3         [ A ] ------> [ B ] -----> [ C ]

X4         [ A ] ------> [ B ] -----> [ C ] -----> [ D ]

X5         [ A ] ------> [ B ] -----> [ C ] -----> [ D ]

X6         [ A ] ------> [ B ] -----> [ C ] -----> [ D ]

Fin qui può sembrare una normale pipeline.

Ma la differenza fondamentale è che A, B, C e D non sono istruzioni.

Possono essere interi processi numerici.

La granularità è macroscopica.

È come se invece di pipelinizzare:

ADD
MUL
LOAD
STORE

pipelinizzassi:

filtra il segnale
        |
        v
calcola la trasformata
        |
        v
riconosci il pattern
        |
        v
aggiorna il modello

Il macro-pipeline dinamico

La parte più interessante è che la pipeline non doveva necessariamente essere fissa.

Le architetture sviluppate attorno a queste idee prevedevano processori con memoria distribuita e interconnessioni riconfigurabili.

Un processore poteva ricevere un lavoro quando i dati necessari diventavano disponibili.

Quindi la struttura dell'esecuzione poteva emergere dal grafo delle dipendenze, invece di essere imposta da una sequenza rigida di istruzioni.

Per esempio:

             +--------+
        A -->| TASK 1 |----+
             +--------+    |
                           v
                        +--------+
                        | TASK 3 |----> RISULTATO
                        +--------+
                           ^
             +--------+    |
        B -->| TASK 2 |----+
             +--------+

TASK 3 non parte perché il program counter è arrivato alla sua istruzione.

Parte quando i suoi input sono pronti.

Vista oggi, questa idea ricorda immediatamente:

• task graph;
• DAG scheduler;
• dataflow runtime;
• actor systems;
• futures;
• stream processing;
• workflow engines distribuiti.

Da questa linea di ricerca nacquero macchine concrete come ES-2701 ed ES-1766, prodotte negli anni Ottanta.

Erano sistemi multiprocessore MIMD, con riconfigurazione dinamica e l'obiettivo di ottenere una crescita quasi lineare delle prestazioni aggiungendo risorse.

Quindi non si trattava soltanto di teoria.

Le costruirono davvero.

REFAL: Lisp da una linea evolutiva differente

Con REFAL, sviluppato da Valentin Turchin, usciamo dall'hardware ed entriamo nei linguaggi.

REFAL nasce negli anni Sessanta come linguaggio orientato alla manipolazione simbolica.

Ma non pensa esattamente come Lisp.

Lisp tende a vedere strutture costruite attraverso liste e operazioni come:

CAR
CDR
CONS

REFAL parte invece dall'idea che un programma sia fondamentalmente un insieme di trasformazioni di forme simboliche.

Il cuore è:

PATTERN MATCHING
       +
TERM REWRITING

Concettualmente puoi immaginare regole del tipo:

f(0)  -> 1

f(n)  -> n * f(n-1)

La computazione diventa allora una sequenza di trasformazioni:

            f(3)
              |
              v
         3 * f(2)
              |
              v
      3 * 2 * f(1)
              |
              v
   3 * 2 * 1 * f(0)
              |
              v
              6

Non stai più necessariamente “eseguendo istruzioni”.

Stai riscrivendo un oggetto simbolico finché assume una forma finale.

Un'altra rappresentazione può essere:

+------------------+
| FORMA SIMBOLICA  |
+--------+---------+
         |
         | trova pattern
         v
+------------------+
| APPLICA REGOLA   |
+--------+---------+
         |
         v
+------------------+
| NUOVA FORMA      |
+--------+---------+
         |
         | trova pattern
         v
        ...

Quanto è moderno REFAL

Questa impostazione compare oggi dappertutto.

Nei compilatori:

AST pattern
     |
     v
AST trasformato

Nei sistemi di algebra simbolica:

x + 0  -> x

x * 1  -> x

Nei theorem prover:

termine
   |
   v
termine normalizzato

Negli ottimizzatori:

pattern IR
    |
    v
IR migliore

REFAL nasce esattamente per questo genere di manipolazione.

Turchin sviluppò poi anche il concetto di supercompilation.

L'idea è molto più ambiziosa dell'ottimizzazione locale.

Invece di guardare una singola istruzione o una piccola funzione, il sistema cerca di esplorare simbolicamente il comportamento del programma e costruirne una nuova versione specializzata.

Molto schematicamente:

               PROGRAMMA
                   |
                   v
        ESECUZIONE SIMBOLICA
                   |
                   v
        ANALISI DELLE FORME
                   |
                   v
       SPECIALIZZAZIONE CODICE
                   |
                   v
          NUOVO PROGRAMMA

In termini moderni, la supercompilation ha parentela concettuale con:

• partial evaluation;
• symbolic execution;
• program specialization;
• compile-time reasoning;
• aggressive optimizer transformations.

E queste idee vengono sviluppate già negli anni Settanta.

Programmi come reti dinamiche di automi

Un'altra linea collegata alla scuola di Glushkov sviluppò architetture nelle quali il programma poteva essere rappresentato come una rete di automi.

Un automa poteva rappresentare:

• un dato;
• un'operazione;
• una relazione;
• un riferimento;
• una risorsa hardware.

Gli automi potevano combinarsi in strutture più grandi.

A quel punto la macchina non deve necessariamente seguire un program counter:

PC = PC + 1

La computazione può consistere nella trasformazione di una rete:

       RETE 0
          |
          v
       RETE 1
          |
          v
       RETE 2
          |
          v
       RETE 3
          |
          v
      RISULTATO

Oppure:

       [ A ]----\
                 \
                  >----[ F ]----\
                 /               \
       [ B ]----/                 \
                                   >----[ H ]
       [ C ]----\                 /
                 \               /
                  >----[ G ]----/
                 /
       [ D ]----/

La computazione non consiste necessariamente nel percorrere la rete da sinistra a destra.

La rete stessa può cambiare struttura durante l'esecuzione.

È un modo radicalmente diverso di intendere il computer.

Assomiglia più a una combinazione di:

• graph reduction;
• dataflow;
• term rewriting;
• Petri nets;
• reti di automi;

che a una CPU tradizionale.

Data-driven computing

Una delle possibilità era il calcolo data-driven.

L'operazione parte quando sono disponibili i dati necessari.

Per esempio:

        A --------\
                   \
                    +----> [ ADD ] ----> C
                   /
        B --------/

ADD non viene eseguita perché:

PC = indirizzo_di_ADD

Viene eseguita perché:

A disponibile = SI
B disponibile = SI

quindi:

             A pronto
                \
                 \
                  >---- [ ADD ] ----> C
                 /
                /
             B pronto

Non serve necessariamente un program counter globale che ordini:

adesso esegui ADD

È la disponibilità dei dati a far partire il calcolo.

Demand-driven computing

L'altra possibilità è quasi speculare.

Qualcuno richiede C.

La macchina scopre che per calcolare C servono A e B.

Quindi:

                 WANT C
                   |
                   v
        +-----------------------+
        | Per produrre C servono|
        |         A e B         |
        +-----------+-----------+
                    |
             +------+------+
             |             |
             v             v
          WANT A         WANT B
             |             |
             +------+------+
                    |
                    v
                [ CALCOLO ]
                    |
                    v
                    C

La computazione viene quindi attivata dalla domanda del risultato.

È concettualmente molto vicina alla lazy evaluation.

Solo che qui la lazy evaluation non è soltanto una proprietà del linguaggio.

Può diventare una proprietà dell'architettura.

Von Neumann contro dataflow

La differenza filosofica si vede abbastanza bene così.

Macchina convenzionale:

           PROGRAM COUNTER
                 |
                 v
          istruzione 1
                 |
                 v
          istruzione 2
                 |
                 v
          istruzione 3
                 |
                 v
          istruzione 4

La domanda fondamentale è:

"Qual è la prossima istruzione?"

In una macchina dataflow:

        A ----\
               >---- [ OP1 ] ----\
        B ----/                   \
                                    >---- [ OP3 ] ---> RESULT
        C -------- [ OP2 ] -------/

la domanda diventa:

"Quale operazione possiede già tutti gli input necessari?"

È una differenza molto più profonda di quanto sembri.

Akademgorodok e Kronos

Spostiamoci a Novosibirsk, nell'ambiente scientifico di Akademgorodok.

Qui nasce Kronos.

La genealogia è interessante perché Kronos non compare dal nulla.

Il punto di partenza è la workstation Lilith di Niklaus Wirth, progettata a ETH Zürich per Modula-2.

Il gruppo sovietico ricevette documentazione su Lilith e Modula-2 nei primi anni Ottanta e iniziò a sviluppare il proprio sistema.

Ma invece di limitarsi a costruire una workstation compatibile, spinse l'idea molto più avanti.

Il ragionamento era sostanzialmente:

Se il software viene scritto in Modula-2, perché costruire una CPU pensata per assembler?

Kronos diventa quindi qualcosa di molto vicino a una:

        VIRTUAL MODULA-2 MACHINE
                   |
                   v
              HARDWARE REALE

Cioè una macchina virtuale del linguaggio trasformata direttamente in processore fisico.

Kronos: il linguaggio entra nella CPU

Una CPU convenzionale conosce cose come:

MOV
ADD
PUSH
CALL
JMP

Il significato di:

modulo
procedura
variabile locale
variabile globale

viene costruito sopra la CPU dal compilatore.

Possiamo rappresentarlo così:

       PROGRAMMA MODULA-2
               |
               v
          COMPILATORE
               |
               v
     ISTRUZIONI GENERICHE
               |
               v
              CPU

Kronos cerca invece di accorciare quella distanza:

       PROGRAMMA MODULA-2
               |
               v
        CODICE KRONOS
               |
               v
      CPU CHE CONOSCE GIA'
       MOLTI DI QUEI CONCETTI

L'architettura supporta direttamente concetti come:

MODULE

PROCEDURE

LOCAL VARIABLE

GLOBAL VARIABLE

e operazioni associate a:

• procedure call;
• strutture di stack;
• variabili locali;
• variabili globali;
• moduli;
• range checking;
• costrutti tipo CASE;
• caricamento dinamico di moduli.

La semantica del linguaggio è quindi parzialmente incorporata nell'hardware.

È un ribaltamento importante.

La struttura tradizionale è:

LINGUAGGIO
    |
    v
COMPILATORE
    |
    v
ISA
    |
    v
CPU

La filosofia Kronos si avvicina molto di più a:

LINGUAGGIO
    |
    v
ISA
    |
    v
CPU

o addirittura, concettualmente:

LINGUAGGIO ~= ISA

Kronos e la stack machine

Kronos utilizza intensamente uno stack per valutare le espressioni.

Prendiamo:

a + b * c

Una macchina a registri potrebbe produrre qualcosa del genere:

LOAD R1, b
LOAD R2, c
MUL  R1, R2
LOAD R2, a
ADD  R2, R1

Su una stack machine il modello diventa:

PUSH a
PUSH b
PUSH c
MUL
ADD

e lo stack evolve così:

inizio:

    +-------+
    |       |
    +-------+

PUSH a:

    +-------+
    |   a   |
    +-------+

PUSH b:

    +-------+
    |   b   |
    +-------+
    |   a   |
    +-------+

PUSH c:

    +-------+
    |   c   |
    +-------+
    |   b   |
    +-------+
    |   a   |
    +-------+

MUL:

    +-------+
    |  b*c  |
    +-------+
    |   a   |
    +-------+

ADD:

    +-------+
    |a+b*c  |
    +-------+

Non serve fare register allocation nello stesso modo di una CPU tradizionale.

La filosofia ricorda molto ciò che più tardi avremmo visto in:

• JVM bytecode;
• CLR;
• WebAssembly;
• Forth;
• altre stack machines.

La differenza interessante è che qui quella macchina virtuale viene materializzata direttamente nell'hardware.

Kronos e gli opcode compatti

L'architettura Kronos era estremamente compatta.

Molte operazioni venivano rappresentate con opcode da un byte.

In una CPU complessa moderna possiamo avere qualcosa del genere:

+--------+-------+------+--------------+-----------+
| opcode | modrm | sib  | displacement | immediate |
+--------+-------+------+--------------+-----------+

In una macchina di tipo Kronos il modello può essere molto più vicino a:

+--------+
| opcode |
+--------+

Naturalmente non tutte le operazioni reali si riducono magicamente a un solo byte senza dati aggiuntivi, ma la filosofia dell'ISA è molto più vicina a quella di una bytecode machine che a quella di un x86.

Ed è importante ricordare che non stiamo parlando di una VM software.

Stiamo parlando della CPU fisica.

Kronos e la protezione del software

Kronos incorporava anche concetti che rendevano naturale distinguere:

• codice;
• dati;
• moduli;
• procedure;
• riferimenti interni ed esterni.

Quindi il mondo non appare semplicemente come:

MEMORIA = UN ENORME ARRAY DI BYTE

ma più come:

+----------------------------------+
| PROCESSO                         |
|                                  |
|   +-----------+   +-----------+  |
|   |   CODE    |   |   DATA    |  |
|   +-----------+   +-----------+  |
|                                  |
|   +---------------------------+  |
|   | MODULE TABLE              |  |
|   +---------------------------+  |
|                                  |
|   +---------------------------+  |
|   | PROCEDURE / ENTRY TABLE   |  |
|   +---------------------------+  |
+----------------------------------+

Questo rende molto naturali concetti come:

• relocation;
• dynamic linking;
• reentrant code;
• separazione fra aree;
• riferimenti mediati da tabelle.

Non significa che Kronos fosse una moderna capability machine o che avesse automaticamente tutte le proprietà di sicurezza che oggi associamo a CHERI o ai managed runtime.

Ma la filosofia è molto diversa dalla classica:

ecco 4 GB di memoria, arrangiati

Kronos diventa MARS

Kronos finì poi dentro il progetto MARS, acronimo di Modular Asynchronous Developable Systems.

E qui Akademgorodok torna sul tema del parallelismo.

L'idea generale era costruire sistemi:

MODULARI
    +
ASINCRONI
    +
ESPANDIBILI
    +
RICONFIGURABILI

Invece di pensare:

QUESTA E' LA CPU
QUESTA E' LA MACCHINA

si pensa qualcosa di più simile a:

           +---------+
           | MODULE  |
           +----+----+
                |
        +-------+-------+
        |               |
        v               v
   +---------+      +---------+
   | MODULE  |      | MODULE  |
   +----+----+      +----+----+
        |                |
        +-------+--------+
                |
                v
           +---------+
           | MODULE  |
           +---------+

La macchina è quindi l'insieme dei moduli e delle loro relazioni.

Vista oggi, questa mentalità ricorda:

• manycore;
• compute tile;
• network-on-chip;
• transputer;
• message passing;
• chiplet architectures.

Naturalmente non bisogna proiettare direttamente tecnologie moderne nel passato.

Ma il tipo di domanda architetturale è sorprendentemente simile.

Recursive architectures e tagged architectures: non sono esattamente Kronos

Qui occorre distinguere bene alcune cose che avevo compresso troppo nella lista iniziale.

Le recursive architectures appartengono principalmente al filone legato a Glushkov e ad altri gruppi che lavoravano esplicitamente su architetture non-von-Neumann.

Le tagged architectures hanno invece una storia parzialmente differente.

Un'architettura tagged associa a una parola di memoria non soltanto il valore, ma anche informazione sul tipo dell'oggetto.

Una memoria tradizionale vede:

+------------------------------+
|       0101010101010101       |
+------------------------------+

La CPU deve decidere dal contesto se quei bit significano:

integer
pointer
instruction
float
character
...

In una tagged architecture l'oggetto assomiglia invece a:

+---------+------------------------------+
|   TAG   |           VALUE              |
+---------+------------------------------+

per esempio:

+---------+------------------------------+
| INTEGER |          123456              |
+---------+------------------------------+

+---------+------------------------------+
| POINTER |          0xABCD              |
+---------+------------------------------+

+---------+------------------------------+
| CODE    |           ...                |
+---------+------------------------------+

L'hardware può quindi sapere che cosa sta manipolando.

Questo tipo di idea compare con particolare forza nella famiglia Elbrus.

Kronos, invece, è meglio descritto come:

STACK MACHINE
      +
HIGH-LEVEL-LANGUAGE MACHINE
      +
MODULAR ARCHITECTURE

non semplicemente come “recursive tagged machine”.

Il punto comune: eliminare il divorzio fra problema e macchina

A questo punto si può vedere un filo comune.

Una CPU convenzionale riceve un problema del mondo reale:

PROBLEMA
   |
   v
MODELLO MATEMATICO
   |
   v
ALGORITMO
   |
   v
LINGUAGGIO
   |
   v
COMPILATORE
   |
   v
ISTRUZIONI
   |
   v
CPU

Ogni passaggio distrugge un po' della struttura originale del problema.

Alla fine una cosa che magari nasce come:

          A
        /   \
       B     C
      / \   / \
     D   E F   G

diventa:

LOAD
LOAD
ADD
STORE
LOAD
CALL
JUMP
...

Molti dei progetti sovietici più strani provano invece ad accorciare quella catena.

M-9:

FUNZIONE MATEMATICA
        |
        v
OPERANDO HARDWARE

REFAL:

ESPRESSIONE SIMBOLICA
        |
        v
OGGETTO COMPUTAZIONALE

Glushkov:

GRAFO DEL PROBLEMA
        |
        v
STRUTTURA DELLA COMPUTAZIONE

Kronos:

COSTRUTTO DEL LINGUAGGIO
        |
        v
COSTRUTTO DELLA CPU

Macro-pipeline:

FASE DELL'ALGORITMO
        |
        v
UNITA' DI ESECUZIONE PARALLELA

Questa è probabilmente la cosa veramente “aliena”.

SKIF: interessante, ma appartiene a un'altra epoca

Infine c'è SKIF.

SKIF non è propriamente sovietico.

È un programma russo-bielorusso nato dopo il 2000 e orientato alla costruzione di supercomputer cluster.

A quel punto l'hardware non ha più l'aspetto esotico delle vecchie macchine:

+---------+      +---------+      +---------+
|  NODE   |------|  NODE   |------|  NODE   |
|  Linux  |      |  Linux  |      |  Linux  |
+---------+      +---------+      +---------+
     |                |                |
     +----------------+----------------+
                      |
                  NETWORK

CPU commodity, cluster, sistemi operativi relativamente convenzionali.

Ma una parte della vecchia filosofia riappare nei sistemi software per il parallelismo.

In particolare nella T-system ritorna una domanda tipica di quella scuola:

Perché deve essere il programmatore a specificare manualmente tutta la sequenza di esecuzione, se può limitarsi a dichiarare le dipendenze?

Il modello diventa più simile a:

        TASK A ----\
                    \
                     >---- TASK C ----\
                    /                  \
        TASK B ----/                    >---- TASK E
                                       /
        TASK D -----------------------/

Il programmatore descrive il grafo.

Il runtime decide:

quali task sono pronti?

dove posso eseguirli?

quanti processori ho?

come distribuisco il lavoro?

Ed ecco l'ironia storica.

Negli anni Sessanta:

Costruiamo hardware strano per esprimere naturalmente il parallelismo.

Negli anni Duemila:

Va bene, usiamo CPU normali. Facciamo diventare strano il runtime.

Una linea evolutiva alternativa

Se mettiamo tutte queste idee in una tabella concettuale, viene fuori qualcosa di interessante:

La linea evolutiva che ha vinto commercialmente può essere grossolanamente rappresentata così:

VON NEUMANN
     |
     v
CPU GENERAL PURPOSE
     |
     v
REGISTRI + MEMORIA
     |
     v
ASSEMBLER
     |
     v
C / FORTRAN
     |
     v
UNIX
     |
     v
RISC / x86
     |
     v
ENORMI STRATI DI SOFTWARE

Molti di questi filoni sovietici provavano invece qualcosa del genere:

        PROBLEMA
           |
           v
   STRUTTURA MATEMATICA
           |
           v
 "CHE MACCHINA SERVE PER
  RAPPRESENTARLA DIRETTAMENTE?"
           |
           v
       ARCHITETTURA

E questa è la differenza fondamentale.

La linea classica continua a chiedersi:

Come facciamo a eseguire più velocemente una sequenza di istruzioni?

Questi gruppi continuavano invece a chiedersi:

Perché stiamo rappresentando il problema come una sequenza di istruzioni?

Ed è una domanda molto più profonda.

Il ritorno delle vecchie idee

La parte divertente è che molte di queste idee, viste dal presente, non sembrano affatto morte.

Non perché ci sia necessariamente una genealogia diretta.

Spesso non c'è.

Ma davanti agli stessi problemi, l'informatica moderna ha ricominciato a inventare strutture sorprendentemente simili.

M-9:

M-9
 |
 +----> array processor
 |
 +----> GPU
 |
 +----> tensor processor

Macro-pipeline:

MACRO-PIPELINE
      |
      +----> DAG scheduler
      |
      +----> stream processing
      |
      +----> distributed workflow

REFAL:

REFAL
 |
 +----> term rewriting
 |
 +----> compiler IR transformations
 |
 +----> symbolic execution
 |
 +----> program specialization

Kronos:

KRONOS
 |
 +----> JVM
 |
 +----> CLR
 |
 +----> WebAssembly
 |
 +----> language-oriented VM

Recursive/dataflow machines:

DATAFLOW / RECURSIVE MACHINE
           |
           +----> lazy evaluation
           |
           +----> graph reduction
           |
           +----> futures
           |
           +----> task graphs

Non significa che le tecnologie moderne derivino direttamente da quelle sovietiche.

Significa qualcosa di forse ancora più interessante:

quando il problema ritorna, certe soluzioni matematiche ritornano con lui.

E probabilmente il caso più spettacolare rimane M-9.

Perché dire:

"una funzione è un operando hardware"

nel 1967 non significa semplicemente progettare una CPU veloce.

Significa avere già smesso di pensare che la CPU debba necessariamente essere una macchina che prende un numero alla volta e gli fa qualcosa.

E da lì in poi, praticamente, può succedere di tutto.

Quindi si, sono esistiti computer “comunisti” nel senso che soltanto l'organizzazione finanziaria di un sistema comunista, indifferente al problema “successo sul mercato”, poteva finanziare.

E le idee venivano da “partiamo dall'idea che gli occidentali stiano sbagliando perche' non capiscono Marx. che succede se noi....”

Ed e' uscita roba davvero aliena.

Se io finissi nel Medioevo, probabilmente potrei anticipare alcune tecniche, ma sarebbero poca cosa rispetto a ciò che conosco oggi. Sarei forse riconosciuto come inventore, magari persino come inventore geniale, ma poco più. In campo militare potrei forse accelerare lo sviluppo e la diffusione di artiglierie e razzi, ma non potrei davvero dire di averli inventati: i razzi a polvere esistevano già nella Cina medievale, e l’artiglieria a polvere comparve anche in Europa durante il tardo Medioevo.

Potrei forse tentare qualcosa nel campo delle macchine termiche. Il problema è che conoscere il principio di funzionamento di una macchina non significa automaticamente essere capaci di costruirla con la tecnologia disponibile. Con le tecniche metallurgiche e meccaniche medievali non è semplice produrre un cilindro, un pistone e soprattutto delle tenute abbastanza precise da ottenere una macchina efficiente.

Qualcosa concettualmente simile a una primitiva macchina di Stirling sarebbe forse possibile, almeno come dimostratore: il principio è relativamente semplice e non richiede una caldaia ad alta pressione. Ma tra sapere come dovrebbe funzionare e costruirne una capace di erogare una potenza realmente utile rimarrebbe una distanza tecnologica considerevole. Non a caso il primo motore Stirling realmente impiegato risale al 1818.

Magari, con espedienti come accoppiamenti tra bronzo e ferro, qualcosa si potrebbe fare, ma sarebbe complicato. Bisognerebbe sperimentare parecchio con le combinazioni di materiali disponibili all'epoca: bronzo e ferro, bronzo e pietra, ferro e pietra, legno dove possibile. Ma ne uscirebbero facilmente macchine complicatissime, inefficienti e fragili.

Il problema, cioè, è che mi mancherebbero le fondamenta tecnologiche necessarie per portare all'indietro delle nozioni che, per noi, sono elementari.

Io so perfettamente cos'è un pistone. So come funziona un cilindro. So cos'è una valvola, conosco una macchina a vapore e conosco il principio di una macchina di Stirling. Ma questo non significa che sappia costruire, partendo da una fucina medievale, un cilindro abbastanza regolare, un pistone abbastanza preciso, delle tenute affidabili e delle superfici lavorate con tolleranze sufficienti.

E non è soltanto una questione di conoscenze: dietro oggetti che oggi consideriamo banali esiste una supply chain notevole. Servono materiali con caratteristiche abbastanza prevedibili, utensili capaci di lavorarli, altri utensili capaci di costruire quegli utensili, sistemi di misura, tecniche di fusione e lavorazione, e persone che sappiano fare tutte queste cose con una certa ripetibilità. Insomma: potrei portare nel Medioevo l'idea della macchina. Ma non necessariamente la civiltà industriale necessaria per costruirla.

Abbiamo due problemi, quindi, se vogliamo tornare indietro e fare tutto il lavoro daccapo.

Per prima cosa, le fondazioni. Bisogna avere idea di come si costruiscono le cose. Non semplicemente di come funzionano, ma proprio di come si costruiscono. Probabilmente, già nel Rinascimento, con i materiali giusti e una quantità indecente di tentativi, si sarebbe potuto costruire qualcosa che oggi riconosceremmo come un rudimentale dispositivo a semiconduttore: per esempio un raddrizzatore a cristallo. Il problema sarebbe stato ottenere materiali abbastanza puri e contatti abbastanza affidabili da mostrare qualcosa di ripetibile.

E alla fine quale sarebbe stata la grande dimostrazione? «Guardate: la corrente passa molto meglio in una direzione che nell'altra».

E loro: e che diavolo sarebbe questa “corrente”?

Fantastico.

Non sarebbe fregato un cazzo a nessuno, considerando il lavoro necessario per ottenere materiali decenti e il fatto che, intorno a quell'oggetto, non esisteva ancora praticamente nulla che potesse servirsene.

Il secondo problema è, appunto, la supply chain.

Non riuscirete mai a ottenere una tecnologia senza avere prima almeno una parte della base industriale necessaria a costruirla.

Erone di Alessandria, nel I secolo, descriveva già l'eolipila: una sfera fatta ruotare dalla reazione di getti di vapore. Quindi il principio secondo cui il vapore poteesse produrre movimento era lì, visibile, quasi duemila anni prima della rivoluzione industriale.

Ma era poco più di un dispositivo dimostrativo. Girava, certamente, ma non era una macchina progettata per trasferire quantità significative di potenza a un carico.

Per arrivare a una macchina a vapore che funzioni davvero non basta sapere che il vapore spinge.

Occorrono cilindri sufficientemente regolari, pistoni che combacino abbastanza bene, valvole, tenute, metallurgia ripetibile, strumenti di misura e soprattutto macchine utensili capaci di costruire con precisione altre macchine. Quando nel Settecento si cominciarono a produrre cilindri molto più precisi mediante alesatura, le macchine a vapore fecero un salto enorme.

Occorre quindi finire in un mondo sufficientemente avanzato da consentire l'invenzione, non semplicemente la scoperta.

Per quanto noi sappiamo immensamente più di quanto si sapesse nel passato, probabilmente non riusciremmo a spacciarci per grandi scienziati. Molti dei principi che conosciamo sarebbero incomprensibili, oppure completamente inutili senza tutto ciò che deve esistere intorno a essi.

Potremmo invece diventare grandi inventori, a una condizione: dominare abbastanza bene la tecnologia primitiva del periodo e, contemporaneamente, conoscere il passo immediatamente successivo.

Non si tratta di prendere uno stadio tecnologico n e saltare direttamente a n + 100. A n mancano precisamente le novantanove industrie, tecniche, conoscenze pratiche e supply chain necessarie per costruire n + 100.

Bisogna procedere per piccoli passi: da n a n + 1.

Saremmo forse più fortunati nelle arti “liberali”, perché lì alcune idee richiedono molta meno infrastruttura materiale.

Potremmo anticipare la scoperta europea delle Americhe, per esempio, con tutte le conseguenze devastanti che ne deriverebbero. Potremmo portare ai Romani un sistema contabile basato sulla partita doppia: avevano una contabilità sorprendentemente sviluppata, ma non risulta che possedessero la partita doppia nel senso che acquisterà più tardi nel mondo mercantile italiano.

Oppure potremmo semplicemente spiegare ai medici di lavarsi le mani.

Persino con l'ottica incontreremmo lo stesso problema. Produrre lenti veramente buone è complicatissimo: bisogna saper scegliere il vetro, lavorare le superfici con precisione, controllarne la curvatura e lucidarle senza rovinarne la geometria. Non per niente bisogna arrivare all'epoca di Galileo perché il telescopio diventi rapidamente uno strumento realmente utile.

Potremmo pensare di aggirare il problema usando uno specchio. L'idea del telescopio riflettore non richiede affatto Newton per essere concepita: già all'inizio del Seicento si fecero tentativi con specchi concavi, ma ottenere uno specchio con la forma e la superficie necessarie per produrre un'immagine decente era a sua volta un notevole problema tecnologico.

E anche qui bisognerebbe trovare l'ascoltatore giusto.

Galileo lo trovò nella Repubblica di Venezia. Nel 1609 mostrò il suo cannocchiale alla Signoria e ai senatori veneziani facendo osservare, dai campanili, navi che erano ancora così lontane da richiedere ore prima di diventare visibili a occhio nudo. L'utilità militare e commerciale dello strumento era immediatamente evidente.

E i telescopi per usi militari diventarono anche un'attività economicamente interessante: all'inizio del 1610 Galileo scriveva di averne già costruiti più di sessanta, molti dei quali finirono venduti o distribuiti.

Questo, per fare un esempio, funzionava.

Ma difficilmente riusciremmo ad andare molto oltre.

E qui sarebbe la mia teoria. Un uomo del futuro, a patto di avere conoscenze simili a quelle di Cyrus Smith, l’ingegnere de L’isola misteriosa di Jules Verne, uno di quegli ingegneri ottocenteschi letterari che non sanno soltanto come funzionano le cose: sanno come rifarle partendo quasi da zero. non apparirebbe come uno scienziato geniale, al massimo come un ingegnere creativo, o un creativo tout-court.

Ecco la mia teoria: un uomo del futuro sarebbe indistinguibile da un inventore del suo tempo, e un inventore del suo tempo da un uomo del futuro.

A sostegno, ho un esempio.

Cosa direste se io vi spiegassi che nel 1987 — e ripeto: nel 1987 — qualcuno aveva costruito, non semplicemente immaginato, una macchina che anticipava concettualmente CUDA, il calcolo su GPU, il data-parallel computing, il superparallelismo, il calcolo vettoriale massivamente parallelo, i virtual processor, la memoria distribuita, il routing hardware tra migliaia di unità di calcolo, le operazioni globali di reduce e broadcast, il graph computing, le sparse matrix operations, le simulazioni cellulari, le reti neurali parallele e perfino, in forma ancora embrionale, l'idea che convenga portare il calcolo verso i dati invece di spostare continuamente i dati verso un unico processore?

Non aveva “inventato CUDA”, naturalmente. Non aveva “inventato MapReduce”. Non aveva “inventato le GPU”.

Aveva però già messo insieme molti dei concetti architetturali che oggi consideriamo moderni: migliaia di processori semplici, enormi quantità di parallelismo, dati distribuiti, comunicazione tra nodi gestita dalla macchina, e un modello di programmazione nel quale non si pensa più a un processore che esegue una sequenza di istruzioni, ma a una popolazione di processori che esegue contemporaneamente operazioni su una popolazione di dati.

Nel 1987.

Parliamo dei sistemi di CM, la “Connection Machine”.

La Connection Machine non fu una singola macchina, ma una famiglia progettata da Thinking Machines, la società fondata da Danny Hillis e Sheryl Handler. Il punto interessante, è che CM-1 e soprattutto CM-2, del 1987, sembrano quasi un catalogo di idee che oggi consideriamo normali, solo realizzate quando il normale computer era ancora sostanzialmente una CPU abbastanza grossa che parlava con una memoria abbastanza grossa.

La CM-2 poteva avere 65.536 processori elementari, ciascuno semplicissimo e dotato della propria memoria. Non cercava quindi di costruire un processore mostruosamente veloce: cercava di costruire una quantità mostruosa di processori piccoli. Oggi diremmo massively parallel computing. È la stessa inversione concettuale che sta dietro alle GPU moderne: non fare un'operazione alla volta molto velocemente, ma fare una quantità enorme di operazioni contemporaneamente.

E qui cominciano le genialate.

• Un'istruzione, una quantità enorme di dati. La CM-1 e la CM-2 erano SIMD: un controllo centrale diceva a migliaia di processori di eseguire contemporaneamente la stessa operazione sui propri dati. Oggi il parente concettuale più evidente è GPU computing, CUDA, OpenCL, SIMT/data parallelism. Non è CUDA ante litteram, ma l'idea fondamentale è quella: scrivo essenzialmente cosa deve succedere a ciascun elemento, e la macchina lo fa in parallelo su una popolazione enorme di elementi.
• Il computer principale diventa il coordinatore dell'acceleratore. La Connection Machine aveva normalmente un computer convenzionale davanti — una workstation Sun, una VAX o una Lisp Machine — che eseguiva il programma e impartiva il lavoro alla macchina parallela. Oggi diremmo, molto naturalmente, host CPU + accelerator: praticamente il modello con cui programmiamo una GPU.
• I dati stanno vicino al processore che li usa. Ogni processing element disponeva della propria memoria. Non c'era l'idea di decine di migliaia di CPU che litigano per accedere a un'unica RAM centrale: dati e computazione venivano distribuiti. Oggi questo concetto ricompare continuamente sotto nomi diversi: distributed memory, local memory, NUMA, accelerator memory, compute-near-data. La documentazione del successivo CM-5 dice esplicitamente che, aumentando i processori, memoria condivisa e bus diventano colli di bottiglia e che quindi memoria e comunicazione devono essere distribuite.
• Non programmi i processori: programmi i dati. In Lisp, C e successivamente CM Fortran si potevano descrivere strutture di dati parallele e applicare operazioni collettivamente. La documentazione di Thinking Machines fa esempi quasi comici da leggere oggi: un documento per processore, un pixel per processore, una cella di automa per processore. Oggi diremmo array programming, data-parallel programming, kernels, tensor operations, e in parte penseremmo a CUDA, NumPy, JAX o framework simili.
• Più elementi logici che processori fisici. La CM possedeva i cosiddetti virtual processors. Il programmatore poteva ragionare come se avesse molti più processori di quelli realmente installati; l'hardware e il software multiplexavano gli elementi virtuali sui processori fisici. Si arrivava a oltre un milione di processori virtuali. Oggi l'idea ci sembra banalissima: logical threads, work items, massive oversubscription, cioè descrivere un parallelismo logico molto superiore alle unità fisiche disponibili e lasciare alla piattaforma il compito di schedularlo.
• La rete faceva parte del computer. I 4.096 chip della CM-1/CM-2 erano collegati secondo un ipercubo a dodici dimensioni, così che qualunque chip fosse raggiungibile in non più di dodici passi. Inoltre esisteva hardware dedicato al routing dei messaggi. Oggi penseremmo immediatamente a high-speed interconnect, network-on-chip, cluster fabric, e a tutto il problema moderno di come spostare dati velocemente tra migliaia di unità di calcolo.
• Il routing non era lasciato al programmatore. Tu descrivevi dove dovevano finire i dati; la rete della CM provvedeva a farli arrivare, gestendo contemporaneamente un numero enorme di comunicazioni. Concettualmente è molto vicino all'idea moderna di message routing hardware, delle fabric HPC e, più alla lontana, di cose come RDMA: il trasferimento dei dati non deve trasformarsi in un lavoro manuale della CPU centrale.
• Operazioni collettive. Broadcast, comunicazioni globali, combinazione e distribuzione di risultati erano parte naturale del modello. È qui che puoi citare con prudenza map/reduce: non il MapReduce di Google, che comprende un modello distribuito, fault tolerance, shuffle su cluster eccetera, ma le primitive concettuali map, reduce, scan, broadcast e redistribuzione dei dati erano precisamente il genere di operazioni per cui quelle macchine erano costruite.
• Sparse matrix e graph computing. Una macchina nella quale ogni elemento possiede dati propri e può comunicare attraverso una rete era naturalmente interessante per grafi, matrici sparse, automi cellulari, PDE e simulazioni fisiche. Oggi diremmo graph processing, sparse computation, scientific GPU computing. Già nel 1988 venivano pubblicati risultati di calcolo scientifico su tutti i 65.536 processori della Connection Machine.
• Reti neurali sulla macchina parallela. La Connection Machine nasceva esplicitamente anche dall'ambiente dell'AI del MIT e dall'idea di ottenere comportamento complesso da un'enorme quantità di elementi semplici interconnessi. Non era una GPU per il deep learning, ovviamente; ma era una piattaforma quasi naturalmente adatta al connectionism, alle reti neurali e ai modelli nei quali molti nodi fanno simultaneamente operazioni semplici. Ed è difficile non vedere la parentela filosofica con gli acceleratori AI odierni.
• Acceleratori specializzati dentro una macchina parallela. La CM-2 aggiunse unità hardware in virgola mobile condivise da gruppi di processori elementari. Anche qui non direi “tensor core del 1987”, perché sarebbe troppo; ma l'idea di avere una massa di elementi generalissimi affiancata da unità specializzate per le operazioni numeriche costose è terribilmente moderna.
• Storage parallelo. Il DataVault distribuiva i dati su molti dischi e più DataVault potevano lavorare contemporaneamente; i dati potevano essere trasferiti direttamente verso le sezioni della macchina parallela. Oggi diremmo striped parallel storage / parallel I/O. E il DataVault adottava ridondanza ed error correction in una forma che retrospettivamente viene classificata come RAID-2, prima ancora che il termine RAID diventasse comune.
• La rete diventa più importante del singolo processore. Questa idea diventa ancora più evidente con la CM-5 del 1991: Thinking Machines abbandona il gigantesco SIMD di processori a un bit, passa a centinaia o migliaia di nodi SPARC con memoria locale e costruisce attorno a essi una fat-tree network ad alta banda. Oggi una fat tree/Clos è esattamente il genere di struttura che associamo ai grandi cluster e ai data center. La CM-5 aveva addirittura reti separate per dati, controllo e diagnostica.
• SIMD quando conviene, MIMD quando serve. La CM-5 non obbligava più tutti i nodi a fare esattamente la stessa cosa: potevano operare indipendentemente, ma restava il supporto per l'esecuzione sincronizzata data-parallel. Oggi diremmo che stai combinando distributed computing, SPMD e vector/SIMD acceleration nella stessa macchina.

E secondo me la genialata più premonitrice non è nessuna di queste singolarmente.

È l'astrazione.

Hillis aveva sostanzialmente detto: smettiamo di pensare al computer come a un processore che possiede della memoria. Pensiamolo come a una popolazione di elementi computazionali che possiedono ciascuno dei dati, e costruiamo una rete abbastanza intelligente da permettere loro di collaborare.

Nel 1987 sembrava una maniera piuttosto esotica di costruire un supercomputer. Eccola, in una foto.

E faccio notare che quei LED non servivano praticamente a nulla.

Ma qualcuno, evidentemente, aveva già deciso che se mettevi un computer dentro un rack alto quanto un armadio, allora ci dovevano essere dei LED. Molti LED. Possibilmente abbastanza da far capire, anche da lontano, che lì dentro stava succedendo qualcosa di molto interessante.

Oggi si chiama semplicemente un rack.

Ma nel 1987 quasi tutta l'industria dei supercomputer stava andando nella direzione opposta.

L'idea dominante era: costruire pochi processori sempre più potenti, sempre più veloci, con registri vettoriali enormi e memorie capaci di alimentarli abbastanza in fretta. Era, grosso modo, la filosofia Cray.

La Connection Machine faceva quasi il contrario: prendeva decine di migliaia di processori stupidissimi, dava loro della memoria locale, li collegava con una rete mostruosa e diceva: adesso lavorate tutti insieme.

Non era la prima macchina parallela della storia, naturalmente. Esistevano già SIMD, vector processor e predecessori come ILLIAC IV.

Ma nessuno aveva portato quella filosofia fino a quel livello di esasperazione: 65.536 processori, (nel cazzo di 1987!!!!) virtual processor, memoria distribuita, routing hardware e un modello di programmazione nel quale il programmatore ragionava sui dati, non sulla CPU.

Cray, che in quel periodo rappresentava praticamente l'aristocrazia del supercomputing, sarebbe arrivata al massively parallel processing soltanto negli anni Novanta.

E quando ci arrivò, con il Craylink e il uniCOS e tutto quanto, il mondo che Thinking Machines aveva cominciato a costruire sembrava già molto meno assurdo.

Potete continuare a studiare la macchina, e troverete cose come un'architettura di interconnessione a ipercubo a dodici dimensioni, nella quale ogni nodo è identificato da un indirizzo binario e ogni bit dell'indirizzo corrisponde, di fatto, a una dimensione del cubo.

Per capire quali passi separano due nodi basta fare lo XOR dei loro indirizzi: ogni bit a uno segnala una dimensione lungo la quale bisogna ancora muoversi. La distanza tra due punti dell'ipercubo diventa quindi semplicemente il numero di bit diversi tra i due indirizzi, cioè la loro distanza di Hamming.

In pratica, un “lattice” a dodici dimensioni nel quale una parte enorme del problema del routing viene ridotta a operazioni logiche elementari sugli indirizzi, invece di richiedere tabelle gigantesche o algoritmi complicati per decidere ogni volta dove mandare un dato.

E tutto questo non era un esercizio accademico: serviva a far comunicare migliaia di processori e a spostare enormi quantità di dati attraverso la macchina senza trasformare la rete interna nel collo di bottiglia dell'intero sistema.

Ed è questo che fa impressione.

Più si entra nei dettagli, più si trovano idee che oggi ci sembrano naturali: topologie pensate per scalare, indirizzamento che incorpora la geometria della rete, routing hardware, parallelismo spinto, memoria distribuita, calcolo vicino ai dati.

C'è tanta di quella roba che oggi chiameremmo moderna lì dentro, e così poca roba che sembra appartenere davvero al 1987, da fare quasi paura.

E poi, l'idea di metterci led inutili e una forma stravagante, per farle apparire in questo modo:

che diavolo avevano in mente?

Se io vi dicessi che un ingegnere di NVIDIA e uno di IBM, arrivati dal 2026, fossero finiti nel 1987 e avessero costruito un supercomputer usando soltanto i mezzi disponibili all'epoca, ovviamente mi dareste del pazzo.

Ma santiddio, se poi scendessimo nel tecnico, fareste tanta, tanta, tanta fatica a dimostrare che la storia è inverosimile.

Perché quasi tutti i concetti avanzati che riconosciamo nei prodotti del 2026 sono già lì dentro.

Certo: sono costruiti come una macchina di Stirling costruita dai Romani dopo che qualcuno gli ha passato il progetto. Rozza, gigantesca, costosa, fatta con quello che esisteva allora.

Ma l'idea è quella.

Nel 1987 questi avevano già dati distribuiti tra migliaia di memorie locali, processori assegnati ai dati, processori virtuali, routing hardware per spostare informazioni da una parte all'altra della macchina e primitive collettive come scan e reduce.

Non avevano MapReduce nel senso di Google, naturalmente.

Avevano però già costruito buona parte dei meccanismi architetturali dai quali un'idea come MapReduce diventa quasi ovvia: distribuire i dati, portare il calcolo dove sono i dati, fare la stessa operazione su una popolazione di elementi e poi raccogliere o redistribuire i risultati.

In hardware.

Nel 1987.

Certo, i due fondatori non erano dei pirla qualsiasi. E tra quelli che finirono a lavorare sui problemi matematici della macchina c'era anche un tale Richard Feynman.

Perché non ci facciamo mancare niente.

Ma se provo a immaginare due ingegneri arrivati dal 2026, uno di NVIDIA che progetta GPU e uno di IBM che disegna mainframe, finiti per sbaglio nel 1987 e costretti a costruire qualcosa usando soltanto la tecnologia disponibile allora, beh: questo è più o meno quello che farebbero.

Prenderebbero migliaia di processori relativamente stupidi, distribuirebbero la memoria, costruirebbero una rete per farli comunicare, inventerebbero un modo per assegnare enormi quantità di dati a enormi quantità di unità di calcolo e cercherebbero di nascondere tutta questa mostruosità dietro un'astrazione programmabile.

Ah, sì.

Oggi una parte importante di tutto questo la chiamiamo semplicemente GPU.

E allora il sospetto che, periodicamente, qualcuno cada dal futuro e finisca nel nostro presente diventa, santiddio, difficile da togliersi dalla testa.

E ri-ecco la mia teoria: un uomo del futuro sarebbe indistinguibile da un inventore del suo tempo, e un inventore del suo tempo da un uomo del futuro.

Tadaaa...

Il concetto di gap, cioè quanto manca per arrivare a X, si definisce come la differenza tra X e lo stato attuale.

Il primo problema di chi calcola il famoso «gap con gli USA» è quindi piuttosto semplice: considera X, cioè il punto di arrivo, come lo stato attuale degli Stati Uniti.

E da questa assunzione iniziale discende poi tutta una serie di errori logici che, passando per think tank, consulenti e comunicati vari, finisce regolarmente sulle pagine dei giornali.

Il GAP tra UE e USA, se lo definite in questo modo, rimarrà SEMPRE.

Per la semplice ragione che la UE non può — prima di tutto per ragioni politiche, istituzionali e di struttura del mercato — diventare una copia degli Stati Uniti sul piano dell'industria IT.

E soprattutto non sembra nemmeno essere questo il punto di arrivo che l'Unione si sta dando.

Per capirci.

La UE è fatta di 27 nazioni, ciascuna con una propria economia, un proprio sistema industriale, interessi nazionali e una propria sensibilità politica.

Supponiamo di voler replicare banalmente il modello americano del cloud, creando due attori enormi, qualcosa di equivalente, diciamo, ad Azure e AWS.

Questi due attori sarebbero aziende. E le aziende, persino quando operano su scala continentale, hanno una sede, un centro decisionale, una proprietà, una fiscalità, un ecosistema industriale attorno e inevitabilmente un luogo nel quale una parte importante del valore economico prodotto finisce per concentrarsi.

Diciamo allora che i quartier generali dei nostri due ipotetici colossi europei si trovino nella nazione X e nella nazione Y.

Se X e Y fossero due grandi economie europee, diciamo due paesi del top 3 del PIL della UE, gli Stati più piccoli avrebbero immediatamente il problema di trovarsi tecnologicamente dipendenti da aziende enormi concentrate nelle economie già dominanti.

Avremmo cioè costruito, dentro l'Unione, qualcosa che assomiglia molto al problema dal quale stiamo cercando di uscire: una dipendenza strutturale da pochissimi fornitori giganteschi, semplicemente sostituendo Seattle o Redmond con qualche città europea.

Non sarebbe esattamente un trionfo della sovranità digitale.

Se invece X e Y fossero due nazioni relativamente piccole, succederebbe probabilmente il contrario: le grandi economie europee avrebbero tutto l'interesse economico, industriale e politico a finanziare concorrenti nazionali capaci di ridurre quella dipendenza.

Insomma: un modello costituito da pochissimi giganti, sul modello americano, nella UE incontra PRIMA DI TUTTO un problema POLITICO.

Questo non significa che in Europa sia impossibile far nascere aziende gigantesche. Significa qualcosa di diverso: che un mercato digitale europeo strutturato esattamente come quello americano non è uno stato finale particolarmente plausibile, e soprattutto non è l'unico possibile metro con cui misurare il successo.

Anzi, le politiche europee più recenti sul cloud parlano esplicitamente di interoperabilità, portabilità, concorrenza, infrastrutture federate, edge computing e riduzione della dipendenza da pochi fornitori extra-UE. Persino l'infrastruttura Telco-Edge-Cloud che la Commissione ha finanziato nel 2026 viene descritta esplicitamente come federata, non come il tentativo di fabbricare artificialmente un «AWS europeo».

E questa non è una sottigliezza terminologica.

È un'architettura industriale differente.

Lo stesso vale per la AI.

Anche qui il dibattito giornalistico tende a fare una classifica abbastanza infantile: OpenAI vale tot, Google vale tot, Anthropic vale tot, quindi dov'è «la OpenAI europea»?

E se non c'è una società europea identica, con la stessa capitalizzazione, lo stesso numero di GPU e la stessa capacità di bruciare miliardi, allora l'Europa sarebbe automaticamente «indietro».

Ma ancora una volta si sta scegliendo arbitrariamente il modello americano come unità di misura.

La strategia europea attuale comprende certamente infrastrutture enormi: la Commissione ha avviato 19 AI Factories in 16 Stati membri, accompagnate da ulteriori AI Factory Antennas, e sta lavorando alla creazione di un massimo di cinque AI Gigafactories, con circa 20 miliardi di euro previsti per mobilitarne la realizzazione. Quindi non è affatto vero che l'Europa abbia deciso di giocare soltanto con piccoli laboratori universitari e Raspberry Pi.

Ma anche qui il modello è diverso.

L'obiettivo dichiarato comprende accesso condiviso alla capacità di calcolo, sviluppo di un ecosistema industriale europeo, infrastrutture distribuite tra gli Stati membri, maggiore autonomia tecnologica e riduzione della dipendenza da fornitori non europei. Nel giugno 2026 la Commissione ha persino presentato un nuovo pacchetto sulla European Technological Sovereignty che mette insieme cloud, AI, semiconduttori e open source precisamente sotto questa logica.

E tutto questo avviene contemporaneamente ad una politica della concorrenza che considera esplicitamente problematico il potere dei grandi gatekeeper digitali e cerca di mantenere i mercati contendibili. Il DMA nasce precisamente dentro questa filosofia.

Quindi immaginare come obiettivo finale dell'Europa la creazione di quattro o cinque mostri monopolistici europei identici a quelli americani, e poi misurare il nostro «ritardo» contando quanti di questi mostri abbiamo già prodotto, significa probabilmente misurare la distanza dalla destinazione sbagliata.

Per capire meglio la difficoltà politica, immaginate per un momento di avere in Europa, che so io, in Francia, un Elon Musk della situazione.

Pomposo. Presuntuoso. Cialtrone. Sprezzante e stupido.

E adesso immaginate che Monsieur le Musk, dalla Francia, cominci a fare contro il vostro paese qualcosa di simile a quello che Musk ha fatto nella politica europea.

Che cominci ad usare il proprio media per influenzare le vostre elezioni. Che sostenga apertamente un partito politico del vostro paese, che ne amplifichi i messaggi, che intervenga durante la campagna elettorale, magari comparendo persino ai suoi eventi. Musk lo ha fatto davvero durante la campagna elettorale tedesca del 2025: ha sostenuto pubblicamente AfD, ha ospitato Alice Weidel su X invitando i tedeschi a votarla ed è apparso in video ad un evento elettorale del partito.

Che mandi i suoi uomini, i suoi consiglieri, i suoi contatti politici a costruire relazioni con partiti locali. Che utilizzi la propria enorme capacità di amplificazione per spostare l'agenda politica e alterare il peso relativo delle diverse voci nel dibattito pubblico.

Non sto dicendo, attenzione, che Musk possa magicamente decidere il risultato di un'elezione. Anzi, le analisi disponibili sulla Germania non dimostrano affatto che abbia determinato il risultato elettorale. Il punto è diverso: un proprietario privato di una grande infrastruttura mediatica può decidere di entrare personalmente nella politica di un altro paese, usando contemporaneamente denaro, notorietà e controllo della piattaforma. Ed è esattamente questo che ha prodotto il dibattito sull'interferenza di Musk nella campagna tedesca.

Ma stavolta immaginiamo che non sia americano.

Stavolta è francese.

E magari voi siete tedeschi. O italiani. O polacchi. O spagnoli.

Sareste davvero disposti a lasciar correre in nome dell'«Unità Europea» un comportamento simile?

Perché quando il miliardario è americano la faccenda, paradossalmente, sembra più semplice da raccontare. Negli Stati Uniti Musk può accumulare un'enorme influenza politica e qualcuno può persino interpretarla come la solita storia americana del miliardario di successo che cerca di trasformare il proprio potere economico in potere politico.

Ma trasferite la stessa dinamica dentro l'Europa.

Immaginate un miliardario francese proprietario di una piattaforma usata da milioni di tedeschi che decide chi sostenere alle elezioni tedesche.

Oppure un miliardario tedesco che usa il proprio social network per spiegare agli italiani quale partito debbano votare.

Oppure uno spagnolo che comincia a finanziare, amplificare e promuovere movimenti politici polacchi perché il governo di Varsavia non gli piace.

A quel punto la questione cambia immediatamente natura.

Non avete più soltanto una concentrazione di mercato.

Avete una concentrazione transnazionale di potere politico privato.

Ed è qui che il modello americano dei giganteschi campioni tecnologici diventa politicamente molto più difficile da riprodurre nell'Unione Europea. Perché NESSUNO vorrebbe davvero trovarsi con un miliardario di un altro Stato membro capace di fare il bello e il cattivo tempo nella propria politica nazionale.

Nessuno.

E questa è precisamente una delle difficoltà politiche della UE che, personalmente, considero salutare.

La UE è fatta di 27 Stati.

Ventisette governi, ventisette sistemi politici, ventisette opinioni pubbliche, ventisette storie nazionali e soprattutto ventisette paesi che hanno deciso di stare insieme a condizione che nessuno possa pisciare davvero in testa agli altri.

Questa struttura rende molte cose esasperantemente lente.

Rende difficile concentrare rapidamente quantità mostruose di capitale.

Rende difficile costruire un singolo centro decisionale continentale.

Rende difficile produrre il classico «campione nazionale» e poi lasciarlo crescere sino a diventare così potente da dettare le condizioni al resto del mercato.

Ma forse questa non è semplicemente una debolezza.

Forse è anche uno dei meccanismi attraverso i quali l'Europa impedisce che una potenza economica privata, nata casualmente dalla parte giusta di una frontiera interna, finisca per trasformarsi in una potenza politica sopra le altre ventisei.

E quindi, quando qualcuno mi mostra Microsoft, Google, Meta, Amazon, Musk e compagnia e domanda:

«Perché l'Europa non ha prodotto la stessa cosa?»

una delle risposte possibili è:

perché non è affatto ovvio che vogliamo produrre la stessa cosa.

E questo è il motivo OVVIO per il quale il punto di arrivo della politica europea sul cloud, sulla AI e in generale sull'infrastruttura digitale non può semplicemente essere una copia della situazione americana.

Qui però bisogna fare una precisazione.

Non è vero che il commissario europeo alla concorrenza interverrebbe necessariamente MOLTO PRIMA che un'azienda diventi grande quanto Amazon, Azure o OpenAI. Essere giganteschi, di per sé, non è vietato. Anzi: oggi la UE sta spendendo parecchi soldi proprio per creare aziende e infrastrutture europee capaci di raggiungere una scala molto maggiore di quella attuale.

Il problema arriva quando la scala produce dominanza, lock-in, dipendenza strutturale e capacità di chiudere il mercato agli altri.

Ed è qui che la differenza diventa interessante.

Per come viene gestita oggi la questione della sovranità informatica europea, il desiderata non sembra essere:

dobbiamo avere UN Amazon europeo, UN Microsoft europeo e UNA OpenAI europea.

Assomiglia molto di più a:

per ogni funzione importante dobbiamo avere più fornitori europei credibili, possibilmente distribuiti tra diversi paesi, interoperabili e sostituibili tra loro.

La mia maniera di riassumerlo, che non è una regola scritta da qualche parte ma rende abbastanza bene l'idea, è questa: un cittadino o un'azienda europea dovrebbero poter trovare almeno una scelta ragionevolmente locale e altre due o tre scelte europee, senza essere obbligati a consegnarsi ad un unico gigante.

E se guardiamo quello che sta succedendo, il panorama comincia effettivamente ad assomigliare a questo.

Cloud

Prendiamo il cloud.

In Francia esistono OVHcloud e Scaleway.

In Germania ci sono IONOS Cloud e STACKIT, la piattaforma cloud di Schwarz Digits, cioè il braccio digitale del gruppo Schwarz, quello di Lidl e Kaufland. STRATO rimane poi un grande attore tedesco nell'hosting, nei server, nella mail e nello storage, anche se oggi appartiene allo stesso gruppo IONOS e quindi non costituisce un concorrente industrialmente indipendente da IONOS.

In Italia c'è Aruba, che non è soltanto quello presso cui vostro cugino ha comprato il dominio nel 2007: possiede propri data center, offre cloud, hosting, mail, PEC e infrastrutture AI, e si presenta esplicitamente come operatore europeo sovrano.

In Spagna c'è Arsys, che partecipa direttamente all'IPCEI-CIS; è però parte del gruppo IONOS, quindi anche qui bisogna distinguere tra presenza locale e indipendenza societaria.

In Polonia troviamo, fra gli altri, Oktawave, anch'essa coinvolta nei progetti europei di nuova generazione cloud-edge.

In Belgio c'è Proximus.

In Lussemburgo POST Luxembourg.

E la cosa interessante è che non sto facendo un elenco di aziende che Bruxelles guarda da lontano sperando che sopravvivano.

La Commissione ha appena assegnato un (altro) contratto da 180 milioni di euro per cloud sovrano europeo a quattro offerte: STACKIT dalla Germania, Scaleway dalla Francia, POST Luxembourg con OVHcloud e Clever Cloud, e Proximus con un consorzio di partner.

E ancora più importante è IPCEI-CIS, il grande progetto europeo Cloud Infrastructure and Services.

Sette Stati membri possono metterci fino a 1,2 miliardi di euro di denaro pubblico, ai quali dovrebbero aggiungersi circa 1,4 miliardi di investimenti privati.

Per fare cosa?

Non per costruire «AWS ma con la bandiera europea».

La descrizione ufficiale parla del primo ecosistema europeo di elaborazione dati interoperabile, apertamente accessibile e multi-provider, dal cloud fino all'edge: infrastrutture distribuite, federate e capaci di lavorare insieme. IONOS, per esempio, riceve finanziamenti per tecnologie destinate alla gestione di workload distribuiti tra cloud ed edge; Arsys lavora dalla Spagna allo stesso progetto; OpenNebula sviluppa il livello open source destinato precisamente alla federazione e alla portabilità dei workload.

Questa cosa ha persino un nome, oggi: 8ra.

Il concetto è che un domani voi possiate avere il vostro workload su un provider tedesco, spostarlo o distribuirlo su uno francese, usare capacità italiana o spagnola, senza dover riscrivere metà dell'azienda perché avete deciso di lasciare il padrone precedente.

E infatti il Data Act europeo contiene obblighi specifici per facilitare switching e portabilità tra cloud provider.

Questo è quasi l'esatto contrario del modello del gigantesco silo proprietario.

Intelligenza artificiale

Con la AI la struttura che sta emergendo è simile, ma ancora più evidente.

La Francia ha Mistral AI, che ormai è senza dubbio uno dei principali attori europei del settore. È una società francese indipendente con sede a Parigi e sta costruendo in Francia anche capacità di calcolo propria su scala molto importante.

La Germania ha Aleph Alpha, oggi fortemente integrata nell'ecosistema Schwarz Digits: PhariaAI viene offerta direttamente sopra STACKIT.

L'Italia ha realtà come iGenius e, su un altro piano, Engineering con la propria architettura IS-IA, costruita attorno a EngGPT 2 e presentata esplicitamente come piattaforma italiana di AI sovrana.

E contemporaneamente OVHcloud ha annunciato di voler addestrare propri frontier model, quindi persino la distinzione fra «cloud provider» e «azienda AI» sta già cominciando a sfumare.

Ma sopra questi campioni nazionali sta crescendo un'altra infrastruttura che è tipicamente europea.

Ci sono ormai 19 AI Factories distribuite in 16 Stati membri, costruite attorno alla rete EuroHPC, che devono mettere GPU, supercomputer, dati e competenze a disposizione di startup, università e aziende.

E sopra queste la UE sta costruendo fino a cinque AI Gigafactories, con strutture progettate per superare i 100.000 acceleratori AI ciascuna e con decine di miliardi di investimenti previsti.

Ancora una volta: non UNA gigantesca OpenAI europea.

Un'infrastruttura continentale distribuita sulla quale possono crescere Mistral, Aleph Alpha, aziende italiane, spagnole, polacche, startup che ancora non esistono e magari qualche futuro mostro che oggi lavora in uno sgabuzzino con quattro GPU.

E qui si vede bene la differenza tra scala e centralizzazione.

La UE vuole la scala.

Eccome se la vuole.

Quello che cerca di evitare è che tutta quella scala appartenga necessariamente ad UN SOLO padrone.

Hosting, domini e posta elettronica

Se scendiamo di livello e andiamo verso servizi molto più quotidiani, la cosa è già visibile da anni.

Un tedesco può comprare dominio, hosting e mail da IONOS, STRATO, Tuta o mailbox.org.

Un italiano ha Aruba, che offre tutto il percorso dal dominio alla posta elettronica, dalla PEC al cloud.

Un francese dispone di OVHcloud e di diversi operatori locali.

Un belga ha Mailfence, che offre posta, calendario, contatti e documenti.

E un cittadino di uno qualsiasi di questi paesi può tranquillamente comprare il servizio da uno degli altri.

Quindi il tedesco non è costretto ad usare il tedesco.

Può usare l'italiano.

L'italiano può usare il francese.

Il francese può usare il tedesco.

E tutti e tre possono cambiare idea.

Per la posta privata esiste persino una costellazione abbastanza interessante di operatori europei specializzati nella privacy: Tuta in Germania e Mailfence in Belgio, per esempio. Proton viene spesso inserita nello stesso gruppo culturale e tecnologico, ma va ricordato che è svizzera: europea geograficamente, NON appartenente alla UE.

Ed è proprio qui che bisogna stare attenti alla parola «locale».

Locale non deve significare:

ogni nazione deve ricostruirsi Google da zero.

Sarebbe stupido, costosissimo e probabilmente impossibile per molti dei 27 Stati.

Il modello sensato è avere alcuni poli nazionali forti e, attorno a loro, abbastanza concorrenti europei perché nessuno diventi indispensabile.

Software e collaboration

Lo stesso principio comincia ad apparire anche nello strato software.

Schwarz Digits, per esempio, ormai non vende soltanto STACKIT.

Sta costruendo un vero stack: cloud STACKIT, Aleph Alpha per la AI, sicurezza informatica, Wire per la messaggistica sicura e Workspace by STACKIT per gli strumenti di produttività.

Questo significa che in Germania sta nascendo qualcosa che comincia vagamente ad assomigliare, per ampiezza dello stack, ad un concorrente locale delle grandi piattaforme americane.

Ma contemporaneamente esistono aziende francesi, italiane, belghe, spagnole e di altri paesi che coprono pezzi sovrapposti dello stesso stack.

Ed è precisamente la sovrapposizione ad essere importante.

Perché se STACKIT diventa bravissima, bene.

Se diventa enorme, ancora meglio.

Se diventa così enorme che non potete più vivere senza STACKIT, allora abbiamo ricreato il problema.

Cybersecurity

Lo stesso fenomeno esiste nella cybersecurity.

In Francia ci sono aziende come Thales e una vasta industria della sicurezza.

In Germania Schwarz Digits possiede XM Cyber, oltre ad avere costruito un ecosistema attorno a STACKIT.

In Italia esistono Leonardo e decine di fornitori specializzati.

Poi queste aziende operano anche negli altri paesi europei.

Ancora una volta non esiste necessariamente «la CrowdStrike europea».

Esiste, o dovrebbe esistere sempre di più, un mercato europeo nel quale diversi attori europei sono abbastanza grandi da fornire gli stessi clienti e nessuno può presentarsi dicendo: senza di me spegnete tutto.

Ed è questa, secondo me, la parte che viene capita meno quando si parla del famoso «ritardo europeo».

Se il metro di misura è:

quanti AWS abbiamo?

la risposta europea sarà sempre deprimente.

Se il metro diventa:

quante infrastrutture indipendenti abbiamo, quanto sono interoperabili, quanto facilmente possiamo cambiare fornitore, e quanta parte dello stack possiamo controllare senza chiedere permesso fuori dalla UE?

allora state misurando un'altra cosa.

E questa seconda cosa assomiglia molto di più a ciò che Bruxelles chiama oggi Digital Sovereignty.

Il Cloud and AI Development Act proposto nel giugno 2026 lo rende abbastanza esplicito: l'obiettivo è almeno triplicare la capacità dei data center europei nei prossimi cinque-sette anni, aumentare la capacità europea nel cloud e nella AI e contemporaneamente creare un quadro comune europeo per valutare la sovranità dei fornitori.

Quindi no: la strategia non consiste nel rassegnarsi ad essere piccoli.

Consiste nel diventare grandi senza diventare dipendenti da uno solo.

E questa differenza, che sembra una sottigliezza, cambia completamente il significato della parola GAP.

E questo è il mio punto.

Se per voi essere diversi dagli Stati Uniti, e non voler costruire un sistema nel quale cinque o sei oligarchi tecnologici possano accumulare abbastanza potere economico, mediatico e politico da condizionare direttamente la vita democratica, significa essere «indietro», allora prima dovete chiedervi una cosa: volete davvero andare dove sono andati gli Stati Uniti?

Oppure volete andare da qualche altra parte?

Perché se volete andare da qualche altra parte, ALLORA il famoso GAP non può più essere misurato prendendo gli Stati Uniti come punto di arrivo.

Dovete prima stabilire dove volete arrivare, e soltanto dopo misurare la distanza tra quel punto e dove siamo oggi.

E potreste avere delle piacevoli sorprese.

Una delle sorprese, per esempio, è che una parte importante dei finanziamenti europei sulla sovranità digitale non serve affatto a costruire capannoni pieni di server.

Naturalmente i finanziamenti alle infrastrutture fisiche esistono eccome: data center, supercomputer EuroHPC, AI Factories, reti edge, semiconduttori e capacità di calcolo sono una parte importante della strategia europea.

Ma una quantità enorme del lavoro riguarda il software necessario a fare funzionare insieme queste infrastrutture.

Ed è perfettamente logico.

Perché se il vostro obiettivo fosse semplicemente costruire «AWS europeo», basterebbe costruire dei data center giganteschi, comprare montagne di GPU, scrivere uno stack proprietario e mettere un cancello intorno a tutto.

Se invece volete costruire un sistema nel quale STACKIT, OVHcloud, Scaleway, Aruba, IONOS e gli altri possano costituire parti di una vera infrastruttura europea, allora il problema più difficile non è più soltanto avere abbastanza ferro.

È fare in modo che il software non trasformi ogni infrastruttura in un'isola.

Ed è esattamente il problema che la Commissione dichiara di voler affrontare.

L'IPCEI-CIS, per esempio, non viene descritto come un programma per costruire semplicemente altri data center. Il suo obiettivo ufficiale è creare un ecosistema europeo di elaborazione dei dati interoperabile, apertamente accessibile e multi-provider, dal cloud fino all'edge.

Ed è qui che cominciano i problemi interessanti.

Supponiamo che io abbia una workload su un cloud europeo.

La macchina virtuale, o il container, è quasi il problema facile.

• Devo poter spostare i dati.
• Devo poter spostare la configurazione.
• Devo poter ricreare networking, identity e policy.
• Devo poter ricostruire le dipendenze.
• Devo avere API sufficientemente compatibili.
• Devo poter trasferire o ricreare in sicurezza certificati, credenziali, chiavi, token e tutto ciò che permette all'applicazione di funzionare.

E soprattutto devo poter fare queste cose senza che il costo tecnico dello spostamento sia così alto da rendere puramente teorica la possibilità di cambiare cloud.

Questa non è una mia interpretazione particolarmente creativa. Il Data Act europeo dice esplicitamente che i clienti dei servizi cloud ed edge devono poter passare da un provider all'altro in maniera efficace e che devono essere sviluppati standard armonizzati e specifiche aperte di interoperabilità. La Commissione cita persino strumenti capaci di trasferire workload fra tecnologie di virtualizzazione diverse.

Quindi il GAP, molto spesso, sta proprio nel software intermedio.

• Sta negli orchestratori.
• Sta nelle API.
• Sta nei sistemi di identity.
• Sta nella gestione delle policy.
• Sta nei sistemi di secret management.
• Sta nelle astrazioni sopra il networking.
• Sta negli strumenti per trasferire workload e dati.
• Sta nei formati comuni.
• Sta nei middleware che permettono a sistemi costruiti da aziende differenti di riconoscersi e lavorare insieme.

Per questo uno dei progetti europei più interessanti è Simpl, un middleware open source finanziato dalla UE il cui scopo dichiarato è precisamente permettere federazioni cloud-to-edge e fornire il software comune sul quale possono funzionare i Data Spaces europei.

E ci sono progetti IPCEI che fanno esattamente questo ad altri livelli.

SAP, per esempio, con ApeiroRA, lavora ad un blueprint di riferimento aperto per un'infrastruttura cloud-edge di nuova generazione. Altri progetti sviluppano API indipendenti dalla piattaforma, orchestrazione distribuita, gestione dei workload e software destinato precisamente a rendere possibile quel famoso cloud-edge continuum che altrimenti rimarrebbe una bella espressione da PowerPoint.

E poi ci sono componenti meno spettacolari, ma assolutamente indispensabili.

Prendiamo i secrets.

Se un'applicazione cifra dei dati, usa certificati TLS, password per database, API key, credenziali dinamiche o chiavi di cifratura, non basta copiare i suoi file dal cloud A al cloud B.

Bisogna assicurarsi che possa ottenere nuovamente quelle credenziali, con le stesse garanzie di sicurezza, senza infilare le chiavi in un file ZIP e mandarle per posta.

Serve quindi uno strato di gestione dei secrets e delle chiavi che non sia legato indissolubilmente ad un singolo hyperscaler.

Un esempio concreto è OpenBao, il fork open source di Vault oggi gestito sotto OpenSSF. OpenBao offre secret management, PKI e encryption as a service, e supporta scenari distribuiti fra cloud e data center. Una parte dello sviluppo viene svolta da sviluppatori SAP ed è finanziata attraverso fondi europei NextGenerationEU.

Ed è interessante anche perché mostra quanto poco cinematografica sia, in realtà, una parte della sovranità digitale.

Non sempre significa costruire una fabbrica di chip da dieci miliardi.

A volte significa che qualcuno deve scrivere bene il pezzo di software che gestisce una chiave crittografica.

Oppure il plugin che parla con un HSM.

Oppure il sistema che consente ad una PKI di sopravvivere allo spostamento di un'applicazione.

Oppure l'interfaccia comune attraverso la quale due infrastrutture differenti possono scambiarsi ciò che serve senza che il cliente debba riscrivere tutto.

OpenBao, per esempio, è già integrato con OpenStack, con infrastrutture OVHcloud e con HSM di fornitori europei come Utimaco. Non perché OpenBao sia «la soluzione europea ai vault», ma perché è un buon esempio del tipo di mattone open source che rende materialmente possibile un ambiente multi-cloud.

E ce ne sono moltissimi altri.

Perché quando dite:

«voglio poter cambiare cloud»

state facendo una richiesta enorme.

• Dovete poter cambiare storage.
• Compute.
• Networking.
• DNS.
• Identity.
• Secrets.
• Logging.
• Monitoring.
• Policy.
• Database.
• Container registry.
• Message queue.
• API gateway.

E magari dovete farlo senza fermare il servizio.

La portabilità non è quindi un bottone con scritto EXPORT TO EUROPE.

È un'intera industria del software.

Ed è precisamente per questo che la nuova strategia europea sull'open source non considera l'open source una simpatica attività per programmatori coi sandali, ma una componente della sovranità tecnologica. La Commissione stima che in Europa esistano già oltre 500 aziende commerciali open source attive in settori come cloud, cybersecurity, dati e sistemi industriali, e nel 2026 ha indicato esplicitamente l'open source come uno degli strumenti con cui ridurre dipendenze tecnologiche e rafforzare la resilienza europea. Ed ecco quindi un altro errore abbastanza sistematico quando si misura il famoso GAP.

• Si contano i data center.
• Si contano le GPU.
• Si contano gli LLM.
• Si contano le capitalizzazioni.

E tutte queste cose sono importanti.

Ma se il sistema europeo che vogliamo costruire è federato, allora una parte del GAP sta necessariamente in una montagna di software che nessun giornalista metterà mai in copertina.

Il software che permette al pezzo francese di parlare con quello tedesco.

A quello tedesco di essere sostituito da quello italiano.

A quello italiano di usare capacità di calcolo spagnola.

E al cliente di poter mandare tutti al diavolo e cambiare fornitore senza dover demolire la propria infrastruttura.

In altre parole, se il punto di arrivo è un ecosistema europeo grande, distribuito, interoperabile e sostituibile, allora non siamo semplicemente in ritardo nella corsa verso AWS.

Stiamo correndo un'altra gara.

E soltanto dopo aver capito quale gara stiamo correndo ha senso chiedersi quanto siamo indietro.

Sta a voi chiedervi se volete Elon Musk o no.

E ricordarvi che dietro un Elon Musk ci sono sempre dieci Epstein.

Prima, una doverosa premessa: la città di Licata sembra avere un problema con l’immondizia, con la pulizia delle strade e con la loro manutenzione. L’ultima volta che ci sono stato, all’inizio degli anni Duemila, non era così. Ma, per quello che ho potuto vedere, è come se il sindaco non ci provasse nemmeno. E siccome ha anche tolto i cassonetti per passare alla raccolta porta a porta, se volete essere civili e tentare di facilitare le cose, semplicemente non serve a nulla.Non avete altro posto dove lasciare i vostri rifiuti, e, non esistendo un calendario vero, prima o poi verranno raccolti. Questo, con una temperatura da forno a legna, produce una fragranza che piace moltissimo ai turisti. Ma, ripeto, non lasciatevi ingannare: la gente non ha colpa. Anche noi tre abbiamo cercato di smaltirla nel modo dovuto: semplicemente, non esiste il modo dovuto. Chi vi dice che è anche colpa della gente incivile appartiene all'insieme dei leccapiedi del sindaco, che onestamente andrebbe impalato. Col faro che c’è al porto. Una parte fondamentale del panorama.

Descrizione della compagnia. Ci sono io, che faro' da traduttore. Poi c'e' “il Corto”, un tedesco che appunto non e' alto, fa il preside di una scuola superiore, suona heavy metal, ha gli avambracci tatuati con motivi maori, ha l'hobby delle motociclette Triumph, e accetta di venire con noi anche usando un mezzo ignobile, opportunista e codardo come un aereoplano. Poi c'e' il lungo. Alto, sempre biondo, ma di mestiere e' un manager per una gloriosa assicurazione, ritiene che la Polo sia l'equivalente casual di quello che per me e' una canottiera del Manowar con le borchie sopra. Ovviamente, shorts con le pinces, e occhiali rettangolari. Ama le regole. Adora le regole. PENSA in termini di regole. E vuole che lo sappiate. Non gi basta avere un piano, vuole un piano perfetto. Fino nei dettagli. Nonostante io lo abbia avvisato che andremo in un posto dove i piani falliscono proprio nei dettagli. Ma lui dice che allora e' un cattivo piano. Ma lui e' un manager. Oh, yeah.

Comunque, ci siamo conosciuti in palestra, facendo Judo, e dopo un decennio di bevute, mangiate, Wacken e ippon ci consideriamo amici. Che, in Germania, è una cosa importante: non è affatto facile avere un amico qui.

E si parte.

Il piano fallisce immediatamente: prima ci si mette l’Etna, che decide di eruttare. E quindi chiudono l’aeroporto di Catania. Mentre noi siamo già in volo.

Morale? Dovremmo atterrare a Lamezia Terme, ma non c’è abbastanza carburante, e quindi andiamo prima a Brindisi a fare rifornimento. Si perdono tre ore buone, poi finalmente arriviamo a Lamezia. Di andare a Catania non se ne parla nemmeno, e l’aeroporto di Palermo è completamente nel panico. Io e il Grosso, che prendiamo la vita con sarcasmo, ci mettiamo a dire cazzate e a sghignazzare per tutto il tempo. A volte anche troppo.

Per esempio, a un certo punto lui chiede a una signora italo-tedesca, che sta urlando al telefono, per quale motivo stia usando il telefono, visto che da Catania la sentono benissimo anche senza. In compenso, questo aiuta l’aria condizionata di bordo a raffreddare.

E poi via, perché quando un aereo si ferma tutti sentono improvvisamente il bisogno di alzarsi: quelli seduti davanti devono andare in fondo, quelli seduti in fondo devono andare davanti, e quelli in mezzo hanno uno spin -1. E si sente la voce del Grosso che dice:

„Schönes Wetter zum Spazierengehen, oder?“

Ovvero: “Tempo fantastico per una bella passeggiata, eh?”

Penso di avervi descritto il carattere del Corto. Divertentissimo, piace alle donne – ricambiato – e ha sempre la battutaccia pronta.

Il Lungo, invece, la prende con grazia. Discussione con me, tipo:

• Ma il vulcano a Catania non esiste da oggi, vero?
• No, credo siano milioni di anni.
• E quindi a Catania lo sanno che c’è un vulcano, giusto?
• Credo sospettino qualcosa, sì.
• E allora perché chiudono l’aeroporto per l’Etna, se sanno che potrebbe eruttare? Non e' normale che erutti? Non ci sono abituati?
• È gente strana, amico mio. È gente strana.
• Io non lo capisco.
• Genau.

Credo di aver descritto la combriccola.

Allora, arriviamo troppo tardi a Lamezia, quindi prendiamo un albergo per una notte. L’indomani prendiamo il treno fino a Villa San Giovanni, da lì il traghetto veloce, e poi finalmente Catania. Nessuno fa ritardo, nessuno perde coincidenze, anche se il Lungo continua a ripetere che, essendo il viaggio assicurato, riuscirà a farci risarcire tutte le spese aggiuntive. Ok.

Arriviamo all’aeroporto di Catania, perché il Lungo ha prenotato online un’automobile. E naturalmente conosce a memoria ogni singola clausola del contratto firmato online.

Peccato che fosse una truffa.

Nel senso che quello, a detta del losco individuo che troviamo lì, era soltanto un “broccheRRR”, e quindi:

“Adesso il contratto nuovo lo fate con ME.”

Accento sul ME. Lo pronuncia come se fosse “ammia” nel Padrino.

Io capisco immediatamente l’antifona. Guardo davanti al posto dove dovrebbe esserci il “broccheRRR” e vedo una discreta fila di gente incazzata. A quel punto il quadro generale mi sembra abbastanza chiaro.

E, naturalmente, il tipo cerca di fregarci tirando fuori clausole assicurative improbabili, condizioni assurde e altre amenità che sembrano inventate sul momento.

Ma commette un errore.

Lo dice al Lungo, pensando che essendo tedesco sia facile fregarlo. Non lo conosce. E' un tedesco, ma del nord. Una cosiddetta fischkopf, una testa di pesce, come li chiamano. Non cambia opinione dal 700 Avanti Cristo.

Il risultato è una discussione forbita di mezz’ora, durante la quale il Lungo cerca pazientemente di dimostrare al tipo — che era chiaramente un ciarlatano — che stava dicendo delle stronzate.

Punto per punto.

Clausola per clausola.

Con metodo.

Il problema è che non c’era verso di portarlo via da lì. Il Lungo aveva ormai trasformato il noleggio auto in una questione di principio, e probabilmente sarebbe ancora lì a discutere di condizioni contrattuali se, a un certo punto, non lo avessimo praticamente trascinato fuori.

Insomma, cosi' (nella maglietta c'e' scritto ICH HABE RECHT, io ho ragione. Ma aveva una polo.).

Comunque, usciamo fuori e, mentre cerchiamo di pianificare una strategia — come dice il Lungo — passa un autobus.

In alto c’è scritto:

LICATA

Sorpresa: non c’è affatto bisogno di un’auto.

Con 9,80 euro a cranio si parte e si arriva direttamente a Licata.

Fine della necessità strategica.

Il Lungo dice qualcosa del tipo che non poteva certo prevedere che in Sicilia ci fossero degli autobus.

È ovvio.

Come sarebbe a dire, il motore a scoppio?

Ovviamente lo prendiamo, e io e il Corto prenderemo per il culo l’organizzazione perfetta del Lungo per circa due ore.

Ma due ore con l’aria condizionata.

E credetemi: da quelle parti serviva. Ma non “era meglio averla”. Serviva tipo DEVS LO VULT.

Insomma, il tipo che ci affitta l’appartamento viene preso da pietà e ci viene a prendere all’autostazione di Licata, e noi finalmente raggiungiamo il posto. La macchina è molto piccola, ma esiste una ragione.

Si tratta di un quartiere antichissimo, estremamente pittoresco, con strade larghe mediamente due metri, due metri e mezzo, e curve ad angolo assurdamente strette. Si trova giusto un paio di traverse prima di Via Palma, diciamo vicino al municipio.

Se siete di Licata avete già capito dove. Altrimenti dovete immaginare un quartiere medievale siciliano fatto di strade strettissime, case addossate l’una all’altra e svolte nelle quali una macchina normale sembra improvvisamente una petroliera.

Ne esiste un altro simile, detto la Marina, che dà sul porto.

Io e il Corto siamo lì a fare fotografie, perché il posto è veramente bello. Il Lungo, visto il posto, chiede dove affittare un’auto.

Io e il Corto, invece, decidiamo di cambiare il piano.

Molto meglio degli scooter.

Così chiediamo al nostro oste, gentilissimo, dove si possano affittare degli scooter, e lui ci porta in un posto dove si affittano gommoni per i tour turistici, ma anche scooter.

Il Corto, ovviamente, non ha la sua Triumph, ma sono sempre due ruote. A me va benone il 125 cc.

Il Lungo, però, ci ricorda che:

• Ma non basta la patente B per guidare un 125. Occorre anche uno Schlüsselzahl 196, cioè quella roba che esiste in Germania e permette di guidare un 125 con la patente B dopo la formazione prevista.
• Non siamo in Germania, casomai ti fosse sfuggito. E levati quei calzini: siamo vicini alla temperatura di fusione dello zinco.
• Ma le assicurazioni come fanno ad assicurarti? Magari poi non ci pagano se abbiamo un incidente.
• Non lo so come fanno. Ma qui si fa così, QUINDI si fa così. Secondo te cosa dovremmo fare?
• Andare in auto. Il piano era di avere un’auto.

Risponde il Corto:

— E sticazzi del piano. (Scheiß auf die Planung.)

Insomma, io affitto un 125 cc, come il Lungo, mentre il Corto, che ha la patente per le moto, si prende un 250 cc.

Ma ormai siamo usciti dalla pianificazione.

E quindi il Lungo, da questo momento in poi, si aspetta delle catastrofi.

Che non avverranno.

Almeno una volta capito come si guida a Licata.

Diciamo che, come dice il corto, loro non violano le regole del codice. Le migliorano, ecco tutto.

A quel punto torniamo al nostro appartamento. Il tipo, gentilissimo, ci mostra il garage dove possiamo mettere gli scooter.

Non per i ladri.

Per evitare che fondano nell’asfalto.

La temperatura è attorno ai 49 gradi.

Convinto finalmente il Corto a togliersi i calzini, andiamo a un chiosco che avevamo visto a un incrocio, con anche qualche tavolino. Vende granite.

Io so bene che la granita al limone non contiene latte, e il Lungo è allergico al latte di mucca. Ma non so bene cosa contenga la famosa brioscia col tuppo.

Così lo dico alla signora del chiosco, che per tutta risposta ci mostra il garage dietro al chiosco, dove fanno letteralmente le briosce.

Niente latte.

E così la brioscia con la granita diventa la nostra colazione.

Peccato che nel piano ci fosse scritto di andare in qualche pasticceria, comprare qualcosa per colazione e mangiarlo a casa.

Scheiß auf die Planung.

Siccome però il piano esiste ancora, almeno formalmente, e dopotutto vale la pena assaggiare il cibo locale, andiamo ANCHE in una pasticceria a chiedere se abbiano cannoli fatti con ricotta di sola pecora.

La signora non parla inglese, ma chiama la figlia.

Io sto zitto, sfruttando quello che ormai chiamo il gradiente di ospitalità: a Licata, più siete stranieri, più la popolazione si fa in quattro per voi.

No, sul serio: va provato.

Se non lo provate, non sapete davvero cosa sia l’ospitalità.

Kudos ai licatesi.

La signora, intanto, ci guarda con un’espressione che tradotta dal siciliano universale significa più o meno:

“Voi malvagi settentrionali del demonio state forse insinuando che io metta dell’orrido latte di mucca nella ricotta dei MIEI cannoli? È questo che state insinuando? Eh? Eh? Volete litigare?”

A quel punto intervengo io e spiego, in italiano con accento chiaramente non locale, che il Lungo sta veramente male se mangia latte di mucca e quindi, semplicemente, ha paura.

Detto fatto.

La signora sparisce nel laboratorio e ricompare sulla porta con un cucchiaino da assaggio da consegnare al Lungo.

Il Lungo assaggia.

Aspetta due minuti.

E infine conclude che sì: chiaramente non c’è latte di mucca.

Nel frattempo il Corto era entrato nel negozio e aveva già fatto amicizia con la figlia.

La scena che troviamo, quindi, è praticamente questa:

No, non c'era la mitragliatrice e nemmeno l'elmetto. Ma il Corto stava comprando cibo. TANTO Cibo. E riesce a legare benissimo con le donne. Anche a Licata, pare.

Nel senso che nel frattempo Il Corto si e' procurato uno sconto-simpatia e ha comprato cosi' tanti dolci, da mastazzoli (Für Deutsche: Gebäck, das nach Glühwein verlangt!!!! WOW!!!) a tutto quello che c'era con le mandorle, che abbiamo riempito due ripiani del frigo. Per merenda. La colazione era presa dal chiosco delle granite.

Scheiß auf die Diät.

Così decidiamo che è arrivato il momento di andare in spiaggia.

Chiediamo indicazioni a un passante, subito dopo un ponte, e ci spiega come arrivare alla Playa.

Ok. Come inizio può andare.

Ma prima occorre un negozio per attrezzarsi. Troviamo un “bangla” e compriamo un ombrellone da lasciare lì, mentre il Lungo compra un secondo asciugamano e noi da Sidis per creme protettive 50+.

Precisiamo.

Il Lungo, nel bagaglio in stiva, ha messo LA SUA crema. Quella che funziona. L’UNICA che funziona sulla sua pelle.

Effettivamente, gente così bianca l’avevo vista solo in Irlanda. Quindi, in effetti, ci sta.

Arriviamo in questa spiaggia libera, ci ricopriamo di crema 50+, mentre il Lungo si passa addosso il suo spray miracoloso.

L’acqua è limpidissima, ha praticamente la temperatura del corpo umano e, siccome ormai è pomeriggio, ti ci immergi che è una meraviglia. Specialmente dopo una mattinata passata prima in autobus, dalle sette alle dieci, a sudare, e poi in giro per la città fino a quando finalmente siamo riusciti a procurarci gli scooter.

Kudos per le spiagge di Licata.

Usciamo dall’acqua, ci mettiamo magliette e cappelli comprati dai bangla, prendiamo qualche birra dall’ambulante del caso, mentre il Lungo comincia lentamente ad assumere una posizione difensiva.

Io e il Corto ci mettiamo a giocare a carte sull’asciugamano e, dopo un po’, cominciamo a notare degli sguardi straniti da parte dei passanti e della gente seduta attorno.

Il problema è che il Lungo ha la pelle TROPPO sensibile.

E ha appena scoperto che il suo spray del cazzo può anche andare benissimo sulle spiagge olandesi o sul Baltico, ma lì il sole gioca decisamente in un altro campionato.

Anziché chiedere le nostre creme — comprate sul posto, quindi quantomeno testate empiricamente da una popolazione che, se guardate il colore della pelle, di sole qualcosa deve capire — decide di mettere un asciugamano sotto di sé, un asciugamano sopra di sé e una maglietta sulla faccia.

• Cosa fai?
• Mi sono messo al riparo. Ho visto che mi sto bruciando.
• Vuoi che andiamo a casa?
• No. Oggi pomeriggio avevamo detto di venire in spiaggia. Non voglio rovinarvi la vacanza.
• Ok. Allora vuoi le nostre creme? Le abbiamo comprate qui. È roba che usa la gente del posto e, se guardi le pelli, di abbronzatura se ne intendono.
• No, no. Quello spray è quello che uso sempre, ed è L’UNICO che io uso. Uso solo e sempre quello. Non conosco queste creme. (Sarebbe capacissimo di leggere il manuale e tutte le avvertenze delle creme solari, credetemi. Lo Stiftung Warentest è la sua droga.)
• Ok, ma qui non funziona. Usa le creme.
• No. Userò il MIO spray, che conosco bene, e mi coprirò così, usando gli asciugamani.

A quel punto, ovviamente, il Corto — che reagisce SEMPRE al ridicolo — si alza, va da alcuni ragazzi e ragazze sotto altri ombrelloni e chiede se può prendere un cartone della pizza che hanno appena finito.

Con un residuo di pomodoro ci scrive sopra:

RIP

aiutato dai ragazzi, che nel frattempo stanno ridendo.

Poi sistema la lapide accanto al Lungo.

Che, avvolto negli asciugamani con la maglietta sulla faccia, sembra ormai una mummia egizia lasciata a essiccare sulla spiaggia.

La scena appare più o meno così:

Tutto sembra andare bene, quando improvvisamente si sente:

“Morumamma, morumamma, morumamma, morumamma, morumamma, morumamma…”

e via così, una quarantina di volte.

Non so esattamente cosa sia una “morumamma”, ma si avvicina una signora piuttosto sferica, sulla cinquantina, abbronzatissima, costume intero con un cappello di paglia dalla tesa enorme, che ci chiede molto allarmata cosa sia successo al Lungo.

Allora le spiego in italiano che il Lungo sta benissimo. La signora parla un mix italiano-dialetto, che capisco agevolmente, tranne alcune parole. Comunque, dico, il lungo sta bene.

Lo evochiamo dal suo sonno sotto gli asciugamani, lui riemerge lentamente dal bozzolo e dimostra di essere ancora vivo.

La signora, rassicurata solo fino a un certo punto, ci intima di non fare mai scherzi coi morti, perché le è preso uno “scanto”.

Ok. Qualsiasi cosa sia. Ma capisco il punto.

Il Corto riesce a farsi perdonare pronunciando due o tre parole in italiano, più o meno:

— Ouhhh… mmi tispiacce, Sinn-iora..

Ma è praticamente impossibile resistere al Corto quando fa quella faccia.

Io, nel frattempo, spiego che con il colore della pelle del Lungo — che ora è emerso almeno parzialmente dagli asciugamani — quella protezione diventa necessaria, altrimenti finisce in ospedale.

La signora lo guarda attentamente.

Constata che sì, effettivamente il Lungo ha il pallore dei morti.

Poi, però, aggiunge che un po’ di sole gli farebbe bene. E che si deve abituare al sole, deve stare in spiaggia, e cominciare almeno ad aprile, che gli viene la salute. Io immagino il Lungo su una spiaggia del Baltico o del Mare del Nord ad Aprile, mentre muore assiderato, ma traduco spiegando che la signora era sinceramente preoccupata, e mentre per farmi perdonare insisto con la donna, che la sua pelle bianca – letteralmente – comunque non ha speranze contro il sole di Licata.

Io traduco e basta, ma il Lungo non sembra apprezzare particolarmente il consiglio medico.

La signora, soddisfatta di aver verificato che il cadavere respirasse ancora, finalmente se ne va. Ma ci dice che con la morte non si scherza.

Non si sa mai che lo dimentichiamo.

Arriva sera. Torniamo a casa.

Sulla via del ritorno, il Lungo vede un supermercato.

E vuole entrare per comprare la cena.

Dialogo:

• Cena? Ma andremo fuori a mangiare. Non hai visto la trattoria vicino a casa?
• Ma così spenderemo moltissimo.
• E che cazzo sei venuto qui in ferie, per risparmiare?
• (Faccio notare che il Lungo sta sui 250K euro l’anno.)
• Ma non ha senso buttare via soldi, no?
• Buttare via? Aspetta di aver mangiato in un ristorante italiano.
• Ma li conosco i ristoranti italiani. A Düsseldorf ce ne sono tanti.
• No.
• Come, no?
• Non ce n’è nemmeno uno. E stasera capirai.

Insomma, andiamo da Donna Rosa, che ha principalmente un menu di pesce.

Io parto con una pasta alla Norma (perche' sono stanco e il pesce richiede concentrazione) , ma durante quella settimana abbiamo fatto metodicamente il giro: varie paste al pesce spada, pasta con le sarde alla licatese, Norma, Bella Donna, poi i secondi, il pesce, tutto quello che capitava.

Fino a quando il Lungo non si è reso conto che, effettivamente, lui un vero ristorante italiano probabilmente non l’aveva mai visto.

Tant’è vero che non conosce nemmeno il sorbetto.

E allora io, ormai promosso a guida turistica, interprete e responsabile delle relazioni interculturali, gli spiego che serve anche a togliersi dalla bocca il sapore del pesce prima di passare ad altro.

Potrei andare avanti per parecchio con gli aneddoti sulla collisione culturale tra un tedesco “etnico”, o comunque decisamente “del Nord”, come il Lungo, uno più “del Sud”, quasi di impostazione bavarese, come il Grosso, e un italiano che passa metà del tempo a fare da guida e l’altra metà a tradurre non tanto le parole, quanto il modo di vivere.

Insomma, abbiamo preso chili.

E risate.

Prima di chiudere questa parte: in effetti siamo davvero amici, e non ho idea di cosa scriverebbero loro di me. A me fa molto ridere il Lungo, ma è un vero amico: uno di quelli sempre disponibili ad aiutare — previa pianificazione perfetta, naturalmente. Se dovessi affidare a qualcuno una valigetta con dentro dieci milioni di euro e dirgli di portarla in banca, la darei a lui. E lui la porterebbe in banca. Tutta. Perché rubare è vietato. Anche il Corto è una persona bellissima, e uno di quelli con cui puoi passare ore a dire cazzate senza che la cosa perda qualità. Ma le dinamiche Nord-Sud in Germania sono davvero troppo divertenti per non prenderle in giro. E se io sfotto loro, probabilmente dovrei sentire cosa dicono di me.

Prima di finire, una recensione.

1. Al nostro oste, Davide. Una persona incredibile, che crede di essere normale e invece si è fatto in quattro per noi molto più del normale. Per poco non si offriva di darci un secondo frigorifero. A un certo punto abbiamo dovuto limitarlo noi.
2. Alla cittadinanza licatese. Ospitalità incredibile. Mentre a Catania hanno cercato di impallinarci perché stranieri, a Licata non siamo riusciti a comprare nulla — nemmeno della frutta in un coloratissimo negozio all’angolo — senza che qualcuno ci regalasse qualcosa. Persino un tizio abbastanza incomprensibile che girava in Ape e ci ha venduto dell’uva con chicchi grandi come proiettili ci ha aggiunto qualche pesca. Perché sì.
3. Cibo licatese. Fuori scala. E lo dico io, che sono romagnolo.
4. Licata. Una potenzialità turistica e culturale tremenda, rovinata da una giunta comunale che andrebbe usata come preservativo per somari. Sembra quasi che intendano boicottare deliberatamente la crescita turistica della città.
5. Al sindaco di Licata e alla giunta comunale. Dovete morire. Male. E poi dovete finire all’inferno. Dove ogni donna deve chiamarsi Lexington Steele. Quella città merita di meglio, cazzo. E se non riuscite a provvedere almeno alla pulizia delle strade, alla manutenzione e alla rimozione dei rifiuti — che sono davvero il minimo sindacale — allora uscite dalla politica e datevi all’abigeato. Veramente: quella città merita di più.
6. Etna: e vaffanculo, eh. Proprio quel lunedì dovevi scoppiare?