Frequently asked questions (Italiano)
Generale
Cos'è Arch Linux?
Vedere l'articolo Arch Linux.
Perché non dovrei utilizzare 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 una architettura che non sia x86_64.
- Se credi fermamente che una distribuzione debba essere fornita solamente da software libero come definito dalla filosofia GNU.
- Se pensi che un sistema operativo debba configurarsi da solo, funzionare sin da subito, ed includa 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' (costantemente aggiornata).
- se si è contenti del proprio sistema operativo attuale.
Perchè dovrei voler utilizzare Arch Linux?
Perché Arch è il meglio
Quale architettura è supportata da Arch Linux?
Arch supporta solamente l'architettura x86_64 (comunemente chiamata amd64). Il supporto per l'architettura i686 è terminato nel novembre 2017 [1].
Esistono dei canalinon ufficiali per l'architettura i686 [2] e processori ARM [3], con la loro comunità. [4]
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 si è alle prime armi e si vuole utilizzare Arch, bisogna tenere a mente che bisogna investire del tempo per comprendere un nuovo sistema, e accettare che Arch è stata progettata come una distribuzione che bisogna costruire da soli, e quindi l'utente si deve assemblare il proprio sistema.
Prima di chiedere aiuto, bisognerebbe essere indipendenti nella ricerca delle soluzioni sul Web, sul forum e verificando la superba documentazione fornita da Arch wiki. ecco un motivo per cui queste risorse sono state messe a tua disposizione. Molti volontari hanno speso centinaia di ore per compilare questa eccellente documentazione.
Si consulti 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 i dev 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 rilasciati di solito nella prima metà di ogni mese
Arch è un sistema operativo stabile? Avrò frequentemente problemi
L' utente è l'ul6timo responsabile per la stabilità del proprio sistema rolling realease. L'utente decide quando aggiornare e come effettuare il merge delle nuove caratteristiche. C'è da sottolineare che la comunità di arch è sempre molto disponibile ad aiutare chi è in difficoltà nello svolgere questa operazione. Arch si contraddistingue da altre distribuzioni proprio perché rende davvero una distribuzione fatta da sé, i reclami di rottura sono fuorvianti e improduttivi, poiché le modifiche a monte non sono responsabilità di Arch devs.
Si deva l'articolo System maintenance per suggerimenti su come rendere un sistema Arch Linux il più stabile possibile.
Arch ha bisogno di più pubblicità
Già così Arch ha molta pubblicità. L'obiettivo di Arch Linux non è essere grande; piuttosto, 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?
Arch utilizza un programma di installazione con una interfaccia testuale chiamata Arch Installation Framework (AIF). Dopo che l'ultimo manutentore ha lasciato lo script Arch Install è stato deprecato in favore di arch-install-scripts
Sin dal 1° Aprile 2021, Arch ha nuovamente un programma di installazione. Vedere archinstall per i dettagli.
Ho installato Arch e ora sono a una shell! E adesso?
Vedere General recommendations (Italiano)
Quale ambiente desktop o gestore delle finestre posso utilizzare?
Dal momento che molti sono a tua disposizione, usa quello che meglio si adatta alle tue esigenze. Dai un'occhiata agli articoli Desktop environment (Italiano) e Window manager (Italiano).
Cosa rende Arch unica tra le altre distribuzioni 'minimali'?
vedere Arch comparato con le altre distribuzioni.
Manutenzione del sistema
Consultare System maintenance
Perchè Internet è così lento in confronto ad altri sistemi operativi?
La rete è configurata correttamente? Controllare bene l'articolo Network configuration (Italiano).
Si noti inoltre che Arch Linux non applica alcun controllo sull'utilizzo del traffico internet (traffic shaping). È quindi possibile che un programma utilizzi completamente la banda disponibile (ad esempio client P2P o classiche connessioni client-server) causando lag, timeout e ping molto elevati. In ausilio può essere installato un firewall come Shorewall o Vuurmuur; si noti che esistono anche degli script statici per iproute2 (come ad esempio questo derivato di Wondershaper) che svolgono proprio questo compito.
Perchè Arch utilizza tutta la mia RAM?
Fondamentalmente la RAM inutilizzata e' 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 e' data dal comando free :
$ free -h
total used free shared buff/cache available Mem: 2.8Gi 1.1Gi 283Mi 224Mi 1.4Gi 1.2Gi Swap: 3.0Gi 881Mi 2.1Gi
E' importante notare la differenza tra memoria free e available. In questo esempio un laptop con 2.8 Gib di RAM totale sembrerebbe utilizzarne la maggior parte con solo 283 Mib di memoria libera. Tuttavia 1.4 Gib di essi sono in buff/cache. Ci sono ancora 1.2 Gib disponibili per avviare nuove applicazioni, senza bisogno di swap. Consultare free(1) per i dettagli. Il risultato finale? Migliori prestazioni!
Vedi questo articolo ( in inglese) se vuoi 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 tools che possono aiutare molto.
Gestione Pacchetti
Consultare le pagine pacman (Italiano), pacman/Tips and tricks e Official repositories (Italiano) per avere risposta.
Ho trovato un errore nel pacchetto X. Che dovrei fare?
In primo luogo, devi capire se questo errore è qualcosa che il team Arch può sistemare. Qualche volta non è così (che Firefox vada in crash può essere colpa del gruppo Mozilla) - questo è chiamato un upstream error. Se è un problema di Arch , c'è una serie di passi che puoi seguire:
- Cerca sui forum per informazioni. Controlla se qualcun altro lo ha notato.
- Posta un bug report con informazioni dettagliate su https://bugs.archlinux.org.
- Se preferisci, scrivi un post sul forum spiegando in dettaglio il problema a il fatto che hai già riportato.Questo aiuterà molte persone dal fare un report dello stesso errore.
I pacchetti di Arch hanno bisogno di usare un'unica estensione. .pkg.tar.gz e .pkg.tar.xz sono troppo lunghe e/o poco chiare
Questo è stato discusso sulla Arch mailing list. Alcuni hanno proposto una estensione .pac. Da quanto si sa non c'è intenzione di cambiare l'estensione dei pacchetti. Come ha detto Tobias Kieslich, uno degli sviluppatori di Arch, "Un pacchetto è un gzipped [xz] tarball! E può essere aperto, ispezionato e manipolato da ogni applicazione che gestisca i tar. Inoltre, il tipo mime è automaticamente e correttamente rilevato 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 a libalpm(3), la libreria di mantenimento pacchetti di Arch Linux . Questa libreria permette di scrivere un alternativo front-end (per esempio, front-end grafico).
Pacman ha bisogno della caratteristica X!
Se tu pensi che l'idea meriti e non violi questi ideali di semplicità discutilo qui. Potresti anche controllare https://bugs.archlinux.org/index.php?project=3 per una lista di caratteristiche richieste.
Comunque il miglior modo di ottenere una caratteristiche aggiuntiva per Pacman o Arch Linux è implementartela da solo. Nessuno ti dirà che la patch sarà ufficialmente accettata ma altri apprezzeranno e testeranno il tuo contributo.
Ho appena installato il pacchetto X. Come lo avvio?
Se tu stai usando un ambiente desktop come KDE o GNOME, il programma dovrebbe automaticamente mostrarsi nel tuo menu. Se stai cercando di avviare il programma da un terminale e non sai il nome del file binario prova a eseguire
$ pacman -Qlq package_name | grep /usr/bin/
Perchè nei repositories c'è solo una versione per ogni libreria?
Molte distribuzioni, come ad esempio Debian, mantengono nei propri repositories più versioni dello stesso pacchetto, ad esempio libfool1, libfool2, libfool3 ecc. In questo modo è possibile compilare il proprio sistema in modo differente in base alla versione di libreria installata.
Nel caso di una distribuzione come Arch, sono ufficialmente supportate solo le ultime versioni stabili dei pacchetti. Eliminando il supporto per software obsoleto, i manutentori dei pacchetti sono in grado di dedicare più tempo a garantire che le versioni più recenti funzionino come previsto. Non appena una nuova versione di una libreria condivisa diventa disponibile dall'upstream, viene aggiunta ai repository e i pacchetti interessati vengono ricostruiti per utilizzare la nuova versione.
Cosa succede se aggiornando il sistema ricevo aggiornamenti per una libreria e non per le sue dipendenze?
Questa è una situazione praticamente impossibile. Supponiamo di avere un'applicazione il cui pacchetto risponde il nome di foobaz, compilata dal manteiner con la libreria libbaz, se un aggiornamento di libbaz non crea problemi a foobar, pacman aggiornerà libbaz tranquillamente. In caso contrario, sarà premura del manteiner, inserire una dipendenza di versione a foobar, ad esempio libbaz=1.5, e verrà rimosso da pacman durante l'aggiornamento di libbaz, a causa di un conflitto.
Se foobaz è invece un pacchetto compilato da AUR, si dovrà procedere manualmente alla ricompilazione quando la nuova libreria libbaz viene installata sul sistema. Se il pacchetto dovesse presentare errori di compilazione, farlo presente al manteiner di foobar.
È possibile che ci sia un aggiornamento di versione del kernel e al tempo stesso non ci sia un aggiornamento adeguato dei drivers?
No, impossibile. Ogni qualvolta il kernel viene aggiornato (Es. da linux 3.5.0-1 a linux 3.6.0-1) viene ricreata l'immagine del kernel con, di conseguenza, la ricompilazione dei driver. In altre parole, se si usano pacchetti non supportati come ad esempio da AUR, l'utente deve essere in grado di gestirne l'upgrade e la necessaria ricompilazione. Gli utenti sono responsabili dell'aggiornamento di eventuali pacchetti di driver non supportati che hanno installato.
Cosa devo fare prima di aggiornare?
Segui la sezione System maintenance#Upgrading the system.
È stato rilasciato un aggiornamento del 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 identificare un mirror aggiornato.
Il progetto upstream X ha rilasciato una nuova versione. Quanto tempo impiegherà il pacchetto Arch per l'aggiornamento 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, quindi questo può prolungare 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 collegare simbolicamente alla versione più recente?
Se sei fortunato, potrebbe funzionare, per un po'. Indipendentemente da ciò, non è una soluzione adeguata, perché:
- Le librerie non cambiano le versioni in modo casuale: è probabile che l'API/ABI sia cambiata (possibilmente con i bit rimossi) e se tali modifiche influiscono sull'utilizzo è solo una questione di fortuna.
- Il collegamento simbolico non verrebbe tracciato da un gestore di pacchetti. I neofiti che cercano immediatamente di hackerare i file della libreria di sistema corrono il rischio maggiore di apportare modifiche indesiderate che non possono diagnosticare/riparare, da cui un gestore di pacchetti aiuta a proteggersi.
- Una leggera alternativa al dump del vecchio file di libreria nel filesystem, non tracciato, verrebbe dimenticata e non verrebbero notati/riparati potenziali bug di sicurezza.
Invece, ad es. usa/scrivi un pacchetto AUR, che fornisce la versione della libreria richiesta.
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, l'utilizzo del freeware CPU-Z 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?
È più veloce nella maggior parte delle circostanze e come bonus aggiuntivo è anche intrinsecamente più sicuro grazie alla natura di Randomizzazione del layout dello spazio degli indirizzi (ASLR) in combinazione con Codice indipendente dalla posizione (PIC) e il NX Bit che non è disponibile nel kernel stock i686 a causa della 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 utilizzarlo completamente.
I programmatori tendono anche a preoccuparsi sempre meno dei 32 bit ('legacy') poiché le 'nuove' CPU x86 in genere supportano le estensioni a 64 bit.
Ci sono molte altre ragioni che potremmo elencare qui per dirti di evitare i 32 bit, ma tra il kernel, lo spazio utente e i singoli programmi non è semplicemente possibile elencare fino all'ultima cosa che 64 bit fa molto meglio in questi giorni.