Frequently asked questions (Italiano)

Stato della traduzione
Questo articolo è la versione tradotta di
Frequently asked questions
. Data dell'ultima traduzione: 2025-12-20. Se ci sono
cambiamenti
nella versione inglese, è possibile dare una mano a sincronizzarne la traduzione.
Articoli correlati
Arch terminology
Arch User Repository#Frequently asked questions
General troubleshooting
Generale
Cos'è Arch Linux?
Vedere l'articolo
Arch Linux
.
Perché non si dovrebbe usare Arch Linux?
Non
si dovrebbe utilizzare Arch se:
Se non si ha l'abilità, il tempo ed il desiderio di "farsi da sé" una distribuzione GNU/Linux.
Se si richiede un supporto per un'architettura che non sia x86_64.
Se si crede fermamente che una distribuzione debba essere fornita solamente di software libero come definito dalla filosofia GNU.
Se si pensa che un sistema operativo debba configurarsi da solo, funzionare sin da subito e includere un completo set di software e ambienti desktop di base già presenti sul supporto di installazione.
Se non si desidera una distribuzione GNU/Linux "rolling release" (cioè costantemente aggiornata).
se si è contenti del proprio sistema operativo attuale.
Perchè si dovrebbe usare Arch Linux?
Perché
Arch è il meglio
.
Quale architettura è supportata da Arch Linux?
Arch supporta solamente l'architettura
x86_64
(a volte chiamata amd64). Il supporto per l'architettura i686 è terminato nel novembre 2017
[1]
.
Ci sono distribuzioni derivate per l'architettura i686
[2]
e le CPU
ARM
, ciascuna con la propria comunità di utenti. Queste distribuzioni
non sono supportate
da Arch Linux.
Se si desidera che Arch supporti altre architetture, si può dare una mano con i tentativi esistenti di
porting
o iniziarne uno proprio. Si veda
Getting involved
.
Arch segue lo standard della gerarchia dei file system della Linux Foundation? (FHS)
Arch Linux segue lo standard delle
gerarchie dei file system
per i sistemi operativi utilizzando
systemd
come gestore dei servizi. Si veda
file-hierarchy(7)
per un chiarimento sulla designazione delle directory. In particolare
/bin
,
/sbin
, e
/usr/sbin
sono link simbolici a
/usr/bin
, mentre
/lib
e
/lib64
sono link simbolici a
/usr/lib
.
Sono alle prime armi con Linux. Dovrei usare Arch Linux?
Se sei un principiante e vuoi usare Arch, devi essere disposto a investire tempo nell'apprendere un nuovo sistema e accettare che Arch è progettata come una distribuzione "fai-da-te": è l’utente a costruire il proprio sistema.
Prima di chiedere aiuto, svolgi ricerche autonome consultando il Web, il forum e l’ottima documentazione fornita dall'Arch Wiki. C'è un motivo se queste risorse sono state messe a disposizione: migliaia di ore di lavoro volontario sono state dedicate alla creazione di queste informazioni di alta qualità.
Consulta anche
Arch terminology#RTFM
e la
guida all'istallazione
Arch è più adatta a server, desktop o workstation?
Arch non è sviluppata per un uso specifico, è sviluppata per una specifica
utenza
. Arch parte dal presupposto che all'utente piaccia l'approccio del
fare da sé
e che quindi sia in grado di sagomarsi il sistema operativo "attorno alle proprie esigenze". Questo fa si che virtualmente Arch possa essere usato per qualsiasi scopo. Molti utenti usano Arch sia come desktop sia come workstation e sì, archlinux.org, aur.archlinux.org e tutte le
infrastrutture
Arch girano su server Arch.
Mi piace molto Arch, ma a mio parere gli sviluppatori dovrebbero aggiungere la funzionalità X.
Fatti coinvolgere
, contribuisci con il tuo codice e le tue soluzioni alla comunità. Se il tuo lavoro verrà apprezzato dagli altri membri, può darsi che il tuo lavoro venga incluso in Arch stessa. La comunità di Arch approva e supporta la condivisione del proprio lavoro e delle proprie utility.
Quando sarà disponibile il prossimo rilascio?
Arch Linux è semplicemente un ambiente vivo per l'installazione ed i rilasci, che includono
base
meta package
ed alcuni
altri pacchetti
. I rilasci vengono fatti di solito nella prima metà di ogni mese.
Arch è un sistema operativo stabile? Avrò frequentemente problemi?
È l'
utente
a essere, in ultima analisi, responsabile della stabilità del proprio sistema rolling release. È l'utente a decidere quando aggiornare e a integrare le modifiche necessarie quando richiesto. Se l'utente chiede aiuto alla comunità, spesso lo riceve in tempi rapidi. La differenza tra Arch e altre distribuzioni, da questo punto di vista, è che Arch è davvero una distribuzione "fai-da-te"; i lamenti per i malfunzionamenti sono fuorvianti e improduttivi, poiché le modifiche provenienti da upstream non sono responsabilità degli sviluppatori di Arch.
Si veda l'articolo
System maintenance
per suggerimenti su come rendere un sistema Arch Linux il più stabile possibile.
Arch ha bisogno di più pubblicità
Arch ha già
molta pubblicità
. L'obiettivo di Arch Linux non è quello di diventare una distribuzione di massa; semmai la crescita organica e sostenibile avviene naturalmente tra la base degli utenti.
Arch ha bisogno di più sviluppatori
È possibile. Sentiti libero di mettere a disposizione il tuo tempo! Visita il
forum
, i canali IRC, e le
mailing lists
, e vedi di cosa c'è bisogno. Si veda come
Farsi coinvolgere
per ulteriori dettagli.
Installazione
Arch necessita di un installer. È presente un installer grafico?
È disponibile un installer guidato con un'interfaccia testuale. Si veda
archinstall
per i dettagli.
Ho installato Arch e ora sono a una shell! E adesso?
Leggi
General recommendations (Italiano)
.
Quale ambiente desktop o gestore delle finestre dovrei usare?
Dal momento che ce ne sono molti a disposizione, usa quello che meglio si adatta alle tue esigenze. Dai un'occhiata agli articoli
Desktop environment
e
Window manager
.
Cosa rende Arch unica tra le altre distribuzioni "minimali"?
Si veda
Arch compared to other distributions
.
Manutenzione del sistema
Consultare
System maintenance
.
Perché Internet è così lento in confronto ad altri sistemi operativi?
La rete è configurata correttamente? Controlla bene l'articolo
Network configuration
. Per impostazioni avanzate leggi
Traffic shaping
.
Uno dei kernel più utilizzati,
linux
, tende a essere più recente rispetto a quello di altre distribuzioni Linux più stabili. Per questo motivo può capitare, anche se raramente, di imbattersi in una
regressione del kernel
o in un bug del driver, in particolare se utilizzi il Wi-Fi. Tieni presente che la grande maggioranza di questi bug non è specifica di Arch Linux, poiché Arch applica solo le patch più basilari. In questi casi è necessario rivolgersi ad upstream. Vedi anche il paragrafo
Ho trovato un errore nel pacchetto X. Che dovrei fare?
.
Perché Arch utilizza tutta la mia RAM?
Fondamentalmente la RAM inutilizzata è una RAM sprecata.
Molti nuovi utenti notano come il kernel Linux gestisca la memoria in modo diverso da come sono abituati. Poiché l'accesso ai dati dalla RAM è molto più veloce rispetto a un'unità di archiviazione, il kernel memorizza nella cache i dati a cui è stato effettuato l'accesso di recente. I dati memorizzati nella cache vengono cancellati solo quando il sistema inizia a esaurire la memoria disponibile e devono essere caricati nuovi dati.
Solitamente la più comune fonte di confusione è data dal comando
free
:
$ free -h
total        used        free      shared  buff/cache   available
Mem:           377Gi        40Gi       146Gi       1.1Gi       196Gi       337Gi
Swap:          377Gi       1.1Gi       376Gi
È importante notare la differenza tra memoria
free
(libera) e
available
(disponibile). In questo esempio un sistema con 377 GiB di RAM totale sembrerebbe utilizzarne più di metà, con solo 146 GiB di memoria libera. Tuttavia 196 GiB di essi sono in
buff/cache
(buffer/cache). Ci sono ancora 337 GiB disponibili per avviare nuove applicazioni, senza bisogno di swap. Consultare
free(1)
per i dettagli. Il risultato finale? Migliori prestazioni!
Si veda
questo meraviglioso articolo
(in inglese) se si desidera approfondire. C'è anche un sito web dedicato a eliminare questa confusione
https://www.linuxatemyram.com/
.
Dov'è finito tutto il mio spazio libero?
La risposta a questa domanda dipende esclusivamente dal proprio sistema.  Ci sono alcuni
validi strumenti
che possono aiutare a trovare la risposta.
Perché non riesco a fare il login?
Hai digitato la password in modo errato o annullato un comando
sudo
per tre volte in quindici minuti? In tal caso hai attivato un meccanismo di prevenzione contro gli attacchi a forza bruta: per maggiori dettagli vedi
Security#Lock out user after three failed login attempts
.
Arch si prende dati personali?
Risposta breve: No.
In dettaglio:
Gli utenti di NetworkManager dovrebbero sapere che questo esegue
controlli automatici di connettività
. L'URL di connettività predefinito è fornito da Arch e viene impegnato a non registrare alcun accesso.
I
client Network Time Protocol
, nella loro configurazione predefinita, utilizzano un
pool di server NTP
fornito dall'NTP Pool Project (secondo le sue regole).
Come spiegato nella nota in
pacman/Package signing#Upgrade system regularly
, un timer di systemd viene eseguito una volta alla settimana per aggiornare le nuove firme delle chiavi già fidate. Anche in questo caso non viene registrato alcun accesso.
Lo strumento di aggiornamento della lista dei mirror
Reflector
scarica la lista dei mirror da
archlinux.org
. Per l'ambiente live di installazione è abilitato di default e si avvia non appena viene stabilita una connessione di rete.
È comunque possibile inviare dati volontariamente contribuendo al progetto
pkgstats
, che raccoglie dati anonimi sulla popolarità dei pacchetti per aiutare gli sviluppatori di Arch a stabilire le priorità.
Gestione pacchetti
Per ulteriori risposte consultare le pagine
pacman
,
pacman/Tips and tricks
e
Official repositories
.
Ho trovato un errore nel pacchetto X. Che dovrei fare?
In primo luogo, bisogna capire se questo errore è qualcosa che il team Arch può sistemare. Spesso non è così (ad es., che Firefox vada in crash può essere colpa del gruppo Mozilla) e si chiama
errore upstream
: si veda
Bug reporting guidelines#Upstream or Arch?
.  Se invece è un problema di Arch, c'è una serie di passi che si possono seguire:
Cerca informazioni sul forum.  Controlla se qualcun altro lo ha notato.
Posta un
bug report
con informazioni dettagliate sull'
Arch Linux bug tracker in GitLab
.
Se ti va, scrivi un post sul forum spiegando in dettaglio il problema e il fatto che lo hai già segnalato. Questo eviterà che molte persone segnalino lo stesso errore.
I pacchetti di Arch devono seguire una convenzione di denominazione univoca. ".pkg.tar.zst" è troppo lunga e/o fonte di confusione.
Questo è stato discusso sulla mailing list di Arch. Alcuni hanno proposto l'estensione
.pac
, ma non ci sono piani per cambiare l'estensione dei pacchetti. Come ha scritto Tobias Kieslich, uno degli sviluppatori di Arch: "Un pacchetto
è
un tarball [
compresso
]! E può essere aperto, esaminato e manipolato da qualsiasi applicazione compatibile con tar. Inoltre, il tipo MIME viene rilevato correttamente dalla maggior parte delle applicazioni."
Pacman ha bisogno di una libreria così che le altre applicazioni possano facilmente accedere alle informazioni sui pacchetti
Pacman è un front-end di
libalpm(3)
, la libreria "Arch Linux Package Management", che permette di scrivere front-end alternativi, come quelli grafici.
Pacman ha bisogno della funzione X!
Se pensi che l'idea meriti, puoi provare a parlarne su
pacman-dev
. Puoi anche controllare su
https://gitlab.archlinux.org/pacman/pacman/-/issues
la lista delle funzioni richieste.
Comunque il miglior modo per ottenere una caratteristica aggiuntiva per pacman o Arch Linux è implementarla da solo. La patch o il codice potrebbero essere ufficialmente accettati o meno, ma forse altri apprezzeranno, proveranno e miglioreranno il tuo contributo.
Ho appena installato il pacchetto X. Come lo avvio?
Se stai usando un ambiente desktop come
KDE
o
GNOME
, il programma dovrebbe automaticamente essere mostrato nel menu se è dotato di un
file desktop
. Se stai cercando di avviare il programma da un terminale e non sai il nome del file binario, esegui:
$ pacman -Qlq
package_name
| grep /usr/bin/
Perché nei repository ufficiali è presente una sola versione di ciascuna libreria condivisa?
Diverse distribuzioni, come Debian, mantengono più versioni della stessa libreria condivisa sotto forma di pacchetti distinti:
libfoo1
,
libfoo2
,
libfoo3
e così via. In questo modo è possibile installare sullo stesso sistema applicazioni compilate contro versioni differenti di
libfoo
.
In una distribuzione come Arch, invece, sono supportate ufficialmente solo le versioni più recenti. Eliminando il supporto per software obsoleto, i manutentori possono dedicare più tempo a garantire che le versioni aggiornate funzionino come previsto. Non appena una nuova versione di una libreria condivisa arriva da upstream, viene aggiunta ai repository e i pacchetti interessati vengono ricompilati per utilizzarla.
Cosa succede se eseguo un aggiornamento completo del sistema e viene aggiornata una libreria condivisa, ma non le applicazioni che dipendono da essa?
Questo scenario non dovrebbe verificarsi affatto. Se un’applicazione chiamata
foobaz
si trova in uno dei repository ufficiali e viene compilata correttamente contro una nuova versione di una libreria condivisa chiamata
libbaz
, verrà aggiornata insieme a
libbaz
. Se invece non si compila correttamente, il pacchetto
foobaz
avrà una dipendenza con versione specifica (ad esempio
libbaz 1.5
) e verrà rimosso da pacman durante l’aggiornamento di
libbaz
, a causa del conflitto.
Se
foobaz
è un pacchetto che hai compilato tu stesso e installato dall’AUR, devi ricompilarlo contro la nuova versione di
libbaz
. Se la compilazione fallisce, segnala il bug agli sviluppatori di
foobaz
.
È possibile che ci sia un aggiornamento maggiore del kernel nei repository e che alcuni pacchetti dei driver non vengano aggiornati?
No, è impossibile. Gli aggiornamenti maggiori del kernel  (ad es. da
linux 3.5.0-1
a
linux 3.6.0-1
) sono sempre accompagnati dalla ricompilazione di tutti i pacchetti dei driver supportati dal kernel. Al contrario, se si usa nel proprio sistema un pacchetto driver non supportato (ad es. come quelli da
AUR
), allora qualcosa potrebbe andare storto se non viene ricompilato per il nuovo kernel. Gli utenti sono responsabili dell'aggiornamento di qualunque pacchetto driver non supportato che possano aver installato.
Cosa devo fare prima di aggiornare?
Segui la sezione
System maintenance#Upgrading the system
.
È stato rilasciato l'aggiornamento di un pacchetto, ma pacman dice che il sistema è aggiornato
I mirror
pacman
non vengono sincronizzati immediatamente. Potrebbero essere necessarie più di 24 ore prima che un aggiornamento sia disponibile. Le uniche opzioni sono: sii paziente o usa un altro mirror.
MirrorStatus
può aiutarti a trovare un mirror aggiornato.
Il progetto upstream X ha rilasciato una nuova versione. Quanto tempo sarà necessario perché il pacchetto Arch sia aggiornato a quella nuova versione?
Gli aggiornamenti dei pacchetti verranno rilasciati quando saranno pronti. La quantità di tempo specifica può essere da poche ore dopo il rilascio di upstream di un aggiornamento di correzione di bug minore fino a diverse settimane dopo l'aggiornamento principale di un grande gruppo di pacchetti. La quantità di tempo dalla nuova versione di un upstream al rilascio di un nuovo pacchetto da parte di Arch dipende dai pacchetti specifici e dalla disponibilità dei manutentori del pacchetto. Inoltre, alcuni pacchetti trascorrono del tempo nel repository
testing
e ciò può allungare il tempo prima che un pacchetto venga aggiornato. I
Package maintainer
tentano di lavorare rapidamente per portare aggiornamenti stabili ai repository. Se trovi un pacchetto nei repository ufficiali che non è aggiornato, vai alla
pagina web
di quel pacchetto e contrassegnalo.
Se ho bisogno di una versione precedente di una libreria installata, posso semplicemente creare un collegamento simbolico alla versione più recente?
Se sei fortunato, potrebbe funzionare, ma per un po'. In ogni caso, non è una soluzione corretta, perché:
Le librerie non cambiano versione a caso: l'API/ABI probabilmente sarà cambiata (magari con parti rimosse), e il fatto che tali cambiamenti influiscano sull'uso dipende solo dalla fortuna.
Il collegamento simbolico non verrebbe tracciato dal gestore di pacchetti. I principianti che iniziano subito a smanettare con i file di libreria di sistema rischiano maggiormente di introdurre modifiche indesiderate che non sono in grado di diagnosticare o correggere, cosa da cui un gestore di pacchetti normalmente protegge.
Una variante leggermente diversa, vale a dire copiare manualmente la vecchia libreria nel filesystem senza che sia tracciata, verrebbe dimenticata e potrebbe avere vulnerabilità di sicurezza che non verrebbero mai individuate né corrette.
Al contrario, è preferibile utilizzare (o creare) un
pacchetto di compatibilità
, che fornisca la versione richiesta della libreria.
64-bit
Come posso determinare se il mio processore è compatibile con x86_64?
Se il tuo processore è compatibile con
x86_64
, avrai il flag
lm
(
long mode
) in
/proc/cpuinfo
. Per esempio,
$ grep -w lm /proc/cpuinfo
Sotto Windows, puoi usare il freeware
CPU-Z
che ti aiuta a determinare se la tua CPU è compatibile a 64 bit. Le CPU con il set di istruzioni AMD "AMD64" o la soluzione Intel "EM64T" dovrebbero essere compatibili con le versioni x86_64 e i pacchetti binari.
Perchè 64-bit?
Nella maggior parte dei casi è più veloce e, come ulteriore vantaggio, è anche intrinsecamente più sicuro grazie alla natura dell'
Address Space Layout Randomization (ASLR)
in combinazione con il
Position-Independent Code (PIC)
e l'
NX bit
, che non è disponibile nel kernel i686 standard a causa della disattivazione del
Physical Address Extension (PAE)
. Se il tuo computer ha più di 4 GiB di RAM, solo un sistema operativo a 64 bit sarà in grado di utilizzarla completamente.
Gli sviluppatori, inoltre, tendono sempre più a trascurare il 32 bit (considerato "legacy"), poiché le CPU x86 moderne supportano normalmente le estensioni a 64 bit.
Ci sarebbero molti altri motivi per dirti di evitare il 32 bit, ma tra kernel, userspace e singoli programmi sarebbe semplicemente impraticabile elencare ogni singolo aspetto in cui oggi il 64 bit si comporta decisamente meglio.