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.