Reprise du message précédent :
 
Pas pire qu'Ati. Les meilleurs drivers graphiques étant les intel AMHA

AMD est bon aujourd'hui, Intel n'est plus meilleur.

   
Là c'est bizarre car je n'y ai pas touché et ça ne fonctionnait plus   . Je n'ai pas eut de problème avec cette CG Nvidia depuis 2012.
Nouveau ça a l'air de bien fonctionner, je n'ai pas essayé steam mais vu que je joue une fois par an...

8 ans que je tourne sous Arch avec les drivers proprio Nvidia, aucun soucis    

Je confirme pour avoir essayé une carte Amd il y a quelques temps, c'est beaucoup moins facile qu'avec Nvidia ...

 
Quelques années avec 2 PC sous carte N-vidia, que des emmerdes    
Perso je ne jure plus que par le 100 % Intel désormais, aucun pilotes proprio et très rarement des problèmes ( même si Gee a raison, ce n'est plus aussi bon qu'avant )
Reste le cas AMD que je ne connais pas, donc je m’abstiens de tout commentaire.

https://www.youtube.com/watch?v=JbovJbKALzA

J'utilise nvidia depuis 2007 sur ubuntu, debian et manjaro ... Jamais eu un soucis perso. Par contre ati, j'ai essayé plusieurs fois, je vous les laisses. Et puis les soft en cuda ne fonctionnent qu'en nvidia bien sûr

Ce n'est plus ATI depuis 2006
Faudrait essayer du plus recent

à part pour le setup initial, aucun problème pour le moment avec CUDA ou nvidia...

Je n'ai pas encore trouvé un seul paquet disponible sous ubuntu qui ne le soit pas sous arch.
 
Je suis même tombé sur un guide pour y installer aptitude

Êtes-vous affecté par ce bug de freeze de X sur les derniers Kernels ? Moi oui depuis ce matin.

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

Heureusement, repasser sur le LTS "résoud" le problème.

Edit : ha bah non, ça freeze aussi sur LTS.

 
C'est écrit en bas : i3 comme desktop https://wiki.archlinux.org/index.php/i3 XFCE existe sous Arch ...
 
Et ça fonctionne sur laptop oui, il y a des guides dans la doc https://medium.com/@dade/how-to-lin [...] 4ae5a3b822

Non mais peut-etre que ca vient du X 1.20 et non du noyau pour toi?

j'utilise une carte amd radeon HD4650 avec le pilote libre radeon : aucun soucis, le pilote libre radeon est très performant,

les cartes amd récentes utilisent le  pilote libre amdgpu, qui en général ne pose pas de problèmes, de bonnes performances d'après les tests de phoronix,

je dirai que l'avantage d'utiliser une carte graphique amd c'est le pilote libre : il est de grande qualité, comme il est inclus dans le noyau linux ça évite beaucoup de problèmes, ici on a les détails des fonctionnalités qu'offrent les pilote libres radeon et amdgpu :
https://www.x.org/wiki/RadeonFeature/#index1h2

autre avantage d'utiliser une carte amd : l'implémentation d'openCL est meilleure que chez nvidia (qui préfère miser sur sa technologie propriétaire : cuda)

Ca depend de quelle implémentation (il y en a 3 sous Linux).

 
Ha peut-être bien, merci pour l'astuce, je vais désactiver Testing et repasser en X.org 1.19 !

Pour avoir des problème avec une carte amd je sais même pas comment faire.
 
C'est simple, tu ne t'occupe de rien et tout marche.......

 
Arch marche parfaitement chez moi, que ca soit sur le vieux laptop de 10 ans avec une nvidia quadro ou le nouveau avec juste le chip Intel. Quand on lis un peu les avis général sur Arch, ca a tendance a dire que c'est pas toujour ca niveau stabilité / bug and co du faii que c'est une rolling avec des paquets '' très'' recents et que tout peu péter a tout moment mais ca va faire 6 mois qque j' y suis passer et j'ai jamais eu d'ennuis. Limite j'aivais plus d'emmerdes avec debian stable en desktop a devoir souvent bidouiller a cause des paquets de l'an plèbe.
 
  En environment assez lite recent j'ai bien aimé Budgie-desktop (gtk), en tilling aucun , et la j'ai fini chez kde plasma pour longtemps je pense

Même constat, que ce soit :
- au début, en dual boot avec W10 sur mon Laptop Toshiba
- en virtualisation
- et maintenant en monoboot sur mon PC fixe
... Archlinux est pour l'instant un long fleuve tranquille    
 
Pas mal de Fixed Release peuvent en prendre de la graine AMHA

En 2-3 mois pas de soucis à part les mises à jours qui ne se font pas 2 fois.
Un coup à cause de pamac et la semaine dernière à cause d’un fichier qu’il fallait supprimer manuellement.

edit : 3 fois en fait, ça déconne encore ce matin, pamac trouve les maj, mais ne télécharge pas...
 
edit 2 : ah non, après reboot ça fonctionne, peut-être la sortie de veille qui fait des sienne, je n'ai pas eu de demande de mdp dans pamac la première fois.

 
Hier matin -> démarrage de mon PC portable sous W10 -> Windows Update ne pouvait pas se connecter à internet    
Bref, si Archlinux est capricieux, faut pas regarder les autres alors  

je blâme pas, tant que ça en reste là ça va.

J'ai connu une version de Pamac qui déconnait ( résolu via une mise à jour de ce dernier )
J'utilise en parallèle Trizen désormais, histoire d'assurer le coup.

Du manuel dans tous les cas.
Il n'y a que les notifications qui peuvent être automatiques via Pamac ( il me semble )

A ce propos, j'ai remarqué que depuis quelques temps que les mises à jour de sécurité d'Ubuntu se téléchargent et s'installent automatiquement ( façon Windows )
 

 
Par contre, je ne sais pas si d'autres distributions Linux font de même...
Arch je ne pense pas que c'est dans les projets vu la philosophie de la distribution, qui donne à l'utilisateur le maximum de responsabilité sur son système.

C'est a toi de voir, rien ne t'empêche de garder un vieux système qui fonctionne.
 
Mais Arch c'est tout ou rien, il n'y pas des mises à jour juste de securité...

en théorie il y a plusieurs filets de sécurité, qui font que dans un monde idéal l'utilisateur final ne devrait pas avoir de problèmes quand il fait un "pacman -Syu" sur des dépôts stables, mais en pratique on aura quand même quelques bugs à cause de la nature "rolling-release" d'archlinux,

ces filets de sécurités sont :

1) le créateur du logiciel (gimp, libreoffice, firefox etc...) et ses béta-testeurs officiels, archlinux ne propose que les versions "release", pas "bêta" des logiciels (sauf à aller sur le dépôt aur)

2) le mainteneur du paquet : celui qui crée le paquet, normalement il est le premier bêta-testeur archlinux du paquet, certains sont très méthodiques et vont tester à fond le paquet, d'autres sont fainéants et se contentent de lancer un script de construction du paquet, pour le balancer
sur le dépôt testing en espérant qu'un cobaye trouvera les éventuels bugs, et parfois certains paquets jugés non critiques vont zapper les dépôts testing pour arriver directement dans les dépôts stables

3) les utilisateurs du dépôt testing : c'est le dernier filet de sécurité quand les 2 précédents n'ont pas fait leur travail de repérage de bugs,

mais il arrive que ces 3 filets échouent lamentablement, avec des paquets bogués qui arrivent dans les dépôts stables, ou parfois un bug qui ne peut se produire qu'avec un scénario particulier  (bug du noyau linux qui apparaît qu'avec un modèle de chipset particulier, de carte son, carte graphique, si les béta-testeur n'ont pas tous les types de matériels alors le bug passera inaperçu lors de la phase de testing),

pour limiter le risque d'attraper des paquets bogués :

- ne pas utiliser le dépôt testing (mais du coup ça réduira le nombre de cobayes, et augmentera l'arrivée de paquets potentiellement bogués sur les dépôts stables   )
- ne faire un "pacman -Syu" qu'une à deux fois par semaine, au lieu de le faire tous les jours
- consulter régulièrement le forum archlinux et son "bugzilla" avant de faire un "pacman -Syu" pour repérer les bugs : https://bugs.archlinux.org/

une fonctionnalité qui manque chez pacman :

- pouvoir distinguer les mises à jour "critiques/de sécurité" (noyau linux, xorg, navigateur internet), et les mises à jour non-essentielles (un bloc-notes, la calculatrice, un jeu),
ce qui permettrait de faire en priorité et plus souvent les mises à jour de sécurités, et retarder les autres mises à jour moins importantes,

mais comme archlinux est une "rolling-release" cela n'est peut-être pas possible ou trop complexe à faire, ce qui fait qu'un "pacman -Syu" va tout mettre à jour, même les paquets non essentiels

C'est plus qu'Arch est uniquement sous support avec une configuration exact, l'actuel.
Si tu veux avoir des paquets d'il y a quelques semaines avec d'autres d'aujourd'hui, tu peux faire cela toi meme mais tu n'auras aucun support des mainteneurs.

Je viens de voir qu’il y a une mise à jour de Wayland, je croyais qu’on ne l’utilisait pas encore.
En tout cas je suis sous x11, quel est l’intérêt d’avoir Wayland mais non utilisé ?

Pouvoir le tester afin de permettre sa mise au point définitive d'ici une ou deux décennies  

peut-être qu'un paquet archlinux a comme dépendance obligatoire wayland,

sinon j'ai remarqué qu'au fil des mois l'ensemble des paquets installés prenaient du poids sur la partition système,

quand je regarde la ligne "taille de mise à jour nette" de pacman ça affiche souvent des méga-octets supplémentaires, du coup au fil du temps l'espace libre de ma partition / se réduit de plus en plus, même si je n'installe pas de nouveaux paquets,

j'ai bien pensé à supprimer du cache de pacman les anciennes versions des paquets installés (pacman -Sc) mais ça ne résout pas le problème, je pense que ce sont les paquets installés qui prennent de l'embonpoint au fil des mises à jour, ou qui installent des nouvelles dépendances quand on fait un pacman -Syu,

il est possible aussi que des données s’accumulent dans le répertoire /var

C’est pas Gnome qui fait ça ?
---
EDIT :
Pour le reste de ton post, vois si tu peux pas virer les orphelins (pacman -Rdd $(pacman -Qdt), si ma mémoire est bonne).

J'ai kde chez moi.
Il y a pas une commande pour savoir quels softs utilise tel dépendance ?

Qi ne marche pas ?

J'ai d'ailleurs quitté Ubuntu à cause de ce Wayland, j'aimerais bien le virer

 
     
 
pacman -Qdt pour lister les orphelins
pacman -Rsn $(pacman -Qdtq) pour les virer
 
 

Ah je n'avais pas vu cela, Rdd c'est chaud!

idéalement il faudrait aussi combiner la commande "pacman -Qdt" avec une commande bash pour connaître la taille totale que prend les paquets orphelins sur le système, faire un "pipe" entre plusieurs commandes bash pour obtenir la taille totale occupée par ces paquets orphelins,

chaîner des commandes avec un pipe (|) mais j'ai la flemme de chercher, je sais juste que j'ai 107 paquets orphelins (via un "pacman -Qdt | wc -l" )