Ho affidato il mio nuovo PC a un agente AI

Nel post precedente ho scritto che gli agenti vivono a proprio agio in un ecosistema fatto di shell, comandi testuali, file di testo, ssh, ecc. Un ecosistema che sui sistemi operativi Unix-like esiste da sempre.

Ieri ho deciso di sfruttare questa capacità per far installare Linux sul nuovo portatile, da zero, direttamente a OpenCode e GPT-5.5. Un po’ come esperimento, un po’ perché sono più che mai sommerso dal lavoro in quanto “l’AI ci farà lavorare meno” è una promessa che in termini assoluti ancora non è stata mantenuta.

Normalmente quando installo i sistemi tengo traccia, in un diario testuale che potrebbe tornarmi utile in futuro, di cosa ho fatto di diverso rispetto alla configurazione di default. Ma questo, se ci pensate è proprio il compito perfetto per un agente.

Da diversi anni uso Ubuntu Desktop LTS sul mio portatile. Distro comoda, stabile, ma essendo una long-term-support non ha le ultime novità che invece potrebbero servire su questa nuova macchina (Ryzen AI MAX+), inoltre la procedura di installazione standard è grafica e interattiva e gli agenti AI odiano il mouse e le interfacce colorate!

Spazio ad Arch Linux quindi, che è una distribuzione molto più da smanettoni, che si costruisce a piccoli pezzettini e configurazioni personalizzate tutta da terminale. Un paradigma che avrei amato in gioventù, infatti usavo Gentoo, ma che ora sarebbe incompatibile con il mio tempo libero… se non ci fossero gli agenti!

Ho deciso di non toccare praticamente nulla se non avviare la live e dare accesso all’agente, poi ho lasciato fare a GPT-5.5.

Un sysadmin alieno

Ho avviato il portatile dalla live image di Arch, quindi, impostato una password temporanea e avviato ssh per poter far connettere l’agente (OpenCode) che attendeva sul mio pc. Poiché ero curioso di vedere realtime cosa combinasse, ho avviato una sessione tmux condivisa e gli ho detto di usarla. In questo modo potevo osservare il portatile fare cose senza che nessuno lo toccasse, ed è stato bellissimo.

L’accordo era semplice: lui lavora, io guardo. Un po’ come affiancare una risorsa junior durante il suo primo deployment in produzione. Solo che lo junior non era umano e, soprattutto, non era per niente junior!

Gli ho solo comunicato il mio desiderata: voglio il disco cifrato, voglio la sospensione, ecc. Niente tutorial step by step, niente lista di comandi, niente “esegui questo”.

La parte interessante non è che sia riuscito a installare Arch Linux, era abbastanza scontato, ma è stato interessante guardarlo a lavoro, guardarlo fallire, controllare la documentazione, l’output dei comandi, correggersi da solo, ecc.

Esattamente come farebbe un amministratore di sistema che si trova davanti a un sistema che non ha mai visto prima, con la differenza che l’agente esegue questo processo con una pazienza e una dedizione che nessun essere umano possiede.

Non è la prima volta che uso gli agenti per fare cose sui sistemi, anzi, ma è la prima volta che li faccio lavorare su un computer vergine. Inoltre, è la prima volta in cui ho sperimentato la sessione condivisa con tmux e devo dire che è molto comoda.

La documentazione che nessuno scrive

Una volta completata l’installazione gli ho chiesto un’ultima cosa. Generare un file REPORT.md che spiegasse cosa era stato fatto, perché e come ripetere il processo da zero.

Gli agenti non sono utili solo perché fanno il lavoro. Sono utili perché possono documentarlo mentre lo fanno.

Se siete curiosi il report che alla fine ha prodotto è sul wiki di LILIS, Laboratorio per l’informatica libera sannita.

Disclaimer

Questa è una cosa pericolosa. Oltre all’indeterminismo del risultato, in caso di Prompt Injection in qualche ricerca web, l’agente potrebbe installarti un malware. Niente paranoie, ma sii consapevole.

Il prompt utilizzato

# Installazione Arch Linux su un ASUS ProArt PX13 

## GOAL

Devi installare Arch Linux su un ASUS ProArt PX13 HN7306EAC-LX084W (variante HN7306EA), con:
- CPU: AMD Ryzen AI MAX+ 395
- GPU: AMD Strix Halo Radeon 8060S
- RAM: 128 GB LPDDR5X condivisa
- Disco: circa 1.8 TiB NVMe
- Display: 13.3" 3K OLED touch
- Wi-Fi: Wi-Fi 7
- Uso previsto: workstation quotidiana + IA locale con modelli LLM grandi
- Requisito importante: ibernazione supportata e full disk encryption
- Ho disattivato Secure Boot e Fast Boot nel bios

Il portatile è avviato con la ISO Arch con kernel 7.0.10-arch1. Si bloccava al boot, ma aggiungendo `nomodeset` alla riga kernel della ISO sono arrivato al login/root shell.

Il disco è /dev/nvme0n1
- Prevedi una partizione EFI da 1 GiB per /boot
- Poi LUKS sul resto del disco per il full disk encryption
- Dentro luks aggiungi lvm con 2 logical volumes: swap (da 160 GiB per supportare ibernazione) e root per brtfs
- Dentro brtfs pensavo ai seguenti subvolumi:
@          /
@home      /home
@snapshots /.snapshots
@models    /srv/models (dove scaricherò i modelli llm, file di grandi dimensioni)
@pkg       /var/cache/pacman/pkg
@varlog    /var/log

Motivazione:
- Voglio LUKS per cifrare l'intero sistema e swap.
- LVM dentro LUKS per avere swap cifrata dedicata e semplice da usare con ibernazione.
- Btrfs per root e dati, perché voglio snapshot, rollback e subvolumi senza partizioni rigide.

Per brtfs che opzioni consiglieresti?

Kernel da installare:
linux-lts
linux-lts-headers
linux
linux-headers
linux-firmware
amd-ucode

Idea di boot:
- linux-lts installato come kernel secondario di emergenza
- linux come default iniziale
- il bootloader deve supportare il layout scelto (luks + lvm + resume da swap)


## IMPORTANTE

- Devi installare il sistema operativo collegandoti in SSH al portatile con `ssh [email protected]` e usare la password `install`.
- Prima di dare ogni comando devi utilizzare una sessione tmux già esistente, puoi agganciarti con `tmux attach -t install`
- NON devi inviare comandi se prima non sei dentro la sessione tmux.
- NON distruggere mai la sessione tmux

## TRACCIAMENTO ATTIVITÀ

Inizializza AGENTS.md con le istruzioni che possono servirti in caso di nuova sessione. Traccia, inoltre, nello stesso file qualsiasi cosa ti sia utile o risultato di una decisione.

Gli agenti AI e il vantaggio di Linux

Questo è l’anno di Linux su desktop” è uno dei più vecchi, famosi e iconici meme dell’intera cultura informatica su internet.

Un tormentone satirico che ironizza sull’ottimismo eterno della comunità di utenti Linux, la quale dichiara regolarmente, da oltre vent’anni, che l’anno corrente sarà quello in cui il sistema operativo open source supererà Windows e macOS, conquistando la massa dei personal computer.

Sì, perché nonostante Linux sia quasi ovunque, dai server che permettono a internet di esistere fino alla tua lavatrice, la penetrazione sul mercato dei computer desktop è bassissima.
Qualcosa per nerd insomma, infatti il meme nasce dal fatto che, spesso e volentieri, l’utente Linux deve sporcarsi le mani con il terminale e passare dalla grafica a finestre punta e clicca a un’interfaccia a caratteri che ricorda gli anni ’70. Per l’utente comune e per l’ufficio medio, il terminale non è mai stato percepito come potenza, ma come attrito.

Se nel primo decennio degli anni 2000 l’utente Linux apriva il terminale soprattutto per risolvere problemi causati dalla scarsa compatibilità hardware, oggi, che funziona quasi sempre tutto dal primo avvio dopo l’installazione, lo usa esclusivamente per essere più efficiente.

Nonostante Windows, a confronto, sembri sempre più il sistema operativo Clementoni, il lock-in tecnologico, la pigrizia e la paura del diverso hanno fatto preferire una (finta) ergonomia colorata a sistemi operativi più seri che fanno tutto ciò che l’utente vuole, senza troppi fronzoli luccicosi e senza alcun limite.
Un compromesso l’ha creato Apple, che con macOS ha sfruttato l’imbarazzante inadeguatezza di Windows e l’ancora acerba esperienza ergonomica delle distribuzioni Linux dei primi anni 2000 per penetrare prepotentemente sul mercato con un OS che funziona (facile quando gira solo su computer costruiti ad hoc) e che allo stesso tempo mette a disposizione dell’utente la potenza di un sistema unix-like.
Microsoft per un po’ è rimasta a guardare, poi sotto la guida di Satya Nadella ha corretto il tiro mettendo a disposizione degli utenti Windows un sotto-sistema Linux (WSL) cercando di recuperare il gap tecnologico accumulato negli anni. È l’era del “Microsoft loves Linux”.

Oggi però sono arrivati gli LLM e, soprattutto, gli agenti: tu descrivi l’obiettivo in linguaggio naturale, loro eseguono le operazioni necessarie sul computer. Una svolta epocale, di fatto, per molti, la nuova rivoluzione industriale. Ed è qui che la storia si ribalta: almeno al momento, gli agenti sono molto più bravi ed efficienti con le interfacce a caratteri, quindi con il terminale, che con le GUI punta e clicca.

Questo significa che l’OS più diffuso nel mondo del desktop “produttivo”, Windows appunto, tutto d’un tratto si ritrova a essere l’ambiente meno preferito dagli agenti AI.

Anche Windows, oltre al WSL citato prima, ha una sua interfaccia a caratteri, anzi due: l’ormai obsoleto Prompt Dei Comandi (cmd.exe) e il più recente PowerShell.

PowerShell è figlio dell’era moderna, è un linguaggio di scripting complesso che tratta i dati come oggetti .NET. Potente ma pesante e soprattutto costoso per gli LLM.
Gli interpreti e i comandi disponibili nel terminale Linux (e *nix in generale) sono figli della filosofia KISS degli anni ’70: Keep It Simple Stupid, piccoli programmi che fanno una sola cosa e la fanno bene.
Inoltre, come accennavo prima, la sintassi PowerShell è verbosa e quindi in termini di token (le “parole” che l’AI deve gestire, perdonate la semplificazione) è meno efficiente.

Estrarre i nomi che iniziano per la lettera “A” e ordinarli in ordine alfabeto si traduce con:

Linux:
grep "^A" nomi.txt | sort

Windows:
Get-Content nomi.txt | Where-Object { $_ -like 'A*' } | Sort-Object

Trova i processi che occupano più di 100MB di RAM:

Linux:
ps aux | awk '$6 > 102400' | sort -rnk6

Windows:
Get-Process | Where-Object { $_.WorkingSet -gt 100MB } | Sort-Object -Property WorkingSet -Descending

Sono solo alcuni semplici esempi, ma in un task reale gli agenti ne fanno centinaia di queste operazioni.

A precindere dall’efficienza dei token, ci sono anche altri motivi per cui gli agenti AI preferiscono Linux:

  • Abbondanza e qualità dei dati di addestramento: i modelli linguistici sono addestrati su enormi repository di codice e forum tecnici.
    La stragrande maggioranza del software open source, dei server web e delle pipeline di programmazione è documentata e utilizzata tramite Bash.
  • Meno ambiguità: poiché Bash esiste da decenni con una sintassi universale, l’LLM ha una comprensione statistica dei comandi immensamente più solida e accurata rispetto a PowerShell, che ha subito grandi cambiamenti nel passaggio dalla versione Windows-only a quella open-source (Core).
  • Integrazione con altri ecosistemi e linguaggi: Python, Go, Ruby, PHP, Perl, Node, ecc, sono tutti linguaggi comuni su Linux, se mancano basta installarli con un comando breve, di 2 sole parole. L’agente lo sa, e li usa quando servono.
    Windows ha recuperato molto negli ultimi anni, ma è ancora lontano dal mondo dello sviluppo che non sia .NET. Gli interpreti dei linguaggi sono tutti installabili, ma con più fatica in quanto non reperibili da un’unica fonte, spesso attraverso layer aggiuntivi e configurazioni meno uniformi.
  • Tooling: oltre ai linguaggi, l’agente sa usare molto bene le GNU Core Utilities come cat, grep, sort, cut, head, tail, ecc. Il loro vantaggio principale è che sono stream-oriented e permettono di operare anche su file enormi senza caricarli interamente in memoria. Inoltre sono strumenti componibili, leggono input, producono output testuale e si collegano naturalmente tramite pipe. Per un agente AI questo significa poter costruire procedure robuste con pochi comandi semplici.
  • Container e sandboxing: Linux supporta in maniera nativa i container, utilissimi all’agente per eseguire codice e programmi in ambienti controllati; Windows è costretto a farlo in una macchina virtuale con un overhead prestazionale enorme. Anche gli strumenti di isolamento (sandboxing) sono nativi e più avanzati in ambiente Linux.

Tutto ciò non implica che gli agenti non possano essere utilizzati su Windows, anzi, più o meno tutti (OpenCode, Codex, Claude Code, Claude Cowork, Antigravity, ecc), hanno una versione per Windows, ma inevitabilmente risultano meno performanti e più costosi in termini di token e quindi anche in termini economici.
Questo si traduce nel fatto che su Windows se usi l’agente in modalità API spenderai più soldi, in modalità subscription raggiungerai i limiti giornalieri, settimanali, ecc più in fretta.
Infine, in conseguenza delle dinamiche collaterali a quanto finora esposto, anche la qualità del lavoro dell’agente ne risente perché le finestre di contesto si allungano e quindi è costretto a riassumerle perdendo dettagli.

Se su Windows è però installato WSL (il sotto-sistema Linux), l’agente ha la capacità di usarlo recuperando in questo modo un po’ di gap tecnologico – ringraziate Satya Nadella per questo bel regalo!

Se tale gap è recuperabile dall’agente, non lo è però, o almeno non alla stessa velocità, dall’utente che potrebbe non avere la capacità di accorgersi che l’agente ha preso una strada poco conveniente o potrebbe non riuscire a intervenire tempestivamente in caso di errore o, ancora, potrebbe approvare ciecamente comandi proposti non comprendendoli.

In sostanza, si crea un pericoloso gap cognitivo tra l’utente Windows e l’agente che usa WSL. Sono convinto che il vero limite, su Windows, non sia solo tecnico ma culturale: per pilotare al meglio un agente AI moderno serve comunque una certa familiarità con il mondo Linux.

Chi invece Linux l’ha sempre utilizzato e si trova a proprio agio sui sistemi *NIX ha ora un enorme vantaggio competitivo: conosce l’ecosistema in cui l’agente si muove meglio e può fare steering, prompt dopo prompt, guidandone le scelte e modellandone finemente il comportamento, invece di limitarsi a fidarsi dell’AI.

Forse l’anno di Linux sul desktop è arrivato davvero, ma non nel modo in cui lo avevamo immaginato.

Bit4id – Autenticazione CNS e Firma Digitale su Linux Debian/Ubuntu

Anche se “l’anno di Linux sul desktop sarà l’anno prossimo” (cit.), ormai le distro moderne funzionano senza troppi problemi anche per gli utenti meno tecnici.
A complicare le cose, spesso, ci si mettono gli altri. Nello specifico la TS-CNS italiana (Tessera Sanitaria/Carta Nazionale dei Servizi) e il middleware sviluppato da Bit4id.

Normalmente ci sarebbe OpenSC per interagire con i certificati presenti all’interno della Smart Card, tramite le API PKCS#11 fornite dalla libreria opensc-pkcs11.so.
Ma la CNS italiana è “speciale” e quindi ha bisogno di un middleware proprietario. Ci pensa Bit4id ed è scaricabile da qui oppure da qui come riportato anche nel Wiki di Ubuntu, ma voi non fatelo!.

Fantastico che ci sia la versione per Linux, ma il pacchetto .deb per le distro Debian/Ubuntu utilizza un PATH non standard e installa all’interno delle directory di sistema destinate alle librerie alcuni file (con estensioni .rc e .conf) non conformi agli standard, dove normalmente dovrebbero essere presenti esclusivamente file con estensione .so (ELF shared object). La libreria bit4id richiede che i file .conf siano nella stessa directory 🙁

A seguito dell’installazione, il sistema genera dei warning ogni qual volta venga eseguito ldconfig.

Warning all’esecuzione di ldconfig

Ho segnalato la questione a Bit4id. Nel frattempo possiamo sfruttare InfoCert GoSign che si porta dietro la stessa libreria middleware (libbit4xpki.so) evitando così di installare il pacchetto buggato.

GoSign è un software per la firma digitale e, visto che supporta la TS-CNS, ha bisogno di quel middleware. InfoCert l’ha inclusa nel suo pacchetto di installazione di GoSign per Debian/Ubuntu.

Autenticazione CNS e Firma Digitale con TS-CNS su Linux Debian/Ubuntu, un’installazione pulita senza warning

Firma Digitale

Autenticazione CNS con Firefox

  • Scaricare e installare InfoCert GoSign se non l’avete già fatto
  • Aprire Firefox, andare su impostazioni, Privacy & Sicurezza, scorrere fino alla sezione Certificati e cliccare “Dispositivi di Sicurezza
  • Cliccare su Carica
  • Inserire come Nome Modulo quello che volete, ad esempio Bit4id e come file /usr/lib/gosigndesktop/resources/app/node_modules/@ice/dike-core-js/node_modules/@ice/dike-core-linux/native/lib/libbit4xpki.so e date OK a tutto
  • Fine

Autenticazione CNS con Chrome o Chromium

sudo apt install libnss3-tools opensc-pkcs11
  • Aggiungere il middleware al DB tramite il comando
modutil -force -dbdir sql:$HOME/.pki/nssdb -add Bit4id -libfile /usr/lib/gosigndesktop/resources/app/node_modules/@ice/dike-core-js/node_modules/@ice/dike-core-linux/native/lib/libbit4xpki.so
  • Fine

Dev & Hacking

Tool non necessari al funzionamento di cui sopra, ma utili per interagire con la Smart Card

pcscd libpcsclite1 pcsc-tools libccid libnss3-tools opensc-pkcs11

Decoding Oregon Scientific RTGN129 with RTL-SDR [PART 1]

Oregon Scientific RTGN129 is a remote temperature and humidity sensor designed to be used with Oregon’s PRYSMA series stations.
It uses the standard 433MHz band so we can tune our RTL-SDR USB dongle to receive their signal. But how to decode it?

There are plenty of documentation about decoding Oregon’s devices, and Benjamin Larsson’s rtl_433 tool may decode many of 433.92MHz devices but, unfortunately, it didn’t support the RTGN129.

This is the great opportunity to skill myself in reverse-engineering of an “unknown” signal, so I decided to implement it into rtl_433 (Merged pull request: https://github.com/merbanan/rtl_433/pull/634).

From RTGN129 datasheet we have the confirmation that this device transmits at 433MHz.

Oregon uses several protocol versions (v1.0, v2.1, v3.0) so, first of all, we need to discover if our RTGN129 uses one of these. Protocol documentation are here and here.

Instead of using directly rtl_433 in analyze mode (-a flag), we’ll pretend it does not exist and we’ll go down to low level just for fun. A sort of simulated black-box approach.

There are several tools in the wild to analyze the radio signal from an RTL dongle, but one of the best, IMHO, is baudline.

You can use it in the “hacker’s way”, for example:

FR="433.944e6"; SR="2.5e6"; \
rtl_fm -f $FR -s $SR -g 30 -M am | \
baudline -reset -flipcomplex -samplerate $SR \
-basefrequency $FR -channels 2 -quadrature \
-format u8 -fftsize 2048 -stdin

First of all, we need to find the right PPM value to use in the next commands to calibrate our dongle.

rtl_test -p

So we can find the exact frequency of RTGN129 starting from the 433.92MHz:

FR="433.92e6"; SR="2.5e6"; \
rtl_sdr -p 130 -f $FR -s $SR -g 30 - | \
baudline -reset -flipcomplex -samplerate $SR \
-basefrequency $FR -channels 2 -quadrature \
-format u8 -fftsize 2048 -stdin

Where -p is our PPM, -f is the tuned frequency, -s is the sample rate, and -g is the gain (0 for auto). The last “-” before the pipe stands for “stdout”.
433.92e6 stands for 433.92 * 10^6 so 433.92MHz that is more readable than 433920000.

The above command shows you the baudline window. When you see the burst passing in the spectrogram press “pause” on your keyboard, center the signal in the spectrogram area (green background) with the mouse, than center it in the spectrum analyzer (black background) and read the exact frequency on the bottom-right area: 433.95Mhz

Right click on the spectrogram area, then select display, then click wafeform. Now we can see the waveform of the signal in the time domain. To zoom in/out you may use ALT + right and left arrows.

Navigating the waveform we notice that, when the signal is present, the frequency and the amplitude stills the same, and there are silence between two signal, just like in the On-Off Keying!

Basic digital modulation formats:

Now we use “rtl_fm” instead of “rtl_sdr” to demodulate the signal using AM demodulator:

FR="433.95e6"; SR="2.5e6"; \
rtl_fm -f $FR -s $SR -g 30 -M am | \
baudline -reset -flipcomplex -samplerate $SR \
-basefrequency $FR -channels 2 -quadrature \
-format u8 -fftsize 2048 -stdin

and finally visualize the demodulated bits!

If we decode it as “Manchester code” we read:

Instead of frustrating us overlaying red lines in gimp, as I did with the above image, we can use Universal Radio Hacker to decode the stream!

(to be continued …)