SIAMO GEEK

  • Watt for FLOPS

    Un numero che non mi convinceva

    Negli ultimi mesi mi è capitato sempre più spesso di leggere notizie di questo tipo: “L’azienda X annuncia un data center da 5 Gigawatt per l’intelligenza artificiale“, “Il progetto Y supererà i 10 GW entro il 2030“. Mai un FLOPS, mai un riferimento diretto alla potenza di calcolo. Da professionista IT, la cosa mi ha sempre lasciato un po’ perplesso: stiamo misurando l’intelligenza artificiale con un’unità che, in fondo, ci dice quanta corrente consuma un impianto industriale, non quanto velocemente “pensa” un computer. Mi sembrava, nella migliore delle ipotesi, una scorciatoia giornalistica; nella peggiore, un trucco di marketing per impressionare chi non ha gli strumenti per giudicare un FLOPS.

    Poi mi sono fermato a ragionarci con più calma, e la risposta — come capita spesso con le domande apparentemente semplici — si è rivelata molto più interessante della domanda stessa. Non è (solo) una questione di marketing. È il sintomo di un cambiamento profondo in cosa significhi davvero “costruire potenza di calcolo” nel 2026.

    Le basi: cosa misurano davvero Watt e FLOPS

    Partiamo dalle fondamenta, perché vale la pena essere chiari fin dall’inizio.

    I FLOPS (FLoating point Operations Per Second) misurano quante operazioni matematiche in virgola mobile un sistema può eseguire ogni secondo: somme, moltiplicazioni, le operazioni di base su cui si costruisce qualunque calcolo scientifico o modello di intelligenza artificiale. È, concettualmente, l’unità che dovrebbe rispondere alla domanda “quanto calcolo grezzo può fare questa macchina”.

    I Watt (e i loro multipli, kW, MW, GW) misurano invece la potenza elettrica: quanta energia un sistema consuma — o, nel caso di una centrale, quanta ne può generare — in un determinato istante. Un Gigawatt equivale a un miliardo di Watt: per dare un’idea, una centrale nucleare di medie dimensioni produce intorno a 1 GW, e un datacentre “da 1 GW” consuma, a pieno regime, quanto una città di alcune centinaia di migliaia di abitanti.

    Sono due unità che misurano cose fisicamente diverse: una è una misura di lavoro computazionale, l’altra è una misura di energia. Non sono automaticamente intercambiabili, e non è scontato che l’una sia un buon proxy dell’altra.

    Detto così, sembrerebbe naturale concludere che i GW siano semplicemente “la misura sbagliata”. Ma le cose, come vedremo, sono più sfumate.

    Il vero collo di bottiglia non sono (più) i chip

    Per anni, il limite principale alla crescita dei datacentre per l’AI è stato semplicemente “quanti chip riesci a comprare”. Poi qualcosa è cambiato. Il problema non è più (solo) procurarsi le GPU: è procurarsi abbastanza energia elettrica nel posto giusto.

    La ragione è quasi banale, una volta spiegata: i chip si rinnovano in fretta, ogni 12-18 mesi circa esce una generazione più efficiente e, soldi permettendo, si possono comprare o affittare in tempi relativamente brevi. L’infrastruttura elettrica no: costruire nuove sottostazioni, linee di trasmissione, accordi con i gestori di rete, a volte persino far ripartire centrali dismesse, richiede anni, non mesi.

    L’esempio più clamoroso, e probabilmente il più citato nel settore, è quello di Microsoft: nel settembre 2024 l’azienda ha firmato con Constellation Energy un accordo di acquisto di energia (PPA) della durata di 20 anni per far riaccendere l’Unità 1 della centrale nucleare di Three Mile Island, in Pennsylvania — quella, per chiarezza, non coinvolta nel celebre incidente del 1979, ma comunque chiusa nel 2019 per ragioni puramente economiche. Il riavvio, ribattezzato Crane Clean Energy Center, è previsto per il 2028 e fornirà a Microsoft circa 835 MW, l’equivalente del consumo di 800.000 abitazioni americane, dedicati interamente ai suoi datacentre AI. Amazon ha fatto qualcosa di simile con la centrale di Susquehanna, Google sta investendo in piccoli reattori modulari.

    Quando un’azienda tech arriva a far riaccendere un reattore nucleare spento da cinque anni con un contratto di vent’anni, non sta facendo marketing: sta risolvendo, nel modo più diretto possibile, il vincolo che la sta davvero limitando.

    Ecco perché, quando un’azienda annuncia “X GW di capacità”, quel numero non descrive quanto calcolo farà oggi: descrive quanta capacità infrastrutturale si è assicurata per i prossimi anni, capacità che riempirà progressivamente con chip sempre più efficienti, generazione dopo generazione. È una misura dell’ambizione a lungo termine — o, per essere più precisi, una misura di dove si trova davvero il collo di bottiglia in questo momento storico.

    Il paradosso di Jevons: più efficienza, più fame di energia

    A questo punto, una domanda viene naturale: se i chip diventano sempre più efficienti — più calcolo per ogni Watt consumato — perché continuare a inseguire sempre più GW? Non dovrebbe, prima o poi, bastare l’hardware che già abbiamo?

    La risposta sta in un fenomeno economico descritto già nel 1865 dall’economista inglese William Stanley Jevons, osservando il consumo di carbone in piena rivoluzione industriale: quando una tecnologia diventa più efficiente, il consumo complessivo della risorsa associata non scende — sale. Perché l’efficienza abbassa il costo d’uso, e un costo più basso sblocca nuova domanda che prima non era sostenibile.

    Nel gennaio 2025 abbiamo avuto una dimostrazione quasi da manuale di questo fenomeno. Il rilascio del modello cinese DeepSeek R1, addestrato con un’efficienza dichiarata molto superiore ai modelli concorrenti, ha scatenato il timore opposto: se i modelli diventano così efficienti, si è chiesto il mercato, serviranno meno chip costosi. Le azioni Nvidia hanno perso circa il 17% in un solo giorno, quasi 600 miliardi di dollari di capitalizzazione bruciati in poche ore. Il CEO di Microsoft Satya Nadella ha commentato pubblicamente la vicenda evocando proprio il paradosso di Jevons, prevedendo che l’efficienza avrebbe fatto esplodere l’uso dell’AI invece di ridurre il fabbisogno infrastrutturale. Nelle settimane successive, i fatti gli hanno dato ragione: la domanda di GPU, lungi dal calare, è aumentata ulteriormente.

    L’efficienza, finora, non si è mai tradotta in “meno energia per lo stesso risultato”: si è tradotta in “più risultato con la stessa energia, e ancora più energia per fare di più”.

    È una dinamica diversa da quella, per dire, degli smartphone: lì il “lavoro da fare” (scorrere i social, guardare video) ha raggiunto un plateau, e l’efficienza guadagnata è stata reinvestita in batteria e dimensioni più compatte. Per l’AI, almeno finora, non esiste un plateau evidente: ogni aumento di capacità sembra sbloccare nuovi usi — modelli più grandi, agenti autonomi, generazione di video — che assorbono tutta la capacità liberata. Questo, ovviamente, non è una legge di natura: è un pattern osservato finora, e potrebbe non valere per sempre. Ma finché vale, i GW annunciati dalle big tech non sono numeri gonfiati per fare colpo: sono, semmai, una scommessa razionale, forse anche prudente, su una domanda che continua a correre più veloce di quanto l’efficienza riesca a contenerla.

    Ma allora, i mega data center serviranno sempre?

    C’è però un’obiezione legittima a tutto questo ragionamento: non potrebbe l’AI seguire lo stesso percorso del calcolo in generale, passato dai mainframe con i loro “terminali stupidi” ai personal computer, fino agli smartphone che oggi hanno potenza da PC in tasca? Se i nostri dispositivi diventeranno abbastanza potenti ed efficienti, perché continuare a dipendere da data center grandi come città?

    Il parallelo è valido, ma solo a metà — e la differenza spiega molto. Per i modelli più grandi, il vincolo principale dell’inferenza (cioè dell’uso quotidiano, non dell’addestramento) non è tanto la potenza di calcolo grezza, quanto la banda di memoria: generare ogni singola parola richiede di “scorrere” tutti i pesi del modello, che per i sistemi più capaci pesano centinaia di miliardi di parametri. Un dispositivo personale, per quanto potente, ha limiti di memoria che un server con centinaia di gigabyte di memoria ad alta banda non ha.

    Detto questo, l’AI locale nel 2026 è già una realtà concreta, non fantascienza: con un MacBook Pro M5 Max e 128 GB di RAM si possono far girare in locale modelli con qualità da frontiera, gratis, offline, senza inviare un solo dato a server esterni. Anche sugli smartphone, le moderne unità NPU dedicate permettono di eseguire piccoli modelli per compiti come riassumere un messaggio, trascrivere audio, classificare una foto — lavori per cui un modello compatto è spesso più che sufficiente, e risponde all’istante.

    Ma quasi tutte le fonti tecniche più autorevoli convergono sulla stessa previsione: non “il locale sostituirà il cloud”, ma un’architettura ibrida. I compiti di routine si spostano sul dispositivo; quando serve ragionamento di frontiera, conoscenza ampia del mondo o conversazioni lunghe e complesse, resta più sensato passare al cloud.

    È lo stesso meccanismo del paradosso di Jevons, applicato all’hardware: appena un compito diventa “abbastanza buono” da girare gratis sul telefono, il valore differenziante si sposta verso compiti ancora più ambiziosi, che richiedono ordini di grandezza più memoria e calcolo. Il locale assorbe la base, il cloud rincorre sempre la nuova frontiera.

    C’è anche una ragione più di fondo: addestrare un modello di frontiera e usarlo quotidianamente sono due attività profondamente diverse. Il training richiede sincronizzare migliaia di chip su settimane di calcolo continuo — è più simile a un acceleratore di particelle che a un’applicazione personale. Il mainframe→PC ha funzionato perché il calcolo personale era un’attività intrinsecamente individuale, replicabile su una scrivania. L’addestramento di un modello di frontiera non lo è, e probabilmente non lo sarà mai, qualunque sia l’efficienza dei chip del futuro.

    Vale anche la pena notare che la storia dell’informatica non è mai stata una linea retta verso la decentralizzazione: dopo i PC, gran parte del calcolo aziendale è tornato centralizzato nel cloud computing, non perché i PC fossero insufficienti, ma per economie di scala, manutenzione, elasticità. L’AI sembra seguire lo stesso pendolo, non un’unica direzione.

    Anche i FLOPS, da soli, sono meno onesti di quanto sembrino

    Fin qui sembra che il problema riguardi solo i GW. Ma anche i FLOPS, l’unità che sembrava “quella giusta” di partenza, nascondono almeno tre trabocchetti.

    Il primo: il numero di FLOPS che un chip “promette” sulla scheda tecnica è un massimo teorico, raggiungibile solo in condizioni di laboratorio. Quello che conta davvero è quanta parte di quel massimo viene effettivamente usata, una misura che nel settore si chiama Model FLOPs Utilization (MFU). I numeri reali sono sorprendentemente bassi: nel 2026, un MFU del 40-60% durante l’addestramento è considerato un buon risultato, sopra il 50% è già eccellente. In fase di inferenza va molto peggio: con batch piccoli si scende all’8-12%, non per inefficienza ma perché si è limitati dalla banda di memoria, non dal calcolo puro. Persino un modello noto come Llama 3.1 ha raggiunto “solo” un MFU del 38-43% in addestramento — più della metà della potenza “venduta” resta sulla carta anche nei casi migliori.

    Il secondo: lo stesso identico chip ha FLOPS diversi a seconda del formato numerico con cui calcola. Passare da BF16 a FP8 può quasi raddoppiare il picco teorico. Quindi quando un’azienda annuncia “X FLOPS” senza specificare la precisione, il numero è quasi privo di significato per un confronto — un po’ come dire “questa macchina fa 200 all’ora” senza dire se è in discesa.

    Il terzo, e forse il più importante: anche misurati bene, i FLOPS non equivalgono a “intelligenza”. Due modelli addestrati con lo stesso identico budget di calcolo possono avere capacità molto diverse, a seconda della qualità dei dati, dell’architettura, dell’algoritmo di addestramento — è lo stesso principio che rende possibile l’efficienza di DeepSeek di cui parlavamo prima. I FLOPS misurano quanto lavoro computazionale è stato fatto, non quanta intelligenza ne è uscita.

    Un problema già risolto altrove: la lezione di TOP500

    A questo punto si potrebbe pensare che il calcolo, in generale, sia impossibile da misurare onestamente con un singolo numero. Ma c’è un settore che questo problema lo affronta seriamente da più di trent’anni: il supercalcolo scientifico classico, e la sua classifica più famosa, il TOP500.

    TOP500 classifica i supercomputer del mondo non in base al picco teorico dichiarato dal produttore, ma in base a Rmax: la performance effettivamente misurata facendo girare un benchmark standardizzato (LINPACK/HPL) che risolve un sistema di equazioni lineari, sempre in doppia precisione (FP64), sempre nello stesso modo per tutti i sistemi in gara. È esattamente l’MFU di cui parlavamo, applicato con rigore quasi accademico. Gli stessi curatori della classifica, sul loro sito, spiegano la scelta con parole che meriterebbero di essere incollate su ogni comunicato stampa del settore AI: usare la performance di picco al posto di un benchmark misurato non avrebbe alcun senso — e aggiungono che il loro ranking viene spesso fraintenso, perché chi non è esperto tende a vederlo come un giudizio valido per qualunque applicazione, cosa che non è vera.

    La cosa più interessante, però, è un’altra: TOP500 non ha mai scelto i FLOPS al posto dell’efficienza energetica. Dal 2009 esiste il Green500, che classifica gli stessi 500 sistemi non per potenza assoluta ma per quanta performance erogano per ogni Watt consumato (in Gigaflops/Watt). Due classifiche complementari, ciascuna per la domanda a cui risponde meglio: una dice quanto calcolo puro fa un sistema, l’altra quanto è efficiente nel farlo. Nessuna delle due sostituisce l’altra.

    Il mondo del supercalcolo ha risolto decenni fa, con onestà tecnica, esattamente il problema che oggi attanaglia il dibattito sull’AI: non si scelgono i Watt o i FLOPS, si usano entrambi, ciascuno per quello che sa dire davvero.

    La sintesi: servono tre numeri, non uno

    Mettendo insieme tutto quello che abbiamo visto, possiamo finalmente rispondere alla domanda di partenza. I GW non sono una misura “sbagliata”: rispondono in modo legittimo, e tutt’altro che arbitrario, alla domanda “quanto è grande l’impegno infrastrutturale ed energetico di questo progetto”. Il problema è che vengono usati come se rispondessero a una domanda completamente diversa — “quanto è potente, o quanto è intelligente, questa AI” — a cui semplicemente non possono rispondere da soli.

    Per avere un quadro onesto servirebbero tre livelli, non uno:

    • I GW dicono quanto è grande l’investimento e dove si trova il collo di bottiglia infrastrutturale del momento.
    • Il calcolo effettivamente realizzato (non il picco dichiarato, ma performance misurata con benchmark standardizzati come MLPerf, l’equivalente AI del LINPACK) dice quanto lavoro computazionale concreto può svolgere un sistema.
    • I benchmark di capacità — test diretti su cosa il modello sa effettivamente fare — dicono quanto è davvero capace l’AI che ne risulta.

    La parte più curiosa di tutta questa storia è che il secondo livello, quello tecnicamente più corretto, esiste già: MLPerf non misura i FLOPS di picco, ma il tempo necessario per raggiungere una soglia di qualità prestabilita su un compito standardizzato — un approccio molto più onesto dei semplici numeri di marketing. Eppure quasi nessun titolo di giornale lo cita, mentre i GW finiscono ovunque.

    Il motivo, credo, non è tecnico ma comunicativo: i GW sono un numero semplice, visivo, comprensibile anche senza alcuna competenza tecnica — “alimenta 800.000 case” si capisce all’istante, “abbiamo raggiunto il 47% di MFU su un benchmark MLPerf Training” no. Tra ciò che è facile da comunicare e ciò che è davvero informativo, nei titoli vince quasi sempre il primo.

    Come leggere il prossimo annuncio da record

    La prossima volta che leggerete “Azienda X costruisce un data center da N Gigawatt”, provate a tradurlo mentalmente così: è la scala dell’ambizione industriale e il segnale di dove sta il vero collo di bottiglia di oggi — non una misura della potenza di calcolo, e ancora meno dell’intelligenza che ne uscirà. E se vi capita di leggere “Y FLOPS” o “Y exaFLOPS”, prima di trattarlo come un numero comparabile chiedetevi: di picco o realizzati? A quale precisione? In addestramento o in inferenza?

    Nessuno dei due numeri, da solo, vi dirà quanto sia davvero brava l’AI che ne risulta. Per quello, come per i supercomputer scientifici da trent’anni a questa parte, serve un terzo numero — e quello, purtroppo, non sta ancora nei titoli dei giornali.

    Reazioni nel fediverso

    Luca Mauri

  • Un’unica configurazione SSH per domarle tutte

    Ho quattro macchine su cui lavoro regolarmente: due desktop (uno Windows, uno Ubuntu) e due laptop (anche qui, uno per sistema). A questi si aggiungono alcuni server Linux VPS a cui mi collego per vari progetti. Sono tanti endpoint, tante chiavi SSH e tanti profili di terminale da tenere sincronizzati.

    Per un po’ ho semplicemente convissuto col caos. Ogni volta che configuravo una nuova macchina, o reinstallavo un sistema operativo, ripetevo lo stesso rituale: ricreare la configurazione SSH, copiare le chiavi in qualche modo, reinserire tutti gli alias degli host, riconfigurare colori e font del terminale. E ogni volta che cambiavo qualcosa su una macchina — un nuovo server da aggiungere, una nuova chiave da registrare — dovevo ricordarmi di replicare quella modifica su tutte le altre. Inevitabilmente, me ne dimenticavo. Le configurazioni divergevano. Una macchina aveva l’alias, un’altra no. Era una seccatura lenta e sotterranea, che non raggiungeva mai il livello di crisi, ma non spariva mai.

    Alla fine ho deciso di risolvere il problema per davvero. La soluzione che ho trovato è semplice nel concetto, solida nella pratica, e richiede circa venti minuti di configurazione iniziale.

    L’idea di fondo: una cartella sola, ovunque

    Il ragionamento è questo: invece di tenere chiavi SSH e file di configurazione sparsi su ogni singola macchina, si mette tutto in un’unica cartella all’interno del proprio cloud storage — OneDrive, Dropbox, Google Drive, qualunque si usi già. Ogni macchina poi punta a quella cartella, invece di mantenere una copia separata.

    Il meccanismo che rende possibile tutto questo si chiama collegamento simbolico (o symlink). Funziona come un cartello stradale: quando il client SSH cerca il suo file di configurazione nel posto solito, trova un cartello che lo reindirizza alla cartella condivisa sul cloud. Dall’esterno non cambia nulla. Sotto il cofano, tutte le macchine leggono dalla stessa unica fonte di verità.

    Su Windows i collegamenti simbolici funzionano allo stesso modo — ed è la scelta giusta anche lì. Forse hai sentito parlare degli hard link, un concetto correlato, ma gli hard link funzionano solo all’interno dello stesso disco. Dato che la cartella del cloud storage di solito si trova su un percorso diverso (o addirittura su un disco diverso) rispetto al profilo utente, i collegamenti simbolici sono la scelta corretta anche su Windows.

    Un prerequisito importante: il client di cloud storage deve essere configurato per mantenere i file disponibili localmente, non solo nel cloud. Su OneDrive questa opzione si chiama “Mantieni sempre su questo dispositivo”. I file devono trovarsi fisicamente su disco, accessibili anche offline.

    Creare la cartella condivisa

    All’interno della directory sincronizzata col cloud, crea questa struttura:

    ~/CloudSync/ssh-terminal/
├── ssh/
│   ├── config
│   ├── id_ed25519_workstation
│   ├── id_ed25519_server
│   └── id_ed25519_development
└── terminals/
    ├── windows-terminal.json
    └── gnome-terminal-profiles/

    La sottocartella ssh/ contiene le chiavi SSH e il file di configurazione. La sottocartella terminals/ contiene le impostazioni dei terminali. Vedremo come popolarle entrambe nei passi successivi.

    Il file di configurazione SSH

    SSH legge le sue impostazioni da un file di testo semplice chiamato config, normalmente situato in ~/.ssh/config. È lì che si definiscono gli alias degli host, si specifica quale chiave usare per quale server, si impostano le opzioni di connessione. Se non l’hai mai usato, è una di quelle cose che, una volta scoperte, ti chiedi come hai fatto a farne a meno.

    Un esempio tipico di configurazione:

    # Esempio di configurazione SSH condivisa
Host server-produzione
    HostName 192.168.1.100
    User administrator
    IdentityFile ~/.CloudSync/ssh-terminal/ssh/id_ed25519_production
    Port 22

Host sviluppo
    HostName dev.example.com
    User developer
    IdentityFile ~/.CloudSync/ssh-terminal/ssh/id_ed25519_development

    Nota che i percorsi di IdentityFile usano il carattere ~ (tilde) per rappresentare la home directory. Vale la pena capire esattamente cosa significa, perché è il segreto della portabilità.

    Su Linux e su Windows, ogni utente ha una home directory: una cartella personale dove il sistema conserva file, impostazioni e configurazioni. Su Linux è tipicamente /home/tuonome, su Windows C:\Users\tuonome. Il carattere tilde (~) è un’abbreviazione che sia Bash su Linux che PowerShell su Windows espandono automaticamente alla home directory dell’utente corrente. Quindi ~/.ssh/config diventa /home/tuonome/.ssh/config su Linux, e C:\Users\tuonome\.ssh\config su Windows.

    Questo è ciò che rende il file di configurazione davvero portabile: dato che ogni macchina espande ~ alla propria home directory locale, la stessa riga funziona ovunque senza modifiche. Se avessimo scritto il percorso completo — /home/luca/CloudSync/... — funzionerebbe solo sulle macchine in cui il nome utente e la struttura delle directory coincidono esattamente.

    Una volta che il file config è pronto nella cartella condivisa, lo si collega al percorso che SSH si aspetta:

    Windows (PowerShell come Amministratore)

    New-Item -ItemType SymbolicLink `
  -Path "$env:USERPROFILE\.ssh\config" `
  -Target "$env:USERPROFILE\CloudSync\ssh-terminal\ssh\config"

    Ubuntu

    ln -sf ~/CloudSync/ssh-terminal/ssh/config ~/.ssh/config

    Da questo momento in poi, modificare il file di configurazione nella cartella cloud lo aggiorna istantaneamente su tutte le macchine. Aggiungi un nuovo server sul desktop, e il laptop lo conoscerà già alla prossima sincronizzazione.

    Profili del terminale: Windows Terminal

    Windows Terminal conserva l’intera configurazione — profili, schemi di colori, font, scorciatoie da tastiera — in un unico file JSON. Questo lo rende un candidato ideale per questo approccio.

    Il file si trova in:

    $env:LOCALAPPDATA\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json

    Chiudi Windows Terminal, poi sostituisci quel file con un collegamento simbolico alla copia condivisa:

    # Esegui in PowerShell come Amministratore, con il Terminale chiuso
New-Item -ItemType SymbolicLink `
  -Path "$env:LOCALAPPDATA\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json" `
  -Target "$env:USERPROFILE\CloudSync\ssh-terminal\terminals\windows-terminal.json"

    È anche possibile definire profili SSH direttamente all’interno della configurazione di Windows Terminal, in modo che i server specifici appaiano come voci con nome nel menu a tendina:

    {
    "$schema": "https://aka.ms/terminal-profiles-schema",
    "profiles": {
        "list": [
            {
                "name": "SSH Produzione",
                "commandline": "ssh server-produzione",
                "icon": "ms-appx:///ProfileIcons/server.png"
            }
        ]
    }
}

    Profili del terminale: GNOME Terminal e Ptyxis su Ubuntu

    Sia GNOME Terminal che Ptyxis conservano la propria configurazione in dconf, un database di impostazioni a basso livello usato in tutto l’ambiente desktop GNOME. Pensalo come l’equivalente GNOME del Registro di sistema di Windows: un database strutturato dove le applicazioni memorizzano le proprie preferenze. Non c’è un singolo file a cui creare un collegamento, ma è possibile esportare e importare l’intera configurazione come uno snapshot in testo semplice usando lo strumento da riga di comando dconf.

    L’approccio è identico per entrambi i terminali — cambia solo il percorso all’interno del database dconf.

    GNOME Terminal

    Per esportare i profili attuali:

    dconf dump /org/gnome/terminal/legacy/profiles:/ \
  > ~/CloudSync/ssh-terminal/terminals/gnome-terminal-profiles/profiles.dconf

    Per ripristinarli su un’altra macchina:

    dconf load /org/gnome/terminal/legacy/profiles:/ \
  < ~/CloudSync/ssh-terminal/terminals/gnome-terminal-profiles/profiles.dconf

    Ptyxis

    Ptyxis è un emulatore di terminale più recente, ora predefinito nelle distribuzioni basate su GNOME più aggiornate, come Fedora 41 e Ubuntu 25.10. Usa un percorso dconf diverso:

    dconf dump /org/gnome/Ptyxis/ \
  > ~/CloudSync/ssh-terminal/terminals/ptyxis-profiles/profiles.dconf

    Per ripristinare:

    dconf load /org/gnome/Ptyxis/ \
  < ~/CloudSync/ssh-terminal/terminals/ptyxis-profiles/profiles.dconf

    Automatizzare il ripristino dei profili all’avvio

    È possibile automatizzare il ripristino in modo che i profili vengano applicati automaticamente ad ogni accesso, aggiungendo un controllo al proprio profilo di shell (~/.profile). Adatta il percorso e la chiave dconf al terminale che utilizzi:

    #!/bin/bash
# Per GNOME Terminal:
if [[ -f ~/CloudSync/ssh-terminal/terminals/gnome-terminal-profiles/profiles.dconf ]]; then
    dconf load /org/gnome/terminal/legacy/profiles:/ \
      < ~/CloudSync/ssh-terminal/terminals/gnome-terminal-profiles/profiles.dconf
fi

# Per Ptyxis:
if [[ -f ~/CloudSync/ssh-terminal/terminals/ptyxis-profiles/profiles.dconf ]]; then
    dconf load /org/gnome/Ptyxis/ \
      < ~/CloudSync/ssh-terminal/terminals/ptyxis-profiles/profiles.dconf
fi

    Una nota sulla sicurezza

    Conservare chiavi SSH private in una cartella sincronizzata col cloud è un compromesso ragionevole, ma richiede alcune precauzioni.

    Usa sempre le passphrase

    Ogni chiave privata deve essere protetta da una passphrase robusta. Questo garantisce che anche se qualcuno dovesse accedere al tuo cloud storage, non potrebbe usare le chiavi senza conoscere la passphrase. Per generare le chiavi:

    ssh-keygen -t ed25519 -a 100 -C "workstation@$(hostname)" \
  -f ~/CloudSync/ssh-terminal/ssh/id_ed25519_$(hostname)

    Il flag -t ed25519 seleziona un algoritmo moderno ed efficiente. Il flag -a 100 aumenta il numero di cicli di derivazione della chiave, rendendo significativamente più difficile un attacco a forza bruta sulla passphrase.

    Usa chiavi separate per ogni dispositivo

    Invece di condividere una singola coppia di chiavi su tutte le macchine, mantieni chiavi distinte per dispositivo o livello di fiducia:

    • Workstation principale: id_ed25519_workstation
    • Sistemi secondari: id_ed25519_backup
    • Ambienti di sviluppo: id_ed25519_development

    In questo modo, se una macchina viene compromessa, puoi revocare solo quella chiave senza influire su tutto il resto.

    Limita i permessi sui file

    PiattaformaCosa fare
    WindowsRimuovi i permessi ereditati del gruppo “Utenti” dalla directory SSH
    Linuxchmod 700 ~/CloudSync/ssh-terminal/ssh && chmod 600 ~/CloudSync/ssh-terminal/ssh/id_*

    SSH su Linux si rifiuterà di usare chiavi con permessi troppo permissivi — quindi questo passaggio non è opzionale.

    Quando qualcosa va storto

    Alcuni problemi che potresti incontrare, e come risolverli:

    ProblemaWindowsLinux
    Creazione del collegamento fallisceEsegui PowerShell come AmministratoreProva con sudo ln -sf
    Configurazione non caricataRiavvia Windows Terminaldconf reset -f /org/gnome/terminal/legacy/profiles:/
    Chiavi non trovateVerifica che la sincronizzazione cloud sia completatals -la ~/CloudSync/ssh-terminal/ssh/
    Passphrase richiesta continuamenteStart-Service ssh-agent; ssh-addssh-add ~/CloudSync/ssh-terminal/ssh/id_*

    Per andare oltre: configurazione condizionale

    SSH supporta gli include condizionali, che permettono di caricare blocchi di configurazione diversi a seconda del sistema operativo o di altre condizioni. È utile se hai alcune impostazioni che differiscono genuinamente tra Windows e Linux:

    # ~/.ssh/config
Include ~/.ssh/config.d/common.conf

Match exec "uname -s | grep -q ^Linux"
    Include ~/.ssh/config.d/linux.conf

    Il file comune contiene tutto ciò che è condiviso tra le macchine. I file specifici per piattaforma gestiscono le eccezioni.

    Il risultato

    Una volta messo in piedi, configurare una nuova macchina richiede circa cinque minuti: installa il client di cloud sync, aspetta che la cartella si scarichi, esegui due o tre comandi di collegamento, fatto. Ogni alias degli host, ogni chiave, ogni schema di colori del terminale — già lì, esattamente come li hai lasciati sulle altre macchine.

    Ma la cosa più importante è un’altra: quando fai una modifica — aggiungi un nuovo server, ruoti una chiave, ritocchi un profilo del terminale — la fai una volta sola, e si propaga ovunque automaticamente. Niente più replicazione manuale. Niente più configurazioni che divergono. Niente più sorprese quando ti siedi a una macchina e scopri che è rimasta indietro.

    È una di quelle soluzioni che, una volta installata, dimentichi di avere. Ed è esattamente questo il punto.

    Reazioni nel fediverso

    Luca Mauri

  • Ignoranti certificati

    I certificati a chiave pubblica sono la base della sicurezza delle comunicazioni online con protocolli come https o, più in generale, TLS.

    Benchè a livello di programmazione, gli algoritmi coinvolti e la loro implementazione non siano esattamente lineari, a livello di utilizzo come amministratore di sitema sono relativamente semplici, forse troppo.

    Continua a leggere
    Reazioni nel fediverso

    Luigi Rosa

  • Installazioni nascoste via Windows Update

    Da un mesetto ho messo un Palo Alto PA-220 in modalità virtual wire tra il router Internet e lo switch di casa.

    Questa mattina controllo il report dell’ACC e trovo tanto traffico Windows Update, eppure non è patch tuesday.

    Continua a leggere
    Reazioni nel fediverso

    Luigi Rosa

  • Informazioni? Chiedi all’AI (se ti accontenti del 2023).

    È da tempo che non scrivo qualcosa, ma ho letto un articolo che mi ha fatto immediatamente pensare che sarei dovuto tornare qui.

    Da qualche anno ho iniziato a seguire in modo sempre più serio la pallavolo femminile. Per questo sono piuttosto interessato a leggere i pochi articoli dedicati a questo sport.

    Nota polemica: questo sport, diversamente da “quell’altro”, partecipa sempre ai mondiali o agli europei e, di solito, nella peggiore delle ipotesi, si classifica tra le prime 4, se non addirittura vincendoli.

    Mi è capitato tra le mani un articolo online (su Movmag.com) che, dopo averlo letto, mi ha lasciato perplesso: sembra proprio che chi l’ha scritto abbia una conoscenza limitatissima di questo sport, tanto da aver probabilmente utilizzato una Generative AI gratuita.

    (altro…)

    Kazuma

  • Esfiltrare NTDS.dit senza accesso ai DC

    In un dominio Active Directory gli hash delle password degli utenti sono registrati nel file NTDS.dit presente in ogni Domain Controller (DC), il cui path di default è C:\Windows\NTDS\NTDS.dit

    Esistono vari modi per fare una copia degli hash, ma tutti quelli normalmente elencati partono dal presupposto che si abbia accesso di un certo tipo ad un Domain Controller.

    Molte linee guida raccomandano di monitorare e regolare bene l’accesso ai DC, ma si dimenticano di un dettaglio.

    I backup.

    Continua a leggere
    Reazioni nel fediverso

    Luigi Rosa

  • Ultimo HyperTrek in HTML

    Per fare un tuffo nel passato e ricordarsi di come era il web quando era solamente HTML senza script o popup vari, ho deciso di caricare l’ultima versione di HyperTrek 100% HTML prima che venisse convertita in PHP+MySQL.

    http://www.hypertrek.org

    Mancano dei pezzi nella pagina di download e, ovviamente, non è detto che funzionino i link esterni, ma un vero geek non ha bisogno di questi avvertimenti perché ci arriva da solo.

    Per qualcosa di un po’ più aggiornato, il progetto continua su https://wikitrek.org

    Edit 2024-12-27 sera: i file di download ci sono tutti, solo hypertrek.zip è lo ZIP con il sito che vedete, gli altri sono più vecchi. Si possono scaricare anche il vecchio WinTrekHelp e i sorgenti della Norton Guide.

    Luigi Rosa

  • Migrare un telefono Android

    Passare ad un telefono nuovo è sempre una rottura.

    Android adesso fa le cose abbastanza semplici: si accende il telefono nuovo con a fianco quello vecchio collegato in Wifi, si seguono le istruzioni, si aspetta il tempo di trasferimento, si sposta la SIM ed il gioco è fatto.

    Quasi.

    Continua a leggere

    Luigi Rosa

  • Bloccare New Outlook

    Microsoft ha annunciato che da inizio 2025 inizierà a forzare il passaggio da Outlook Desktop a New Outlook.

    New Outlook non è altro che un brutto wrapper di Outlook Web Access, più limitato nelle funzionalità di Outlook Desktop, specialmente se si possiedono più account.

    Continua a leggere

    Luigi Rosa

  • Copia interna della zona pubblica

    Capita spesso di voler creare dei nomi della LAN interna con il FQDN di un nome a dominio pubblico o di voler sovrascrivere alcuni host con IP pubblico con gli stessi nomi, ma con IP interno.

    La soluzione più comune è creare una zona con lo stesso nome della zona esterna con gli stessi contenuti, a meno di quelli che devono essere differenti.

    Continua a leggere

    Luigi Rosa

  • Un UPS non fa primavera

    Questo post scaturisce da una conversazione che ho avuto pochi giorni fa con un elettricista a proposito di come debba essere inserito un UPS in un impianto elettrico un e della utilità dei relativi accessori.
    Mi sono reso conto di una ignoranza generalizzata di come funzioni un UPS e di quali siano i suoi punti di forza e di debolezza: di conseguenza ho deciso di riassumere qui una serie di argomenti che ho usato per convincere il fornitore che il modo di fare che proponevo io fosse il migliore.

    Come prima cosa ci sarebbe da ribadire il concetto per cui, invece di essere il fornitore sedicente esperto nel campo, a suggerire al cliente (povero ignorante) le soluzioni migliori, per l’ennesima volta sono stato io a dovermi documentare, a dover trovare la soluzione giusta e anche a dover convincere l’altra persona della bontà delle mie conclusioni.
    Non ne usciremo mai.

    Premetto che quanto racconto qui di seguito si applica in prima battuta a una server room, ma i concetti che stanno dietro alla spiegazione sono idealmente applicabili a impianti di ogni genere, al limite anche a quello di un datacentre.

    Premesse

    UPS è l’acronimo della frase inglese “Uninterruptible Power Supply” termine che in italiano è normalmente tradotto come “gruppo di continuità“.
    Nonostante esistano molti tipi di questi apparecchi, basati su varie tecnologie, nella sua forma più basica è sostanzialmente una batteria che viene installata tra la fornitura di corrente e gli apparati da alimentare.

    Il suo scopo è quello di smorzare eventuali fluttuazioni di corrente che potrebbero rivelarsi dannose e di erogare energia anche in caso di blackout. A seconda dei casi, la quantità di energia immagazzinata è progettata per durare i minuti necessari al graceful shutdown delle apparecchiature collegata, oppure per permettere loro di funzionare anche per periodi di tempo lunghi senza corrente esterna.
    Le apparecchiature discusse sopra sono spesso quelle definite business-critical, ovvero che sono fondamentali per il funzionamento di una qualsivoglia organizzazione.
    All’atto pratico, sono spesso server e dispositivi di rete.

    A questo punto è chiaro quindi che un UPS è un apparecchio importante, anzi fondamentale, nella progettazione di una infrastruttura IT, ma molti pensano che sia il classico silver bullet: lo compro, lo installo, me lo dimentico e tutto andrà bene.
    Anche no, questo funziona solo nei film: un UPS non fa primavera!

    Reality check

    Per prima cosa bisogna rendersi conto di due fondamentali verità:

    • Lo UPS prima o poi si guasterà
    • lo UPS deve essere manutenuto e, dopo qualche anno, andrà sostituito

    Una volta fatto pace con queste due ineluttabilità, si può iniziare a ragionare su cosa serva intorno allo UPS per renderlo davvero efficace.

    Dopo aver installato il vostro UPS ed essere andati a letto tranquilli, una telefonata vi sveglia dicendo che nella vostra infrastruttura IT non funziona nulla. Cosa sarà successo? Strano sembra che non ci sia elettricità da nessuna parte. Seguendo i cavi e controllando gli apparati, si scopre che l’UPS è guasto!
    Ebbene, sì, succede. Ve lo hanno venduto come un apparato indistruttibile e invece è proprio lui a tradirvi. Tuttavia avete collegato tutti i vostri apparati alle uscite del UPS pensando di essere protetti e dovrete quindi ricablare tutto, riparare lo UPS e poi ricablare tutto di nuovo.
    Forse esiste una soluzione migliore?

    Certo che sì.
    Avrete notato che i vostri preziosi e costosi apparati di rete, così come i server e i NAS sono dotati di due (a volte anche quattro) prese elettriche.
    Invece di collegarle entrambe allo UPS, provate a collegarne una all’UPS e l’altra alla rete elettrica diretta: in caso di assenza di corrente da una delle due sorgenti, l’altra fonte continuerà a fornire energia, tenendo accesi i vostri apparecchi.

    Regola numero 1: in ogni rack ricordate di portare due alimentazioni, una dalla rete elettrica, l’altra dall’UPS.

    Sento già le proteste dal pubblico: molti apparati professionali hanno le due (quattro, sei, quello che volete) prese elettriche, ma molti non lo hanno!
    Classico è l’esempio del vostro Internet Service Provider che vi fa pagare un prezzo ragionevole per la vostra bella connessione a internet, ma che poi vi porta il router di fascia media con una presa elettrica e stop.
    Certo, è possibile avere il router della [inserite marca costosissima a piacere] con doppia alimentazione, ma vi costa millemila euro al mese in più.

    Grazie, no.
    Quei mille euro li investo veramente, ma non in un router che dite voi, bensì in una cosa molto più utile: uno Automatic Transfer Switch.
    Un ATS è un apparecchio intelligente che ha due alimentazioni e una o più uscite.
    Avrete forse intuito che le due alimentazioni vanno collegate, una alla rete elettrica pubblica e l’altra allo UPS.
    Alle uscite del ATS si collegano i vari apparati dotati di singola presa elettrica e il commutatore si occupa automaticamente di passare da un’alimentazione all’altra quando una viene a mancare. Una serie di condensatori fanno si che l’alimentazione non fluttui nelle frazioni di secondo necessarie per commutare.

    Regola numero 2: investite in un ATS e usatelo per alimentare gli apparati low end, dotati di singola presa elettrica.

    Quindi dobbiamo alimentare lo UPS, alimentare gli apparati con doppia sorgente elettrica e alimentare lo ATS.
    Siamo a posto, finito?

    Non esattamente, manca in effetti un tassello, forse meno importante, ma comunque da considerare.
    L’ultimo componente da considerare è il cosiddetto maintenance bypass, un apparecchio che consente di “aggirare” lo UPS per permetterne la manutenzione o addirittura lo smantellamento.

    Ricordiamo che lo UPS è un apparecchio elettrico che, non solo è alimentato spesso a corrente trifase, ma che contiene anche una discreta quantità di energia (normalmente chimica) e quindi va trattato con attenzione.
    Alcune azione manutentive richiedono lo spegnimento, inoltre l’apparecchio ovviamente si può guastare in maniera catastrofica o semplicemente raggiungere la fine della sua vita operativa, necessitando smontaggio completo.

    Il bypass ha la funzione di prelevare la corrente dalla rete, trasmetterla al UPS, dopodiché prenderne l’uscita “protetta” e distribuirla al carico.
    Il lettore avrà già capito che, agendo sugli opportuni comandi, il bypass permette di scegliere se “tagliare fuori” lo UPS dal circuito elettrico distribuendo la corrente di rete a tutti gli apparati a valle.
    Effettuata questa operazione, lo UPS può essere testato, riparato o eventualmente sostituito senza disturbare il carico.

    Di nuovo sento una protesta: se i miei apparati hanno già doppia alimentazione oppure alimentazione tramite ATS, cosa mi serve avere un bypass che, in caso di guasto al UPS, non fa altro che distribuire due volte la corrente di rete?
    Fondamentalmente corretto, ma non considera la Legge di Murphy: nel momento in cui una delle due alimentazioni non è disponibile l’altro alimentatore potrebbe avere un guasto, mandando quindi a gambe all’aria la ridondanza.

    Regola numero 3: investite in un maintenance bypass e fate in modo che si possa isolare lo UPS in qualsiasi momento.

    Pessimismo?

    Pensate che sia pessimista?
    Permettetemi un aneddoto.
    Dopo 10 anni di onorato servizio, causa mancanza di parti di ricambio e impossibilità a prolungare il contratto di assistenza, ho dovuto programmare la sostituzione di un UPS. Grazie a tutto quanto scritto sopra, è stato facile isolare l’apparecchio in una normale giornata lavorativa senza interrompere l’operatività.

    Tutto bene e tutti contenti, ma cosa capita a metà del lavoro? Si verifica un black-out e, essendo lo UPS ovviamente smontato e fuori linea, si spegne tutto.
    Avrei dovuto avere due UPS in modo da fare manutenzione alternata, ma che probabilità c’era che succedesse una cosa del genere?
    Piccolissima, eppure è successo.

    Anything that can go wrong, will go wrong

    Conclusioni

    Riassumendo, quando si progetta un impianto elettrico per centri dati (di ogni dimensione) è opportuno ricordare:

    • Una alimentazione dalla rete per apparecchi con ingressi ridondanti
    • una alimentazione per un apparecchio ATS
    • una alimentazione per un maintenance switch (che poi la erogherà al UPS)

    Bisognerà poi distribuire:

    • L’alimentazione del ATS agli apparecchi con una sola presa
    • l’alimentazione del maintenance bypass (che la prende dalla rete o dal UPS) agli apparati con due prese
    • la stessa alimentazione di cui sopra all’ingresso del ATS

    Spero di avervi convinto che, anche in questo caso, esiste un modo giusto è un modo sbagliato per progettare una soluzione di alimentazioni ridondante.
    Quella giusta sembra più cara e più complicata. Alla lunga si rivelerà quella più flessibile.

    Luca Mauri

  • Il formato DBF

    Chi vi scrive ha mosso i primi passi nel mondo dei database con dBase II su CP/M, ha passato gran parte del servizio di leva davanti ad un M24 con dBase III+, si è guadagnato da vivere per un po’ di anni scrivendo applicazioni in Clipper.

    Quindi, il DBF è stato mio compagno di viaggio informatico per qualche tempo, qui trovate una bellissima e molto documentata storia di quel formato e dell’ecosistema che ha generato da quando è nato ai giorni nostri: The Rise, Fall, and Surprising Survival of dBase.

    Luigi Rosa