Frequently asked questions (Français)

From ArchWiki
Jump to navigation Jump to search
État de la traduction: Cet article est la version francophone de Frequently asked questions. Date de la dernière traduction: 08/07/1988. Vous pouvez aider à synchroniser la traduction s'il y a eu des changements dans la version anglaise.

Generalités

Qu'est-ce qu'Arch Linux?

Voir l'article Arch Linux (Français).

Pourquoi ne voudrai-je pas utiliser Arch?

Vous ne voudrez probablement pas utiliser Arch si :

  • Vous n'avez ni les capacités ni le temps ni l'envie pour une distribution de type «faites le vous-même»
  • Vous avez besoin du support d'architectures autres que x86_64
  • Vous mettez un point à utiliser une distribution qui ne fournit que des logiciels libres
  • Vous pensez qu'un système d'exploitation devrait se configurer tout seul, inclure un jeu complet de logiciel pré-intégrés ainsi qu'un environnement graphique sur le média d'installation.
  • vous considérez qu'un système d'exploitation doit se configurer lui-même, fonctionner dès le départ et inclure un ensemble complet de logiciels et d'environnements de bureau par défaut 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 architectures Arch supporte t il?

Arch ne supporte que l'architecture x86_64 (aussi appelée architecture amd64). Le support de l'architecture i686 a été abandonné en Novembre 2017 [1].

Il existe des ports non-officiels pour l'architecture i686 [2] et pour les processeurs ARM [3], chacun avec leur propre communauté et canaux. [4]

Arch suit il le Linux Foundation's Filesystem Hierarchy Standard (FHS)?

Arch Linux suit le file system hierarchy à la façon des sytèmes d'exploitation utilisant Systemd. Voir file-hierarchy(7) pour une explication sur chacun des ces répertoires,. 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?

Cette question a été longuement débattue. Arch cible avant tout les utilisateurs plus avancés, mais certains pensent que "Arch est un bon endroit pour commencer". Si vous êtes un débutant et voulez utiliser Arch, sachez simplement que vous DEVEZ vouloir apprendre. Avant de poser des questions, faîtes vos propres recherches indépendantes sur Google, le Wiki et le Forum (et en lisant la FAQ). Cela devrait vous aider.

Sachez également que personne n'a envie de répondre sans arrêt aux même questions élémentaires, et que c'est l'environnement auquel vous vous exposez. Ces ressources ont été créées et mises à votre disposition pour une raison. Vous pouvez vous référer à l'installation.

Voir aussi 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 aucun type d'utilisation particulière, 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. De nombreux utilisateur d'Arch l'utilisent à la fois sur leur ordinateurs personnels et sur des stations de travail (et même sur des machines industrielles... Ndt.) Bien sûr, archlinux.org, aur.archlinux.org et presque toute l'infrastructure 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 cela est vu d'un bon œil par la communauté et l'équipe de développement ceci pourrait être inclus. La communauté Arch ne prospère que par 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 ?

La réponse courte est : Arch est stable selon ce que vous en faites.

Vous assemblez votre propre Arch, depuis une base simple vers des environnements plus évolués et vous contrôlez les mises à niveau du système. De toute évidence, un système plus vaste, plus complexe, intégrant une multitude de paquets sur mesure et une pléthore d'outils et d'environnements de bureau sera plus susceptible d'éprouver des problèmes de configuration en raison des changements en amont qu'un système plus mince et plus simple. Arch est destiné aux utilisateurs capables et proactifs. Des compétences générales en UNIX et de bonnes pratiques en maintenance du système et en mises à jour jouent également un rôle important dans la stabilité du système. Rappelons également que les paquets sous Arch sont majoritairement non corrigés, donc la plupart des problèmes d'application sont intrinsèquement en amont.

Par conséquent, c'est l'utilisateur qui est responsable de la stabilité de sa propre rolling release. C'est à lui de décider du moment des mises à jour et de se préoccuper des changements nécessaires en cas de besoin. Si l'utilisateur s'adresse à la communauté pour obtenir de l'aide, celle-ci est souvent fournie dans un délai raisonnable. La différence entre Arch et d'autres distributions à cet égard est qu'Arch est véritablement une distribution «faites-le par vous-même»; les plaintes de casse sont inutiles et improductives, car les changements en amont ne sont pas de la responsabilité des développeurs d'Arch.

Voir System maintenance (Français) pour des conseils pour améliorer la stabilité.

Arch doit être plus présent dans la presse (ie publicité)

Arch est suffisamment présent dans la presse comme cela. Le but d'Arch Linux n'est pas d'être large. Le but est d'être bien fait. Laissons la croissance se faire naturellement. Essayer de la forcer à être trop rapide risque seulement de causer des problèmes.

Arch doit avoir plus de développeurs

C'est possible. Vous pouvez vous porter volontaire quand vous voulez! Visitez les forums, les canaux irc, les listes de diffusion, pour savoir ce qui est à faire.

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 Arch Install Scripts furent dépréciés en faveur de arch-install-scripts.

Depuis Le premier Avril 2021, Arch possède de nouveau un installeur. Voir archinstall (Français) pour plus de détails.

J'ai installé Arch, et j'arrive sur un shell! Que se passe t il?

Voyez les recommandations générales.

Quel environnement de bureau ou gestionnaire de fenêtres devrais-je utiliser ?

Un bon nombre d'environnements graphiques est disponible, par conséquent à vous de voir celui que vous aimez et le plus adapté à vos besoins. Jetez un œil sur les pages environnements de bureau et gestionnaires de fenêtres qui en recensent une certaine quantité.

Qu'est ce qui rend Arch si unique comparée aux autres distributions ?

Voir Arch comparée aux autres distributions.

System maintenance

Voir 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é? Voyez l'article configuration du réseau.

Notez également qu'Arch Linux ne fait pas par défaut de la 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?

Essentiellement car de la RAM inutilisée est de la RAM gaspillée.

Nombre de 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 depuis la mémoire vive est largement plus rapide que d'y accéder depuis l'espace de stockage, le noyau met en cache, dans la mémoire, les données récemment consultées. 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.

Ceci est distingué par la commande 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

Il est important de noter la différence entre "free" (libre) et "available" (disponible). Dans l'exemple ci dessus, un laptop avec 2.8 GiB de RAM semble utiliser une grande partie de sa mémoire avec seulement 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 free(1) pour plus de détails. Résultat de tout ceci? La performance!

Voir cet article (en) si cela a piqué votre curiosité. Il existe aussi un site web dans le but de dissiper 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

Voir 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 évaluer si l'erreur peut être fixée par l'équipe d'Arch. Parfois ce n'est pas le cas (un crash de firefox peut être la faute de l'équipe de Mozilla) - c'est appelé une erreur «upstream». Si c'est un problème d'Arch, il y a une série de démarches que vous pouvez suivre:

  1. Rechercher des informations dans les forums. Voir si quelqu'un a déjà observé le problème.
  2. Mettre le responsable du paquet au courant. Tapez la commande "pacman -Qi <nom du paquet>" pour obtenir cette information.
  3. Poster un rapport de bug, avec des informations détaillées sur https://bugs.archlinux.org
  4. Poster un message dans le forum si vous voulez, en détaillant le problème et le fait que vous l'avez déjà reporté. Cela permettra d'éviter que la même erreur soit reportée trop de fois.

Les paquets Arch devraient utiliser une convention nominative unique. .pkg.tar.xz est trop long, et/ou embrouillant

Ceci a été discuté dans la liste de diffusion de Arch. Certains ont proposé une extension ".pac". Pour le moment, il ne semble pas y avoir d'intention de changer les extensions des noms de 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 gérant les tar. De plus, le mime-type est détecté correctement par la plupart des applications.

Pacman a besoin d'une librairie 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 librairie qui permet l'écriture de front-ends alternatifs.

Pacman doit avoir la caractéristique X!

Si vous pensez que votre idée le mérite, discutez la: pacman-dev. Vérifier aussi https://bugs.archlinux.org/index.php?project=3

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 Debian, ont différentes version des librairies partagées, empaquetées comme différents paquets libfoo1, libfoo2, libfoo3 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 libfoo.

Dans le cas de Arch, seulement la dernière version stable des paquets sont officielement supportés. En laissant tomber le support des programmes 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 librairie devient disponible «upstream», 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 foobaz 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 elle même. Si cependant, la construction du programme n'est pas possible, le paquet foobaz 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 foobaz est un paquet que vous construisez vous même, ou installez depuis AUR, vous devriez essayer de reconstruire foobazavec la nouvelle version de libbaz. Si la construction échoue, reportez le bug aux développeurs de foobaz.

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 à 3.6.0-1 ) sont toujours accompagnées par des reconstructions 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, comme catalyst, 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. Cela peut prendre 24 heures jusqu'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 fournir la nouvelle version?

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 tente 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 librairie, puis-je simplement la «symlink» vers la nouvelle version ?

Si vous avez de la chance, cela pourrait marcher, un certain temps. Ce n'est cependant pas une solution propre 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 comment cela en perturbe sont utilisation n'est qu'une question de chance.
  • Le lien symbolique ne sera pas suivi par le gestionnaire de paquets. Le débutants qui tenteront de bidouiller les bibliothèques du système prennent le risque d'appliquer des changements à leur système qu'ils ne sauront pas diagnostiquer/réparer; ces problèmes sont la raison d'être des gestionnaires de paquets.
  • Toute mise en place d'une librairie dans le système de fichier (non-suivi) sera aussitôt oubliée. Et les futurs problèmes de sécurité et/ou bugs ne seront ni patchés, ni même remarqués.

A la place utilisez 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 le drapeau 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 comme les nouveaux CPUs supportent tous 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.