🍺 Buy me a beer

Debian

Il sistema operativo fatto da volontari da cui discendono metà delle distro che usi ogni giorno. APT, rilasci, pinning, debconf e il progetto che sta dietro allo swirl rosso.

"It's the software you use." — non è lo slogan ufficiale, ma se hai usato Ubuntu, Kali, Proxmox VE o un Raspberry Pi, hai già usato Debian senza saperlo.

01 / 13

Cos'è davvero Debian

Non è una startup, non ha un CEO, non vende supporto enterprise come RedHat. È un progetto di volontari con una costituzione scritta, e funziona da oltre 30 anni.

📅 Una storia più vecchia di Google

Debian nasce nell'agosto 1993, annunciato da Ian Murdock quando era ancora studente. Il nome è la fusione tra il suo nome e quello della fidanzata (poi moglie) Debra: Deb+Ian = Debian. L'idea era radicale per l'epoca: una distribuzione mantenuta apertamente da una comunità di sviluppatori, non da un'azienda o da una singola persona, con un processo decisionale scritto e pubblico invece che un fork estemporaneo di qualcun altro.

💡 Una biblioteca pubblica, non un negozio

Se Ubuntu è una libreria ben organizzata gestita da un'azienda (Canonical) che decide cosa mettere in vetrina e quando, Debian è più simile a una biblioteca pubblica gestita da bibliotecari volontari: nessuno spinge un prodotto, le regole su cosa entra nello scaffale sono scritte in un documento pubblico (le DFSG, sotto), e chiunque può candidarsi a diventare bibliotecario seguendo un processo formale. È più lenta a volte, ma le decisioni non cambiano a seconda di chi ha comprato l'azienda quest'anno.

📜 Il Social Contract e le DFSG

Il Debian Social Contract è la "costituzione" del progetto: promette che Debian resterà sempre 100% software libero, che i bug non verranno mai nascosti, e che il progetto lavora per i suoi utenti e la comunità free software. Le Debian Free Software Guidelines (DFSG) sono i criteri tecnici che un pacchetto deve rispettare per stare in main: libertà di ridistribuzione, codice sorgente disponibile, nessuna discriminazione contro persone o campi d'uso. Sono anche, storicamente, la base della Open Source Definition.

🌐 "Il sistema operativo universale"

Debian gira ufficialmente su una quantità di architetture CPU che nessun'altra distro maggiore copre: amd64, arm64, armhf, i386, mips64el, ppc64el, riscv64, s390x e altre ancora in porting non ufficiale. Non è un dettaglio da nerd: significa che lo stesso know-how su APT e i pacchetti Debian funziona da un Raspberry Pi a un mainframe IBM, senza dover reimparare nulla.

DerivataCosa aggiunge
UbuntuCicli di rilascio più brevi, supporto commerciale Canonical, più driver proprietari "pronti all'uso"
Kali LinuxDistro per penetration testing, basata su Debian testing con tool di sicurezza preinstallati
Proxmox VEHypervisor KVM/LXC costruito sopra Debian stable (vedi la guida Proxmox)
Raspberry Pi OSDebian ottimizzato per l'hardware ARM del Raspberry Pi
TailsLive OS orientato alla privacy, basato su Debian (vedi la guida Privacy)
MX Linux, deepin, antiX...Decine di altre derivate desktop-oriented
💡 Quando impari Debian, impari anche l'80% di Ubuntu (che ne eredita APT, dpkg e gran parte della struttura), più una fetta enorme dell'ecosistema Linux server. È per questo che vale la pena capirla a fondo, anche se poi lavori quotidianamente su una derivata.
02 / 13

Rilasci: stable, testing, unstable, sid

Quattro rami paralleli, ognuno con uno scopo preciso, e nomi presi tutti da Toy Story. Sì, anche quello ha una ragione.

UNSTABLEsid
dove arrivano i pacchetti nuovi per primi
nome permanente, non cambia mai a ogni rilascio
TESTINGnome in preparazione
pacchetti "invecchiati" ~10 giorni senza bug gravi in sid
diventerà la prossima stable
STABLErilascio corrente
Debian 13 "trixie" (rilasciata il 9 agosto 2025)
quella che gira in produzione, aggiornamenti solo sicurezza/bugfix
OLDSTABLE
Debian 12 "bookworm" — LTS fino al 2028, extended LTS fino al 2033
ancora supportata, ma è ora di pianificare l'upgrade
🌖 sid non è un nome come gli altri Tutti i nomi dei rilasci vengono da Toy Story: bookworm, trixie, forky (l'attuale testing) sono personaggi del film. sid però è diverso: era il bambino vicino di casa che rompeva i giocattoli, e "Still In Development" è il backronym perfetto — sid non diventa mai stable, resta per sempre il ramo instabile permanente. È la tradizione avviata nei primi anni '90 da Bruce Perens, allora Debian Project Leader, e nessuno l'ha mai cambiata.

❄️ Il "freeze" e il ciclo di rilascio

Debian non ha un calendario fisso rigido come Ubuntu (ogni 6 mesi), ma un ciclo "quando è pronto" che in pratica dura circa 2 anni. A un certo punto testing entra in freeze: niente più nuove feature, solo bugfix, finché la qualità non è sufficiente per diventare la nuova stable. È un processo lento ma è il motivo per cui "Debian stable" ha una reputazione di solidità quasi proverbiale.

🚩 Quale ramo usare, e quando

  • stable — server, produzione, qualsiasi cosa che non deve rompersi
  • testing — desktop personale se vuoi pacchetti più recenti accettando qualche rischio
  • unstable/sid — sviluppatori Debian, chi vuole i pacchetti più freschi e sa gestire le rotture
  • experimental — software sperimentale non ancora pronto nemmeno per sid, usato a pacchetti singoli
⚠️ Su un server, la regola è quasi sempre stable, punto. Il prezzo che paghi è software un po' più "vecchio" (Debian 13 ha versioni congelate all'agosto 2025), il vantaggio è che per anni ricevi solo fix di sicurezza mirati, non nuove versioni che possono rompere le tue configurazioni.
03 / 13

Installazione & anatomia post-install

Debian può installarsi in tre modi molto diversi, e la scelta cambia parecchio cosa ti ritrovi al primo boot.

🔌

netinst

~700 MB, scarica tutto da rete durante l'installazione. La scelta più comune per server.

💿

DVD/BD completo

Contiene migliaia di pacchetti offline. Utile senza connessione affidabile.

🖥️

Live

Provalo prima di installarlo, con o senza ambiente desktop già pronto.

tasksel: i "pacchetti di pacchetti"

Durante l'installazione (o dopo, con tasksel) puoi scegliere dei task: gruppi predefiniti di pacchetti come "Desktop environment", "SSH server", "Web server". Per un server minimale, la scelta più comune è deselezionare tutto tranne "standard system utilities" e installare solo quello che serve dopo, a mano.

tasksel dopo l'installazione
sudo tasksel                    # interfaccia a menu
tasksel --list-tasks             # vedi i task disponibili
sudo tasksel install ssh-server
⚠️ Niente utente sudo per default A differenza di Ubuntu, un'installazione Debian minimale storicamente non aggiunge il tuo utente al gruppo sudo: devi loggarti come root (se hai impostato una password root in installazione) oppure fare su - e aggiungerti tu stesso con usermod -aG sudo tuoutente, poi rifare login. Le installazioni più recenti con l'installer grafico spesso lo chiedono esplicitamente, ma su un netinst minimale in modalità testuale è ancora la sorpresa classica del primo giorno.

📋 Cosa NON c'è in un'installazione minimale

Un Debian appena installato in modalità "standard" è volutamente scarno: niente firewall attivo di default, niente editor oltre a nano/vi, spesso nemmeno curl o htop. È una scelta filosofica, non una dimenticanza: Debian preferisce darti un sistema pulito su cui costruisci esattamente quello che ti serve, invece di un sistema pieno di cose che poi devi rimuovere.

04 / 13

APT: il cuore del sistema

Se impari un solo strumento su Debian, è questo. Tutto il resto — installare, aggiornare, rimuovere software — passa da qui.

⚖️ apt vs apt-get vs aptitude

apt (dal 2014 circa) è il comando pensato per l'uso interattivo: output colorato, barra di progresso, sintassi semplificata. apt-get/apt-cache sono i comandi storici, più verbosi ma con un'interfaccia stabile pensata per gli script (non cambia mai tra versioni, a differenza di apt). aptitude è un frontend alternativo con un risolutore di dipendenze diverso, utile nei conflitti più ostici.

📄 sources.list: da dove vengono i pacchetti

La lista dei repository vive in /etc/apt/sources.list e nei file .list (o dal 2023 in poi, formato .sources "deb822") dentro /etc/apt/sources.list.d/. Ogni riga dice: da quale URL, quale distribuzione (bookworm, trixie...) e quali componenti (main, contrib...).

🔧 I comandi di ogni giorno

apt quotidiano
# Aggiorna la lista dei pacchetti disponibili (NON installa nulla)
sudo apt update

# Aggiorna i pacchetti installati, senza rimuovere nulla
sudo apt upgrade

# Come upgrade, ma puo' installare/rimuovere pacchetti se serve per risolvere dipendenze
sudo apt full-upgrade

# Installa / rimuove / rimuove con configurazione
sudo apt install nginx
sudo apt remove nginx        # lascia i file di config in /etc
sudo apt purge nginx         # rimuove anche la config

# Pulizia: pacchetti installati come dipendenza e non piu' necessari
sudo apt autoremove

# Cerca e ispeziona
apt search nginx
apt show nginx
apt list --installed
apt list --upgradable
💡 Se ti serve uno script robusto e riutilizzabile nel tempo, preferisci apt-get/apt-cache (interfaccia stabile, mai cambiata). Se stai digitando a mano nel terminale, apt è più comodo e leggibile.
05 / 13

dpkg: cosa fa APT sotto il cofano

APT non installa nulla da solo: risolve le dipendenze, scarica i file, e poi passa la palla a dpkg, che fa il lavoro sporco vero e proprio.

💡 Il magazziniere e il gestore degli ordini

dpkg è il magazziniere: sa come spacchettare un .deb, dove mettere ogni file, come registrare cosa è installato in /var/lib/dpkg/status. Non sa niente di Internet, non scarica nulla, e soprattutto non risolve le dipendenze da solo — se gli dai un pacchetto che ne richiede altri non installati, si ferma e si lamenta. apt è il gestore degli ordini: parla con i repository via rete, calcola quali pacchetti servono per soddisfare le dipendenze, li scarica, e poi passa tutto a dpkg uno alla volta.

🔍 Ispezionare con dpkg

query utili
# Elenca tutti i pacchetti installati
dpkg -l | less
dpkg -l | grep nginx

# Quali file appartengono a un pacchetto
dpkg -L nginx-common

# A quale pacchetto appartiene QUESTO file
dpkg -S /etc/nginx/nginx.conf

# Installa un .deb scaricato a mano (NON risolve dipendenze mancanti da solo!)
sudo dpkg -i pacchetto.deb
sudo apt --fix-broken install   # risolve le dipendenze rimaste a meta'
📦 Costruire un pacchetto .deb da zero (debhelper, control file, changelog, repository APT firmati) è il territorio della guida Pacchetti .deb: qui l'obiettivo era solo capire la divisione dei ruoli tra apt e dpkg.
06 / 13

Repository, sezioni e componenti

Non tutti i pacchetti in un repository Debian sono uguali: alcuni sono "puri" software libero, altri no, e la distinzione è presa sul serio.

ComponenteContiene
mainSoftware che rispetta al 100% le DFSG. L'unico componente abilitato di default, l'unico "vero Debian"
contribSoftware libero (DFSG-compliant) ma che dipende da software non libero per funzionare
non-freeSoftware che non rispetta le DFSG: licenze restrittive, uso limitato, ecc.
non-free-firmwareFirmware proprietario per hardware (WiFi, GPU...), separato da non-free dal 2023 (Debian 12) proprio per rendere esplicita la scelta di installarlo
⚠️ Il firmware mancante è la causa nascosta più comune di "il WiFi non funziona" Un'installazione Debian "pura" (solo main) su un laptop con una scheda WiFi che richiede firmware proprietario semplicemente non la vedrà. La soluzione è aggiungere non-free-firmware a sources.list (l'installer moderno spesso lo offre già come opzione esplicita durante il setup, con tanto di avviso).

🔒 Il repository security

Gli aggiornamenti di sicurezza per stable non arrivano dal repository normale, ma da uno dedicato: bookworm-security, trixie-security. Deve sempre essere presente in sources.list — toglierlo (anche per errore) significa perdere silenziosamente le patch di sicurezza.

Backports

Il repository trixie-backports ricompila pacchetti più recenti (di solito da testing) per farli girare su stable, per chi vuole una versione più nuova di un pacchetto specifico senza passare tutto il sistema a testing. Va abilitato esplicitamente e usato con il pinning (cap. 7), non come repository di default.

/etc/apt/sources.list — esempio trixie completo
deb http://deb.debian.org/debian trixie main contrib non-free-firmware
deb http://deb.debian.org/debian trixie-updates main contrib non-free-firmware
deb http://security.debian.org/debian-security trixie-security main contrib non-free-firmware
deb http://deb.debian.org/debian trixie-backports main contrib non-free-firmware
07 / 13

Pinning: mescolare rami senza farsi male

A volte vuoi restare su stable ma con UN pacchetto più recente da backports o testing. Il pinning è lo strumento per farlo senza far collassare tutto il sistema.

💡 Un'etichetta di priorità su ogni fonte

APT assegna a ogni pacchetto disponibile una priorità in base a da dove viene (stable, backports, testing...). Di default, stable ha priorità alta e gli altri rami priorità bassa: anche se abiliti backports nel sources.list, APT non installerà automaticamente la versione più recente da lì a meno che non gliela chiedi esplicitamente. Il pinning ti permette di alzare la priorità di un repository specifico, per un pacchetto specifico.

📌 Installare da backports senza convertire tutto il sistema

uso puntuale, senza toccare le preferenze globali
# -t indica il target release SOLO per questa installazione
sudo apt install -t trixie-backports linux-image-amd64

📜 Pinning persistente con apt_preferences

/etc/apt/preferences.d/backports.pref
Package: *
Pin: release a=trixie-backports
Pin-Priority: 100

# priorita' di riferimento (apt_preferences(5)):
#  >1000  installa anche se e' un downgrade
#  990    e' il default della release "target" (stable)
#  500    default per un repository generico gia' abilitato
#  100    installato SOLO se lo chiedi esplicitamente (-t / apt install pkg/release)
#  <0     non verra' mai installato
💡 Verifica sempre con apt-cache policy nomepacchetto da quale repository verrebbe installato un pacchetto prima di lanciare l'install: ti mostra tutte le versioni disponibili e le rispettive priorità, così non hai sorprese.
08 / 13

Configurazione "alla Debian"

Debian ha le sue convenzioni per configurare pacchetti in modo interattivo e per gestire "quale programma fa cosa" quando ce n'è più di uno disponibile.

💬 debconf: la configurazione interattiva

debconf è il sistema che fa le domande durante l'installazione di un pacchetto (es. "quale timezone?", "password di MySQL?"). Le risposte vengono salvate in un database, e puoi rifare la configurazione in qualsiasi momento senza reinstallare.

dpkg-reconfigure
sudo dpkg-reconfigure tzdata
sudo dpkg-reconfigure locales
sudo debconf-show nomepacchetto

🔁 update-alternatives

Quando più pacchetti forniscono lo stesso comando (es. editor, java), il sistema alternatives gestisce quale versione è effettivamente attiva tramite link simbolici in /etc/alternatives/, con un punteggio di priorità per ognuna.

scegliere l'editor di default
sudo update-alternatives --config editor
update-alternatives --list editor

📁 /etc/default/*: opzioni degli init script

Molti pacchetti leggono opzioni di avvio da un file dedicato in /etc/default/ (es. /etc/default/grub, /etc/default/docker), separato dalla configurazione vera e propria del programma. È una convenzione Debian per non dover editare direttamente gli script/unit file: le impostazioni comuni (memoria, flag da riga di comando, opzioni booleane) stanno lì.

09 / 13

Passare da una release major alla successiva

Aggiornare i pacchetti dentro la stessa stable è routine. Saltare da bookworm a trixie è un'operazione diversa, che va pianificata.

🔄 Aggiornamento minore (dentro la stessa release)

routine, sicuro, frequente
sudo apt update
sudo apt full-upgrade
sudo apt autoremove

🚀 Upgrade major (es. bookworm → trixie)

pianificato, con backup prima
# 1. Sei gia' completamente aggiornato su bookworm?
sudo apt update && sudo apt full-upgrade

# 2. Sostituisci "bookworm" con "trixie" in tutti i sources.list*
sudo sed -i 's/bookworm/trixie/g' /etc/apt/sources.list

# 3. Aggiorna l'elenco pacchetti e fai l'upgrade vero
sudo apt update
sudo apt full-upgrade

# 4. Riavvia: nuovo kernel, nuovo systemd, meglio ripartire puliti
sudo reboot
💥 Leggi SEMPRE le release notes prima, e non saltare release Debian supporta ufficialmente solo l'upgrade da una release alla successiva immediata (bookworm → trixie), non saltando in mezzo (bullseye → trixie direttamente). Le release notes di ogni versione elencano cambiamenti che richiedono attenzione manuale (rimozione di pacchetti, cambi di default, migrazioni di configurazione): sono noiose ma ignorarle su un server di produzione è il modo più comune per trasformare "ho fatto l'upgrade" in "ho un incidente". Fai sempre un backup/snapshot prima.
10 / 13

Sicurezza & manutenzione continua

Debian stable esiste apposta per essere stabile: le patch di sicurezza arrivano senza cambiare comportamento del pacchetto sotto di te.

📣 Restare informati

  • debian-security-announce — mailing list ufficiale con ogni DSA (Debian Security Advisory)
  • security-tracker.debian.org — stato dei CVE per ogni pacchetto
  • apt list --upgradable — cosa hai in sospeso adesso

⚙️ unattended-upgrades

Il pacchetto unattended-upgrades applica automaticamente gli aggiornamenti di sicurezza (e opzionalmente quelli normali) senza intervento manuale: la scelta giusta per server che non controlli ogni giorno.

attivarlo
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

🔄 Servizi che restano vecchi in memoria dopo un update

Aggiornare una libreria (es. libssl) non riavvia automaticamente i processi già in esecuzione che la usano: restano a girare con il vecchio codice caricato in memoria finché non vengono riavviati. needrestart individua questi servizi "zombie" dopo un upgrade e propone di riavviarli.

needrestart e pacchetti bloccati
sudo apt install needrestart
sudo needrestart

# "Congela" un pacchetto a una versione specifica (non verra' toccato da upgrade)
sudo apt-mark hold nomepacchetto
apt-mark showhold
sudo apt-mark unhold nomepacchetto
11 / 13

Community & governance

Nessuno "possiede" Debian. Capire come funziona il progetto aiuta a capire perché certe cose sono lente, e altre incredibilmente affidabili.

👤 Debian Developer & Debian Maintainer

Un Debian Developer (DD) è un membro a pieno titolo del progetto, con diritto di voto e la possibilità di mantenere qualsiasi pacchetto; ci si arriva tramite un processo formale (New Member Process) che verifica identità, competenza tecnica e comprensione della filosofia Debian. Un Debian Maintainer (DM) ha permessi più limitati, per mantenere pacchetti specifici senza passare tutto il processo NM.

👑 Il Debian Project Leader

Il DPL viene eletto ogni anno dai DD con voto tramite il metodo Condorcet. Non è un "capo" nel senso aziendale: rappresenta il progetto verso l'esterno, gestisce budget e delega, ma le decisioni tecniche restano distribuite tra i singoli manutentori di pacchetto e i team.

🐛 Il Bug Tracking System

Ogni bug su un pacchetto Debian ha un numero pubblico su bugs.debian.org (il BTS), consultabile e commentabile via email o web. Lo strumento reportbug guida nella segnalazione raccogliendo automaticamente le informazioni di sistema rilevanti.

segnalare un bug
sudo apt install reportbug
reportbug nomepacchetto
💡 Se il processo ti sembra "lento e burocratico", è lo stesso motivo per cui funziona da 30+ anni senza un'azienda dietro che possa fallire, essere acquisita o cambiare licenza da un giorno all'altro. Il costo della governance distribuita è la velocità; il beneficio è la continuità.
12 / 13

Troubleshooting comune

Gli stessi cinque problemi tornano sempre. Ecco come riconoscerli e risolverli senza reinstallare tutto.

🔌 Dipendenze rotte / installazione a metà

fix-broken & configure -a
sudo apt --fix-broken install
sudo dpkg --configure -a
sudo apt update && sudo apt full-upgrade

💾 Disco pieno per colpa della cache APT

pulire /var/cache/apt
du -sh /var/cache/apt/archives
sudo apt clean          # cancella TUTTI i .deb scaricati
sudo apt autoclean      # solo quelli non piu' scaricabili (versioni vecchie)

🔑 "NO_PUBKEY" / chiave GPG scaduta

Ogni repository è firmato; se la chiave è scaduta o mancante, apt update si rifiuta di fidarsi. Verifica sempre la fonte della chiave prima di importarla ciecamente da uno script trovato online.

diagnosi
apt-key list                # deprecato ma utile per capire
ls /etc/apt/trusted.gpg.d/

Un pacchetto "held" blocca l'upgrade

Se un pacchetto è marcato hold (cap. 10) o ha una dipendenza in conflitto, apt full-upgrade può rifiutarsi di procedere su quel pacchetto specifico, lasciando gli altri aggiornati.

capire chi blocca
apt-mark showhold
apt-cache policy nomepacchetto
13 / 13

Cheat Sheet & Glossario

Tutto quello che serve, su una pagina. Bookmark questa sezione e dimentica il resto.

⚖️ APT quotidiano

i comandi che usi sempre
sudo apt update
sudo apt full-upgrade
sudo apt install pkg
sudo apt purge pkg
sudo apt autoremove
apt list --upgradable
apt-cache policy pkg

📦 dpkg & diagnosi

query e riparazioni
dpkg -l | grep pkg
dpkg -L pkg
dpkg -S /percorso/file
sudo apt --fix-broken install
sudo dpkg --configure -a
sudo apt clean

📌 Pinning & configurazione

backports, alternatives, debconf
sudo apt install -t trixie-backports pkg
sudo update-alternatives --config editor
sudo dpkg-reconfigure tzdata
sudo apt-mark hold pkg

🛡️ Sicurezza

aggiornamenti automatici
sudo apt install unattended-upgrades needrestart
sudo dpkg-reconfigure -plow unattended-upgrades
sudo needrestart

✓ Regole d'oro

  • Server in produzione: stable, sempre, senza eccezioni
  • Repository -security sempre presente in sources.list
  • Backports con pinning, mai come repository "libero" senza priorità
  • Leggi le release notes prima di ogni upgrade major
  • Un ramo alla volta: mai saltare una release intermedia
  • apt-cache policy prima di installare da fonti multiple
  • Backup/snapshot prima di ogni full-upgrade tra release

✗ Errori classici

  • Mescolare stable e testing/sid senza pinning ("Frankendebian")
  • Importare chiavi GPG di terze parti senza verificarne la fonte
  • apt upgrade quando serve full-upgrade (dipendenze non risolte)
  • Dimenticare apt clean su server con disco piccolo
  • Saltare direttamente da bullseye a trixie ignorando bookworm
  • Ignorare needrestart dopo un upgrade di librerie critiche (openssl, glibc)

📚 Glossario essenziale

  • DFSG — Debian Free Software Guidelines, i criteri per stare in main
  • Social Contract — la "costituzione" di principi del progetto
  • stable / testing / unstable — i tre rami principali di sviluppo
  • sid — nome permanente del ramo unstable ("Still In Development")
  • freeze — fase in cui testing smette di ricevere nuove feature prima del rilascio
  • APT — Advanced Package Tool, il gestore di dipendenze e repository
  • dpkg — lo strumento di basso livello che spacchetta e installa i .deb
  • main / contrib / non-free — le componenti di un repository per libertà della licenza
  • backports — pacchetti più recenti ricompilati per girare su stable
  • pinning — assegnare priorità diverse a repository diversi
  • debconf — sistema di configurazione interattiva dei pacchetti
  • update-alternatives — gestisce quale binario risponde a un comando condiviso
  • tasksel — installa gruppi predefiniti di pacchetti ("task")
  • DD / DM — Debian Developer / Debian Maintainer
  • DPL — Debian Project Leader, eletto ogni anno
  • BTS — Bug Tracking System, bugs.debian.org
  • DSA — Debian Security Advisory, annuncio ufficiale di sicurezza
  • held package — pacchetto "congelato" e ignorato dagli upgrade

📚 Risorse

  • debian.org — sito ufficiale, release notes, documentazione
  • wiki.debian.org — guide pratiche mantenute dalla community
  • packages.debian.org — ricerca pacchetti per nome/file contenuto
  • security-tracker.debian.org — stato dei CVE per pacchetto
  • man apt_preferences — la bibbia del pinning

🔗 Guide collegate

  • Pacchetti .deb — come si costruisce un pacchetto, non solo come si installa
  • Linux Admin — systemd, LVM, SSH: il resto del mestiere
  • Il Kernel Linux — cosa gira davvero sotto la distro
  • Proxmox VE — un'intera piattaforma di virtualizzazione costruita su Debian stable
  • Privacy — Tails, una derivata Debian orientata all'anonimato
🌀
Regola finale dello svogliato — su un server usa stable e non discutere, tieni sempre il repository security abilitato, e se proprio devi mescolare rami fallo con il pinning, non a mano. Il resto — community, DFSG, il nome buffo di sid — è il motivo per cui questo progetto di volontari regge da più di 30 anni mentre aziende ben più grandi sono nate e sparite.