Reprise du message précédent :
J'ai utilisé yay également mais je viens de refaire avec makepkg pas de soucis ... Franchement ça change rien, je me demande même pourquoi je l'ai fait ;-)
 
$ pacman -Q simgear
simgear 2019.1.1-3
 
et j'ai bien ça sans rien faire :
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include;/usr/include"

Ok donc c'est bien ce que je pensais,
il y a un chemin "/include" qui est ajouté dans "SimGearTargets.cmake"  lorsque je compile simgear, mais pas chez toi,

ce qui laisse à penser qu'il y a peut-être une variable d'environnement propre à chaque utilisateur, qui peut influer sur les résultats quand on compile simgear,

peut-être le contenu de la variable $PATH, chez moi il est égal à :

ou une histoire de cache pour la compilation (j'utilise le paquet ccache pour accélerer la compilation),
https://wiki.archlinux.org/index.php/Ccache

à noter qu'il y a quelques mois je n'avais pas de problème, j'ai regardé dans la version 2017 du paquet simgear, quand je le compile il n'y a pas ce chemin "/include" rajouté dans SimGearTargets.cmake, c'est que depuis la version 2019.1 que ce chemin est rajouté chez moi  .

Qu'est ce que tu en fais de flightgear par curiosité ?
 

un peu de Cessna C172P, le robin DR-400 plus faciles à piloter, des avions "auto-école" :

http://wiki.flightgear.org/Cessna_172P
http://wiki.flightgear.org/Robin_DR400

j'ai testé les avions de ligne, le boeing 777 est pas mal, ainsi que le "airbus 320 family" :

http://wiki.flightgear.org/Boeing_777
http://wiki.flightgear.org/Airbus_A320_Family

et pour m'amuser le F-14 comme dans top gun   :
http://wiki.flightgear.org/Grumman_F-14_Tomcat

  Sympa. On a pas le même usage, simulation de plans de vols pour ma part et tests de paramètres avant utilisation dans la vraie vie.

kikiesttoujoursla : peux-tu me dire si tu arrives à controler le F-14 avec la souris (ou le joystick) en utilisant flightgear 2019.1.1 ?

Apparemment la dernière version du F-14 semble boguée avec la 2019.1.1, les ailerons du F-14 ne bougent pas quand on bouge le joystick, même si à l'intérieur du cockpit on voit le yoke et les pédales bouger.

Pour installer le F-14 : il suffit de dézipper l'archive et de coller le dossier f-14b dans le répertoire aircraft :
http://mirrors.ibiblio.org/flightg [...] /f-14b.zip

puis de sélectionner l'avion "f-14a" ou "f-14b".

On remarque que la jauge hydraulique est à zéro, d'où l'impossibilité de faire bouger les ailerons, un bug dans le modèle JBSIM, qui est peut-être corrigé dans les versions "next" de flightgear.

J'aime bien la méthode tmpfiles.d
 
Dans powertop je lis "/sys/bus/usb/devices/1-3/power/control" :

 
j'ai essayé avec ce fichier :

ça ne fonctionne pas.
 
et j'ai vu, en allant rechercher dans l'historique de Dolphin, qu'en fait ça serait plutôt "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3/power/control", le bon chemin, Donc a priori je devrais faire :

 
Désolé pour ma noobitude, c'est une sorte de raccourci, un lien symbolique, non ?
Je suis tombé sur le vrai chemin un peu par hasard, comment j'aurai pu le connaitre ?
Si je change physiquement de port usb, la manip fonctionnera encore ?
 

Je ne crois pas non.

AMA la méthode du tmpfiles est vouée à l'échec car tu maîtrises pas (vraiment, hors modification des units...) l'ordre d'activation des services.
Tu sais pas si ton powertop sera activé avant ton tmpfiles et si l'ordre est stable dans le temps.
(Je pense même qu'il ya plus de chances que tmpfiles soit executé avant d'atteindre multi-user.target...)

berlo > si tu veux continuer à utiliser l'autotune de powertop, effectivement, il faut pouvoir garantir que ta modification (dans tmpfile donc) se fasse après celui-ci, ce qui n'est pas évident comme le dit make install

Dans cette situation, tu peux essayer de créer une unité oneshot qui s'éxécute après powertop :

ce qui lancera tmpfile avec les options que tu as indiqué après le service powertop (le nom est à vérifier). Tu enregistres le contenu dans un fichier le_nom_que_veux.service qui tu vas placer dans /etc/systemd/system ; ensuite un coup de systemctl daemon-reload pour prendre en compte ton nouveau fichier, puis systemctl enable le_nom_que_tu_veux.service pour l'activer au démarrage.

SI tu préfères ne pas passer par tmpfiles.d, tu peux aussi remplacer la ligne execstart par :

Merci à vous 2.
 
Je m'étais posé la question sur l'ordre justement.
 
Je commence à comprendre des choses, mais ce n'est pas très clair encore, c'est là que je me dis que j'ai beaucoup à apprendre encore ...

La version 1.09 d'Anarchy est sortie.  
https://github.com/AnarchyLinux/installer/releases

Est-ce qu'il existe une "roadmap" pour archlinux, c'est à dire une feuille de route de nouvelles fonctionnalités pour 2020 que les développeurs d'archlinux essaient de suivre ?

Une amélioration intéressante serait d'augmenter les performances de l'outil pacman, actuellement il y a une latence pour la plupart des opérations (consulter les infos d'un paquet, installer un paquet, mettre à jour le système), car la base de données de pacman est sous forme de fichiers textes, réparties dans plein de petits fichiers et dossiers, dans le répertoire /var/lib/pacman/,

si on a un disque dur classique les opérations de pacman seront assez lentes, le passage à un format binaire de base de données (comme SQLite) augmenterait la réactivité, la rapidité, car traiter du binaire est beaucoup plus simple et moins coûteux en temps CPU que de parser des données au format texte pur,

autres améliorations :

- faire afficher les messages d'interventions manuelles (du site archlinux) dans la console avant l'installation des paquets, quand on tape un "pacman -Syu" l'outil doit d'abord afficher les warnings du site archlinux et demander à l'utilisateur s'il veut continuer l'opération

- proposer une fonctionnalité "Hint, conseils" quand l'utilisateur est confronté à un problème de mise à jour ou d'installation de paquet, souvent pacman se contente d'afficher une question "tel paquet est en conflit avec le paquet X, souhaitez-vous le remplacer ? Y/N", ou de planter avec un message d'erreur ("le paquet machin casse la dépendance toto du paquet bidule" ), avec un peu d'IA on devrait pouvoir faire mieux en donnant la meilleure solution à l'utilisateur pour résoudre son problème.

- proposer une fonctionnalité "rollback", pour annuler automatiquement la dernière opération de pacman (un pacman -Syu, des installations manuelles de paquets, les suppressions de paquets), afin de revenir à un état antérieur, très utile en cas de régression due à la mise à jour du noyau linux, de plasma, ou des paquets Qt5

Belle idée effectivement.
La rapidité au niveau des thread aussi. Là tout se fait séquentiellement (j'imagine que pacman peut savoir s'il peut installer le paquet pendant que les autres paquets se téléchargent) et pour la conf.
Après je ne pense pas (j'aimerai me tromper) que ce soit la philosophie des createurs, (garder le plus simple et minimal possible ?) mais peut-être qu'on peut espérer ça sur aur ça serait top!

 
Mon Arch est installé sur un disque dur classique ( en 7200tr/min ) et je ne trouve pas que Pacman soit lent dans son fonctionnement.
Je le trouve même plus rapide que APT ( ubuntu ) qui est lui installé sur un SSD !    
Mais bon, dans les 2 cas le processeur n'est pas du tout le même : un Celeron bien souffreteux pour Ubuntu et un Intel i3 3225 bien costaud pour Arch  
edit : si tu as un disque dur en 5400tr/min et un processeur mou du genoux dans le style de mon Celeron, tu auras bien du mal pour obtenir un résultat vigoureux j'en ai bien peur...

Tiens, ce matin, j’ai eu la surprise de découvrir que gconf (typiquement le genre de paquet que je n’ai pu installer explicitement, et qui a donc été fourni par un autre lors de l’installation d’Arch) avait été relégué sur AUR. Étant donné que sur mes ordis, je n’ai aucun paquet qui en a encore besoin, et qu’il nécessite mille autres paquets pour être compilé, je me demande s’il n’est pas plus simple de le virer simplement ? Si ça se trouve, il doit être lié à Python 2.7, c’est pour ça qu’il a été dégagé des dépôts…

Moi je le garde car j'utilise encore Cryptkeeper qui en a besoin.
Il est lui aussi archi obsolète, mais vu que je ne connais aucune alternative plus moderne et tout aussi pratique, je garde le tout.
https://aur.archlinux.org/packages/cryptkeeper/

J'ai fait un "pacman -Qs gconf" pour savoir si j'ai ce paquet : ça a pris des plombes à s’exécuter (plus de 20 secondes, avec le disque dur qui gratte, mais j'ai énormément de paquets installés, c'est peut-être pour ça que pacman est lent, mon CPU est vieux aussi, un core 2 quad Q9650),
 

 
Des infos sur gconf :
https://fr.wikipedia.org/wiki/GConf

C'est étonnant car ton processeur ne semble pas à la ramasse par rapport au mien :
https://cpu.userbenchmark.com/Compa [...] 1706vs1488
 
Ton disque dur est encore en bonne santé ?

Effectivement, mes récents essais de manjaro en vm m'ont permis de comparer l'install de logiciels de base avec une vm ubuntu (sur la même machine hôte, avec les mêmes confs au niveau des vms).
Typiquement pour installer vim, qui est une des premières choses que je fais.
Eh bien y'a pas photo : pacman est clairement plus rapide.

Oui, par contre l'interrogation de la base locale est trop lente chez moi aussi.
En fait, quand je veux de l'info sur un paquet, la plupart du temps je passe par pacman -S pour interroger plutôt les dépôts.

Oui d'après les infos smart,
je dois avoir 2288 paquets installés.

Si il est vieux et qu'il a un paquet d'heures au compteur, méfiance quand même !
Surtout qu'il semble gratter fortement...
La surveillance smart n'est pas fiable à 100 %

Il y a aussi la phase où pacman collecte des infos sur les paquets installés quand on fait un "pacman -Syu" et les phases où il calcule l'espace libre, l'intégrité des paquets, vérifie s'il n'y a pas de conflits entre les paquets, ces phases sont assez lentes sur ma configuration,

une fois ces phases lentes passées l'installation et la mise à jour des paquets sont assez rapides, car il ne fait que copier les fichiers de l'archive sur le disque après les avoir décompresser, et éventuellement exécuter des scripts post-install (qui peuvent ajouter de la lenteur si il y a des commandes dkms qui recompile des modules externes)

Ben après tout ça demande forcément un peu de temps, même si ça irait surement mieux avec une base en binaire comme tu dis, mais pour le coup il me semble justement que ces choses-là sont plus rapides qu'avec apt.
Typiquement le apt update, qui est le pendant du pacman -Sy, est clairement plus long aussi (toutes choses égales par ailleurs, notamment au niveau de la connexion / état des serveurs).

A une époque y avait un script "pacman-optimize", ça aidait bien sur les HDD un peu mous... Mais ça a été retiré
Sinon tentez une defrag si vous êtes sous ext4, en gros pacman-optimize faisait plus ou moins ça en rafraichissant tout le contenu de la db from scratch.

J'en ai dit une belle, car pacman -S interroge tout autant la base (et aussi peu les dépôts) que pacman -Q.
Seulement voilà : mon expérience est que pacman -S ne galère jamais, alors que parfois (parfois seulement) pacman -Q peut mettre plusieurs secondes à s'exécuter.
J'ai eu le cas plusieurs fois en comparant les détails d'un paquet, en -Qii et -Sii, après une mise à jour (quand le paquet se retrouve orphelin ou hors dépôts).
Au final je ne sais pas trop pourquoi, mais comme ça n'a rien de dramatique…  

Quand tu fais un "pacman -Qi <nom du paquet>" alors peut-être que pacman en profite pour vérifier l'état de santé de la base de données 100% texte de pacman,

vu que le disque dur gratte comme un malade ça donne l'impression qu'il parcourt un nombre impressionnant de fichiers texte, à la recherche d'infos, dans le dossier /var/lib/pacman/, il y a aussi des fichiers archives compressés dans ce dossier, peut-être que pacman doit décompresser les archives pour récupérer un fichier texte de description du paquet,

il faudrait regarder dans le code source de pacman, pour voir ce que fait exactement l'option "Qi <nom du paquet>",

quand on relance dans la foulée la même commande "pacman -Qi <nom du paquet>" ça va plus vite car ça utilise le cache mémoire du noyau linux au lieu de redemander à la tête de lecture du disque de lire les fichiers texte de la base de données de pacman.

Il y a clairement un défaut de conception/design de pacman, des choix techniques (format 100% texte de la base de données) qui font que c'est lent, ceux qui ont un SSD sont un peu mieux lotis car ça va masquer un peu cette lenteur.
Les développeurs de pacman justifient ces choix par la volonté de "rester simple" (le principe KISS), mais le revers de la médaille c'est qu'il y a de la lenteur, c'est très rustique comme manière de procéder.

Finalement gconf est reviendu dans sa version aur sur mon PC, en effet la compilation c'est du costaud    
 
https://aur.archlinux.org/packages/gconf/

Dites, j'ai installé Sway pour essayer, j'y connais absolument rien en Tiling WM, j'ai copié le conf d'exemple vers mon .config/sway/config, et c'est normal qu'aucune touche clavier ne réponde ? Je ne peux rien cliquer, j'ai essayé les combinaisons de touche qui normalement fonctionnent avec Sway (Ctrl + D pour le Launcher, Ctrl + Enter pour la console), essayé de changer la Hotkey (Alt, Ctral, Super, etc.), rien n'y fait... Il faut faire quoi pour que ça marche ce machin ???

Aucune idée car jamais testé, il y a un article sur le site d'archlinux, ça remplace i3 et se base sur wayland, donc vérifier déjà si tu as bien respecté à la lettre le wiki en cas de configuration à faire :
https://wiki.archlinux.org/index.php/Sway

le site officiel :
https://swaywm.org/

une définition du "tiling window manager", appelé en français "gestionnaire de fenêtres par pavage", où les fenêtres sont gérées comme des tuiles, pas de superposition de fenêtres contrairement à un bureau classique :
https://fr.wikipedia.org/wiki/Gesti [...] par_pavage

Oui j'ai bien suivi le wiki d'Arch, c'est ma première source d'informations, mais je n'ai toujours aucun input clavier...

Si tu utilisais i3 alors tu peux reprendre à l'identique le fichier de configuration de i3 d'après le wiki :

Si tu as repris à l'identique le fichier exemple de sway alors le souci est peut-être là, si les options par défaut ne sont pas adaptées à ta configuration, il faudrait regarder le manuel de sway pour les options du fichier de configuration.

La consultation des fichiers logs (dmesg, xorg, journalctl) peut aider à en savoir plus sur cette absence de réaction du clavier, s'il y a un message d'erreur indiquant un crash d'un composant de sway.

Tu peux aussi consulter le bugzilla de sway, pour voir si quelqu'un a le même bug :
https://github.com/swaywm/sway/issues

Le Tiling, les mecs présentent ça comme le messie et naviguent à 30km/h car ils ont l'habitude, C'est  wahouuuu !.
 
Moi, perso, j'ai passé 2 jours à essayé d'apprendre les bases, adapter la config et retenir les raccourcis, le 3ème jour, j’étais totalement rincé, j'avais rien retenu et je suis passé à Plasma    
Je dit pas que c'est mauvais loins de là, mais c'est violent pour celui qui à jamais pratiqué  

Perso j'ai du mal à voir l'intéret, surtout si dans le tas de tes fenêtres tu as quelques GUI à la souris. Donc sauf si tu fais réellement du 100% text based ça peut se justifier.
Dans le cas contraire je trouve qu'un bête tmux/screen dans un ou deux terminaux virtuels c'est largement aussi efficace et moins prise de tête.

A part le pavage intelligent sous E, je ne connais pas trop.

J'ai pas encore franchi le pas, mais je considère i3. Pour moi l'intérêt c'est que j'ai un 32" 4k en résolution native 100%, que j'utilise comme un bi-ecran. Donc je passe mon temps a Snapper les fenêtres a gauche et a droite, voir en 1/4 d'ecran.
J'utilise Kitty et son fenetrage dynamique, mais ça me plairait d'avoir ça pour toutes les fenêtres.

Je crois bien que kwin peut aussi fonctionner en tilling, pour le faire automatiquement il y a different scripts. https://www.reddit.com/r/kde/commen [...] pt_to_use/

Forte accélération de pacman pour les mises à jour depuis le passage au format zstd pour les paquets :
https://archlinux.fr/non-classe/uti [...] -de-paquet

Il faut au moins libarchive en 3.3.3-1.
Je suis sur la version 3.4.1-1 donc tout est OK ?

Oui il y a rien à faire d'autre, normalement tu dois constater un pacman nettement plus rapide quand il installe, met à jour des paquets,

sinon attention pour les utilisateurs de plasma/kde : depuis une récente mise à jour de plasma : un gros bug sur le rendu des polices dans les applications kde (konsole, kate etc...) : elles ont l'air un peu déformées en hauteur (moins hautes), et floues, c'est dû à un bug de rendu des polices :

https://bbs.archlinux.org/viewtopic.php?id=251772

la solution : créer un script "fix_font.sh" dans ~/.config/plasma-workspace/env/

rendre exécutable le script (chmod +x fix_font.sh), puis redémarrer plasma, vous constaterez des polices nettement meilleures (comme avant la mise à jour),
ce n'est qu'un moyen de contournement, j'espère que les développeurs de plasma vont résoudre ce bug qu'ils ont crée eux mêmes.

Si vous avez un fichier de configuration fontconfig (fonts.conf) alors mettez le dans un fichier etc/xdg/kdeglobals (le créer s'il n'existe pas).