Frequently asked questions (Italiano)
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.