Lorsqu'un pilote graphique plante, ça n'emporte pas la session, ni le serveur X avec lui. Le pilote graphique est redémarré dans la plupart des cas(parce que la majeure partie est en espace utilisateur), et au pire une ou deux applications doivent être redémarrés (exemple : un jeu vidéo, un onglet de Firefox utilisant l'accélération graphique)
Entre redémarrer un serveur X et avoir droit à un joli BSOD sous Windows dans la majorité des cas issus de mon expérience personnelle, mon choix est fait.
Qu'un plantage d'un lecteur vidéo (SMPlayer, pour ne pas le nommer) ne ferme pas la session graphique (ça m'est arrivé, et même sur un linux correctement configuré et avec de bons pilotes)
J'aimerai vraiment avoir le log pour le coup, parce que ça ne m'est simplement jamais arriver. Au pire il crash lamentablement mais n'entraîne pas X dans sa chute.
Que les frappes au clavier lorsqu'on utilise X.org ne soient pas hyper faciles à enregistrer.
Accordé.
Que le rendu graphique soit toujours correcte, au lieu d'avoir des problèmes récurrents avec la synchro verticale chez de multiples personnes (ce qui donne, entre autre, des vidéos "déchirées")...
Partiellement accordé. En général, sur les configs desktops, une bonne configuration du xorg.conf permet de résoudre le problème. Pour les laptops c'est plus problématique mais c'est de la faute de Nvidia (pour les GPU Nvidia), je ne sais pas vraiment ce qu'il en est pour AMD.
Mais le Vsync pour les technos Optimus devrait arriver, le patch côté Kernel est dispo depuis le 4.5, le patch pour Xorg-server est prêt mais pas encore merge et les fixes sur le binaire Nvidia ne sont toujours pas disponibles...
... Ou des lenteurs lorsque les fenêtres sont dessinées à nouveau (suite à un redimensionnent, etc...) chez tout le monde parce que X.org est un "très mauvais middle-man" (dixit les développeurs... X.org !)
Je te laisse le bénéfice du doute, je n'ai jamais rencontré ce problème.
De pouvoir mettre un disque dur externe en veille lors de son démontage (c'est légèrement important pour beaucoup de modèles, histoire de pouvoir les utiliser sur une longue durée), sans devoir lancer un script en tant que root (Windows fait ça depuis 16 ans en deux clics)
Faire un script qui exécute # hdparm -B 1 -Y /dev/device ça ne me paraît pas non plus très fastidieux... C'est personnellement automatiquement exécuter avant chaque démontage par une tâche cron.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Mir et Wayland périmés
Posté par Nibel . En réponse à la dépêche Sortie d’Ubuntu 16.04 LTS Xenial Xerus. Évalué à 3.
Entre redémarrer un serveur X et avoir droit à un joli BSOD sous Windows dans la majorité des cas issus de mon expérience personnelle, mon choix est fait.
J'aimerai vraiment avoir le log pour le coup, parce que ça ne m'est simplement jamais arriver. Au pire il crash lamentablement mais n'entraîne pas X dans sa chute.
Accordé.
Partiellement accordé. En général, sur les configs desktops, une bonne configuration du xorg.conf permet de résoudre le problème. Pour les laptops c'est plus problématique mais c'est de la faute de Nvidia (pour les GPU Nvidia), je ne sais pas vraiment ce qu'il en est pour AMD.
Mais le Vsync pour les technos Optimus devrait arriver, le patch côté Kernel est dispo depuis le 4.5, le patch pour Xorg-server est prêt mais pas encore merge et les fixes sur le binaire Nvidia ne sont toujours pas disponibles...
https://devtalk.nvidia.com/default/topic/775691/linux/vsync-issue-nvidia-prime-ux32vd-with-gt620-m-/6
Je te laisse le bénéfice du doute, je n'ai jamais rencontré ce problème.
Faire un script qui exécute # hdparm -B 1 -Y /dev/device ça ne me paraît pas non plus très fastidieux... C'est personnellement automatiquement exécuter avant chaque démontage par une tâche cron.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.