Kernel Linux e distribuzioni

Questa è una guida lunga e meditata sul kernel Linux e sulle distribuzioni: cosa sono, come funzionano, perché esistono tante “Linux” diverse e come scegliere quella giusta.

Fonti e letture ufficiali:

• Linux Kernel Archives: https://www.kernel.org/
• Documentazione ufficiale del kernel: https://docs.kernel.org/
• Panoramica kernel Fedora: https://docs.fedoraproject.org/en-US/quick-docs/kernel-overview/

Introduzione: perché serve chiarezza

Quando qualcuno dice “uso Linux” spesso non è chiaro se intende il kernel, una distro specifica, un desktop environment, o una combinazione di tutto questo. Qui separo i livelli, li spiego e poi scendo nei dettagli tecnici: così, quando leggi una guida, sai se sta parlando del kernel, della distribuzione o del desktop.

Parte 1 — Il kernel (che cos’è e come funziona)

Cos’è il kernel, in parole semplici

Il kernel è il software che sta tra l’hardware e tutto il resto: processi, filesystem, rete. Gestisce scheduling, memoria, driver, I/O, sicurezza, networking. Senza kernel, il computer non sa cosa significhi “eseguire un programma”.

Tecnicamente: il kernel Linux è un kernel Unix-like, monolitico modulare (monolithic kernel con possibilità di caricare moduli), sviluppato upstream da una vasta comunità; la sua documentazione e i sorgenti sono su kernel.org.

Struttura interna del kernel (panoramica tecnica)

Il kernel non è “una cosa sola”: è un insieme di sottosistemi interconnessi. Ecco i principali, con un pelo di dettaglio tecnico.

• Scheduler (CPU scheduler)

  • Decide quale thread/processo va eseguito, per quanto tempo, su quale CPU.
  • Tipici algoritmi: CFS (Completely Fair Scheduler) per carichi desktop/generali; real-time scheduler (SCHED_FIFO, SCHED_RR, SCHED_DEADLINE) per task realtime.
  • Il comportamento dello scheduler influisce su reattività, throughput e latenza.

• Gestione della memoria

  • Pagine, tabelle di pagina (MMU), memoria virtuale, mappature, copy-on-write (COW).
  • Sistema di swap: pagine vengono spostate su disco quando RAM limitata.
  • Slab allocators (kmalloc / slab / slub) per allocazioni kernel, page allocator per pagine fisiche.
  • OOM killer per gestire out-of-memory.

• VFS (Virtual File System) e filesystem

  • VFS astrae filesystem diversi (ext4, btrfs, xfs, f2fs, ntfs-3g) dietro chiamate uniformi (open, read, write, stat).
  • Journaling, journaling vs copy-on-write (btrfs), mount options, barriers.
  • I/O scheduler o I/O path: blocchi, request queues, bio, elevator (in passato CFQ, ora none/kyber a seconda del sistema).

• Driver e moduli

  • Driver hardware: spesso in kernel tree, a volte distribuiti come moduli caricabili (insmod/modprobe).
  • Moduli permettono di aggiungere supporto a dispositivi senza ricompilare tutto il kernel.
  • Firmware blobs: alcuni driver richiedono firmware proprietari caricabili a runtime.

• Networking

  • Stack TCP/IP: gestione di sockets, netfilter (iptables/nftables), bridging, routing.
  • Sockets API, TUN/TAP per interfacce virtuali, bonding, VLAN.
  • QoS e traffic control (tc) per shaping/prioritizzazione.

• IPC e sincronizzazione

  • Mutex, spinlocks, RCU (Read-Copy-Update) per sincronizzazione efficiente in presenza di concorrenza.
  • Semafori, futex per sincronizzazione tra processi/threads.

• Architetture CPU

  • Il kernel supporta molte architetture: x86_64, ARM, AArch64, RISC-V, PowerPC.
  • Ogni arch ha specifici assembly entry/exit, context switch, exception handling e ABI.

Modelli di build: monolitico vs microkernel (nota)

Linux è “monolitico modulare”: la maggior parte delle funzionalità vive nel kernel address space per performance, ma è possibile caricare moduli dinamicamente. Non è microkernel (es. Minix, seL4), dove moltissimo viene spostato nello spazio utente.

Alcuni dettagli pratici per chi amministra

• Versioni kernel: upstream rilascia patch e major; distro spesso patchano o backportano funzioni di sicurezza.
• LTS vs stabile: per server spesso si scelgono LTS; per hardware recente conviene kernel più nuovo.
• Compilare kernel: opzioni CONFIG_* abilitate/disabilitate influenzano funzionalità e dimensione.

Parte 2 — Dal kernel alla distribuzione: che cosa aggiunge una distro

Una distribuzione mette insieme:

• un kernel (con patch, config e versione scelta),
• toolchain (glibc, gcc, libstdc++),
• package manager e repository,
• init system e servizi (systemd, unit files),
• strumenti di installazione e configurazioni predefinite,
• desktop environment, temi e set di applicazioni,
• policy di sicurezza (SELinux, AppArmor),
• supporto e documentazione.

Il kernel è il motore. La distro è il veicolo completo.

Due distro possono condividere lo stesso kernel ma offrire esperienze molto diverse, perché cambiano tutti gli strati sopra di esso.

Parte 3 — Modelli di rilascio e loro implicazioni

Tre modelli principali:

1. Rolling release

   • Aggiornamenti continui (Arch, openSUSE Tumbleweed).
   • Pro: sempre software fresco, driver e kernel nuovi, spesso migliore supporto hardware.
   • Contro: potenziali regressioni più frequenti, più attenzione richiesta.

2. Point release (stable/LTS)

   • Release con versioni congelate per un periodo (Debian Stable, Ubuntu LTS, openSUSE Leap).
   • Pro: prevedibilità, test approfonditi, ideale per server.
   • Contro: software più vecchio, driver nuovi potrebbero non essere presenti.

3. Hybrid / Fast release

   • Rilasci regolari ma con pacchetti aggiornati (Fedora).
   • Pro: bilancio tra stabilità e freschezza, politiche di testing strutturate.
   • Contro: occasionalmente richiede workaround per software proprietario.

Fedora Linux Kernel Overview sottolinea che il kernel Fedora segue da vicino le release upstream.

Parte 4 — Package manager e formato pacchetti (perché conta)

Il package manager condiziona tutto: installare, aggiornare, risolvere dipendenze, ripristinare pacchetti.

• Debian / Ubuntu / Mint: apt (dpkg) con pacchetti .deb. Grande ecosistema, PPA (Personal Package Archives) su Ubuntu per software non ufficiale.
• Fedora / RHEL / CentOS / openSUSE: RPM con gestori moderni come dnf (Fedora) o zypper (openSUSE). RPM ha tool di check e verifica robusti.
• Arch: pacman per pacchetti binari ufficiali; AUR (Arch User Repository) per build script della community.
• Altri: Nix (sistema di pacchettizzazione funzionale), Guix (simile), Flatpak/Snap/AppImage (sandboxed/universal packaging).

Impatto pratico:

• Disponibilità dei pacchetti.
• Facilità di rollback.
• Documentazione e comunità.
• Filosofia: alcuni repository privilegiano software libero (Debian), altri sono più pragmatici (Ubuntu, Fedora).

Parte 5 — AppImage e Flatpak

Qui entriamo in due formati di distribuzione software molto importanti nel mondo Linux moderno: AppImage e Flatpak. Non sono distro, non sono package manager tradizionali e non sono semplici “archivi da aprire”: sono due modi diversi di consegnare applicazioni Linux in modo più portabile e meno dipendente dalla singola distribuzione.

AppImage

Un AppImage è un file eseguibile autocontenuto. L’idea è molto semplice: scarichi un singolo file, lo rendi eseguibile e lo avvii. Il progetto AppImage descrive chiaramente il modello come “upstream packaging”: idealmente è l’autore originale dell’app a costruire e distribuire il pacchetto, un po’ come succede con un .exe su Windows o un .dmg su macOS.

Perché piace

• Non richiede installazione nel sistema.
• È spesso portabile tra distro diverse.
• È utile per software distribuito direttamente dallo sviluppatore.
• Evita in molti casi il problema delle dipendenze mancanti.

Come funziona davvero

Un AppImage non si “installa” nel senso classico: si scarica, si rende eseguibile con chmod +x, poi si avvia. Dentro contiene quasi tutto ciò che serve all’applicazione, con alcune dipendenze esterne minime a seconda del caso.

Gestione pratica degli AppImage

Una volta scaricato il file:

chmod +x NomeApplicazione.AppImage
./NomeApplicazione.AppImage

Alcuni AppImage si integrano con il desktop tramite menu, icone o launcher esterni, ma l’idea base resta la stessa: un file singolo, eseguibile, separato dal gestore pacchetti della distro.

Pro e contro

Pro:

• zero installazione classica.
• molto comodo per software fuori repository.
• ottimo per versioni upstream.
• facile da trasportare.

Contro:

• aggiornamenti non sempre automatici.
• integrazione col sistema meno coerente.
• possibili problemi con temi, librerie o sandbox.
• gestione un po’ più manuale.

Quando ha senso usare AppImage

• Software distribuito direttamente dall’autore.
• App singole che vuoi provare senza installare mezzo sistema.
• Tool portabili.
• Situazioni in cui vuoi evitare repository o pacchetti della distro.

Flatpak

Flatpak è un sistema di distribuzione per applicazioni desktop che punta a essere indipendente dalla distro. Il sito ufficiale lo presenta proprio come un modo per distribuire app su diverse distribuzioni Linux con un modello moderno, sandboxato e centrato su runtime condivisi.

L’idea tecnica dietro Flatpak

Flatpak non consegna solo l’app: consegna anche una parte dell’ambiente necessario a farla girare, sotto forma di runtime. L’app viene eseguita in una sandbox che limita l’accesso al sistema, e riceve permessi specifici per accedere a file, rete, audio, webcam, USB e così via.

Perché è così usato

• Funziona su molte distro diverse.
• Isola le app dal sistema base.
• Riduce il problema delle dipendenze.
• Consente aggiornamenti centralizzati tramite repository come Flathub.
• È comodo per software desktop moderno.

Installazione di Flatpak

Su molte distro moderne Flatpak è già presente o molto facile da installare.

Esempio base:

sudo dnf install flatpak

Poi di solito si aggiunge Flathub, che è il grande catalogo di app Flatpak più usato nel mondo desktop.

flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

Installare applicazioni Flatpak

Puoi installare un’app con il suo ID:

flatpak install flathub org.mozilla.firefox

Oppure da file locale .flatpak:

flatpak install --user NomeApp.flatpak

Avvio di un’app Flatpak

flatpak run org.mozilla.firefox

Gestione quotidiana

Flatpak ha una logica diversa dai pacchetti nativi della distro:

• aggiornamento centralizzato;
• permessi sandbox;
• runtime condivisi;
• possibile coesistenza con il software del sistema.

Comandi utili:

flatpak update
flatpak list
flatpak uninstall org.mozilla.firefox
flatpak info org.mozilla.firefox

Permessi e gestione sandbox

Il punto forte di Flatpak è la sandbox, ma a volte la sandbox va capita e regolata. Se un’app deve accedere a una cartella specifica o a una periferica, puoi gestire i permessi con strumenti come flatseal oppure con i parametri Flatpak.

flatpak override --user --filesystem=home org.mozilla.firefox

Pro e contro di Flatpak

Pro:

• portabile.
• isolato.
• aggiornamenti semplici.
• ottimo per desktop.
• molto utile quando il pacchetto nativo manca o è vecchio.

Contro:

• può occupare più spazio per via dei runtime.
• alcune app non si integrano perfettamente col tema del sistema.
• sandbox da capire se hai bisogno di accessi speciali.
• può sembrare “un altro strato” da gestire.

Quando usare Flatpak

• Quando vuoi software moderno su qualsiasi distro.
• Quando il repository della distro è troppo vecchio.
• Quando vuoi separare bene le app dal sistema base.
• Quando vuoi meno differenze tra una distro e l’altra.

Gestire AppImage e Flatpak in pratica

La differenza utile da tenere a mente è questa:

• AppImage: singolo file, portabile, poco invasivo.
• Flatpak: app sandboxata con runtime, più strutturata, aggiornata via repository.

Se vuoi semplicità assoluta

AppImage è spesso la strada più diretta.

Se vuoi manutenzione e aggiornamenti più ordinati

Flatpak è spesso la scelta migliore.

Se vuoi integrazione nativa con la distro

I pacchetti tradizionali (apt, dnf, zypper, pacman) restano la soluzione più “pulita” a livello di sistema.

Strategia pratica consigliata

• Sistema base: pacchetti nativi della distro.
• App desktop moderne e portabili: Flatpak.
• Tool singoli distribuiti upstream: AppImage.

Questa combinazione è spesso quella più sensata nella vita reale.

Parte 6 — Ambienti senza desktop e server

Non tutte le installazioni Linux hanno bisogno di un desktop grafico. Anzi, in moltissimi casi il desktop non serve affatto. Un server spesso deve solo esporre servizi: SSH, database, web server, storage, container, DNS, VPN, reverse proxy, mail server. In questi casi un’interfaccia grafica sarebbe solo consumo extra di RAM, CPU, spazio disco e superficie di attacco.

Perché si evita il desktop sui server

• Meno risorse usate.
• Meno pacchetti da mantenere.
• Meno superficie di attacco.
• Meno complessità inutile.
• Più stabilità operativa.

Cosa significa davvero “server senza desktop”

Significa che il sistema viene installato con un set minimo di componenti:

• kernel;
• init system;
• rete;
• SSH;
• tool amministrativi;
• eventuali servizi applicativi.

Di solito si arriva al sistema via terminale, locale o remoto, senza sessione grafica.

Esempio tipico

Un server può partire direttamente in modalità testuale, accedere via SSH e non avviare nessun ambiente grafico. Questo non lo rende “meno Linux”: lo rende semplicemente più adatto al suo compito.

Parte 7 — Runlevel, target e stati di avvio

Storicamente Linux usava i runlevel del vecchio sistema SysV init. Oggi quasi tutte le distro usano systemd, che lavora con i target. Il concetto però è simile: definire in che stato deve trovarsi il sistema all’avvio. systemd fornisce una mappatura di compatibilità tra runlevel e target, e la documentazione spiega che multi-user.target corrisponde ai vecchi runlevel 2, 3 e 4, mentre graphical.target corrisponde al runlevel 5.

Runlevel tradizionali

• 0 = shutdown / poweroff.
• 1 = single-user / rescue.
• 2 = multi-user senza una definizione fortissima storica, spesso non usato in modo standard.
• 3 = multi-user testuale con rete.
• 4 = spesso libero o personalizzabile.
• 5 = multi-user con interfaccia grafica.
• 6 = reboot.

Mappatura con systemd

Con systemd, questi concetti si traducono in target:

• poweroff.target → runlevel 0.
• rescue.target → runlevel 1.
• multi-user.target → runlevel 2/3/4.
• graphical.target → runlevel 5.
• reboot.target → runlevel 6.

La documentazione Oracle Linux mostra chiaramente questa corrispondenza e specifica anche che un server di produzione può usare multi-user.target per evitare di avviare l’interfaccia grafica.

Perché conta nella pratica

Se imposti il sistema su multi-user.target, il computer parte in modalità testuale con networking e servizi, ma senza desktop grafico. Questo è perfetto per server, VPS, nodi container, appliance e ambienti di amministrazione remota.

Comandi utili

systemctl get-default
systemctl list-units --type target
sudo systemctl set-default multi-user.target
sudo systemctl set-default graphical.target
sudo systemctl isolate multi-user.target
sudo systemctl isolate graphical.target

Quando usare cosa

• graphical.target: desktop, workstation, laptop, uso quotidiano.
• multi-user.target: server, VM di servizio, sistemi headless.
• rescue.target: recupero, diagnosi, manutenzione minima.

Runlevel oggi

I runlevel non sono il modo moderno di pensare il boot, ma restano utili come linguaggio di compatibilità. runlevel oggi stampa soprattutto informazioni di compatibilità e non dovrebbe essere usato come modello principale di amministrazione nei sistemi moderni. Il riferimento giusto, in pratica, sono i target di systemd.

Parte 8 — Desktop, server e headless

A questo punto la distinzione è chiara:

• Desktop = sistema pensato per interazione grafica quotidiana.
• Server = sistema pensato per erogare servizi, spesso senza GUI.
• Headless = sistema senza monitor o senza necessità di desktop locale.

Molte distro possono fare tutte e tre le cose, ma le scelte di installazione cambiano molto.

Esempio concreto

• Fedora Workstation: orientata al desktop.
• Fedora Server: orientata al server, senza GUI per default.
• Debian: può essere usata sia come desktop sia come server.
• Ubuntu Server: installazione minimale, di solito senza desktop.
• Arch: scegli tu cosa installare.

Parte 9 — Le distro principali (dettagli)

Debian

• Focus: stabilità, coerenza, robustezza.
• Ciclo: stable/testing/unstable (sid). Stable è molto testata; testing è base per next stable; unstable è upstream continuo.
• Pacchetti: .deb + apt.
• Kernel: versione più conservativa in stable, con backport di sicurezza; possibilità di usare kernel più recenti da backports.
• Quando: server, macchine dove la prevedibilità conta.
• Aspetti tecnici: eccellente gestione delle dipendenze, policy rigorose su firmware non-libero (contrib/non-free separati).

Ubuntu (e derivati)

• Base: Debian, con cicli LTS e interim (non-LTS).
• Obiettivi: esperienza desktop “out of the box”, ampio supporto hardware, grande ecosistema.
• Pacchetti: .deb + apt, PPAs per software extra.
• Kernel: tende a includere versioni con backport e patch per compatibilità hardware.
• Quando: desktop facile, supporto vendor, comunità enorme.

Linux Mint

• Basata su Ubuntu (o Debian in ed. Debian-based).
• Filosofia: esperienza desktop familiare (Cinnamon), comodità, codec preinstallati, meno frizioni nel passaggio da Windows.
• Quando: utenti che vogliono “usare” e non “configurare” troppo.

Fedora

• Focus: tecnologie moderne upstream, integrazione stretta con GNOME, sperimentazione controllata.
• Pacchetti: RPM + dnf.
• Kernel: relativamente nuovo, segue l’upstream; ottimo supporto hardware moderno.
• Ciclo: release rapide (~6 mesi), lifecycle corti (supporto limitato).
• Quando: workstation moderne, sviluppatori che vogliono features recenti senza rolling release.

Arch Linux

• Filosofia: KISS (Keep It Simple, Stupid), rolling release, pacman e AUR.
• Caratteristiche: installazione minima (utente costruisce tutto), documentazione approfondita (Arch Wiki), pacchetti estremamente freschi.
• Rischi: richiede manutenzione, attenzione a breaking changes, lettura delle note di aggiornamento.
• Quando: imparare Linux, controllo assoluto, ambiente di test con software sempre aggiornato.

openSUSE

• Varianti: Leap (stabile) e Tumbleweed (rolling).
• Strumenti forti: YaST per amministrazione, zypper come package manager.
• Filosofia: ingegnerizzazione e strumenti aziendali; buone opzioni per sysadmins.
• Quando: aziendale, amministrazione, chi cerca equilibrio tra controllo e usabilità.

Parte 10 — Kernel versioning e backporting

• Upstream rilascia kernel con numerazione semantica. Alcune distro mantengono patch LTS (es. 6.x LTS), altre aggiornano spesso.
• Backport: per mantenere stabilità, una distro può backportare fix di sicurezza a una versione kernel meno recente.
• DKMS (Dynamic Kernel Module Support): sistema per ricompilare moduli (es. driver proprietari) automaticamente quando il kernel viene aggiornato.

Implicazioni:

• Driver proprietari (es. NVIDIA) spesso richiedono DKMS o kernel header adeguati.
• Se hai hardware molto nuovo (Wi-Fi, GPU), un kernel più aggiornato aiuta.
• Se hai server critici, kernel ben testati (LTS) e patch backportate sono preferibili.

Parte 11 — Init systems, systemd e alternative

Perché importa l’init system

L’init è il primo processo che parte (PID 1): gestisce il boot, servizi, unità, log e shutdown.

systemd

• È lo standard di fatto su molte distro (Fedora, Debian, Ubuntu, Arch, openSUSE).
• Offre: unit files, socket activation, journal (journald), cgroups integration, timed/triggered services.
• Pro: avvio parallelo, gestione uniforme servizi, integrazione con cgroups (container-friendly).
• Contro: complessità, surface di API grande; alcune critiche per “troppo centralizzato”.

Alternative

• SysV init (vecchio), OpenRC, runit, s6: più semplici, meno integrazione creata ad hoc ma più leggerezza o filosofia modulare.

Impatto pratico:

• systemd fornisce strumenti standard (systemctl, journalctl) ma richiede familiarità.
• Alcune scelte di distro (es. Fedora) integrano fortemente systemd in tutto lo stack.

Parte 12 — Sicurezza: SELinux, AppArmor, altre politiche

SELinux

• Mandatory Access Control (MAC) originato da NSA policy.
• Fortemente integrato in Fedora/RedHat family.
• Define policy che limitano cosa può fare ogni processo (oltre ai normali permessi Unix).
• Curva di apprendimento: potente ma può bloccare servizi se policy non previste.

AppArmor

• MAC basato su profili per ogni applicazione (progetti come Ubuntu, SUSE).
• Solitamente più semplice da configurare per principianti rispetto a SELinux (profiling path-based).

Cosa scegliere

• Fedora/RedHat: SELinux abilitato e consigliato.
• Ubuntu/openSUSE: AppArmor è spesso predefinito.
• Debian: supporta entrambi, spesso usa AppArmor in ambito desktop.

Impatto pratico:

• Se lavori con server o servizi esposti, capire e configurare SELinux/AppArmor è importante per sicurezza robusta.
• Logs (auditd) e strumenti (sealert, aa-status) aiutano nel debugging.

Parte 13 — Containers e virtualizzazione

Il kernel fornisce primitive usate da container (namespaces, cgroups) e da KVM (virtualizzazione hardware):

• Namespaces: isolano PID, network, mounts, user IDs.
• cgroups: limitano risorse (CPU, memoria, I/O).
• KVM: modulo kernel per virtualizzazione completa con HW assist (VT-x/AMD-V).

Distro moderne preparano immagini e kernel perfetti per container, e molte includono tool come Podman/ Docker/CRI-O. Fedora e CentOS/ Red Hat sono posizionate fortemente su questo ecosistema.

Parte 14 — Grafica: X11 vs Wayland, compositor e GPU

X11

• Vecchio ma estremamente compatibile.
• Architetturalmente client-server: X server gestisce input/output.
• Problemi: sicurezza, modernizzazione limitata.

Wayland

• Moderno, disegnato per sicurezza, compositing e performance migliori.
• Compositor (es. Weston, Mutter, KWin) gestisce buffers e compositing.
• Wayland migliora tear, latency e sicurezza, ma alcune app legacy richiedono XWayland fallback.

Distro:

• Fedora è tra le prime a spingere Wayland come predefinito.
• Ubuntu/others stanno migrando gradualmente, ma ci sono eccezioni.

GPU:

• Driver open (Mesa) vs driver proprietari (NVIDIA). Il kernel interagisce con driver grafici per KMS (Kernel Mode Setting) e DRM (Direct Rendering Manager).

Parte 15 — File systems

• ext4: default storico, maturo, solido.
• btrfs: copy-on-write, snapshot native, subvolumes, RAID-like features (usato come default in alcune distro per laptop/desktop).
• xfs: ottimo per throughput elevato su grandi file/IO pesante.
• f2fs: ottimizzato per flash/NVMe/SD.

La scelta influisce su snapshot, backup, performance e recovery.

Parte 16 — Strumenti amministrativi tipici per ogni famiglia

• Debian/Ubuntu: apt, dpkg, systemctl, ufw (facoltativo).
• Fedora: dnf, rpm, systemctl, firewall-cmd, SELinux tools.
• Arch: pacman, systemctl, AUR helpers (yay), pacman hooks.
• openSUSE: zypper, YaST, systemctl, AppArmor.

Parte 17 — Casi d’uso e raccomandazioni pratiche

• Server enterprise: Debian Stable / RHEL / CentOS Stream / openSUSE Leap (stabilità, LTS, certificazioni).
• Desktop moderno e sviluppo: Fedora (per tecnologie recenti) o Ubuntu LTS (per ecosistema e driver).
• Laptop consumer con hardware very-new: Fedora / Arch / Ubuntu (kernel aggiornati).
• Utente che vuole “just work”: Linux Mint / Ubuntu LTS.
• Utente che vuole imparare: Arch o Debian (per capire meccanismi profondi).

Parte 18 — Troubleshooting base

• Kernel logs: dmesg, journalctl -k.
• Servizi: systemctl status <service>, journalctl -u <service>.
• Moduli kernel: lsmod, modprobe, dmesg per firmware messages.
• Network: ip a, ip route, ss, iptables -L o nft list ruleset.
• Filesystem: mount, lsblk, blkid, fsck (usare con cautela).
• SELinux/AppArmor: sestatus, ausearch, sealert, aa-status.

Parte 19 — Approfondimenti utili

• Compilare kernel custom: utile per hardware molto specifico o per ridurre la superficie di attacco, ma aumenta manutenzione.
• Abilitare/gestire Zswap/Zram per laptop con poca RAM.
• Usare BPF/eBPF per tracing e networking avanzato (kernel recenti).
• Usare DKMS per gestire driver di terze parti tra aggiornamenti kernel.

Parte 20 — FAQ tecniche rapide

• “Se uso la stessa versione di kernel, avrò lo stesso comportamento su tutte le distro?”
  Non necessariamente: config kernel, moduli, patch distribution-specific e versioni di librerie userland (glibc, systemd) cambiano il comportamento e le prestazioni.

• “Perché il mio laptop nuovo funziona meglio su Fedora?”
  Probabilmente perché Fedora usa kernel e driver più recenti (maggiore supporto hardware).

• “Devo temere systemd?”
  systemd è vasto ma offre API e strumenti coerenti; è importante imparare i comandi base e leggere le unit file in caso di debugging.

• “Quale filesystem scegliere?”
  Per la maggior parte: ext4 va bene; se vuoi snapshot nativi e gestione snapshot, considera btrfs; per performance grosse scritture su server, xfs può essere migliore.

Conclusione

Il kernel Linux è il nucleo tecnico che fa girare tutto.
La distro è il sistema completo che trasforma quel nucleo in un ambiente usabile.
Il desktop è l’interfaccia che vivi ogni giorno.

Capire questa distinzione ti cambia davvero il modo di leggere il mondo Linux. Non parli più di “Linux” come se fosse una sola cosa; inizi a vedere scelte, compromessi e obiettivi diversi.

Ed è qui che tutto diventa interessante: Debian sceglie prudenza, Ubuntu sceglie accessibilità, Mint sceglie comfort, Fedora sceglie modernità equilibrata, Arch sceglie controllo, openSUSE sceglie solidità ingegnerizzata.

Se tieni separate queste idee, il resto del mondo Linux smette di sembrare una giungla e comincia a sembrare una mappa.

In una frase: il kernel è il cuore, la distro è il sistema completo, il desktop è il modo in cui tu lo vivi.