Why I Stopped Guessing at Linux Distros and Started Asking AI to Reason Through It

Prompt Your Way to Linux: Una serie in 4 parti

Parte 1: Scegliere la distro → Parte 2: Storage e cifratura → Parte 3: Installazione manuale → Parte 4: Servizi e GPU

Ho installato Linux più volte di quante riesca a contare. Ogni singola volta, la scelta della distro si è ridotta a un'impressione viscerale o a quello che avevo usato l'ultima volta. Il problema è questo: se stai costruendo qualcosa di specifico, l'istinto non basta. Un nodo di sicurezza che ha bisogno di Docker, PostgreSQL, modelli AI locali e cattura di pacchetti su tre dischi cifrati? È un problema di architettura, non di sensazioni.

Questo capitolo ti mostra come impostare la conversazione in modo che l'AI ti fornisca un'architettura reale, non un riassunto da Wikipedia. Fornirai il tuo carico di lavoro effettivo, riceverai un ragionamento strutturato, mapperai il tuo hardware su un piano di storage e individuerai i problemi firmware prima che ti costino ore di lavoro. Alla fine, avrai un metodo ripetibile che funziona per qualsiasi build, qualsiasi hardware, qualsiasi distro.

Il Primo Prompt è il Più Importante

Ecco cosa scrivono la maggior parte delle persone su ChatGPT quando pensano a Linux:

"Quale distro Linux dovrei installare?"

E ricevono esattamente quello che ci si aspetta: una lista della spesa di distribuzioni con descrizioni superficiali. Ubuntu è adatto ai principianti. Fedora ha pacchetti più recenti. Arch è per chi ama soffrire. Grazie, incredibilmente inutile.

Il problema non è l'AI. È il prompt. Stai facendo una domanda generica e ottieni una risposta generica. Nel momento in cui passi da "cosa dovrei installare" a "ecco cosa deve fare questa macchina", la conversazione cambia completamente.

Ecco il pattern di prompt che funziona davvero:

1I'm setting up a Linux machine for [specific role].
2My requirements are: [list workloads].
3The machine needs to support: [list services].
4What distribution should I consider and why?

Struttura semplice. Differenza enorme nella qualità dell'output. Stai dando all'AI abbastanza contesto per ragionare, non solo per recitare.

Di Cosa Ha Davvero Bisogno la Tua Build

Prima di lanciare quel prompt, sii specifico sul ruolo. Non dire "un server Linux." Di' cosa fa. Per un nodo di sicurezza (la build che questa serie illustra), la lista dei carichi di lavoro è questa:

• Container Docker che eseguono più strumenti e servizi di sicurezza
• PostgreSQL e Redis per dati strutturati e caching
• Ollama per eseguire modelli AI locali (senza dipendenza dal cloud)
• Futuro passthrough GPU NVIDIA per inferenza accelerata
• Storage di artefatti di attacco con separazione appropriata della catena di custodia
• Storage multi-disco cifrato su NVMe, SSD e HDD
• Stabilità a lungo termine senza rotture continue da aggiornamenti bleeding-edge

Non è più una domanda su "quale distro". È una domanda di architettura. E quando la inquadri in questo modo, l'AI inizia a ragionare su ecosistemi di pacchetti, tempistiche di supporto del kernel, disponibilità dei driver e strumenti della community. Il tuo compito è fornire i vincoli. Il compito dell'AI è ragionarci sopra.

Come Si Articola il Ragionamento

Fornisci all'AI una lista di carichi di lavoro come quella e non otterrai solo una risposta. Otterrai il ragionamento dietro ogni opzione. Ecco cosa aspettarsi:

Kali Linux ottiene la raccomandazione più forte. È basato su Debian, il che significa una gestione dei pacchetti solida e un'ampia compatibilità. Gli strumenti di sicurezza vengono preinstallati o sono a un apt install di distanza. Le release rolling mantengono gli strumenti aggiornati senza l'instabilità di qualcosa come Arch. E la community è specificamente focalizzata sul tipo di lavoro che questa macchina svolge.

Ubuntu Server si piazza come secondo. Eccellente supporto Docker, community enorme, release LTS. Ma per una build orientata alla sicurezza, passeresti i primi due giorni a installare strumenti che Kali include di default. È una base generica quando hai bisogno di una base specializzata.

Debian Stable è troppo conservativo. Le versioni dei pacchetti sono in ritardo rispetto a ciò di cui Ollama e i driver NVIDIA più recenti hanno bisogno. Saresti costantemente a combattere con i backport.

Arch Linux ha i pacchetti più freschi, ma l'instabilità delle release rolling su una macchina che esegue database in produzione e servizi Docker è cercare guai. Un pacman -Syu andato male e la tua istanza PostgreSQL è offline.

Fedora Server è interessante ma introduce strumenti basati su RPM che non si allineano con il più ampio ecosistema Kali/Debian a cui si rivolgono la maggior parte degli strumenti di sicurezza.

Per questa build, la scelta è Kali. Non perché sia di tendenza o perché qualche video su YouTube lo abbia detto, ma perché il profilo del carico di lavoro si mappa direttamente su ciò per cui Kali è progettato, e la base Debian fornisce la stabilità che Docker e PostgreSQL richiedono. La tua build potrebbe indicare una direzione diversa. Questo è il punto centrale del lasciare che l'AI ragioni invece di indovinare.

La Conversazione di Scoperta dell'Hardware

Con la distribuzione decisa, non raggiungere ancora l'ISO. Prima, scopri esattamente con quale hardware stai lavorando. È qui che la conversazione con l'AI diventa davvero potente.

Prova questo prompt:

1You are a security expert and are setting up a clean Kali Linux
2install. I'm sitting in front of the terminal. What commands do
3you want me to run to get you all the specs and hard drives
4available to plan this?

Rileggilo. Non stai chiedendo "come controllo la mia CPU." Stai dicendo all'AI di progettare l'intera sequenza di scoperta in base a ciò che deve sapere per la pianificazione. È un'interazione fondamentalmente diversa. Stai mettendo l'AI al posto di guida per l'indagine mentre tu esegui i comandi e riferisci i risultati.

Cosa Chiede l'AI (e Perché Ogni Categoria è Importante)

Riceverai una lista strutturata di comandi, raggruppati per categoria. Non comandi casuali. Un protocollo di scoperta deliberato. Ecco cosa aspettarsi:

Modalità firmware (ls /sys/firmware/efi o controllo delle impostazioni BIOS): Questo determina l'intera strategia di avvio. UEFI significa tabelle di partizione GPT e partizioni ESP. Legacy BIOS significa MBR e configurazioni del bootloader diverse. Sbagliare questo e dovrai reinstallare.

CPU e RAM (lscpu, free -h): Il numero di core e la dimensione della memoria determinano quanti container Docker puoi eseguire simultaneamente, se i modelli AI locali entreranno in memoria e quanto aggressiva può essere la configurazione di PostgreSQL.

Inventario dei dischi (lsblk -o NAME,SIZE,TYPE,ROTA,TRAN,MODEL, fdisk -l): Dimensione, tipo di interfaccia (NVMe, SATA) e stato rotazionale di ogni disco. Questa è la base dell'architettura di storage.

Modalità controller (impostazioni BIOS, dmesg | grep -i ahci): La modalità AHCI vs RAID vs IDE influisce sulle prestazioni del disco e sulla compatibilità con Linux. Alcuni controller in modalità RAID nascondono i singoli dischi all'installer.

Hardware GPU (lspci | grep -i vga, lspci -nn | grep -i nvidia): Critico per due motivi. Primo, le GPU NVIDIA possono causare crash dell'installer se non gestite correttamente. Secondo, conoscere il modello esatto della GPU determina quale versione del driver ti servirà in seguito.

Dispositivi di rete (ip link, lspci | grep -i net): Hai bisogno dell'accesso alla rete durante l'installazione per scaricare i pacchetti. Sapere se hai rete Intel, Realtek o Broadcom determina se avrai bisogno di pacchetti firmware.

Tabelle di partizione esistenti (fdisk -l, blkid): Qualsiasi dato esistente o schema di partizione deve essere compreso prima di cancellare qualsiasi cosa.

Salute SMART (smartctl -a /dev/sdX): I dati sulla salute del disco ti dicono quali unità sono affidabili per lo storage a lungo termine e quali potrebbero guastarsi sotto carichi di lavoro pesanti.

Il Pattern di Lavoro

Ecco come si svolge in pratica:

1. L'AI ti fornisce un batch di comandi
2. Li esegui nel terminale
3. Incolli l'output nella chat
4. L'AI interpreta i risultati e fa domande di approfondimento
5. Ripeti finché il quadro completo non emerge

Non hai bisogno di capire cosa significa ogni riga dell'output di lspci. L'AI lo legge, segnala ciò che è rilevante e ti dice cosa implica per la tua build. Pensa a questo come a una risoluzione dei problemi collaborativa: tu sei le mani, l'AI è l'analista. Questa divisione del lavoro funziona perché l'AI può elaborare output tecnici densi più velocemente di quanto la maggior parte delle persone possa leggerli.

L'AI Interpreta il Tuo Hardware

Una volta eseguiti i comandi di scoperta, ecco il tipo di inventario con cui lavorerai (questo è l'hardware esatto per la build di questa serie):

• NVMe SSD, 1TB: Samsung 970 EVO Plus, lettura sequenziale ~3.500 MB/s
• HDD SATA, 1TB: Western Digital Blue, 5400 RPM, meccanico
• SSD SATA, 128GB: Kingston più vecchio, discreto ma piccolo, SMART con eventi di temperatura elevata
• GPU: Intel integrata + NVIDIA GeForce (configurazione ibrida/Optimus)
• RAM: 32GB DDR4
• CPU: Intel i7, 8 core / 16 thread

Le specifiche grezze sono solo numeri. Ciò che conta è come l'AI le mappa sul tuo carico di lavoro. Incolla l'output del tuo hardware nella chat e osservala derivare un'architettura di storage basata su come le caratteristiche di ogni disco corrispondono ai requisiti che hai descritto in precedenza.

Architettura di Storage a Tre Livelli

Per una build multi-disco, l'AI proporrà un sistema a livelli in cui ogni disco serve i carichi di lavoro per cui è più adatto:

Livello 1: NVMe (il motore) per tutto ciò che ha bisogno di velocità. Il sistema operativo, lo storage dei container Docker, i database PostgreSQL, i dati Redis e i modelli AI di Ollama. Questi carichi di lavoro generano un I/O casuale intenso, e l'NVMe lo gestisce senza sforzo. Questo disco riceve la cifratura LUKS con LVM per una gestione flessibile delle partizioni.

Livello 2: SSD SATA (lo spazio di lavoro attivo) per l'analisi in corso. Quando stai lavorando su un caso, hai bisogno di accesso rapido a campioni estratti, output temporanei degli strumenti e dati in elaborazione. L'SSD da 128GB fornisce accesso alla velocità degli SSD senza inquinare l'NVMe primario con file transitori. Anch'esso cifrato con LUKS, montato come spazio di lavoro dedicato.

Livello 3: HDD SATA (l'archivio a freddo) per la conservazione a lungo termine. Catture di pacchetti, esportazioni forensi, archivi di prove e tutto ciò che deve esistere ma non ha bisogno di accesso rapido. L'unità meccanica è perfetta qui: grande, economica e affidabile per scritture sequenziali. Cifrata con LUKS con una chiave separata.

"Non mettere i tuoi database su dischi meccanici, e non sprecare la larghezza di banda NVMe su file che apri due volte l'anno. Abbina il livello di storage al pattern di accesso."

Perché il Piccolo SSD Viene Scartato come Disco Root

Ecco una trappola in cui potresti cadere: usare un SSD più piccolo come disco root per mantenere l'NVMe "libero" per i dati. Sembra logico. L'AI si opporrà fermamente, ed ecco perché.

Le immagini Docker e i volumi dei container da soli possono consumare 40-60GB su una workstation di sicurezza. Aggiungi le directory dei dati di PostgreSQL, i file dei modelli di Ollama (che possono essere 4-8GB ciascuno) e i pacchetti di sistema, e stai guardando un minimo di 80-100GB per una partizione root comoda. Su un disco da 128GB, rimane quasi nessun margine per la crescita. Un grande pull Docker e sei al 95% della capacità.

I dati SMART aggiungono un'altra preoccupazione. Se l'SSD ha registrato eventi di throttling termico, non sta fallendo, ma non è il disco che vuoi come root di sistema.

L'NVMe è il primario ovvio. Più veloce, più grande, più sano e costruito esattamente per il tipo di carico di lavoro misto casuale/sequenziale che una partizione root con Docker e database genera. Non complicare troppo.

Il Controllo Firmware che Risparmia Ore

È qui che il processo di scoperta ripaga prima che un singolo byte venga scritto su disco.

Uno dei primi comandi di scoperta potrebbe rivelare che la tua macchina è in esecuzione in modalità Legacy BIOS. La macchina funziona bene in modalità legacy. Ma per una build multi-disco cifrata, è sbagliata. Questo è esattamente il tipo di cosa che l'AI individua e che potresti non pensare di controllare. Ecco perché è importante:

Legacy BIOS + MBR ti limita a quattro partizioni primarie per disco. Per una build cifrata su tre dischi con LVM, è un vero vincolo. Finisci per usare partizioni estese e volumi logici in modi che aggiungono complessità non necessaria.

UEFI + GPT rimuove il limite al numero di partizioni, supporta nativamente dimensioni di disco maggiori e fornisce un processo di avvio più pulito. Per una build multi-volume cifrata, GPT è semplicemente la base giusta.

La tua prossima mossa se l'AI segnala questo: tre modifiche al firmware prima dell'installazione.

1. Passare alla modalità UEFI nelle impostazioni del BIOS
2. Disabilitare Secure Boot (l'installer di Kali può gestire Secure Boot, ma aggiunge attrito durante la configurazione iniziale e l'installazione dei driver, specialmente con NVIDIA)
3. Verificare la modalità AHCI per i controller SATA (potrebbe essere già impostata, ma confermalo)

Questo è il tipo di problema che non sai di dover cercare finché non ti colpisce. Individuarlo durante la scoperta, prima ancora che l'unità USB venga preparata, risparmia tempo reale e frustrazione. Il cambio del firmware richiede cinque minuti nelle impostazioni del BIOS. Scoprire il problema a metà installazione significa ricominciare da capo.

Il Tuo Metodo Ripetibile

Ecco a cosa si riduce l'intero processo: una metodologia che puoi usare per qualsiasi build, qualsiasi hardware, qualsiasi distribuzione. Salvala.

Passo 1: Descrivi i tuoi obiettivi con specificità. Non "voglio Linux" ma "ho bisogno di un sistema che esegua questi servizi, gestisca questi carichi di lavoro e memorizzi questo tipo di dati." Più sei specifico, meglio l'AI può ragionare sulle tue opzioni.

Passo 2: Lascia che l'AI progetti la scoperta. Non cercare su Google i singoli comandi. Di' all'AI quale ruolo sta interpretando e chiedi di progettare l'indagine. Chiederà cose che non avresti pensato di controllare.

Passo 3: Esegui e riferisci. Esegui i comandi, incolla l'output. Tu sei le mani; l'AI è l'analista. Questa divisione del lavoro funziona perché l'AI può elaborare output tecnici densi più velocemente di quanto la maggior parte delle persone possa leggerli.

Passo 4: Lascia che l'AI interpreti rispetto ai tuoi obiettivi. Le specifiche grezze sono prive di significato senza contesto. Un SSD da 128GB va bene come partizione root per un server multimediale. È pericolosamente piccolo per una workstation di sicurezza con molti container Docker. L'AI mappa l'hardware sui requisiti del carico di lavoro e segnala le discrepanze che potresti perdere.

Passo 5: Itera finché il quadro non è completo. La scoperta raramente si esaurisce in un solo giro. L'AI farà domande di approfondimento. "Cosa mostra smartctl per quell'SSD più vecchio?" o "La GPU NVIDIA è l'adattatore display principale?" Ogni giro affina il piano.

"Non hai bisogno di memorizzare i comandi Linux. Hai bisogno di sapere cosa stai costruendo. L'AI gestisce la traduzione tra obiettivi e implementazione."

Questa metodologia funziona che tu stia configurando un server multimediale domestico, una workstation di sviluppo, un'appliance di rete o un rig per penetration testing. I comandi cambiano. Il pattern rimane lo stesso.

Ora hai una distro definita, un inventario hardware completo, un piano di storage a livelli e impostazioni firmware pulite. Tutto da qui in poi è esecuzione. La Parte 2 prende tutto questo e lo trasforma in uno schema di partizione reale: volumi cifrati, layout LVM, punti di mount e lo script di preparazione che valida tutto prima che l'installer tocchi un disco. È lì che la build diventa concreta.

Prossimamente: Parte 2: Storage e cifratura copre la progettazione dei volumi cifrati, il layout LVM e lo script di controllo di sicurezza che valida il tuo hardware prima che inizi l'installazione. Porta il tuo terminale.