Frequently asked questions (Français)
Generalités
Qu'est-ce qu'Arch Linux?
Voir l'article Arch Linux (Français).
Pourquoi Arch ne me conviendrait pas?
Vous ne voudrez probablement pas utiliser Arch si :
- Vous n'avez ni les compétences ni le temps ni l'envie d'utiliser une distribution GNU/Linux de type «faites le vous-même»
- Vous avez besoin de la prise en charge d'architectures autres que x86_64
- Vous êtes très attaché à utiliser une distribution qui ne fournit que des logiciels libres selon la définition GNU
- Vous pensez qu'un système d'exploitation devrait se configurer tout seul, fonctionner dès le départ et inclure un ensemble complet de logiciel par défaut ainsi qu'un environnement de bureau sur le support d'installation.
- Vous ne voulez pas d'une distribution GNU/Linux en «rolling release».
- Vous êtes heureux de votre système d'exploitation actuel.
Quelles sont les architectures prises en charge par Arch ?
Arch ne prend en charge que l'architecture x86_64 (parfois appelée amd64). La prise en charge de l'architecture i686 a été abandonné en Novembre 2017 .
Il existe des ports non-officiels pour l'architecture i686 et pour les processeurs ARM , chacun avec leur propre canaux communautaires.
Arch respecte-t-elle la norme FHS (Filesystem Hierarchy Standard) de la Fondation Linux?
Arch Linux suit le file system hierarchy grace à Systemd. Voir file-hierarchy(7) pour une explication de chaque répertoire ainsi que leurs désignations. Notez que, /bin, /sbin, et /usr/sbin sont des liens symboliques vers /usr/bin, et ainsi que sont des liens symboliques vers .
Je suis débutant avec Linux. Arch est-elle adaptée pour moi?
Si vous êtes un débutant et que vous voulez utiliser Arch, vous devez être prêt à investir du temps dans l'apprentissage d'un nouveau système, et accepter qu'Arch est conçu comme une distribution do-it-yourself ; c'est l'utilisateur qui assemble le système.
Avant de demander de l'aide, faites indépendamment vos propres recherches en consultant le Web, le forum et la superbe documentation fournie par le Wiki d'Arch. Il y a une raison pour laquelle ces ressources ont été mises à votre disposition en premier lieu. Plusieurs milliers d'heures de bénévolat ont été consacrées à la compilation de ces excellentes informations.
Consultez également Arch terminology#RTFM et le guide d'installation.
Arch est elle conçue pour être utilisé sur une serveur ou un ordinateur de bureau?
Arch n'a pas été conçue pour un type d'utilisation particulier, mais plutôt pour un type d'utilisateur en particulier. Arch cible les utilisateurs compétents qui apprécient sa nature «en kit» pour se tailler un système unique façonné à leur besoin. Ainsi entre les mains de son utilisateur cible, Arch peut virtuellement remplir n'importe quels besoins. Beaucoup utilisent Arch à la fois sur leur ordinateurs personnels et sur des stations de travail. Bien sûr, archlinux.org, aur.archlinux.org et presque toute l'infrastructure d'Arch fonctionne grâce à Arch Linux.
J'aime beaucoup Arch, mais l'équipe de développement devrait implémenter telle ou telle fonctionnalité.
Impliquez-vous, partagez votre code/solution avec la communauté. Si elle est vue d'un bon œil par la communauté et l'équipe de développement elle sera peut-être incluse. La communauté Arch ne prospère que par les contributions, le partage de code et d'outils.
Quand la prochaine version sera t elle disponible?
Les «versions» d'installation ne sont que des environnement live à des fins d'installation et de dépannage. Ceux-ci incluent le méta-paquet et quelques autres paquets. Les images sortent généralement durant la première moitié de chaque mois.
Arch Linux est-elle une distribution stable ? Vais-je avoir fréquemment de la casse ?
C'est l'utilisateur qui est responsable en dernier ressort de la stabilité de son propre système en rolling release. L'utilisateur décide du moment de la mise à jour et inclus les changements nécessaires au besoin. Si l'utilisateur fait appel à la communauté, l'aide est souvent fournie en temps et en heures. La différence entre Arch et les autres distributions à cet égard est qu'Arch est vraiment une distribution "do-it-yourself" ; les plaintes concernant les pannes sont malavisées et improductives, puisque les changements en amont ne sont pas la responsabilité des développeurs d'Arch.
Consultez l'article Maintenance du système pour des conseils sur la façon de rendre une installation d'Arch Linux aussi stable que possible.
Arch doit être plus présent dans la presse (i.e. publicité)
Arch est suffisamment présent dans la presse comme cela. Le but d'Arch Linux n'est pas d'être large. Laissons la croissance se faire naturellement et durablement parmi la base d'utilisateurs visée.
Arch a besoin de plus de développeurs
C'est possible. Vous pouvez vous porter volontaire! Visitez le forum international et le forum francophone, les Canaux IRC et les listes de diffusion pour savoir ce qui est à faire. Consultez également s'impliquer pour plus de détails.
Installation
Arch a besoin d'un installateur. Peut-être même graphique?
Arch a eu un installateur basé sur une interface texte appelé «Arch Installation Framework» (AIF). Après le départ de son dernier mainteneur, les scripts d'installation d'Arch furent dépréciés en faveur de arch-install-scripts.
Depuis le premier avril 2021, Arch possède de nouveau un installeur. Consultez archinstall (Français) pour plus de détails.
J'ai installé Arch, et j'arrive sur un shell! Que se passe t il?
Consultez les recommandations générales.
Quel environnement de bureau ou gestionnaire de fenêtres devrais-je utiliser ?
Au vu du choix à votre disposition, utilisez celui qui répond le mieux à vos besoins. Jetez un œil sur les pages environnement de bureau et gestionnaires de fenêtres.
Qu'est ce qui rend Arch unique parmis les autres distributions "minimales" ?
Consultez Arch comparée aux autres distributions.
Maintenance
Consultez System maintenance (Français).
Pourquoi ma connexion internet est lente par rapport à d'autres systèmes d'exploitation ?
Votre réseau est il correctement configuré? Consultez l'article configuration du réseau.
Notez également qu'Arch Linux ne fait pas par défaut de régulation des flux (traffic shaping). Ainsi, il est possible que dans le cas où un programme utilise pleinement votre connexion Internet – qu'il s'agisse de connexions P2P ou de client-serveur classiques – d'autres programmes locaux la trouvent encombrée, ce qui entraîne des retards et des délais d'attente importants (lags et timeouts). La situation peut être améliorée par des pare-feu tels que Shorewall ou Vuurmuur ; il existe également des scripts statiques pour iproute2 (comme ce dérivé de Wondershaper), qui permettent de réguler la couche réseau.
Pourquoi Arch utilise t elle toute ma RAM?
Fondamentalement, de la RAM inutilisée est de la RAM gaspillée.
De nombreux nouveaux utilisateurs remarquent que le noyau Linux gère la mémoire différemment de la façon à laquelle ils sont habitués. Étant donné qu’accéder aux données en mémoire vive est largement plus rapide que depuis l'espace de stockage, le noyau met en cache les données récemment consultées dans la mémoire. Les données mises en cache ne sont vidées qu'une fois que le système manque de mémoire et que de nouvelles données doivent être chargées.
On peut distinguer la différence avec la commande :
Il est important de noter la différence entre "free" (libre) et "available" (disponible). Dans l'exemple ci dessus, un ordinateur portable avec 2.8 GiB de RAM semble utiliser une majeure partie de sa mémoire, ne laissant que 283 MiB de mémoire libre. Cependant, remarquez qu'1.4 GiB est catégorisé "buff/cache". Il reste toujours 1.2 GiB de disponible pour démarrer de nouvelles applications, sans «swapper». Voir pour plus de détails. Résultat ? Des performances!
Consultez ce merveilleux article (en) si votre curiosité a été piquée. Il existe aussi un site web dédié à éclaircir cette confusion: https://www.linuxatemyram.com/.
Ou est passé mon espace disque?
La réponse à cette question dépend de votre système. Il existe une liste d'utilitaires qui pourrait vous aider à répondre à cette question.
Gestion des paquets
Consultez les pages Pacman, Pacman#Trucs et Astuces and dépots officiels pour plus de détails.
J'ai trouvé une erreur dans le paquet X. Que faire?
D'abord, vous devez déterminer si l'erreur peut être corrigée par l'équipe d'Arch. Parfois ce n'est pas le cas (par exemple les plantages de Firefox peuvent être la faute de l'équipe de Mozilla) - c'est appelé une erreur «upstream» (en amont). Si c'est un problème d'Arch, il y a une série de démarches que vous pouvez suivre:
- Rechercher des informations dans les forums, si quelqu'un d'autre a déjà observé le problème.
- Poster un rapport de bug, avec des informations détaillées sur https://bugs.archlinux.org
- Poster un message dans le forum si vous le souhaitez, en détaillant le problème et le fait que vous l'avez déjà signalé. Cela permettra d'éviter que la même erreur soit signalée par trop de monde.
Les paquets Arch devraient utiliser une convention nominative unique. ".pkg.tar.zst" est trop long et/ou confus
Ceci a été discuté dans la liste de diffusion de Arch. Certains ont proposé une extension .pac, mais il n'est pas prévu de changer l'extension des paquets. Comme Tobias Kieslich, l'un des développeurs d'Arch, l'a dit, "Un paquet est un fichier tar compressé ! Et il peut être ouvert, étudié et manipulé par n'importe quelle application compatible avec le format tar. De plus, le mime-type est détecté correctement par la plupart des applications.
Pacman a besoin d'une bibliothèque pour que les autres applications accèdent facilement aux informations relatives aux paquets.
Pacman n'est que le «front-end», la devanture, de (Arch Linux Package Management), une bibliothèque qui permet l'écriture de front-ends alternatifs.
Pacman doit avoir telle ou telle fonctionnalité !
Si vous pensez que votre idée le mérite, vous pouvez en discuter sur la liste pacman-dev. Vérifier aussi https://bugs.archlinux.org/index.php?project=3 pour les demandes de fonctionnalité existantes.
Cependant, la meilleure façon d'obtenir l'ajout d'une fonctionnalité à pacman ou Arch Linux est de l'implémenter vous-même. Le patch ou le code peut ou non être accepté officiellement, mais peut-être que d'autres personnes apprécieront, testeront et contribueront à votre effort.
Je viens d'installer le programme X. Comment je le lance?
Si vous utilisez un environnement de bureau (comme KDE ou GNOME), le programme devrait automatiquement apparaitre dans votre menu. Si vous essayez de démarrer le programme depuis le terminal et ne connaissez pas le nom du binaire, utilisez:
$ pacman -Qlq package_name | grep /usr/bin/
Pourquoi n'y a t il qu'une seule version de chaque bibliothèque dans les dépôts officiels?
De nombreuses distributions, telle que Debian, ont différentes version des librairies partagées, empaquetées comme différents paquets , , etc. De cette façon, il est possible d'avoir sur le système, plusieurs applications compilées au moyen de différentes versions de .
Dans le cas de Arch, seule les dernières versions des paquets dans les dépôts sont officiellement prises en charge. En abandonnant la prise en charge des logiciels périmés, les mainteneurs de paquets peuvent passer plus de temps à s'assurer que les nouvelles versions fonctionnent comme attendu. Dès qu'une nouvelle version d'une bibliothèque devient disponible en amont, elle est ajoutée aux dépôts, et les paquets affectés sont reconstruits pour utiliser la nouvelle version.
Que se passe t il si une mise à jour pousse une nouvelle version d'une bibliothèque, mais pas une application qui en dépend?
Ce scenario ne devrait simplement pas se produire. En supposant qu’une application est dans les dépôts officiels et qu'elle se compile avec succès en utilisant une nouvelle version de la bibliothèque libbaz, alors cette application sera mise-à-jour en même temps que libbaz. Si cependant, la construction du programme n'est pas possible, le paquet se verra attribué une dépendance liée à une version (par exemple, libbaz 1.5), et sera supprimé par Pacman durant la mise-à-jour de libbaz, en raison d'un conflit.
Si est un paquet que vous construisez vous même ou installez depuis AUR, vous devriez essayer de reconstruire avec la nouvelle version de libbaz. Si la construction échoue, reportez le bug aux développeurs de .
Est-il possible qu'il y ait une mise à jour majeure du noyau dans le dépôt et que certains des paquets de pilotes n'aient pas été mis à jour ?
Non, ce n'est pas possible. Les mises à jour majeures du noyau (par exemple de linux 3.5.0-1 à linux 3.6.0-1 ) sont toujours accompagnées par la reconstruction de tous les paquets de pilotes du noyau pris en charge. Néanmoins, si vous avez un paquet de pilotes non pris en charge installé sur votre système (par exemple depuis l'AUR), une mise à jour du noyau peut casser des choses pour vous si vous ne l'avez pas recompilé pour le nouveau noyau. Les utilisateurs sont responsables de la mise à jour des paquets de pilotes non pris en charge qu'ils ont installés.
Que faire avant de mettre à jour?
Voyez la section System maintenance (Français)#À lire avant toute mise à jour.
La mise-à-jour d'un paquet a été publié, mais pacman dit que le système est à jour.
Les miroirs ne sont pas immédiatement synchronisés. Il peut s'écouler 24 heures pour qu'une mise-à-jour soir disponible pour vous. Soyez patient, ou utilisez un autre miroir. La page MirrorStatus vous donnera l'état de synchronisation des serveurs.
Le projet X vient de publier une nouvelle version. Combien de temps cela prendra t il aux développeurs d'Arch pour se mettre à jour ?
Les paquets mis-à-jours seront publiés quand ils seront prêts. La durée pourrait être quelques heures pour une version mineure d'un paquet, ou une simple correction de bug, comme plusieurs semaines pour une mise à jour majeure d'un groupe de programmes. Le temps entre la parution d'une nouvelle version «en amont» (upstream) et la publication d'un nouveau paquet dépends spécifiquement du paquet et de la disponibilité des mainteneurs. Aussi, certains paquets passent du temps dans le dépôt [[Official repositories (Français)#Dépôts de test|testing]] ce qui peut prolonger le temps avant ladite mise-à-jour. Les mainteneurs de paquets tentent de travailler vite pour que les dépôts contiennent les dernières versions stables. Si vous trouvez un paquet obsolète des les dépôts officiels, allez sur la page lui correspondant sur https://archlinux.org/packages/ et avertissez de son état.
Si j'ai besoin d'une ancienne version d'une bibliothèque, puis-je simplement faire un lien symbolique vers la nouvelle version ?
Si vous avez de la chance, cela pourrait marcher, un certain temps. Ce n'est cependant pas une solution appropriée car:
- Les versions des bibliothèques ne changent pas de façon aléatoires. L'API/ABI a certainement changé (avec de possibles suppressions) et l'impact à l'utilisation n'est qu'une question de chance.
- Le lien symbolique ne sera pas suivi par le gestionnaire de paquets. Le débutants qui essaient de bidouiller les bibliothèques du système courent le risque d'appliquer des changements à leur système qu'ils ne sauront pas diagnostiquer/réparer, ce contre quoi un gestionnaire de paquet aide à se prémunir.
- L'alternative consistant à conserver l'ancienne bibliothèque dans le système de fichier (sans suivi) sera oubliée et les futurs problèmes de sécurité ne seront ni corrigés, ni même remarqués.
Utilisez/écrivez plutôt un paquet de compatibilité,qui fournira la version requise de ladite librairie.
64-bit
Comment déterminer si mon processeur est compatible x86_64?
Si votre processeur est compatible x86_64 , vous verrez l'indicateur lm (long mode) apparaître dans . Par exemple:
$ grep -w lm /proc/cpuinfo
Sous Windows, utilisez le freeware CPU-Z vous aidera à déterminer si votre processeur est compatible 64-bit.
Pourquoi 64-bit?
C'est plus rapide dans la majorité des circonstances et, bonus, par nature plus sécurisé grâce à l'ASLR (Address space layout randomization) en combinaison avec l'utilisation du PIC (Position-independent code) et du NX Bit ce qui n'est pas disponible dans la version stock du kernel i686 à cause de la désactivation de la PAE (Physical Address Extension). Si votre ordinateur possède plus de 4 GiB de mémoire vive, seul un système d'exploitation 64-bit sera capable de l'utiliser pleinement.
Les programmeurs tendent également à se préoccuper de moins en moins de «l'héritage» 32-bit puisque les nouveaux CPUs prennent tous en charge les extensions 64-bit.
Il se trouve de nombreuses raisons que nous pourrions lister ici pour vous dire d'éviter les architectures 32-bit mais entre le noyau, l'espace utilisateur (userspace) et les programmes individuellement, il n'est pas envisageable de désigner tout ce que les architectures 64-bit font mieux que les architectures 32-bit.