Reprise du message précédent :
Peut-être un soucis d'accélération matérielle?

J'ai déjà tout tenté, sans succès.
Ce qui est sur c'est le matériel de ce PC ne pose pas de souci avec Chromium sous Linux ou Firefox sous Windows.
Donc je subodore que mon Firefox version Linux est responsable de cette lenteur.

As-tu essayé un truc comme http://sebaro.pro/viewtube/ ?

Non, mais si je suis obligé de rajouter des extensions dans tous les sens je préfère utiliser Chromium de toute façon...

Sinon il y a SVP. Je ne me rappelle plus si la version 3 (gratuite) a une version linux mais la 4 (payante), oui. Elle permet d'utiliser la licence à la fois sous Windows et Linux.

Changement de taulier pour Arch Linux : Levente « anthraxx » Polyak succède à Aaron « phrakture » Griffith (qui avait lui-même pris la suite de Judd Vinet, son concepteur, en 2007) à la tête de l’équipe qui conçoit la distribution au A bleu !
 
https://www.archlinux.org/news/the- [...] ct-leader/

Petit souci avec la màj de glib2 en 2.64.0-1 ce matin    
Après la màj, dès que j'essayais d'ouvrir un fichier par double clic sur le bureau ou dans thunar, j'avais une erreur

Donc rétrogradage à la version d'hier 2.62.5-1, et blocage des màj sur glib2 et lib32-glib2 jusqu'à nouvel ordre

Aucun problème de ce type sur les deux Arch que j’ai chez moi. Ça devrait pas être lié, a priori, mais est-ce que le fait d’avoir redémarré dans la foulée (il y avait une MAJ du noyau dans le lot) a fait que le problème ne se présente pas ?

Bien vu, c'était ça    

Grâce à ce post https://forums.archlinux.fr/viewtopic.php?t=21762, je viens d'essayer une iso arch xfce : http://dl.gnutux.fr/live/
C'est bien pratique, très fluide comme le dit l'auteur, et il y a diverses options avant le lancement, dont le passage en ligne de commande classique, la découverte du matériel, les modules noyau…
Par contre, pour la persistance dont il est question dans le post cité, j'ai pas l'impression que ça marche, ou alors j'ai loupé quelque chose    
Bien pratique en tout cas, de pouvoir booter sur un environnement graphique, pour un essai ou même pour du dépannage, même si pour une install, je préfèrerais probablement passer par l'iso officielle.

J'ai remarqué récemment la mention au boot après un pacman -Syu, elle n'est apparue qu'une seule fois :

avant le reboot archlinux me semblait un peu plus lent juste après un "pacman -Syu", en redémarrant ça va mieux, donc peut-être que Kajoux a eu le même souci, une histoire de cache pour les bibliothèques dynamiques qui n'était pas à jour, suite à un "pacman -Syu",

idéalement il faudrait qu'il y ait un "hook" pacman qui lance la reconstruction du cache "dynamic linker cache" pour éviter ce problème de lenteur et/ou d'application qui plante après un "pacman -Syu".

Y'a eu un rapport de bug en testing le 28 février en fait : https://bugs.archlinux.org/task/65651
Mais les gars ont pas eu l'air de trop donner suite, au vu des commentaires en tout cas, mais c'est bien exactement les symptômes que j'ai eus.
Peut-être qu'ils se sont dit : "Bah, ils auront qu'à rebooter !"  

Ah, ça m’arrive, parfois. C’est pas systématique, et ce serait même plutôt totalement aléatoire (je fais un « pacman -Syu », et même un « yay » qui l’implique car sans paramètre, tous les matins ; et cette reconstruction ne se produit pas forcément, comme elle peut se produire plusieurs fois de suite, sans recherche de MAJ dans l’intervalle).

Encore un truc que je laisse couler. C’est juste un peu irritant car ça ralentit le démarrage de quelques secondes (et encore, j’ai mis une limite à 20 secondes dans user.conf, mais ça n’en dure jamais plus de 5), mais sans plus. Ce qui était vraiment ch×ant, c’était le job lié à la fermeture de session, qui se déclenchait à l’arrêt. Ça, ça arrivait à peu près une fois par mois, et je suis bien content que ça ait disparu : ça durait 1mn30, voire ça se relançait au bout de ce délai… Je crois qu’une fois, ça a mis plus de 10 minutes avant que la machine ne daigne enfin s’éteindre (quand tu n’attends plus que ça pour aller te coucher, t’es content !). Une fois, j’en avais tellement marre que ça n’en finisse pas que j’ai même éteint à la sauvage, car j’avais pas que ça à faire. Cette fois-là, il avait fini les jobs, coupé les services, mais pour une raison inconnue, il refusait de démonter les partitions.

Tant qu’on est aux bugs bizarres : vers octobre, lorsque je faisais quelque chose qui forçait à une consommation énorme de swap sur une longue durée (plusieurs heures), il arrivait que sur mon portable, l’arrêt automatique depuis le bouton d’allumage ne fonctionne plus. Appuyer dessus ne lançait plus l’arrêt du système. Il fallait que je passe par les menus pour fermer XFCE et même après, je me retrouvais avec un OS qui était techniquement arrêté (le disque dur interne était bien démonté, les têtes parquées, tout ça), mais il refusait quand même de couper le jus. Je devais l’éteindre de force en maintenant le bouton appuyé. Bon, là, ça ne posait pas de problème, car les partitions étaient démontées proprement, et ce bug ne se produisait pas si j’avais un usage plus « sage » de la machine. Ça aussi, ça a disparu, et ça me manque pas davantage.

J'ai eu ça aussi il y a quelques temps, le coup du power off qui ne veut pas se faire, alors que tout le reste s'est bien déroulé, mais indépendamment de l'utilisation que j'avais faite de la machine, ou alors j'ai pas noté.
Mais bon, comme ça pose aucun problème effectivement, je l'ai pas mentionné ici, et ça a disparu assez vite.
Ça m'a rappelé de vieux souvenirs d'ailleurs, car ça me le faisait assez systématiquement sur certains os gnu/linux que j'ai eus dans le temps (les premières mandriva notamment, ou bien la fin des mandrake…)

Plus de mainteneur pour nvidia-390xx, il va passer sur aur, mais ce n'est pas dit que quelqu'un le prenne la-bas...

Je suppose que beaucoup d'entre vous devaient connaitre tout ça, mais bon, au cas où, voici un lien complémentaire sur forums.archlinux.fr expliquant comment faire pour la persistance des données, et d'ailleurs leur chiffrement : https://forums.archlinux.fr/viewtop [...] 18&t=21332

Il faudrait voir la proportion de mainteneurs AUR qui possèdent une carte nvidia ancienne, si la plupart ont une carte amd ou du nvidia récent alors ils ne pourront pas vérifier si le paquet nvidia-390xx fonctionne après compilation, le paquet sera proposé sur AUR, mais rien ne garantit qu'il fonctionnera sans bugs.
Sinon il faudra se contenter du pilote libre "nouveau", et laisser tomber toute idée d'utiliser le pilote propriétaire nvidia.

Chez amd il n'y a pas ce souci, le pilote libre suffit largement, même pour jouer (voir les tests sur le site phoronix).

Je crois que c'est justement la raison du lâchage officiel, le mainteneur ne pouvait pas tester le pilote et en a eu marre...

Ce serait quand même bien que, quand on veut maintenir un paquet de pilote matériel, on possède au moins le matériel concerné…
 
(Oui, c‘est facile, mais le fond n’en reste pas moins vrai)

Quand le mainteneur a changé de matériel personne n'a voulu reprendre la main, donc il a été sympa pendant un moment et a continué.
 
Je ne vois pas trop ce qu'on peut lui reprocher, surtout vu que c'est du bénévolat...

De ne pas l’avoir conservé pour pouvoir tester (même uniquement dans ce but), justement ?

Il a peut-être déjà beaucoup d'autres vieilleries, envie de faire le ménage, a déménagé, etc ... enfin bref c'est déjà sympa de sa part d'avoir contribué !

Dites, il y en a qui utilisent Guake, ici ? J’ai un petit souci, depuis que j’ai fait la mise à jour en 3.7.0 : il plante au lancement.
 
Copie du message qui s’affiche quand je tente de le lancer depuis un terminal :
 

Là, j’ai que deux choix pour le refaire fonctionner :

• revenir en version 3.6.3 (mais bon, c’est pas top de rester sur une version obsolète…)
• ou supprimer le dossier « ~/.config/guake ». Là, Guake 3.7 se relance sans souci.

Sauf que ce serait trop facile, si c’était juste ça : si je le quitte et que je veux le relancer, Guake replante à nouveau. Et dans l’intervalle, un nouveau dossier « ~/.config/guake » a été recréé. En le re-supprimant, il se relance de nouveau (et ainsi de suite).
 
J’ai bien tenté de signaler le bug sur le bugtracker d’Arch, mais apparemment, la personne qui a pris le cas en charge a été incapable de reproduire le bug (et a donc fermé le signalement, cool…).
 
Je suis quand même pas le seul à être touché par ce bug, tout de même ???

Essaie voir de créer un nouvel utilisateur, puis tu te connectes avec cet utilisateur, pour voir si le bug disparaît.
Vérifie aussi qu'il te reste assez d'espace disque dans ton home.

Tu peux aussi créer le rapport de bug sur le site officiel du paquet guake, pour prévenir directement l'auteur du logiciel.

Pour un débogage plus poussé il faut utiliser gdb, et une version de guake compilée avec les infos de débogage (tu recompiles le paquet en modifiant le fichier PKGBUILD, cette mention : "options=(debug !strip)" ) :
https://wiki.archlinux.org/index.ph [...] ging_guide

Encore mieux : faire un git bisect pour trouver le commit qui a introduit le bug :
https://delicious-insights.com/fr/articles/git-bisect/

Je viens d'essayer, je n'ai pas de répertoire ~/.config/guake avant de l'avoir lancé, après je l'ai et pas de crash quand je le relance.
 
Maintenant que tu sais que c'est lié à la présence du dossier, tu peux tenter de voir ce qui pose problème dedans.  
 
Ce n'est probablement pas un bug d'Arch mais du dev du logiciel, donc tant que peu sont touchés Arch ne va pas revenir en arrière.

Tous les paquets sont à jour chez Trit ? (pacman -Syu)
Pas de miroirs pacman en retard, non synchronisés ? (dans le doute ne laisser qu'un seul miroir, un miroir français qui a bonne réputation, comme http://archlinux.polymorf.fr/$repo/os/$arch)
Il a rebooté après la mise à jour ? (pour reconstruire automatiquement le cache des bibliothèques dynamiques), certains utilisateurs ne rebootent jamais leur PC, et se contentent de mettre en veille plutôt que d'éteindre le PC.
Est-ce que Trit utilise plasma comme gee ?
Pas d'utilisation de paquets exotiques qui rajouteraient une surcouche boguée au système (bureau, thème de bureau) ?
Pas d'erreurs dans la configuration de gnome, de gtk dans /etc ?

Il tourne sur le PC qui a un vieux CPU core2 duo ?

Peut-être que le paquet guake a été compilé avec des options non compatibles avec son CPU, il me semble que c'est déjà arrivé avec un autre paquet, le mainteneur qui a voulu optimiser le binaire avec une extension CPU trop récente, les CPU anciens plantaient à l'exécution du paquet.

J'ai fait un petit essai aussi : install, lancement, extinction, relancement, reextinction : pas de problème

M’étant repenché dessus au cours des dernières minutes, je crois que je viens de trouver le fautif… Déjà, il suffisait juste que le fichier session.json soit présent pour que Guake plante au démarrage, chez moi. En le supprimant, je pouvais relancer Guake sans qu’il ne plante.
Par curiosité, j’ai fait un tour dans les options (censées être remises à zéro, puisque j’ai d’abord renommé l’ancien dossier de configuration, mais apparemment non), et j’ai décoché la case « Restauration de la précédentes sessions (onglets) » (sic). Je referme Guake (clic droit dans la pop-up → Quitter → Oui). Je le relance… et il ne plante plus !
 
Visiblement, c’est simplement l’activation (elle l’est par défaut ?) qui ne lui plaît pas.
 
Tu m’étonnes, que personne n’ait repéré ce truc, si cette case n’est pas activée par défaut…

Cette option est active par defaut chez moi, je l'ai decochée et recochée et toujours pas de plantage.

Je comprends pas… Si ça se trouve, c’est comme le dit Elbarto : un changement auquel les C2Duo sont allergiques, contrairement aux CPU plus récents. Enfin, pour ce que cette fonction me servait (spoiler : à rien), ça me dérangera pas plus que ça de la désactiver. Si c’est le prix à payer pour que Guake marche sans aller ameuter la Terre entière pour un truc qui touche peut-être que moi, vu l’absence de retours similaires au mien…

Pareil  

Quant au Core 2 Quad, lui, il avait la case déjà désactivée. Et quand je l’ai activée : boum.  
 
Bon, tant pis, je sais donc qu’il faut que je garde cette case désactivée, ça me suffira.  
 
Affaire classée.

Tu peux toujours faire un rapport de bug, ca pourrait aider quelqu'un d'autre.

Archlinux a 18 ans, happy birthday !

C’est beau, une distribution qui devient majeure ! Quand je l’ai connue, elle allait sur ses 13 ans et demi. Elle a bien grandi, la petite !
 
Bon anniversaire, Arch Linux !

Bon anniversaire et longue vie à Arch Linux, qui est une super distribution  

Pas vraiment une question spécifique Arch mais y a pas de TU Gnome alors...
Vous conseillez quels dock pour Gnome ? J'en ai marre que Dock to Dash pète à chaque update.
J'ai essayé Cairo mais c'est un peu buggué et je n'ai pas trouvé de rendu qui me plaise.
Plank n'est pas compatible Wayland.

Depuis un récent "pacman -Syu" je remarque un bug durant (ou après) le boot de plasma/kde :

- pendant une fraction de seconde l'affichage est corrompu (comme une reception de la TNT pixelisée, ou un fichier vidéo corrompu sur certaines trames), ça disparaît instantanément ensuite, pour ne plus se reproduire (jusqu'au prochain boot, sachant que parfois on ne le voit pas)

j'utilise le pilote libre radeon, une vieille carte graphique (radeon HD4650 pcie), peut-être qu'il y a un bug dans le dernier noyau linux.

 
ça me fait ça depuis des années sur de multiples radeon avec de multiples versions du pilote libre/noyau. A priori, il affiche un bout de la VRAM qui n'est pas encore initialisée ou avant qu'une image soit uploadée dedans. J'avais aussi ça avec le pilote Nouveau quand j'avais encore une nvidia, mais c'était encore plus drôle parce qu'à l'époque, la VRAM était pas correctement initialisée et au reboot on avait des morceaux d'images du boot précédent qui apparaissaient (ce qui trainait dans la VRAM à cet endroit).

J’ai parfois aussi une sorte de « neige télé » à l’ancienne avec XFCE depuis que la version 4.14 est sortie, sur mon portable (qui a aussi une CG AMD et le pilote libre). Encore une fois, comme ça ne dure qu’une fraction de seconde, l’important reste que ça s’affiche correctement ensuite.

+1, depuis xfce 4.14, juste avant l'entrée en session de bureau, j'ai régulièrement (pas toujours) un affichage psychédélique pendant une petite seconde.
Carte graphique Radeon HD 7310, pilote libre.