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.
Pourquoi voudrais-je utiliser Arch ?
Parce que Arch est la meilleure.
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 [1].
Il existe des distributions dérivées pour l'architecture i686 [2] et les processeurs ARM [3], chacune disposant de ses propres canaux communautaires. Elles ne sont pas prises en charge par Arch Linux.
Si vous souhaitez qu'Arch prenne en charge d'autres architectures, vous pouvez contribuer aux projets de ports existants ou lancer le vôtre. Consultez Getting involved (Français)#Aider le port d'Arch Linux vers d'autres architectures.
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 /lib ainsi que /lib64 sont des liens symboliques vers /usr/lib.
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 base 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ésente 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
Quelle quantité de RAM est nécessaire pour démarrer l'environnement live?
Cela dépend si vous utilisez l'ISO principale ou la version netboot. Ces quantités peuvent varier de 1 à 2,5 Gio. Si vous utilisez un ordinateur avec un GPU intégré, moins de mémoire vive sera disponible en raison de la RAM réservée au chipset graphique
Arch a besoin d'un installateur. Peut-être même graphique?
Un programme d'installation guidé doté d'une interface utilisateur textuelle est disponible. 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. Pour les configurations avancées, vous pouvez également vous renseigner sur la régulation de flux.
L’un des noyaux les plus couramment utilisés, linux, est généralement plus récent que celui d’autres distributions Linux, plus stables. De ce fait, vous risquez rarement de rencontrer une régression du noyau ou un bug dans un pilote, en particulier si vous utilisez le Wi-Fi. Notez toutefois que la grande majorité de ces bogues ne sont pas spécifiques à Arch Linux, car Arch Linux n'applique que les correctifs les plus élémentaires. Ces problèmes doivent être signalés en amont. Voir #J'ai trouvé une erreur dans le paquet X. Que faire?.
Pourquoi Arch utilise 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 free:
$ free -h
total used free shared buff/cache available Mem: 377Gi 40Gi 146Gi 1.1Gi 196Gi 337Gi Swap: 377Gi 1.1Gi 376Gi
Il est important de noter la différence entre "free" (libre) et "available" (disponible). Dans l'exemple ci dessus, un système avec 377 GiB de RAM semble utiliser plus de la moitié de sa mémoire, ne laissant que 146 GiB de mémoire libre. Cependant, remarquez que 196 GiB est catégorisé "buff/cache". Il reste toujours 377 GiB de disponible pour démarrer de nouvelles applications, sans «swapper». Voir free(1) 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/.
Où 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.
Pourquoi est-ce que je n'arrive pas me connecter ?
Avez-vous mal saisi votre mot de passe ou annulé une commande sudo à trois reprises en quinze minutes ? Si tel est le cas, vous avez déclenché un mécanisme de prévention contre les attaques par force brute : consultez Security#Lock out user after three failed login attempts pour plus de détails.
Est-ce que Arch se connecte automatiquement à des serveurs distants ?
En bref ? Non.
En plus de détails :
- Les utilisateurs de NetworkManager doivent savoir que celui-ci effectue des vérifications automatiques de la connectivité. L'URL de connectivité par défaut est fournie par Arch, qui s'engage à n'enregistrer aucun accès.
- Les clients du protocole NTP utilisent, dans leur configuration par défaut, un ensemble de serveurs NTP fourni par le NTP Pool Project (conformément à ses règles).
- Comme l'explique la note dans pacman (Français)/Package signing (Français)#Mettre le système à jour régulièrement : une tâche systemd s'exécute une fois par semaine pour mettre à jour les nouvelles signatures des clés déjà considérées comme fiables. Là non plus, aucun accès n'est conservé.
- L'outil de mise à jour de la liste des miroirs Reflector (pour ceux qui l'utilisent) télécharge la liste des miroirs depuis archlinux.org.
Vous pouvez choisir de remonter des informations volontairement en contribuant au projet pkgstats, qui collecte des données anonymes sur la popularité des paquets afin d'aider les développeurs d'Arch à hiérarchiser leurs efforts.
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. Souvent 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), c.f. Bug reporting guidelines#Upstream or Arch?. 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 le système de suivi des bugs d'Arch Linux dans GitLab.
- 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 libalpm(3) (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://gitlab.archlinux.org/pacman/pacman/-/issues 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 s'il est fourni avec un fichier .desktop. 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 libtruc1, libtruc2, libtruc3 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 libtruc.
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 trucmuche est dans les dépôts officiels et qu'elle se compile avec succès en utilisant une nouvelle version de la bibliothèque libmuche, alors cette application sera mise-à-jour en même temps que libmuche. Si cependant, la construction du programme n'est pas possible, le paquet trucmuche se verra attribué une dépendance liée à une version (par exemple, libmuche 1.5), et sera supprimé par Pacman durant la mise-à-jour de libmuche, en raison d'un conflit.
Si trucmuche est un paquet que vous construisez vous-même ou installez depuis AUR, vous devriez reconstruire trucmuche avec la nouvelle version de libmuche. Si la construction échoue, reportez le bug aux développeurs de trucmuche.
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 avant que le paquet pour Arch soit à 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 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, bumpbuddy aurait dû alerter automatiquement le responsable grâce au readthedocs.io/en/latest/usage.html nvchecker dans chaque dépôt individuel (voir cet exemple dans le paquet chromium).
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 /proc/cpuinfo. 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.