Migrazione da Bitbucket a Codeberg

Negli ultimi mesi abbiamo migrato i repository precedentemente ospitati su Bitbucket verso Codeberg.

La scelta non è stata dettata da limiti tecnici, ma da considerazioni più ampie legate a modello, trasparenza e controllo dei dati.

Le principali motivazioni della migrazione sono:

• privacy e trasparenza. Codeberg è una piattaforma gestita da una organizzazione no-profit europea, basata su software open source come Gitea. Questo garantisce un modello più leggibile e verificabile rispetto a soluzioni proprietarie centralizzate;
• allineamento con i nostri valori. Preferiamo strumenti con un modello orientato agli utenti e alla sostenibilità del servizio, piuttosto che alla sola massimizzazione commerciale; inoltre cerchiamo di ridurre le dipendenze dal fornitore ed i vincoli tecnologici;
• sovranità digitale. La possibilità di utilizzare un'infrastruttura europea, sotto giurisdizione europea, è un elemento rilevante per la gestione dei dati.

Codeberg offre un ambiente più essenziale rispetto a Bitbucket. Tuttavia, per il nostro contesto, questi aspetti non rappresentano un limite significativo. 

Migrazione tecnica

Dal punto di vista operativo, la migrazione è stata semplice:

bash
git clone --mirror <bitbucket-repo>
cd <repo>.git
git push --mirror <codeberg-repo>

Le attività accessorie hanno riguardato principalmente: la ricreazione delle issue (quando necessario), l'adattamento delle pipeline CI/CD, l'aggiornamento della documentazione.

Presenza su GitHub

Per alcune tipologie di progetto, in particolare quelle che richiedono maggiore visibilità e networking nella comunità internazionale, manteniamo una presenza su GitHub. In questi casi, la scelta della piattaforma è guidata da esigenze di diffusione e collaborazione più ampia.

Documentazione Facile

La documentazione relativa al nostro software Facile è stata spostata sul sito aziendale ed è consultabile all'indirizzo:  https://eosdev.it/wiki/facile/.

Usare una porta locale per una stampante condivisa

Succede che Windows "veda" una stampante condivisa in rete, ma fallisca quando si prova ad aggiungerla.

Una soluzione pratica è impostarla come stampante locale usando una porta locale che punta alla condivisione, ad esempio:

\\192.168.1.10\NomeStampante

In questo modo il PC usa il driver installato localmente e si limita a inviare i lavori alla stampante condivisa, evitando parte dei problemi legati a driver remoti, permessi e meccanismi automatici di installazione.

È un modo più diretto e, spesso, più stabile per usare una stampante condivisa, soprattutto in piccole reti senza dominio.

Unica attenzione: meglio usare un IP fisso o una prenotazione DHCP, altrimenti la porta smetterà di funzionare se l'indirizzo del PC cambia.

Italian C++ Meetup con Bjarne Stroustrup - Oltre il codice, filosofia e retroscena del C++ secondo Stroustrup

In questa seconda parte (qui la prima parte) riporto alcune domande e risposte che toccano le radici dell'informatica, il design, la sicurezza e l'educazione.

Ricordo che è possibile visionare alla fonte i contenuti su Youtube. Inoltre sul sito ufficiale dell'autore è disponibile un documento tecnico (Concept-based Generic Programming in C++) che approfondisce i concetti introdotti nella conferenza seguendone abbastanza da vicino la "linea narrativa".

---

Il confronto tra concepts ed interfacce virtuali porta Stroustrup a una preferenza chiara: vorrebbe vedere un approccio concepts first.

L'idea è partire dai requisiti che un tipo deve soddisfare, cioè dal comportamento e dalle operazioni richieste, e solo dopo definire o scegliere tipi che rispettino quei vincoli. Per l'utilizzatore non dovrebbe essere importante sapere se qualcosa sia una classe, una gerarchia con funzioni virtuali od altro: se soddisfa i vincoli espressi dal concept, allora è sufficiente.

Ha però precisato che non si tratta di un processo puramente astratto ed unidirezionale. Per costruire un buon concept spesso serve partire da uno o più tipi concreti, così da capire quali requisiti siano davvero necessari.

Le interfacce virtuali non scompaiono: restano utili quando servono vincoli ulteriori, per esempio legati ad ABI stabili o a forme specifiche di polimorfismo a tempo di esecuzione. Dove possibile, Stroustrup sembra preferire che il progetto parta dai concetti e dai vincoli semantici, non dalla meccanica dell'implementazione.

 

Sul rapporto tra concepts, interfacce e meccanismi di adesione alle astrazioni in C++, merita anche Opting into Concepts di Barry Revzin, che confronta ereditarietà, specializzazione di template, CRTP e funzioni libere/membro dal punto di vista di esplicità, intrusività e controllo degli errori.

---

Parlando dei Bell Labs, Stroustrup ha descritto quell'ambiente come un luogo straordinario, unico al mondo e ha osservato che oggi non esiste più nulla di simile. Il centro di ricerca in informatica contava, ad un dato momento, circa sessanta persone, tra cui quattro membri della National Academy of Engineering: una concentrazione impressionante di talento, competenza e conoscenza.

Uno degli aspetti che ricorda con più piacere era l'apertura dell'ambiente: si poteva entrare nell'ufficio di qualcuno e discutere direttamente con un esperto mondiale del tema che interessava in quel momento. Molto del suo lavoro, racconta, è stato fatto sulle lavagne di altre persone.

Ha ricordato, per esempio, di avere avuto come vicino Alfred Aho, uno degli autori del Dragon Book sui compilatori: se aveva bisogno di sapere qualcosa sui compilatori, poteva semplicemente parlare con uno dei massimi esperti al mondo. Anche Dennis Ritchie era, per un certo periodo, poco distante da lui lungo il corridoio.

Stroustrup ha poi espresso rammarico per la fine dei Bell Labs così come li aveva conosciuti: secondo lui fu una grande perdita di talento e competenze, qualcosa che non sarebbe dovuto accadere.

Tra gli aneddoti, ha ricordato un episodio con Rob Pike e Ken Thompson, che prepararono una dimostrazione per Arno Penzias, allora alla guida della ricerca dei Bell Labs e premio Nobel. Lo accompagnarono attraverso i corridoi per mostrargli grafica, giochi e tecnologie sperimentali. Una volta arrivati davanti al terminale finale, Penzias si aspettava di vedere qualche complesso calcolo od una simulazione scientifica. Invece, vide un'immagine di se stesso ripreso di spalle mentre entrava nella stanza.

L'episodio serve a Stroustrup per descrivere il clima del posto: un ambiente molto collegiale, in cui si poteva anche scherzare con persone di altissimo livello, purché con rispetto. Era un luogo che aiutava le persone a crescere. Arrivando lì, racconta, bastava leggere i nomi sulle porte per pensare di dover fare qualcosa di davvero notevole per meritare di appartenere a quel gruppo. La sindrome dell'impostore, conclude, non era affatto rara.

NdA: in un mondo dominato da terminali solo testo, la capacità di visualizzare flussi video digitalizzati / bitmap complesse in tempo reale rendeva tangibile il potere della nuova tecnologia grafica in modo personale ed immediato.

Il terminale in oggetto era il Blit (di cui parte della documentazione tecnica è tuttora disponibile).

 

L'episodio viene raccontato anche da Rob Pike.

---

Di fronte all'ipotesi di riprogettare il C++ "con il senno di poi", Stroustrup ha richiamato il classico "problema della macchina del tempo". È facile, oggi, immaginare consigli da dare al passato; molto più difficile è capire se, all'epoca, quei consigli sarebbero stati davvero utilizzabili.

Il punto centrale è che molte scelte di C e C++ furono condizionate dai limiti tecnici del tempo. Stroustrup ricorda di aver iniziato a lavorare su una macchina con 128 KB di memoria dati; Dennis Ritchie, per il primo C, aveva a disposizione ancora meno: circa 48 KB di memoria totale. Con vincoli di questo tipo, anche la complessità del parser, dell'analisi statica e delle regole del linguaggio doveva essere contenuta.

Una delle cose che Stroustrup avrebbe voluto migliorare è la sintassi. La famosa sintassi inside out di C e C++ (vedi, per esempio, The Clockwise/Spiral Rule) deriva anche dal fatto che Ritchie non voleva inserire due analizzatori sintattici separati nella memoria disponibile: per questo espressioni e dichiarazioni finirono per condividere parte della grammatica. È una scelta che da allora ha reso possibile scrivere dichiarazioni molto complesse, ma anche difficili da leggere; Stroustrup osserva, con una certa ironia, che non bisognerebbe essere troppo orgogliosi di saper scrivere una funzione che restituisce un puntatore a funzione senza usare un `typedef`.

C'è però una cosa che, secondo lui, avrebbe potuto capire e implementare anche allora... se qualcuno gliel'avesse spiegata nel modo giusto: i `concepts`.

Secondo Stroustrup, i `template` senza vincoli rendono il linguaggio più complicato, più difficile da usare e persino più difficile da implementare, perché i controlli devono essere distribuiti "ovunque". Se qualcuno fosse tornato indietro nel tempo, nel periodo in cui lavorava sui template, e gli avesse spiegato chiaramente l'idea di funzioni valutate a tempo di compilazione che prendono tipi come argomenti, probabilmente sarebbe stato difficile convincerlo subito, ma aveva già le conoscenze necessarie per comprenderla.

In questo senso, i concept sono una delle poche cose per cui una macchina del tempo avrebbe davvero aiutato: introdurli prima avrebbe semplificato l'implementazione dei template e si sarebbe adattato meglio al suo modo di pensare.

---

Sul tema delle critiche di Linus Torvalds al C++, Stroustrup ha risposto in modo piuttosto netto. Anzitutto ha ricordato, con una punta di ironia, che oggi Torvalds scrive anche codice C++.

Poi ha contestualizzato le critiche storiche: quando Torvalds espresse le sue posizioni più dure, nel 1996, anche Stroustrup non riteneva il compilatore C++ di GCC sufficientemente maturo. Se la critica fosse stata "quel compilatore non è all'altezza per scrivere un sistema operativo", Stroustrup avrebbe potuto concordare.

Il problema è che la critica andava oltre lo strumento specifico e diventava un giudizio sul linguaggio e sulle persone che lo usavano. Su questo Stroustrup non è d'accordo: C++ non era il linguaggio più facile né il più economico da adottare e non aveva un grande apparato di marketing a sostenerlo. Eppure è arrivato ad avere milioni di utenti. Non è plausibile, osserva, pensare che fossero tutti stupidi.

In sintesi, Stroustrup distingue tra una critica tecnica, che può essere fondata, per esempio sulla qualità degli strumenti disponibili in un certo periodo ed una critica generalizzata al linguaggio ed alla comunità, che considera semplicemente sbagliata.

---

Il tema della sicurezza ha portato anche all'invito del governo statunitense, nel 2024, ad abbandonare il C++ per ragioni di sicurezza. Stroustrup ha osservato che quella posizione si è già fatta più specifica e meno semplicistica. Non si tratterebbe più di una condanna generica di "C/C++", ma di un'analisi più dettagliata delle pratiche che causano problemi.

Secondo Stroustrup, molte delle operazioni pericolose attribuite a C++ non sono necessarie nel C++ moderno: se si scrive codice "in stile C", si ereditano anche molti dei problemi tipici del C, come buffer overflow e violazioni di memoria. Inoltre, osserva che spesso i dati citati sulla sicurezza mescolano C e C++, mentre analisi più attente mostrerebbero che una parte molto rilevante dei problemi riguarda C o C++ scritto in stile C.

Il punto, quindi, non è negare l'esistenza dei problemi, ma distinguerne le cause. Per Stroustrup, la risposta non dovrebbe essere abbandonare C++, ma eliminare progressivamente le pratiche insicure: profili più restrittivi del linguaggio, librerie hardened, controlli sugli accessi fuori range e strumenti migliori possono ridurre molto il rischio.

Ha citato anche il fatto che oggi esistono librerie hardened disponibili da realtà come Google, Apple e Microsoft, che possono introdurre controlli aggiuntivi, per esempio sui limiti degli array o dei container. Qui emerge un altro problema: molte di queste soluzioni, quando rilevano una violazione, terminano il programma.

Per alcune applicazioni questo è accettabile: in un grande data center, se un processo termina, il carico può essere spostato altrove. Nei sistemi embedded, real time o safety critical la situazione è diversa. Se un singolo processore controlla qualcosa di vitale, non si può semplicemente terminare il programma al primo errore.

Stroustrup cita l'esempio di un controller dell'ossigeno in un sistema subacqueo: se c'è una violazione di un'asserzione, terminare il software potrebbe essere l'errore fatale. In questi contesti servono strategie di gestione dell'errore più sofisticate: contenere il problema, portare il sistema in uno stato sicuro, ripristinare o reinizializzare dove possibile.

Il tema centrale, ancora una volta, è che non tutti i domini sono uguali. La sicurezza del software non si ottiene solo cambiando linguaggio, ma capendo quali errori si vogliono prevenire, quali vincoli ha il sistema e quale comportamento è accettabile quando qualcosa va storto.

---

Alla domanda se sia preoccupante che molti studenti di informatica inizino con Python e possano non arrivare mai ad usare un linguaggio compilato, Stroustrup ha risposto di sì: secondo lui è un problema reale.

Il rischio è che molti studenti si abituino a pensare che efficienza, manutenibilità, garanzie e comprensione di ciò che accade "sotto" siano problemi di qualcun altro. Python può essere uno strumento utile, ma sotto Python serve comunque qualcuno che costruisca sistemi efficienti. Se si usa Python direttamente, invece di usarlo come interfaccia verso codice più efficiente scritto per esempio in C++, i costi in termini di prestazioni ed energia possono diventare molto elevati.

Stroustrup osserva anche che chi inizia solo con Python spesso incontra difficoltà quando arriva ad algoritmi, strutture dati e programmazione di sistema: nei programmi Python di grandi dimensioni emergono problemi seri di manutenibilità.

Più in generale la questione riguarda l'educazione informatica. Secondo Stroustrup è un errore trattare computer science, informatica applicata ed alfabetizzazione digitale come se fossero la stessa cosa. Chi deve costruire sistemi safety critical od infrastrutture fondamentali ha bisogno di una formazione diversa da chi deve sviluppare piccole applicazioni web. Non dovrebbero avere lo stesso curriculum, gli stessi esercizi, né gli stessi criteri di valutazione.

Per rispondere al problema, Stroustrup propone quindi di distinguere meglio i percorsi formativi. Vorrebbe vedere informatici con una mentalità ingegneristica, formati su linguaggi compilati, sistemi, costruzione di software, manutenibilità, prestazioni, affidabilità e processi per garantirle.

In questo quadro colloca anche il suo lavoro su C++: non come alternativa diretta a Python, ma come linguaggio pensato per ingegneri ben formati che devono costruire software efficiente, affidabile e mantenibile.

Italian C++ Meetup con Bjarne Stroustrup

I Dipartimenti di Ingegneria dell'Informazione dell'Università di Pisa e dell'Università di Firenze, insieme all'Italian C++ Community hanno organizzato un fantastico incontro con il professor Bjarne Stroustrup, il creatore del linguaggio C++.

L'intero evento è stato coinvolgente: interessante l'approfondimento tecnico sul Concept-based Generic Programming e non meno stimolante la seconda parte, in cui i partecipanti hanno potuto porre domande in libertà.

Il video completo dell'evento è disponibile su YouTube.

Naturalmente, il tema della programmazione assistita dall'IA è stato oggetto di diverse domande. Credo di poter riassumere abbastanza fedelmente il punto di vista di Bjarne Stroustrup in alcuni punti.

Nelle applicazioni che richiedono alta affidabilità, alte prestazioni ed un alto grado di manutenibilità, è necessaria molta prudenza. Gli LLM possono certamente aiutare e non c'è motivo di dubitare di chi dice di trarne beneficio; tuttavia, gli attuali tassi di errore fanno sì che non ci si possa affidare troppo al codice generato. Questo può essere prodotto molto rapidamente, ma deve, comunque, essere revisionato con grande attenzione. Le persone, in generale, non sono particolarmente brave a revisionare codice con il livello di cura necessario: anche per questo i sistemi di tipi, uno degli argomenti della prima parte della conferenza, restano fondamentali.

C'è poi un aspetto organizzativo non secondario: gli sviluppatori esperti potrebbero non voler passare il proprio tempo a revisionare grandi quantità di codice generato. Alcuni preferirebbero persino andare in pensione piuttosto che essere spostati da un ruolo di progettazione ad uno prevalentemente di revisione.

Il messaggio generale non è un rifiuto dell'IA, ma un invito alla cautela. Usare strumenti come Copilot (ed ancora di più strumenti più generali come Claude) richiede una notevole esperienza. In altri ambiti l'IA può essere più appropriata, ma il punto centrale è distinguere il contesto: non tutto il software ha lo stesso livello di rischio e non tutte le conseguenze di un errore sono uguali.

---

Un altro aspetto importante riguarda l'impatto dell'IA sull'apprendimento e sulla capacità di ragionare criticamente. Secondo Stroustrup esistono già studi che indicano come l'uso dell'IA per produrre rapidamente risposte od elaborati possa ridurre l'apprendimento effettivo: si ricorda meno, si comprende meno, perché imparare richiede sforzo, tempo ed anche una certa fatica.

Ha poi citato un rischio ulteriore, ancora non sufficientemente dimostrato ma plausibile: gli studenti più preparati potrebbero riuscire a usare bene l'IA, mentre quelli più deboli potrebbero usarla come una stampella. In questo caso l'IA finirebbe non per ridurre, ma per ampliare le differenze tra le persone.

---

Sul codice generato dall'IA, Stroustrup distingue ancora una volta tra domini diversi. L'IA può produrre buon codice per problemi già risolti molte volte ed affrontati in modo convenzionale. Il problema nasce invece nei settori di cui si occupa più spesso: software critico, spesso basato su conoscenze specialistiche, non sempre presenti nei dati di addestramento ed in cui un errore può causare gravi danni.

Inoltre, quando si cerca di promuovere modi nuovi e migliori di programmare, l'IA tende a riprodurre ciò che è statisticamente più presente nel materiale di addestramento: il "buon vecchio modo", per esempio array C, puntatori... tecniche tradizionali invece delle soluzioni più moderne e sicure. Anche qui, il suo punto non è che l'IA sia inutile, ma che nel dominio che gli interessa di più ci siano fondate ragioni di preoccupazione. Come ha sintetizzato lui stesso: l'IA è artificiale, non intelligente.

---

Una domanda particolarmente interessante ha riguardato il futuro dei linguaggi di programmazione: se il codice fosse sempre più letto dagli esseri umani ma scritto dall'IA, la chiarezza diventerebbe più importante dell'espressività? L'IA potrebbe scrivere direttamente in una rappresentazione intermedia, più vicina alla macchina?

Stroustrup ha contestato anzitutto la premessa: non è convinto che la maggior parte del codice sarà scritta dall'IA; nondimeno ha affermato come l'espressione diretta delle idee sia utile sia per gli esseri umani sia per l'IA. Non vede quindi, in linea di principio, alcun problema nel fatto che un'IA possa generare direttamente una rappresentazione intermedia.

Il punto che, però, non si può saltare, è il controllo dei tipi. Per Stroustrup i tipi sono assolutamente essenziali. L'idea di affidarsi a rappresentazioni ambigue od a sistemi di tipi troppo semplificati è, secondo lui, sbagliata per affidabilità, manutenibilità e prestazioni.

---

In chiusura, Stroustrup ha ribadito ciò che considera ancora centrale in C++: la rappresentazione diretta delle idee nel codice, in una forma che consenta di fare cose nuove e di farle in modo efficiente. Il punto non è solo la performance, ma l'equilibrio tra affidabilità, manutenibilità, prestazioni ed espressività.

In futuri post riporteremo ulteriori domande e risposte che hanno toccato altri argomenti interessanti e curiosi.

Parlare per capirsi o per impressionare?

Spesso mi ritrovo ad usare inutili termini od oscuri acronimi inglesi. Immancabilmente, poi, mi sento in colpa.

Ci sono volte in cui è impossibile farne a meno (davvero?), tuttavia, in genere, il problema risiede in:

• una mescolanza di pigrizia e prolungata esposizione ad ambienti popolati da tecnici informatici, brillanti project manager (volutamente in inglese) e consulenti di ogni sorta (il mondo è tanto bello);
• desiderio di circondarsi di un'aura di competenze o modernità.

Sì, oggi siamo polemici per cui ecco una lista di parole da sostituire con l'equivalente italiano.

Tecnici

Bug → errore, difetto. Purtroppo ci cado sempre.

Crash → blocco, arresto. 

Custom (ed assai peggio customizzato) → personalizzato, su misura.

File → vedi lo specifico articolo. 

Log → registro. 

Release → versione.

Repository→ archivio. Anche se repo fa tanto sviluppatore professionista.

Storage → memoria (o memoria di massa), archiviazione.

Ticket→ segnalazione o richiesta di assistenza. Purtroppo nei momenti di crisi, quelli nei quali siamo più fragili ed esposti, ci ritroviamo ad utilizzare CRM con case/ticket/issue da segnalare/aprire finendo così profondamente condizionati dal termine inglese.

Workflow → flusso di lavoro. È più frequente costruire una frase per poter utilizzare questo termine piuttosto che averne effettivamente bisogno!

Consulenti, manager (lato sensu) e project manager

Best practice → buone pratiche, procedure collaudate, metodologie (metodologie!) collaudate.

Brainstorming → confronto di idee.

Budget → stanziamento o disponibilità economica. È un'equivalenza completa, perciò utilizzare questo termine è peccato ancor più grave.

Call → non offenderò l'intelligenza del lettore proponendo alternative.

Deadline → una scadenza senza fatale (dead) e senza via di uscita?

Follow-up → seguito, riscontro.

Meeting → la cara (si fa per dire), vecchia (ed inutile) riunione.

Performance → prestazioni. 

Update → aggiornamento.

Value proposition → vedi l'articolo dedicato.

Tutti

Content creator → proprio perché ormai tutti siamo creatori di contenuti, è del tutto inutile volersi dare un tono usando la formula inglese.

Fake news → notizie false. No, ormai anche i bambini delle elementari dicono fake news, quindi non sembrerete più intelligenti usandolo anche voi.

Feedback → questa è una parola interessante perché, sebbene possa esser tradotta fedelmente, la scelta migliore dipende dal contesto. Quindi commento, riscontro, opinione, valutazione, reazione; in ambito tecnico retroazione o risposta.

Follower → certo seguace ricorda una setta, ma cosa ci impedisce di usare iscritto?

Hashtag → quando ci si riferisce al carattere (`#`) possiamo chiamarlo filetto (anche se ci prenderanno in giro), più in generale etichetta va benissimo (purtroppo non ha mai attecchito).

Like → mi piace.

Rovesciamento del punto di vista

Non sono da trascurare neanche quelle parole che, pur essendo italiane, sono uscite dal limbo per la loro assonanza con l'equivalente inglese "di moda".

Si tratta di parole abusate ed irritanti, tutte caratterizzate da "inflazione semantica". Utilizzarle ci riduce al livello di un puffo: "Grande Puffo vorrei puffare il puffo che mi puffa quando puffo..." solo con 'assertività', 'resilienza' (o simili) al posto di `puff*`! 

Assertività → devo ancora imbattermi in un corso di formazione nel quale non se ne faccia uso. Parole come fermezza, gentilezza, capacità di farsi valere, chiarezza sono state soppiantate perché troppo "vecchie".

Iconico → il marketing, moderno demonio, vorrebbe conferire un'aura di sacralità (vedi icona) a cose e persone effimere definendole iconiche. Le scarpe, una serie TV,  una padella di penne al salmone... non sono iconiche; possono, tuttavia, essere emblematiche, simboliche, rappresentative, fantasmagoriche, leggendarie... Correttamente, invece, parliamo di "segno iconico" riferendoci a qualcosa che mantiene una relazione di somiglianza con l'oggetto significato (come nei casi di una mappa od un'icona del desktop).  

Resilienza → viene dal latino ed ha sempre trovato posto in ambito fisico/tecnico e psicologico/sociale, tuttavia il continuo uso, esteso al linguaggio comune, la rende abusata ed insopportabile. Guai a dire forza d'animo, adattabilità, tenacia, equilibrio... no solo resilienza; flessibilità, capacità di adattamento, tolleranza ai guasti, robustezza ed affidabilità... termini aboliti per suonare più tecnici e positivi (davvero?).

 

---

La competenza non si misura dalla quantità di parole solenni che riusciamo ad infilare in una frase, ma da quante ne possiamo togliere senza perdere precisione.

Linux ed il codice generato dai LLM

La comunità del kernel Linux, con Linus Torvalds in prima linea, ha stabilito una posizione chiara circa l'uso dell'intelligenza artificiale nella scrittura del codice: AI Coding Assistants.

In modo pragmatico, gli strumenti di IA non vengono vietati, sarebbe poco realistico farlo; vengono considerati un aiuto al pari di altri già presenti nel flusso di lavoro. Quello che conterà davvero non è l'origine del codice, ma la sua qualità.

Il punto centrale della decisione è il rifiuto esplicito del cosiddetto AI slop, cioè codice generato automaticamente ed inserito senza una reale comprensione o revisione. In altre parole, non è accettabile copiare ed incollare ciò che produce una macchina senza verificarlo a fondo.

Viene ribadito un principio già fondamentale nello sviluppo del kernel: la responsabilità è sempre e comunque umana. Chi invia una modifica deve conoscerla, capirla e risponderne, indipendentemente dal fatto che sia stata scritta interamente a mano o con l'aiuto dell'IA. Se ci sono errori, problemi o vulnerabilità, è lo sviluppatore a doverne rendere conto.

Per mantenere trasparenza, è stato anche concordato che l'uso dell'intelligenza artificiale debba essere dichiarato esplicitamente nei contributi, attraverso appositi riferimenti (`Assisted-by`).

CSF - Invito a visitare il nostro spazio espositivo

 

Avviso di sicurezza RDP a seguito dell'aggiornamento Windows Aprile 2026

Con l'aggiornamento Windows, documentato da Microsoft il 14 aprile 2026, l'apertura dei file `.rdp` è diventata più restrittiva. Al primo utilizzo compare un messaggio informativo sui rischi di phishing legati ai file RDP; successivamente, ad ogni apertura, viene mostrato un nuovo dialogo di sicurezza che indica il computer remoto e le risorse locali richieste, come clipboard, dischi, dispositivi o componenti di autenticazione, lasciandole disabilitate, di default, finché l'utente non le abilita esplicitamente. Se il file non è firmato digitalmente, compare anche l'indicazione di publisher sconosciuto.

Si tratta di una misura sensata dal punto di vista della sicurezza, ma in alcuni contesti può risultare fastidiosa o rallentare l'operatività quotidiana.

Come risolvere?

Non basta più "accettare il rischio" come in passato. Per presentare un publisher verificabile ed evitare il classico "Unknown publisher", la strada corretta è firmare digitalmente i file `.rdp` con un certificato trusted (dai client). Microsoft consiglia la procedura tramite rdpsign.

Un passo indietro

Se serve una soluzione rapida e temporanea, è possibile disabilitare il nuovo comportamento del client intervenendo sul registro di Windows. Da PowerShell, con diritti di amministratore:

---

set-itemproperty 'HKLM:\Software\Policies\Microsoft\Windows NT\Terminal Services\Client' RedirectionWarningDialogVersion 1

---

L'equivalente `.reg` è:

---

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Terminal Services\Client]
"RedirectionWarningDialogVersion"=dword:00000001

---

In entrambi i casi si tratta di un rimedio temporaneo, utile magari come hotfix, non della soluzione migliore nel medio periodo.

Firmare file .rdp in una piccola LAN (senza complicazioni inutili)

Se si utilizzano file `.rdp` in una piccola rete (2-3 PC), una PKI completa o una CA pubblica sono spesso eccessive. In questi casi si può adottare un approccio molto più semplice: creare un certificato self-signed su un PC, esportarne la parte pubblica ed installarla come attendibile sugli altri computer.

Creare il certificato

Su uno dei PC, da PowerShell eseguito come amministratore:

---

$cert = New-SelfSignedCertificate -Type CodeSigningCert -Subject "CN=RDP Signing" -CertStoreLocation "Cert:\CurrentUser\My"

---

Il certificato viene salvato nello store personale dell'utente corrente. La chiave privata resta su questa macchina.

 

Esportare il certificato

---

Export-Certificate -Cert $cert -FilePath "C:\temp\rdp-signing.cer"

---

A questo punto si può copiare  `rdp-signing.cer` sugli altri computer.

Rendere attendibile il certificato

Su tutti i PC, incluso quello che firma, il certificato va installato nello store del Computer locale e copiato in due contenitori: Trusted Root Certification Authorities.

Lo si può fare con doppio click sul file `.cer` e procedura guidata, oppure da riga di comando:

---

certutil -addstore "Root" rdp-signing.cer
certutil -addstore "TrustedPublisher" rdp-signing.cer

---

Questo passaggio è fondamentale: senza attendibilità lato client, la firma non elimina l'avviso sul publisher.

Firmare i file `.rdp`

Sul PC che possiede il certificato con chiave privata si usa rdpsign.exe:

---

rdpsign /sha256 <thumbprint> file.rdp

---

Il thumbprint si ricava, sul PC che firma, con:

---

$cert.Thumbprint

---

Il thumbprint serve solo sul PC che firma. Sugli altri computer non serve per firmare nulla: lì viene installato solo il certificato pubblico, usato per verificare la firma. In altre parole, i client controllano l'identità del publisher e l'integrità del file, ma non hanno accesso alla chiave privata.

Verifica finale

Sul PC "client" aprire `certlm.msc` e controllare che il certificato sia presente in: Trusted Root e Trusted Publishers.

Per scenari più ampi bisogna ricorrere ad una PKI interna (es. Active Directory Certificate Services) oppure ad un certificato pubblico.

Outlook classic e le cartelle in inglese con l'account Aruba-IMAP

Il problema delle cartelle in inglese (come Sent, Trash o Drafts) su un account IMAP Aruba è solitamente legato a come il client di posta interpreta i nomi inviati dal server. 

Si può, quasi sempre, risolvere il problema forzando la ridenominazione delle cartelle standard in italiano, tramite un comando specifico:

• chiudere completamente Outlook;
• premere i tasti Windows + R sulla tastiera per aprire la finestra Esegui;
• digitare `outlook.exe /resetfoldernames` e premere Invio;
• incrociare le dita.

Outlook si avvierà e proverà a riassociare i nomi corretti in base alla lingua del sistema.

Come funziona la condivisione su Google Drive

Google Drive è uno strumento ormai molto diffuso per scambiare documenti, ma il suo funzionamento non è sempre così intuitivo come potrebbe sembrare.

Quando si condivide un file, infatti, non si invia una copia, come avviene con gli allegati delle email (o con i vecchi dischetti): si concede invece l'accesso allo stesso documento originale. Il file resta conservato nello spazio di chi lo ha creato e tutte le persone autorizzate lavorano proprio su quello.

Le possibilità sono essenzialmente due:

• condivisione diretta, si indicano le persone tramite indirizzo email;
• condivisione tramite collegamento: si crea un link che può essere più o meno aperto.

È inoltre possibile condividere intere cartelle: in questo caso, i documenti contenuti seguono automaticamente le stesse regole di accesso.

Non tutti possono fare tutto. Il sistema prevede diversi livelli di accesso: visualizzazione (si può soltanto leggere), commento (si possono aggiungere osservazioni) e modifica (si può intervenire direttamente sul contenuto).

I livelli permettono di organizzare il lavoro in modo ordinato, evitando interventi indesiderati.

Dove stanno i file

Un punto importante, spesso trascurato, è che il documento resta sempre nello spazio del proprietario; chi lo riceve lo trova tra i file "condivisi con me".

È possibile aggiungerlo al proprio spazio, ma si tratta solo di un collegamento. Solo creando una copia si ottiene un file separato, indipendente dall'originale.

Una delle caratteristiche più interessanti è la possibilità di lavorare in più persone sullo stesso documento, contemporaneamente. Le modifiche compaiono in tempo reale e si può sempre tornare indietro grazie alla cronologia delle versioni.

Il sistema è stato progettato per essere rapido e pratico. Proprio per questo, conviene usarlo con un minimo di attenzione: assegnare i permessi giusti e scegliere con cura come condividere evita molti problemi (dare a ciascuno solo l'accesso di cui ha davvero bisogno).

Linux compose key sequences

Usare una tastiera US è spesso la scelta più naturale per programmare.

Tuttavia scrivere testo in italiano (od in altre lingue) diventa rapidamente scomodo. La compose key di Linux risolve il problema in modo sorprendentemente elegante offrendo sequenze logiche di tasti al posto di codici mnemonici arbitrari.

Abbiamo raccolto in un unico documento alcune regole, i pattern ricorrenti, le sequenze più utili e la tabella completa:

https://github.com/morinim/documents/blob/master/sysadmin/linux_compose_key_sequences.md

Programmare senza limiti… o senza capire?

Cosa succederebbe se fossimo costretti a far funzionare il codice con metà della memoria, rendendolo due volte più veloce e riducendone ad un decimo il traffico di rete?

La prima reazione sarebbe probabilmente il panico. Poi, però, inizierebbe la parte interessante: cominceremmo a guardare il programma con occhi diversi, a mettere in discussione aspetti prima scontati e ad indagare gli angoli più nascosti del sistema. Raggiungere tutti gli obiettivi prefissati potrebbe risultare impossibile, ma sarebbe comunque sorprendente constatare quanto potenziale fosse rimasto inutilizzato.

Le persone che scrissero i primi videogiochi ed i primi sistemi operativi vivevano sotto questo tipo di pressione ogni singolo giorno. L'hardware non lasciava loro alcun margine per essere vaghi su come funzionasse qualcosa, così svilupparono una relazione estremamente intima con il loro mezzo. Da quella relazione nacquero alcuni dei software più geniali mai scritti. Proprio grazie alla "difficoltà".

Noi abbiamo ereditato macchine molto più veloci e memoria più economica, questo è ovviamente un bene. Eppure da qualche parte lungo la strada abbiamo smesso di porci quelle domande scomode. Credo che ci sia qualcosa di prezioso da recuperare in quell'atteggiamento.

Forse oggi siamo ad un nuovo punto di svolta. Con l'arrivo dei grandi modelli linguistici, programmare sta diventando sempre più assistito e, in molti casi, anche più superficiale: è facile produrre prototipi che funzionano, molto più difficile capire davvero perché funzionano o quanto siano efficienti. Il rischio è che emerga una generazione di programmatori sempre meno consapevoli dei meccanismi profondi delle macchine su cui lavorano.

Ovviamente potrebbe accadere anche il contrario: questi strumenti potrebbero liberarci dal lavoro più meccanico e permettere ai programmatori migliori di concentrarsi proprio sulla creazione di software più ingegnoso. Il futuro dipenderà probabilmente da quale delle due strade decideremo di imboccare.

Un caso reale di compromissione di una casella Outlook, analisi e raccomandazioni operative

Recentemente ci siamo trovati ad affrontare un episodio piuttosto complesso relativo alla casella di posta elettronica di un cliente. Il comportamento osservato inizialmente poteva essere interpretato come un normale tentativo di phishing o spam, ma l'analisi tecnica ha mostrato che la situazione era più articolata.

Ogni email ricevuta nella casella veniva automaticamente sostituita con un messaggio di estorsione (il classico schema di sextortion scam), contenente richieste di pagamento in criptovaluta ed affermazioni false riguardo a presunti accessi a webcam, documenti personali e cronologia di navigazione.

La particolarità del caso era che qualsiasi email in arrivo veniva modificata: anche messaggi di prova inviati da account diversi arrivavano correttamente per pochi istanti e poi venivano sostituiti con il medesimo testo fraudolento.

Un ulteriore elemento significativo era la comparsa periodica di messaggi nella cartella Bozze, che venivano poi spostati nella Posta in arrivo. Questo indicava chiaramente che un processo con accesso alla mailbox stava creando nuovi messaggi e sostituendo quelli originali.

Dopo diverse ore di analisi, incluse verifiche sugli header SMTP, controlli delle impostazioni di sicurezza e revoche progressive delle sessioni, il problema è stato risolto revocando tutte le sessioni attive e disconnettendo completamente gli accessi alla casella, interrompendo così l'attività dell'attaccante.

L'episodio offre alcuni spunti utili sia in termini di prevenzione sia di gestione operativa di incidenti simili.

L'abbiamo sempre avuto, bastava conoscere la parola magica

Windows nasconde da anni un piccolo paradosso: tutti usano Esplora file per copiare cartelle pesanti, poi si lamentano perché è lento, si incarta, sembra riflettere sul senso della vita… ed intanto nel sistema c'è già Robocopy, uno strumento integrato pensato proprio per fare copie serie.

Non è nuovo, non è bello, non è pubblicizzato, non ha i bottoncini rassicuranti delle interfacce moderne, ma fa una cosa molto apprezzata da chi programma: lavora.

Microsoft lo documenta come comando integrato per copiare file e directory, con opzioni avanzate e supporto al multi-threading tramite `/MT`, che consente di velocizzare parecchio i trasferimenti in molti scenari.

La parte quasi comica è che molti utenti cercano utility esterne, benchmark, tutorial arcani e forse anche conforto spirituale, senza sapere che la soluzione era già lì, preinstallata, in attesa dentro il prompt come un vecchio amministratore di sistema che non parla molto ma risolve i problemi.

Robocopy è particolarmente utile quando i file sono tanti, le directory profonde o il trasferimento deve essere più affidabile del classico trascina-e-prega.

Un esempio vale più di mille parole

robocopy "C:\Sorgente" "D:\Destinazione" /E /MT:16 /R:5 /W:5 

Copia tutto, incluse le sottocartelle, usa 16 thread e riprova 5 volte in caso di errore.

Due opzioni "salvavita":

• /Z (restartable mode): se salta la connessione di rete o la corrente, la copia riprende da dove si era fermata, senza ricominciare da zero;
• /LOG: utile per chi deve certificare che la copia sia andata a buon fine (compliance / backup).

Spegnimento di emergenza, funzione nascosta che può salvare il PC bloccato

Cominciamo con una domanda retorica: avete mai sperimentato il blocco completo di Windows? :-)

In questi casi, il gesto più istintivo è tener premuto il tasto di alimentazione e forzare lo spegnimento. Eppure...

Windows include una funzione di emergenza, pensata proprio per queste situazioni!

Cos'è lo spegnimento di emergenza di Windows

Lo spegnimento di emergenza è una funzione integrata in Windows che consente di forzare l'arresto del sistema in modo più controllato rispetto al reset fisico.

Non è una funzione visibile nei menu classici ed è proprio per questo che molti utenti non ne conoscono l'esistenza.

È pensata per i casi in cui:

• il sistema operativo non risponde più;
• il desktop è bloccato;
• le normali opzioni di spegnimento non sono accessibili;
• forzare l'arresto hardware potrebbe aumentare il rischio di errori o perdita di dati.

Come attivare lo spegnimento di emergenza

La procedura è semplice, ma va eseguita solo quando necessario:

• premere Ctrl + Alt + Canc;
• nella schermata che compare, tener premuto Ctrl;
• cliccare sull'icona di spegnimento in basso a destra;
• apparirà la finestra di spegnimento di emergenza;
• premere OK per confermare.

A questo punto Windows tenterà un arresto immediato, saltando i normali processi di chiusura.

Spegnimento normale vs spegnimento di emergenza

Lo spegnimento normale chiude programmi e servizi in modo ordinato, salva le impostazioni di sistema; è la modalità consigliata nella vita quotidiana.

Lo spegnimento di emergenza interrompe immediatamente i processi e non garantisce il salvataggio dei dati. Va usato solo in caso di blocco totale, non è "un'alternativa veloce" ma uno strumento di emergenza.

Quali rischi considerare prima di usarlo

Lo spegnimento di emergenza non è privo di rischi:

• perdita di file non salvati;
• corruzione temporanea del file system;
• necessità di controlli automatici al riavvio.

Proprio per questo non va usato come abituale alternativa al classico spegnimento.

Tipicamente vi si può ricorrere quando:

• il sistema è "congelato";
• non si possono chiudere programmi né riavviare normalmente.

In tutti gli altri casi, meglio attendere o provare una chiusura ordinaria.

Adobe Acrobat Reader 2025.00120997 e problemi con Windows 7

In realtà non è giusto definirli problemi: Windows 7 è ormai "in pensione" da tempo ed è lecito che l'azienda sviluppatrice non lo supporti più ufficialmente. Fatto sta che, negli ultimi giorni, gli "irriducibili di Windows 7" stanno sperimentando seri problemi con la versione del programma in oggetto.

Non c'è molto da fare, la soluzione più rapida e probabilmente più sicura, anche per il futuro, consiste nel disinstallare, dal Pannello di Controllo, l'ultima versione di Acrobat Reader.

Successivamente consigliamo di installare Sumatra PDF (scaricabile sia in versione 32bit che 64bit).

Si tratta di un programma opensource, estremamente leggero ed ancora compatibile con Windows 7 (ultima versione ad oggi disponibile).

Ho chiamato mentre il tuo telefono era occupato...

È una tattica piuttosto irritante e sfrutta un trucco psicologico per indurre a richiamare.

I giapponesi la chiamano wangiri. La sequenza tipica è:

• lo spammer ti chiama utilizzando dei software che effettuano un ping (una chiamata brevissima che viene interrotta in una frazione di secondo);
• se la tua linea è libera, ricevi l'avviso di chiamata persa / se sei al telefono, scatta il servizio del tuo operatore che invia l'SMS di notifica ("il numero +39... ti ha cercato alle ore... mentre avevi il telefono occupato").

Perché lo fanno?

Vogliono che l'input sembri istituzionale: ricevere un SMS dal proprio operatore (es. "Messaggio da TIM / Vodafone / Wind") dà una falsa sensazione di sicurezza rispetto ad una semplice chiamata persa proveniente da un numero sconosciuto; spinge a pensare: "Ah, il mio operatore mi sta avvisando che qualcuno di importante non è riuscito a trovarmi".

Ovviamente non bisogna richiamare. Spesso si tratta di numeri a tariffazione speciale o numeri utilizzati per confermare che la tua utenza è attiva, esponendoti, in futuro, ad ancora più spam.

La soluzione migliore è bloccare il numero usando la funzione integrata nello smartphone.

Gestione dello spazio su Windows: ottimizzare l'impronta del sistema con CompactOS

Uno dei componenti che incide maggiormente sull'occupazione del disco in ambiente Windows è la cartella di sistema. Spesso si ricorre a software di pulizia terzi per eliminare file temporanei, ma esiste una funzionalità nativa di Windows 10 e 11, chiamata CompactOS, che permette di ridurre direttamente l'ingombro dei file binari del sistema operativo tramite compressione.

Cos'è CompactOS?

CompactOS è l'evoluzione del sistema WIMBoot introdotto con Windows 8.1. A differenza della compressione NTFS standard (quella che si attiva dalle proprietà delle cartelle), CompactOS utilizza algoritmi più moderni (come LZX) per comprimere i file eseguibili e le librerie di sistema.

Il vantaggio principale è che il sistema operativo viene eseguito direttamente dai file compressi.

Sebbene questo comporti un minimo overhead sulla CPU per la decompressione "al volo", sui sistemi moderni dotati di SSD la differenza prestazionale è trascurabile, poiché il minor tempo di lettura dei dati dal disco spesso compensa il tempo di calcolo richiesto per la decompressione.

Analisi e attivazione tramite riga di comando

L'operazione si gestisce interamente tramite lo strumento compact.exe. Per procedere, è necessario aprire il prompt dei comandi con privilegi di amministratore.

Verifica dello stato. Per sapere se il sistema è già compresso o se può trarre beneficio dalla funzione, digita:

compact /compactos:query

Il sistema analizzerà lo stato attuale e informerà se la compressione è consigliata o meno.

Attivazione della compressione. Per forzare la compressione dei file di sistema, utilizza il comando:

compact /compactos:always

Il processo può durare dai 5 ai 20 minuti (ed oltre) a seconda delle prestazioni del disco e della CPU. Al termine, Windows riporterà il rapporto di compressione ottenuto (solitamente si risparmiano dai 2 ai 6 GB, ma su installazioni molto corpose il risparmio può essere superiore).

Ripristino (rollback). Qualora si riscontrassero cali di prestazioni su hardware datato, è possibile tornare allo stato originale con:

compact /compactos:never

Considerazioni tecniche

L'uso di CompactOS è particolarmente indicato per:

• dispositivi con unità di archiviazione limitate (eMMC o piccoli SSD da 128/256 GB);
• macchine virtuali dove il risparmio di spazio sul disco host è prioritario.
• sistemi moderni con CPU multi-core, dove la decompressione trasparente non impatta sull'esperienza d'uso quotidiana.

È uno strumento utile per chi desidera un controllo granulare sul sistema operativo senza affidarsi a script di terze parti o ad utility "tuttofare" che spesso agiscono in modo meno trasparente.

File che non si cancella? Come risolvere l'errore "Percorso troppo lungo" su Windows

Ti è mai capitato di provare ad eliminare una cartella od un file e ricevere un errore perché il nome del file o il percorso sono troppo lunghi?

È un problema frustrante che deriva da un vecchio limite di Windows: la maggior parte delle applicazioni (incluso Esplora File) non riesce a gestire percorsi che superano i 260 caratteri.

Perché succede?

Nonostante il filesystem NTFS possa gestire nomi lunghissimi, Windows applica, di default, un limite (MAX_PATH). Nel caso di molte sottocartelle annidate con nomi descrittivi, raggiungerlo è più facile di quanto pensi!

Il "prefisso magico"

Il modo più veloce per forzare l'eliminazione senza installare software esterni è usare il prompt dei comandi (cmd) con un piccolo trucco di sintassi:

• aprire il menu Start e digitare `cmd`;
• scrivere il comando per cancellare (del), ma aggiungendo al percorso il prefisso \\?\

Esempio pratico:

del "\\?\C:\Utenti\Documenti\CartellaInfinitamenteLunga\filechehacomenomelinterocontenutodeldocumento.txt"

Aggiungendo `\\?\` prima del percorso stiamo dicendo a Windows di ignorare le usuali restrizioni e di inviare il comando direttamente al "cuore" del sistema (il kernel NT). In questa modalità, il limite passa da 260 a ben 32.767 caratteri!

Ricetta DEM, dal 31 gennaio autenticazione a due fattori obbligatoria

Il processo di messa in sicurezza della ricetta elettronica compie un passo decisivo. A partire dal 31 gennaio 2026, l'accesso alle funzionalità della ricetta dematerializzata a carico del Servizio Sanitario Nazionale sarà consentito esclusivamente tramite autenticazione a due o più fattori.

La misura, prevista dal Decreto Ministeriale del 27 febbraio 2025, estende alla ricetta "rossa" dematerializzata le medesime procedure di sicurezza già in vigore per la ricetta bianca elettronica, uniformando i protocolli di accesso al Sistema Tessera Sanitaria.

In questo video vengono riassunte le impostazioni da attivare nel gestionale SistemaF per adeguarsi alla nuova modalità operativa.

La truffa WhatsApp "vota la ballerina" - come funziona e cosa fare

Negli ultimi mesi si è diffusa una truffa, su WhatsApp, che ha causato furti di identità digitale a migliaia di utenti. Il messaggio è quasi sempre innocuo e arriva da un contatto conosciuto:

Puoi votare una ballerina / ginnasta / figlia di un'amica in questo concorso?

Dietro a questo invito apparentemente banale si nasconde un meccanismo di furto dell'account WhatsApp basato sull'ingegneria sociale.

 

Come funziona la truffa

• L'utente clicca su un link fraudolento;
• il sito chiede di inserire il numero di telefono;
• i truffatori avviano una vera procedura di accesso a WhatsApp;
• WhatsApp invia un codice OTP ufficiale via SMS;
• l'utente inserisce quel codice nel sito → account rubato.

Non viene installato alcun virus e WhatsApp non viene violato: l'utente viene indotto a consegnare volontariamente il codice di accesso, che equivale alle chiavi dell'account.

Cosa succede dopo il furto

Il legittimo proprietario viene disconnesso ed i truffatori scrivono a tutti i contatti usando la sua identità. In questo modo la truffa si propaga rapidamente.
In alcuni casi vengono richiesti soldi a nome della vittima; per professionisti ed aziende il danno è anche di reputazione.

Se non si interviene, la situazione peggiora rapidamente.

Cosa fare se si cade nell'inganno

Prima di tutto bisogna recuperare l'account reinstallando WhatsApp e richiedendo un nuovo codice (attendere eventuali timeout se l'account è ancora in uso). Quindi bisogna attivare rapidamente la verifica in due passaggi (PIN).

Se il truffatore non ha ancora completato il login, basta l'attivazione del PIN per proteggersi e far fallire l'attacco:

OTP corretto → richiesta PIN → BLOCCO

In ogni caso è opportuno avvisare i propri contatti perché ignorino messaggi fasulli.

Perché la verifica in due passaggi è fondamentale

La truffa funziona solo se la coppia numero di telefono + OTP è sufficiente.

Con la verifica in due passaggi attiva, anche con OTP corretto, la mancanza del PIN determina il blocco dell'accesso.

È la contromisura più efficace contro questo tipo di attacco.

Problemi comuni dopo il ripristino

Dopo il recupero dell'account alcuni utenti notano che:

• i messaggi finiscono nell'Archivio;
• le chat non suonano;
• l'ordine sembra "sballato".

Non è perdita di dati, ma sono impostazioni automatiche da correggere:

• togliere le chat dall'Archivio;
• disattivare "Mantieni chat archiviate";
• ripristinare le notifiche.

Un punto importante sulla sicurezza

Nessuno può "entrare" nel WhatsApp di un’altra persona per sistemarlo: né tecnici, né assistenza, né consulenti. È una tutela di sicurezza, soprattutto dopo una truffa.

Qualche dettaglio in più

  ┌──────────────┐
      Vittima
    (telefono A)
  └──────────────┘
         |
         | ① clic sul link
         ▼
  ┌──────────────────────┐
    Sito finto di voto
    (controllato dai
     truffatori)
  └──────────────────────┘
         |
         | ② inserimento del numero
         |    (+39 xxx xxx xxx)
         ▼
  ┌──────────────────────┐
    Truffatore
    (backend / bot)
  └──────────────────────┘
         |
         | ③ login WhatsApp
         |    con il numero
         ▼
  ┌──────────────────────┐
    WhatsApp
    (server ufficiale)
  └──────────────────────┘
         |
         | ④ invio OTP via SMS
         |    "Il tuo codice è 123-456"
         ▼
  ┌──────────────┐
    Vittima
    (telefono A)
  └──────────────┘
         |
         | ⑤ inserisce OTP
         |    nel sito finto
         ▼
  ┌──────────────────────┐
    Truffatore
    (riceve OTP valido)
  └──────────────────────┘
         |
         | ⑥ completa login
         ▼
  ┌──────────────────────┐
    WhatsApp
    associa account
    al telefono del
    truffatore
  └──────────────────────┘

A questo punto WhatsApp disconnette il telefono della vittima e l'account passa al truffatore.

Circa il punto ④ va notato che il contenuto dell'SMS inviato da WhatsApp, contenente il codice OTP, specifica sempre chiaramente: "non condividere questo codice con nessuno".

Tuttavia, ed è tipico di questo genere di attacco, l'avvertimento sfugge spesso alla vittima, a causa della fretta o della pressione sociale ("vota la figlia della mia amica!").

Verificare ed aggiornare i certificati Secure Boot in Windows

L'avvio protetto (Secure Boot) è una funzionalità UEFI per garantire che il sistema operativo venga avviato solo utilizzando bootloader e componenti firmati / considerati affidabili. Alla base di questo meccanismo c'è un insieme di certificati e chiavi memorizzati nel firmware UEFI e, in parte, gestiti anche da Windows.

In alcune situazioni, ad esempio dopo aggiornamenti di sicurezza critici, cambi di hardware o problemi di compatibilità con driver, può essere utile verificare lo stato dei certificati secure boot e, se necessario, forzarne l'aggiornamento via linea di comando.

 

Attenzione alla scadenza dei certificati Secure Boot

Microsoft ha annunciato che i certificati originali usati per Secure Boot (come quelli del 2011) inizieranno a scadere a partire da giugno 2026. Se un sistema non dispone dei certificati aggiornati, non potrà più ricevere aggiornamenti di sicurezza o fidarsi di firme future. Per questo motivo è importante verificare non solo che l'avvio protetto sia abilitato, ma anche che i certificati correnti siano aggiornati e correttamente installati.

 

Prerequisiti

Prima di procedere, bisogna assicurarsi che:

• il sistema utilizzi UEFI (non BIOS legacy);
• l'avvio protetto sia abilitato nel firmware;
• i comandi vengano eseguiti come Amministratore;
• Windows sia Windows 10 o Windows 11.

in caso contrario... non c'è bisogno di far niente. 

Se invece siamo costretti a lavorare... iniziamo con PowerShell e:

Confirm-SecureBootUEFI

i possibili risultati sono:

• True → l'avvio protetto è attivo;
• False → l'avvio protetto è disattivato;
• Errore → il sistema non usa UEFI (olé).

Questo comando non verifica i certificati in dettaglio, ma è un prerequisito fondamentale.

Uno strumento di sistema che verifica parzialmente lo stato dei database correlati all'avvio protetto è `msinfo32`. Una volta avviato bisogna controllare le voci:

• "Modalità BIOS", deve essere UEFI;
• "Stato avvio protetto", Attivo.

Verificare lo stato dell'aggiornamento dei certificati Microsoft

Microsoft distribuisce aggiornamenti ai database secure boot (in particolare dbx, la lista di revoca) tramite Windows Update. Per verificare se il sistema ha applicato gli aggiornamenti più recenti, possiamo ricorrere a PowerShell:

Get-HotFix | Where-Object {$_.Description -like "*Security*"}

Gli aggiornamenti secure boot più rilevanti (come quelli legati alle vulnerabilità dei bootloader) vengono spesso distribuiti come aggiornamenti di sicurezza cumulativi, quindi non sono sempre immediatamente riconoscibili (!) come riguardanti l'avvia protetto.
Questo significa che non esiste un KB "magico" da cercare. L'aggiornamento dei certificati avviene come parte del normale ciclo di patch di sicurezza di Windows.

Forzare l'aggiornamento dei certificati Secure Boot

Il metodo consigliato e supportato rest Windows Update. È la strada più sicura. Dalla riga di comando:

wuauclt /detectnow
wuauclt /updatenow

Sulle versioni più recenti di Windows, è preferibile:

usoclient StartScan
usoclient StartDownload
usoclient StartInstall

Dopo l'installazione, riavviare il sistema: gli aggiornamenti ai database UEFI vengono applicati solo durante il boot.

Verificare eventuali errori legati a Secure Boot

Se si sospettano problemi con certificati o revoche, si può controllare il registro eventi (eventvwr.msc) in particolare visualizzando:

Registri applicazioni e servizi
└── Microsoft
    └── Windows
        └── Secure-Boot

Errori o avvisi in questa sezione possono indicare bootloader bloccati, firme non valide o conferme dell'avvenuto aggiornamento del database `dbx`.

La scadenza dei certificati, cosa controllare davvero

Windows non fornisce un comando diretto per elencare i certificati UEFI con data di scadenza, perché questi risiedono nel firmware. Tuttavia è possibile verificare se il sistema è già pronto per i nuovi certificati tramite controlli indiretti.

Un primo indizio utile è la versione del boot manager (`bootmgfw.efi`), che viene aggiornata solo se il sistema è pronto ad usare i nuovi certificati:

Get-Item "C:\Windows\Boot\EFI\bootmgfw.efi" | Select-Object VersionInfo

Bisogna osservare `ProductVersion`, `FileVersion` e `Data di compilazione`.

Versioni aggiornate tramite patch di sicurezza dal 2023 in poi indicano che il sistema è compatibile con i certificati più recenti.

Microsoft sta distribuendo gli aggiornamenti in più fasi, proprio per evitare sistemi non avviabili. Un sistema che non riceve più aggiornamenti o è fermo a build molto vecchie rappresenta un segnale critico.

Un ultimo dettaglio pratico: gli aggiornamenti al secure boot possono richiedere la chiave BitLocker al riavvio. È normale e previsto (cambia la "catena di fiducia" del boot). Prima di procedere assicurarsi sempre di avere la chiave di ripristino BitLocker disponibile.

La mia 'value proposition' oggi? Sincerità brutale contro il maglione a collo alto

Sono indeciso su come cominciare... ho appena finito di sorbirmi un affermato consulente che, dopo aver scritto (scritto?) un'email con ChatGPT, senza trovare neanche quel briciolo di dignità per cambiare una riga di testo con un contenuto proprio, ha liquidato la mia successiva telefonata con un "mi lasci parlare, non ho tempo da perdere!".

Il punto di partenza di questa meravigliosa esperienza è la value proposition, termine simbolo dell'odierno "corporate-ese".

Per i fortunati che ancora non si sono imbattuti in queste due parole, dirò che, letteralmente, è traducibile con "proposta di valore".

Si tratta di qualcosa che il compianto conte Lello Mascetti definirebbe "supercazzola" (prematurata): il lecito quesito "Perché mai qualcuno dovrebbe darmi dei soldi?" viene riassunto ed ingentilito in value proposition.

Certo, nell'analizzare l'operato della propria azienda, domande come "Cosa faccio?", "A chi si rivolge la mia offerta?", "Perché preferirla a quella di un concorrente?" sono fondamentali.

Tuttavia queste paiono proprio non far pendant con il maglione a collo alto, gli occhiali alla moda e la giacchetta ultimo grido dell'arrembante consulente.

Pare indispensabile accompagnarle con un tono epico, condirle con quel briciolo di gergo tecnologico ed imbastirle al punto giusto (i maligni direbbero al fine di complicarle e permettere risposte vaghe).

Pascal chiedeva scusa per aver reso "questa lettera più lunga del solito perché non ho avuto il tempo di renderla più breve"; Feymann sosteneva che "Se non riesci a spiegarlo in modo semplice, non lo capisci abbastanza bene"... come siamo caduti in basso!

Per farla breve, mi ritrovo a leggere il documento:

---

PINCOPALLA SRL - Value Proposition Strategica per Settore

1. Difesa, Aerospazio e Settore Militare

Positioning: Fornitore...

Value Proposition: – Riservatezza e sicurezza documentale. –...

---

(da osservare l'uso delle maiuscole, del carattere '–' al posto di '-' e della punteggiatura... onde trarne le debite conclusioni)

La domanda (retorica) che mi viene posta è cosa ne penso. Come minimo penso che sia mancanza di rispetto verso l'interlocutore.

Come ogni buon operativo, ho l'errata inclinazione a disdegnare in toto commerciali e consulenti strategici / finanziari / per il controllo di gestione... Lo so sbaglio a generalizzare e, per fortuna, ogni tanto, incontro persone che col loro lavoro mi dimostrano che sono in errore.

Purtroppo l'avvento dei modelli linguistici di grandi dimensioni sta rendendo gli incontri piacevoli sempre meno frequenti.

L'insegnamento che ne traggo è che bisogna usare gli strumenti nel modo giusto; il rischio, per tutti, è di lasciarsi andare all'ignavia e svilire il proprio lavoro sostituendolo con una meccanica "interpolazione acritica di informazioni rubate al prossimo".

Forse per un po' funzionerà. Confido però che la classica conclusione "Non ho capito cosa vendi ma scommetto che costa caro" possa spazzar via molta immondizia.

Gestire la cache dei pacchetti su Slackware

Chi usa Slackware lo sa, mantenere DELALL=off in slackpkg.conf è fondamentale per avere sempre un paracadute e poter effettuare un rollback in caso di necessità. Tuttavia, col tempo, l'archivio locale dei pacchetti può diventare enorme.

Pubblichiamo uno script che risolve proprio questo problema, inserendosi perfettamente nel workflow di aggiornamento standard:

1. slackpkg update
2. slackpkg upgrade-all
3. manage_updates

Cosa fa lo script? Agisce come un garbage collector intelligente per l'archivio locale. Invece di accumulare versioni obsolete all'infinito, lo script applica una policy di conservazione: mantiene solo le due versioni più recenti di ogni pacchetto.

✅ Sicurezza. Hai sempre a disposizione l'ultima versione stabile e quella precedente per un rollback immediato.

✅ Efficienza. Mantieni il controllo dello spazio su disco in modo automatico.

✅ Pulizia. Eviti la rimozione manuale dei vecchi pacchetti `.txz`.

Trovi la documentazione e lo script qui: https://github.com/morinim/documents/tree/master/sysadmin/slackware

Come dar l'impressione di non sbagliare mai i comandi in Bash! O:‑)

Sei seduto al terminale ed hai appena digitato un lungo e complesso comando. Premi Invio.

ERRORE.

La rabbia ti assale.

Situazione familiare? Bene, la vera arte dello smanettone non è digitare correttamente al primo colpo, bensì far sembrare di riuscirci, sfruttando la cronologia di Bash e confondendo, quando opportuno, eventuali spettatori.

Senza pretendere di scrivere una guida definitiva ed implorando il perdono dei veri maghi della tastiera, ecco qualche suggerimento ricavato da (ahimè) qualche anno di esperienza.

Livello base: le freccette

Quanto segue è per i principianti che hanno ancora la dignità di usare una tastiera fisica.

• il richiamo (↑): hai appena digitato cd /usr/bin/pippo/pluto ed hai dimenticato /local/ nel mezzo. Non ridigitarlo! Premi 'freccia su'. Il comando riappare (!). Premi ancora per riesumare ulteriori errori imbarazzanti;
• il richiamo eccessivo (↓): sei andato troppo indietro ed hai trovato un comando del 1973. Premi 'freccia giù' per tornare alla realtà e non affrontare il tuo passato.

(si, lo so, tutto questo è imbarazzante... ma si deve pur cominciare) 

Livello intermedio: l'investigatore di basso rango (Ctrl+R)

Ti ricordi solo una vaga parola chiave del tuo comando.

Premi Ctrl R. Compare un enigmatico (reverse-i-search). Inizia a digitare, diciamo che vuoi trovare un vecchio comando git. Digiti "gi" e Bash ti mostra la corrispondenza più recente. Non è quella giusta? Continua a premere Ctrl R.

È come cambiare senza posa il canale TV: scorri velocemente tra la programmazione della tua cronologia finché non trovi il tuo vecchio film preferito. In realtà trovi solo git push --force che non avresti mai dovuto usare.

Individuato quanto cercavi, premi Invio per eseguirlo di nuovo (possibilmente, prima, correggendolo).

Livello pro: sapersi affermare (!)

Se vuoi dimostrare di essere un vero hacker della shell, devi padroneggiare il carattere più prepotente di tutti: il pungolo esclamativo ! (no, questa volta nessun rimando a Wikipedia :-).

Sequenza	Obiettivo
!!	Ripete l'ultimo, comando. Perfetto per una situazione tipo sudo !! quando avevi scordato di non poter far qualcosa senza il permesso.
!n	Richiama il comando numero n nella cronologia (server un history preliminare perché nessun essere umano normale ricorda questi numeri).
!git	Rifai l'ultima cosa che ho fatto con git (utile per "incasinare" un repository già sull'orlo del collasso).
!$	Dammi solo l'ultimo ARGOMENTO usato (scorciatoia: ESC + .). Perfetto se hai appena copiato un file su /usr/local/bin/il-file-con-il-nome-impossibile ed ora vuoi semplicemente farci un ls.

Livello finale: analisi post mortem

fc (fix command) apre l'ultimo comando (od uno specifico) nel tuo editor di testo predefinito (speriamo non sia vi/vim, altrimenti rischi di rimanerci intrappolato per l'eternità senza ricordare l'arcana sequenza per uscire).

A questo punto puoi modificarlo in modo esteso prima di eseguirlo.

Una importante nota a margine: se hai aperto il comando nell'editor e ti rendi conto che la sua eventuale esecuzione scatenerà l'Apocalisse, NON uscire come se nulla fosse!

Vai all'inizio della riga ed aggiungi il sacro sigillo del non-comando (`#`). Ora (stai sereno) puoi salvare ed uscire senza... evocare i Cavalieri.