Perché il file system Linux confonde gli utenti Windows (ma è geniale)

Molti utenti provenienti da Windows, una volta avviata l’esperienza con “il pinguino”, rimangono spiazzati dalla struttura articolata a livello di file system Linux. In Windows il modello è tendenzialmente centralizzato: i file binari e le librerie di un’applicazione risiedono in C:\Program Files (%programfiles% o %programfiles(x86)%), le impostazioni personali in %appdata% (con %localappdata% che afferisce allo stesso percorso di base), le configurazioni di sistema nel Registro (accessibile con l’utilità regedit e da riga di comando con reg.exe). Al contrario, in Linux i file sembrano “sparpagliati” in più directory. Questa percezione, che a prima vista può sembrare un difetto, nasconde in realtà un’architettura logica raffinata, nata da esigenze di portabilità, sicurezza, modularità e manutenzione scalabile.

In questo articolo analizzeremo le ragioni storiche e tecniche di queste scelte, illustrando come il modello Linux per il file system non sia casuale, ma il risultato di decenni di evoluzione nel mondo Unix. Quali benefici offre in scenari che vanno dal desktop fino ai grandi sistemi distribuiti?

Origini del modello: Unix e la separazione dei ruoli

Il file system Linux deriva direttamente dalla filosofia Unix, che aveva due principi cardine:

• Tutto è un file: dispositivi, processi, configurazioni e file reali sono trattati con la stessa interfaccia.
• Separazione delle responsabilità: un file binario, un log e un file di configurazione non devono coesistere nello stesso spazio, per ridurre conflitti e facilitare la gestione.

Quest’impostazione ha favorito la possibilità di montare porzioni diverse del sistema su partizioni separate, rendendo Linux estremamente adattabile a scenari di sicurezza (filesystem in sola lettura), cluster distribuiti e containerizzazione.

In un altro articolo parliamo della vera storia di Linux e del rapporto con Unix.

La gerarchia del file system Linux

Il file system Linux segue le convenzioni definite dal Filesystem Hierarchy Standard (FHS). Vediamo le principali aree, distinguendo tra directory di sistema, directory utente, punti di montaggio e file system virtuali.

Directory di sistema

Su Linux non esiste una vera distinzione tra “file di sistema” e “file di programma” quando le applicazioni sono installate come pacchetti. Il sistema di base, quello che si ottiene subito dopo l’installazione, è semplicemente un insieme di pacchetti, mentre le varie “versioni” o “flavor” della distribuzione (come Fedora KDE, Xubuntu, ecc.) altro non sono che insiemi diversi di pacchetti preinstallati come base di partenza. Nel file system Linux possiamo notare la presenza delle seguenti directory principali.

/usr – file statici: binari, librerie, risorse, font.

/var – file variabili: log, spool, database temporanei.

/etc – configurazioni di sistema, leggibili in chiaro.

/boot – kernel, initramfs e file necessari all’avvio.

Un server enterprise può ad esempio montare /usr in sola lettura per impedire modifiche ai file binari.

I backup possono concentrarsi su /etc e /var, mentre /usr può essere ricostruito dal package manager.

Sui sistemi Linux immutabili come Fedora Silverblue o Vanilla OS, /usr è montato in sola lettura e gestito come un’immagine atomica. Ciò significa che il contenuto della cartella è trattato come un’unica unità indivisibile: non si modificano direttamente i singoli file dentro /usr. Aggiornamenti, rollback o sostituzioni avvengono su tutta l’immagine contemporaneamente, invece che file per file. Ciò garantisce coerenza del sistema e facilità di ripristino: se qualcosa va storto, è possibile tornare all’immagine precedente senza rischiare di lasciare file sparsi o incoerenti.

La directory /boot è mantenuta separata perché a volte deve essere isolata. Ad esempio, se la maggior parte del disco è criptata, /boot deve ovviamente risiedere su di una partizione non crittografata, così il kernel può avviarsi e decifrare il resto dell’unità dopo aver richiesto la password di accesso.

Directory utente

Linux prevede l’utilizzo di tutta una serie di directory all’interno delle quali gli utenti possono salvare i propri file senza che il gestore di pacchetti intervenga direttamente (anche se altri strumenti di sistema possono modificarli). Le principali cartelle di questo tipo sono le seguenti:

/home – lo spazio personale degli utenti.

/root – la home dell’amministratore, separata dal resto per motivi di sicurezza.

/srv – file e directory dedicate ai servizi (es. server web o FTP).

La struttura è cruciale in ambienti multi-utente e distribuiti: le home possono risiedere su NAS condivisi, permettendo a un utente di accedere ai propri file da più server, mentre la directory root resta legata a ciascuna macchina.

Punti di montaggio temporanei

Si tratta per lo più di directory vuote (o contenenti altre directory vuote) create per montare partizioni, dispositivi rimovibili, ISO e altri supporti che non avrebbero senso in altre parti del file system, di solito in maniera temporanea:

/mnt – destinato ai montaggi manuali.

/media – usato per i dispositivi rimovibili (i.e. chiavette USB).

Negli ambienti desktop o desktop environment, queste directory sono spesso mantenute non visibili dai file manager, ma rimangono fondamentali per l’amministrazione del sistema via CLI (interfaccia a riga di comando).

L’interfaccia grafica di solito espone un’icona cliccabile che porta direttamente al contenuto di ciascuna unità rimovibile, senza bisogno di navigare manualmente nel percorso corrispondente.

Posizioni virtuali

Nel file system Linux ci sono delle cartelle i cui contenuti “non esistono realmente” sull’unità di memorizzazione. Come abbiamo anticipato in precedenza, una delle grandi potenzialità di Linux, particolarmente apprezzata, è che tutto è considerato un file: sia i file reali su disco, sia i file virtuali.

I programmi che possono scrivere su un file possono quindi scrivere anche su file virtuali, come unità, terminali o file di controllo dei dispositivi:

/proc – rappresentazione dei processi e delle configurazioni del kernel.

/sys – parametri e stato dei dispositivi.

/dev – device file (es. /dev/sda, /dev/tty).

/run e /tmp – file temporanei, spesso in RAM.

Questi spazi non risiedono su disco ma forniscono interfacce dinamiche. Senza di essi, strumenti come ps, top o systemd non potrebbero funzionare.

Vale la pena spendere due parole sul contenuto della cartella /dev che ospita i riferimenti a tutti i dispositivi del sistema. Ci si entra puntualmente in contatto, ad esempio, al momento del flashing di una chiavetta USB: l’applicazione permette di selezionare qualcosa come /dev/sdb (il secondo drive SATA), spesso accompagnato da un nome più leggibile che corrisponde a quello commerciale del supporto rimovibile.

Directory speciali

Ci sono casi in cui i programmi preferiscono essere installati in stile “Program Files”, creando una grande directory con molti file. Succede sia nel caso di software portato su Linux senza applicare le migliori linee guida, sia per le applicazioni che richiedono grandi quantità di dati per funzionare.

Per queste esigenze esiste la directory /opt. Il package manager di solito non interviene su /opt, ma gli installer grafici di software proprietario spesso la scelgono come posizione predefinita.

Per installazioni di grandi dimensioni, /opt semplifica la gestione: alcune sottodirectory o l’intera cartella possono essere collocate su un disco o una partizione separata. Inoltre, permette di montare il contenuto in rete, utile in scenari con più computer che devono accedere allo stesso software proprietario tramite un server NFS locale.

Ancora, la cartella /usr/local funge da alloggio per il software installato manualmente dall’amministratore, compilato da sorgente o fuori dal package manager.

Il microcosmo di /usr

La directory /usr è la più popolata e spesso la più fraintesa. Al suo interno troviamo:

/usr/bin – eseguibili per gli utenti.

/usr/lib – librerie condivise e risorse di sistema.

/usr/share – dati non eseguibili, come documentazione, font, localizzazioni.

/usr/include – file di intestazione per lo sviluppo in C e C++.

Le librerie sono centralizzate perché la maggior parte dei programmi è collegata dinamicamente: se una libreria è usata da 10 eseguibili diversi, esiste solo una volta sul sistema. Gli eseguibili sono raggruppati in un unico percorso per semplificare la ricerca da parte della shell.

Ogni famiglia di distribuzioni gestisce in modo leggermente diverso le librerie e i file di supporto:

• Debian/Ubuntu – /usr/lib/<arch> per librerie multi-architettura.
• Fedora/Red Hat – fa distinzione tra /usr/lib (32 bit) e /usr/lib64 (64 bit).
• Arch Linux – /usr/lib (64 bit) e /usr/lib32 (32 bit).

Directory /bin, /sbin e compatibilità

Storicamente, i binari essenziali per l’avvio del sistema vivevano nelle cartelle /bin e /sbin. Oggi, molte distribuzioni hanno unificato queste directory tramite symlink, semplificandone la gestione. Ad esempio, su Fedora /usr/sbin è un link simbolico a /usr/bin.

Lo spazio utente e lo standard XDG

I programmi Linux hanno bisogno di salvare dati specifici per ciascun utente. Generalmente lo fanno nella home dell’utente, ad esempio /home/mario, $HOME o semplicemente ~.

In passato non esisteva una struttura definita: le directory che iniziavano con un punto (.) erano considerate “nascoste”, quindi ogni programma creava una propria cartella all’interno della home per salvare tutto, ad esempio: ~/.vim, ~/.steam, ~/.ssh e via dicendo. Una consuetudine del genere, tuttavia, ha portato ad ambienti disordinati e difficili da mantenere.

Negli anni seguenti si è cercato di standardizzare i percorsi in cui i programmi salvano i dati per l’utente, creando il cosiddetto sistema di directory XDG. Il sistema rispecchia la gerarchia del file system, con nomi più moderni e una struttura più efficace:

~/.config – configurazioni.

~/.local/share – dati statici.

~/.local/state – dati variabili persistenti.

~/.cache – file temporanei e di grandi dimensioni.

/run/user/<uid> – file temporanei in RAM legati alla sessione utente.

Sempre più software moderni aderiscono a quest’impostazione, garantendo coerenza e portabilità.

Nuovi sistemi per la distribuzione software e la containerizzazione

Con l’avvento di Flatpak, Snap e AppImage, le applicazioni desktop hanno iniziato a usare directory dedicate (ad esempio, ~/.var/app/<nome_app> nel caso di Flatpak), isolando dati e configurazioni. Questa filosofia “per-app” richiama il modello Windows/macOS, ma senza abbandonare la logica modulare di Linux.

Flatpak

Flatpak è un sistema di containerizzazione per applicazioni desktop che consente di eseguire programmi isolati dal resto del sistema. Ogni applicazione Flatpak è eseguita in una sandbox, con accesso limitato a file e risorse di sistema.

• Directory dati: Flatpak salva dati e configurazioni specifiche dell’utente, come osservato in precedenza, nella directory ~/.var/app/<nome_app>, separando così i file dell’applicazione dai dati tradizionali dell’utente (~/.config, ~/.local/share).
• Vantaggi: isolamento delle dipendenze, facilità di aggiornamento, riduzione dei conflitti tra librerie di sistema e librerie richieste dalle applicazioni.
• Runtime: Flatpak utilizza “runtime” condivisi, pacchetti che contengono librerie di base comuni a più applicazioni, riducendo lo spazio su disco e migliorando la coerenza delle librerie.

Snap

Snap, sviluppato da Canonical, adotta un modello simile a Flatpak, ma con alcune differenze chiave:

• Directory dati: Snap salva i dati dell’applicazione in ~/snap/<nome_app>/current per ciascun utente.
• Aggiornamenti automatici: le applicazioni Snap sono aggiornate in background, assicurando sempre l’ultima versione stabile.
• Isolamento: anche Snap utilizza la sandboxing tramite AppArmor per limitare l’accesso dell’applicazione a file e risorse di sistema.
• Vantaggi e svantaggi: Snap garantisce aggiornamenti continui e gestione centralizzata delle applicazioni, ma può occupare più spazio su disco rispetto a Flatpak a causa della duplicazione dei runtime.

AppImage

AppImage è un formato di distribuzione “portabile” che non richiede installazione.

• Funzionamento: un singolo file .AppImage contiene tutto ciò che serve per eseguire l’applicazione, comprese le librerie. Basta renderlo eseguibile e avviarlo.
• Directory dati: poiché non c’è un vero processo di installazione, le configurazioni vengono generalmente salvate nelle directory utente standard (~/.config, ~/.local/share). Alcune applicazioni AppImage moderne supportano anche directory dedicate simili a Flatpak.
• Vantaggi: facilità di esecuzione e portabilità tra distribuzioni, nessuna dipendenza esterna richiesta.

AppInstaller

AppInstaller è un approccio presente in alcune distribuzioni Linux, pensato per fornire un’esperienza simile a quella dei pacchetti containerizzati, ma integrata con i gestori di pacchetti tradizionali:

• Isolamento opzionale: AppInstaller permette di installare applicazioni in sandbox opzionali, decidendo se utilizzare directory dedicate o integrare i dati nella home dell’utente.
• Compatibilità: supporta sia applicazioni containerizzate (come Flatpak) sia pacchetti tradizionali (.deb, .rpm).
• Focus utente: semplifica l’installazione e la rimozione di applicazioni senza richiedere conoscenze avanzate di gestione del sistema.

Conclusioni

Quello che a un utente Windows appare come un sistema “dispersivo” corrisponde in realtà a un file system strutturato con un’architettura precisa, pensata per gestire scenari complessi e diversificati.

La separazione dei file non è un retaggio del passato, ma il fondamento che consente a Linux di funzionare allo stesso modo su un laptop, un supercomputer o un cluster di container Kubernetes.

La sua forza sta nella modularità: i file non vivono tutti nello stesso contenitore perché ogni categoria ha esigenze e cicli di vita differenti. È proprio questa “distribuzione controllata” a rendere Linux affidabile, sicuro e scalabile.

Se aveste ancora dei dubbi o se il nostro articolo non vi fosse piaciuto, basta che digitiate man hier nella finestra del terminale Linux: troverete tutte le informazioni che state cercando.