Reprise du message précédent :
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).

https://www.phoronix.com/scan.php?p [...] rnel-Tests
Rien de bandant pour le noyau Zen dans ces benchmarks.  
 
Sinon, version 1.0.10 de Anarchy.
https://github.com/AnarchyLinux/installer/releases

J'attends perso la résolution du bug RC6, on a perdu en autonomie sur les pc portables. J'ai retrouvé dans le cache d'un pc un kernel 4.19.81 qui profite pleinement du RC6, c'est le jour et la nuit. (Il faut avoir une version <=5.3.10 or <=4.19.83 pour profiter pleinement du RC6)

Simple curiosité, j'ai mon Firefox un peu fébrile et qui pète un câble aujourd'hui,  
Ça fait plusieurs fois qu'il se retrouve pratiquement freezé avec plusieurs onglets qui ce mettent à ce superposer / clignoter rapidement
C'est la première fois que j'ai un truc pareil, vous avez pas eu ça vous ?
 
- Firefox 72.02 (en addons j'ai juste Ublock et Https-everywhere)
- KDE Plasma
- Xorg & Chipset Intel
 
A partir de là je peu plus rien faire, si je ferme les onglets incriminés ça se répands aux autres,  si je relance firefox après c'est bon

Tout va bien chez moi.

Pas de problème comme ça mais aujourd'hui firefox a décidé de ne plus autoriser aucun certificats TLS

Et 10 minutes plus tard c'était revenu dans l'ordre  

Est-ce que la dernière version de blender (blender 17:2.81.a-4) fonctionne chez vous ?
 
Sur ma vieille carte graphique amd radeon HD4650 le lancement de blender fait planter plasma, obligé de tuer blender en ouvrant une console pour faire un kill dessus.

Je viens de tester, pas de soucis pour le lancer sous Plasma. Est-ce lié au projet que tu as ouvert? Je n'en ai pas.

Blender fait crasher plasma quand je le lance, même pas le temps de cliquer sur un menu de blender,
 
il y a au début une fenêtre grise avec blender comme barre de titre, puis une sorte de freeze, et un plantage avec une tooltip qui indique "kwin, le composant graphique a redémarré", mais plasma devient inutilisable tant que je n'ai pas tué blender en ouvrant une console (pas le programme konsole mais une vraie console avec les touches ctrl-Fx),
 
ça sent le bug lié au pilote libre radeon, ou à plasma

J'ai cru noter un bug de merde avec ff et hsts, un reboot de Firefox règle le soucis généralement

Hmmm aucune idée désolé. Rien d'interessant dans dmesg?
J'utilise aussi un pilote libre AMD, mais de mémoire ta carte est plus ancienne et tu es sur r600g et moi radeonsi.

Sais-tu si la version de blender 2.8x exige une carte graphique récente pour tourner ?

comme moyen de contournement en faisant un "LIBGL_ALWAYS_SOFTWARE=1 blender" ça fonctionne, mais blender sera lent car openGL sera émulé en software,

l'openGL marche chez moi avec les autres applications (jeux 3D) et les anciennes versions de blender (2.7x) marchaient avec ma config.

ça se confirme, blender qui favorise l'obsolescence programmée (j'exagère un peu, mais c'est ballot, la carte HD4650 est largement suffisante pour faire de la modélisation graphique) :
https://bugs.freedesktop.org/show_bug.cgi?id=109574
https://developer.blender.org/T61206
https://developer.blender.org/T69735
 
il faudrait voir si dans le dépot AUR on peut trouver une vieille version de blender de la branche 2.7 compatible avec les vieilles cartes graphiques, ou une appimage/flatpak
 
edit : bingo : https://aur.archlinux.org/packages/blender-2.7/

Je ne suis pas certain que ca soit de la faute de Blender et non de Mesa en lisant tout cela, mais on dirait que dans tous les cas, tu n'auras pas grande aide

Pour ton message sur aur, il serait peut-être mieux de le faire en anglais, je crois que "LC=C makekpg" suffirait mais pas sur.

"LANG=C" fonctionne chez moi quand je reportes les bugs en anglais
 
Comme quoi on critique souvent Nvidia et linux mais là c'est pas mal quand même niveau support sous Linux. Merci du retour Elbarto, je suis utilisateur de Blender également mais sous nvidia

Je ne suis pas convaincu pour Nvidia, sur un des liens quelqu'un se plaint du meme soucis avec une geforce 9XX.

 
Blender utilise probablement des fonctions openGL avancées qui sont mal implémentées dans mesa pour les cartes de la famille amd radeon HD4xxx, ou bien il y un bug dans le pilote radeon lorsque mesa appelle certaines fonctions du pilote radeon r600g.
 
Une solution de dépannage si on ne veut pas acheter de nouvelle carte graphique c'est de compiler le paquet blender-2.7 du dépôt AUR, par défaut le PKGBUILD ne se compilera pas, il faudra modifier la ligne 66 du PKGBUILD :
 

 
en la remplaçant par :
 

 
puis mettre "SKIP" pour la vérification de la signature des patchs que j'ai retirés de la ligne 66 (stl_export_iter.patch, python3.7.patch), ça permet de compiler et de créer le paquet,
blender-2.7 se lance, mais je ne sais pas s'il est vraiment utilisable dans toutes ses fonctionnalités, car les auteurs de la branche 2.7x ne garantissent pas un fonctionnement sans bugs pour ceux qui ont des vieilles cartes graphiques.
 
On peut aussi utiliser une image snap pour obtenir blender 2.7 si on ne veut pas compiler, cela aura la garantie que blender 2.7 survivra aux mises à jour des bibliothèques systèmes d'archlinux :
 

 
Idéalement il faudrait une alternative à Blender si on cherche juste un logiciel pas trop avancé de modélisation graphique, quand on est débutant et que l'on souhaite juste faire un truc simple pour s'amuser, sans le coté usine à gaz de blender.

Un modeleur plus simple que blender, avec une version flatpak :
http://www.wings3d.com/

https://www.archlinux.org/packages/ [...] 4/wings3d/

Tout dépend ce que tu en fais mais Blender est devenu une référence. Ce n'est pas uniquement un modeleur 3D. Pas sûr que tu motives ceux qui sont déjà sous blender de les faire switcher sur autre chose !

La meilleure solution est "LC_ALL=C" : pour une explication détaillée, voir https://unix.stackexchange.com/a/87763

Ah, je crois que c'est ce que je cherchais

Je crois qu’Elbarto va être content de la dernière mise à jour de Qt5 : j’avais un bug de rendu des polices* dans les logiciels basés dessus (à commencer par VLC), et il semble désormais corrigé avec les MAJ installées ce matin. Ça devrait lui régler son propre problème sous Plasma, j’imagine.

* Par exemple, le Noto Sans 9 était devenu plus petit et baveux depuis la MAJ précédente, au début du mois.

Je suis en train de faire la mise à jour, merci de l'info .

J'ai un peu de temps à tuer. j'en profite pour découvrir cette distribution.  J'aime le côté old school ou l'utilisateur doit savoir ce qu'il fait pour avancer. Ca me ramène quelques années en arrière.
 
je suis agréablement surpris par la documentation disponible.    
 
J'ai fini l'installation de mon environnement de bureau (xfce4). Avez-vous quelques conseils et outils indispensables à me prodiguer?  
 
 
 

pamac-aur si tu as envie de gérer tes paquets en mode graphique, un indispensable  

Merci pour le tuyau.

Prévoir aussi un plan B si on arrive plus à démarrer la distribution suite à des paquets bogués,

c'est l'un des principaux risques d'une distribution rolling-release, des paquets trop récents pas testés à fond (faute de recul), y compris par les développeurs des logiciels qui n'utilisent pas toujours une distribution rolling-release (ils peuvent développer sur des vieilles bibliothèques, tester que sur du debian figé/ubuntu LTS, du coup ils ne verront pas les changements d'API des bibliothèques récentes),

La trousse de secours en cas de problème :

- ajout d'un noyau linux de secours/alternatif dans le menu de boot, comme le noyau LTS ou un noyau personnalisé

- ajout d'une entrée "rescue mode" (plus sûr du terme) pour démarrer en mode minimale/console sous systemd

- créer une clé de boot avec l'image iso d'archlinux dessus, pour faire des opérations de chroot (il y a un bon article sur le wiki d'archlinux qui donne la méthode pour faire un chroot afin de downgrader un paquet vers la version précédente)

- ne pas vider complètement le cache de pacman, afin de pouvoir retrograder les paquets vers les anciennes versions qui marchaient bien

Très bon conseils ! Entièrement d'accord

Pareil, gros +1 sur les conseils d'Elbarto.

merci pour tous vos bons conseils.
 
Je garde la clé d'installation au chaud.  
 
 
Je vais jeter un oeil sur la procédure à suivre pour faire régresser un paquet intallé.  
 

Tu peux utiliser `downgrade' pour cela si tu n'as pas l'ancien paquet.
 
Après il peut-être nécessaire de régresser aussi les dépendances, ce qui n'est pas toujours automatique.

Un truc que je fais régulièrement (quand des paquets se retrouvent hors dépôt à la suite d'une màj notamment), c'est de me brancher sur archive.archlinux.org dans le mirrorlist.
Il suffit de rajouter en premier miroir une ligne du type

où on ajuste la date, puis pacman -Syy et on se retrouve dans le passé.
On peut alors consulter l'état des paquets, et rétrograder tout ce qu'on veut, dans la limite de ce que ça peut engendrer comme conflit de dépendances, évidemment.
Pratique quand on veut tester une régression sur un utilitaire qui ne dépend pas de trop de trucs par exemple…

Très utile ! Merci je garde ça dans un coin, je connaissais pas

 
T'inquiète pas il n'y a pas besoin de faire ça 3 fois par semaines non plus
En 2 ans j'ai juste eu a le faire une fois sur mon portable par exemple.

Je viens (une fois de plus), de chronométrer le temps nécessaire à une session XFCE pour se lancer sur le PC familial (Core 2 Quad de fin 2008, 4 Gio de RAM) :

Et encore, il y a quelques jours, on franchissait le seuil des 2 minutes d’attente ! Il semble que la mise à jour de systemd a permis de regagner une quarantaine de secondes.

Juste pour noter : ce matin, le numéro de processus du daemon de Thunar (lancé automatiquement) dépassait les 10 000 (au démarrage, bien que j’aie lancé en premier lieu une MAJ de l’OS en TTY, avant de démarrer une session graphique). Alors que sur mon PC portable, il reste aux alentours de 850.
Je comprends pas du tout ce qui cause ce délai, ni même où chercher une réponse, mais à la longue, c’est bien gonflant. Quand je pense qu’avant, en 5 secondes, tout était prêt… >__<

systemd-analyze blame peut montrer certaines choses interessantes, ou bien systemd-analyze critical-chain .

Avec la dernière commande indiquée j'ai ça pour les derniers élements:

le démarrage est long (2 minutes voire plus si on inclu le temps de chargement de plasma/kde, et le temps de démarrage du bios si on a un vieux PC) avec un disque dur classique, quelque soit le système d'exploitation et le bureau et le CPU,

la partie la plus lente c'est le temps de démarrage à partir du moment où le gestionnaire de boot graphique (sddm) se charge, il y a un temps mort chez moi de 5 secondes où le système ne fait rien (il semble attendre quelque chose), je soupçonne sddm,

puis une fois sddm chargé je tape mon login et mot de passe et ensuite le disque rame pour charger les fichiers de plasma, c'est dans ce stade que les développeurs pourraient améliorer les performances, gagner 20 secondes en optimisant ce bazar, les anciennes versions de kde étaient plus rapides à charger, le bureau s'affichait très vite au boot,

j'ai désactivé les trucs inutiles comme akonadi, l'indexeur de fichiers, peu de démons liés à plasma/kde qui tournent en arrière plan.

RAS pour blame, puisque ça ne se produit qu’après LightDM démarré (et donc tous les services démarrés aussi), et aucun ne prend plus de 5 secondes à se lancer (le démarrage complet n’a pris que 16 secondes, ici ; et je n’ai pas de SSD).
RAS pour critical-chain aussi : même si certaines lignes sont en rouge, je ne vois rien d’anormal au point d’expliquer ce délai d’attente.

J’avis bien essayé de regarder des logs comme « .xsession-errors », mais si j’ai bien un tas d’erreurs de type

et qu’au bout d’un moment, il met ça :

et que, visiblement, c’est à ce moment-là que XFCE a bien voulu se charger (puisque je vois des lignes en rapport avec les widgets des tableaux de bord, et ensuite des programmes résidents comme Guake et les applications lancées comme Vivaldi), je vois pas où se situe vraiment le problème. Ou, plus exactement, je vois pas ce qui le cause et comment y remédier.

Moi le plus long c'est les  7.988s du bios mais je peu rien y faire    

chez moi avec un CPU intel core 2 quad Q9650, disque dur classique 7200 tours/minute :

L'UEFI est un poil lent...