freem a écrit 5059 commentaires

Faut voir, y-a-t'il du matos non-libre?

Si oui, il faut vérifier quelle distro l'intègre par défaut, ou, dans le cas de Debian, si c'est présent dans non-free.
La solution, utiliser des ISOs live. Sur une clé usb ou un dur externe, histoire de pas gâcher de la thune pour des prunes.

Pour le fait d'utiliser gnome3 et d'une lenteur, je ne serais pas surpris que ce soit lié, mais faut voir si tes pilotes graphiques sont à jour…
Par contre, je doute fortement que d'autres DEs aient une interface proche, puisque c'est justement l'IHM de gnome3 qui à entraîné tant de forks et à fait couler tant d'encre numérique.
Par contre, niveau DE léger dans un style à peu près gnomique, je dirai XFCE4. LXDE est "trop modulaire", ça risque de nécessiter plus de config et de bidouillage pour avoir un truc à tes goûts, et en plus ça risque de faire évoluer tes goûts ;)

PS: désolé pour le titre pourri, je savais pas quoi mettre…

[edit] grilled…plus ou moins ceci dit.

Et donc, toi tu es le modèle de référence?

Ah bah merde alors, moi qui considère que la diversité et la compatibilité avec elle c'est bien, je vais devoir revoir mes standards…

Je suis d'accord avec ton ratio : 99% mais dans mon cas c'est 99% des jeux n'utilisent pas QWSD, mais les fleches, ça doit venir du fait que je ne joue pas a des FPS.

Pour être un joueur de tout style sauf point and click et jeux de sports (arcade, jeu de baston un peu, FPS, STR, strat en tour par tour, rpg, roguelike…), j'insiste sur le fait que dans tous les styles il existe plusieurs gameplay.
Notion par contre fortement oubliée ce millénaire, à mon grand regret: de nos jours, les jeux d'un même style se ressemblent tous à l'exception des graphismes. On est loin des années 90, et même si je vais faire mon vieu con, c'est dommage, les jeux semblent usinés, faits à la chaîne, et c'est rare d'en trouver des originaux ( bien que ça existe, borderlands par exemple ne ressemble à rien d'autre, et est exceptionnel ).

PS : d'ailleurs, je regarde un peu la sdl 2.0 j'avais peur justement qu'ils l'alourdissent, mais je dois dire que ça m'a l'air d'être du bon boulot. t'en penses quoi ?

J'ai regardé très très vite fait, à diverses reprises. Je me suis senti un peu largué parce que l'API change radicalement, mais en effet, ça à l'air d'être une refonte clean, qui se "contente" de se mettre au goût du jour niveau matos ( utilisation d'opengl, possibilité d'avoir plusieurs fenêtres, support—il me semble—de plus de boutons de la souris et pas de juste 2+molette… ) ainsi qu'un rafraîchissement d'API.

Perso, étant dev C++, je regarde aussi pas mal du côté de SFML ( qui ne gère pas non plus les layouts, pour le coup ) qui est un concurrent direct de la SDL ( et supposément ce qui rendu du peps au dev de la SDL, à cause d'une grosse diff de perf ). De ce côté, même si la V1 était complètement chaotique niveau conventions de codage, la v2 semble plus clean, et me donne presque envie de faire un poc ( genre un truc basique: pong ou casse brique ) sur les 2 libs histoire d'avoir un comparatif d'utilisabilité… j'aime bien les 2 libs en fait, et je me sens un peu comme l'âne de Buridan XD

J'ai voulu ajouter gnumeric comme alternative à Excel, mais j'ai pas trouvé comment faire? J'ai dû passer à côté du bouton… oukilé?

Merci, plus qu'a retrouver la config qui marchait ( j'ai enfin un peu de temps pour m'occuper à nouveau de déployer des outils internes \o/ )

Merci, tu as sauvé pas mal de chatons la! :)

Pour le dernier point, une petite liste non exhaustive des jeux auxquels j'ai joué sur PC, mais qui sont assez peu connus à voir ta réaction:

• age of empires
• dune II
• command and conquer
• battle for wesnoth
• duke nukem
• master of magic
• unvanquished
• nexuiz
• flare-rpg
• dungeon keeper ( 1 et 2, mais le 1 était bien plus fun )
• battlefield 2142
• medal of honor allied assault
• mortal combat
• red eclipse
• unreal tournament

Je continue la liste ou ça te suffit?

Pour les jeux de stratégie, c'est en général les touches fléchées, pour les FPS classiquement c'est ZQSD bien que j'aie connu d'excellents joueurs qui utilisent les flêches parce qu'ils préfèrent le clavier numérique pour changer les armes. Et j'en connais même un qui utilise esdf, bah oui, plus de touches à portée…
Et pour les jeux bâtards style dungeon keeper, qui mixent STR et FPS, idem, amuses toi à te passer des touches fléchées pour voir?

Du coup, je te renvoie la question: tu as déjà joué à des jeux avant?

Vu que je me suis remis à might and magic, et que je me souviens à peu près de duke:

les touches pour orienter la vue sur l'axe vertical, et pour voler, sont affectées par défaut aux touches:

• supprim et pg down pour la vue
• inser et pg up pour monter/descendre quand on vole ( sort de vol pour MM6, jetpack pour duke )

Ok.

Might and magic VI

Tu peux te remettre en cause, merci.

Allez, je suis grand prince, je t'en cite un second: duke nukem

Bon, je m'incruste, mais j'ai vu des trucs qui m'agacent dans ce thread.

Petite liste:

• la touche pg up n'est jamais utilisée par les jeux ==> alooooooors, duke nukem, might and magic, divers autres FPS ( je me souviens aussi que certains jeux libres et récent utilisent ces touches en config alternative pour le coup, mais pour pas dire d'ânerie je ne vais pas citer de noms. Je vous encourage à aller dans aptitude, et consulter la vue par debtags->jeux et fouiner du côté des jeux quake-like… ) que je connais ne doivent pas être des jeux. En réalité, je la vois souvent utilisée par ceux qui préfèrent les touches flêchées au ZQSD. Et j'en connais plusieurs ( j'ai même connu de bons joueurs dans ce cas, pas juste des "noobs" ), qui utilisent les touches appropriées et non pas ZQSD.
• la SDL est faite pour les jeux ( raccourcis très rapide de "la SDL, pas d'une bibliothèque générale, mais d'une bibliothèque qui est beaucoup utilisée dans les jeux" ). MOUAHAHAHAHAHAHA!!!!!! Si je l'enlève de ma machine actuelle ( je suis au boulot ) je casse blender, gimp, makehuman ( bon ok, ces 3 logiciels ne me servent que pendant les pauses, j'avoue ), virtualbox, et mplayer. Combien de jeux dans cette liste? Et je gage que si j'avais un DE classique au lieu d'une machine minimaliste je casserai bien plus de choses. Au passage, j'en profite que les touches ZQSD sont utilisées par blender pour diverses choses, mais sûrement pas pour déplacer la vue ( a minima: S pour Scale, Z pour activer/désactiver le mode filaire).
• c'est à la SDL de gérer les layout. Archi faux, encore une fois. La SDL est, je cite, "a cross-platform development library designed to provide low level access to audio, keyboard, mouse, joystick, and graphics hardware ". Autrement dit, elle existe pour permettre aux dev d'utiliser le matos sans s'occuper de l'OS. Le matos en question n'est pas nécessairement un PC, d'ailleurs la SDL fonctionne sur des tablettes, entres autres, si je ne m'abuse. Cette ( bonne ) lib n'est pas encore un bloatware, et je prie que pour ça soit le cas encore longtemps, parce qu'un accès vidéo simple, c'est vital quand on a pas envie de se cogner 30 pages de docs de divers OS/framework pour faire un truc aussi simple que changer la couleur d'un unique pixel. Les layout ne font pas partie des choses de bas niveau, ne t'en déplaise.

Je vais donc insister lourdement: la SDL n'est pas faite pour les jeux, il se trouve juste que certains jeux connus s'en servent, parce que ce n'est pas un bloatware et que contrairement à nombre de framework, elle n'impose aucun outil.
Merci donc de la conserver simple et efficace, sans qu'elle ne fasse de choix par défauts àlacon (tm) en fonction du baromètre. C'est tellement agréable d'avoir un tournevis qui juste tourne des vis dans le sens et à la vitesse demandés… (Merci à toi Sam Lantinga, qui à rendu la facilité de dessiner sur un écran à des dev passés du mode réel au mode protégé o/ )

Mais comme la critique est facile, je vais te suggérer une solution.
Plutôt qu'utiliser des touches lettrées pour des déplacements, utilises donc les touches fléchées, qui sont faites pour ça. Si elles sont trop loin des autres touches de ton clavier, modifie donc ton layout pour les mettre au milieu du bloc principal ou achètes un clavier dédié au jeu, et ensuite, tu auras le droit de râler qu'une config par défaut ne prenne pas en charge ton layout, n'utilise pas les touches pour l'usage pour lequel elles ont été conçues.
Enfin, je tiens à signaler à l'aimable assistance que certains jeux, tels que flare, sont capables, moyennant contribution, d'intégrer diverses configurations par défaut ( il fut un temps ou un français avait contribué une disposition qui lui convenait sur le wiki de flare. Depuis, cette disposition à été intégrée dans un jeu de configurations paramétrables.).
Par contre, ce n'est pas détecté par défaut, il s'agit d'un choix de l'utilisateur. Ça peut paraître stupide, mais, comme je l'ai indiqué, la configuration "locale" en question à été faite pour convenir à son auteur uniquement, puis partagée au cas où d'autres la trouveraient utile. Au passage, si quelqu'un veut un truc automatique pour la france, rien ne l'empêche de créer un package sélectionnant la config française par défaut, comme c'est le cas notamment pour firefox ou libre office… après c'est sûr, il y a plus de boulot que pour poster sur un forum )

En même temps, pourquoi certains francophones utilisent-ils dvorak, bépo, diverses dispositions qwerty, voire même, comble de l'horreur, des dispositions azerty non franco-françaises? Mais quels idiots… les autres, les français azerty classiques représentent 99% des utilisateurs et on se fait chier avec eux? ( oupa )

Je gage que 0AD ne crachera pas sur les contributions de la dite aimable assistance. Par contre, je doute que critiquer sur un forum quelconque ( pas celui de 0AD donc, dans ce cas précis ) sans connaître les problèmes techniques derrière permettra d'améliorer les choses. Peut-être que je me trompe.

Comme dans tant de jeux…

Alors, je ne vais pas aider, ou du moins, pas directement.

Quand on demande de l'aide sur un programme, on essaie de reproduire le problème avec un bout de code minimal, et d'être succinct.
Sinon, peu probable que des gens soient motivés à lire l'ensemble du source.

Autre point, il existe des outils dont on ne te parlera probablement pas à l'école, mais qui sauvent de nombreux chatons tous les jours de la fureur des dev qui perdent patience, j'ai nommé les outils de versionning.
Pas mal d'avantages, notamment au sujet de comment faire de petites itérations qui évitent d'introduire de super gros bugs, et quand c'est le cas, si les itérations étaient assez petites, de retrouver rapidement le bout de code coupable en cas de régression.
Personnellement, j'apprécie bien git, mais il existe aussi subversion ( ou svn ), mercurial ( ou hg ), bazaar, fossil… pour débuter sur de petits projets, je dirais que fossil est pas mal, mais je ne connais pas de forge logicielle sur le web qui l'utilisent.

Le lien entre le VCS et l'aide sur les forums, c'est que si t'es flemmard, tu peux juste balancer un lien vers ton repo. Et si tu es chanceux quelqu'un ira le lire… mais une fois encore, si tu n'as pas de code minimal qui montre le comportement erroné, c'est peu probable.

Ensuite, au sujet de linuxfr, quand tu mets une balise, genre "```" il faut sauter une ligne avant de la mettre, sinon ça marche pas ( je me suis fait avoir plusieurs fois aussi ).
D'ailleurs, le bouton pré-visualiser est là pour ça ( l'aiguille dans l'œil du voisin, je la vois mieux que la poutre dans le mien ;) ).

Enfin, pour conclure, il s'agit d'un problème de programmation, python, je suppose ( commentaires bash-like, orienté objet, je ne connais pas python, mais je ne serais pas surpris )?
Donc il aurait fallu mettre ce message dans les problèmes de programmation, ce n'est pas spécifique à linux.
Et bien sûr, il aurait fallu préciser le langage, ainsi que les technologies employées qui pourraient impacter le comportement mis en cause.

Ah, et dernier point ( pour de vrai ce coup-ci ): essayez de diviser le code au maximum en fonctions.
Même si la fonction n'est appelée qu'une seule fois, et ne fait que 10 lignes, ça rends le code plus clair, surtout après 2 semaines de pause. Autre avantage: si un jour la même chose est nécessaire ailleurs, il est possible de réutiliser la fonction, et donc d'éviter d'avoir à corriger les choses à 20 coins différents.

Petit exemple:
déplacement bas-gauche
et
déplacement haut-gauche
Leur code est très semblable. Suggestion: une fonction qui applique un déplacement serait probablement intéressante, prenant, au hasard ( j'ai juste survolé le code ), une coordonnée à modifier en entrée, un offset à lui appliquer pour la direction, le nombre d'itérations ( j'ai noté 10? ) ainsi que les probables coordonnées du rectangle dont il ne faut pas sortir.

Une fois le tout refactoré pour être plus propre, ce sera plus simple d'avoir de l'aide, et d'ailleurs, peut-être même que vous aurez trouvé le problème de vous-mêmes.

En théorie, oui.

Dans la pratique, je ne suis pas si sûr. Il me semble par exemple avoir vu dans flare-rpg des raw pointers utilisés à coups de new/delete il y a de cela bien 2 ans ( ==> attention au memory leaks humains donc ).

Je me souviens aussi clairement que la première fois que j'ai entendu parler de smart pointers, c'était bien après mes études, grâce au fait que je fouine sur le net au sujet de comment améliorer mes connaissances sur ce langage ( je suis encore si loin d'être un expert… encore de nombreuses années à fouiller en perspective, miam ).

Si on enseignait encore aux étudiants en 2005 l'utilisation de raw pointers en C++, penses-tu que ceux-ci utilisent des smart pointers?

C'est valable aussi sous Linux, si tu as besoin de Ruby 1.8 et que ta distrib ne fournit que la 2.1, c'est problématique.

Oui, mais au moins tu connais le problème, vu que les systèmes de gestion de paquet savent faire la différence entre 2 versions et exiger une version "au minimum" et/ou "au maximum".
Sous windows, il faut faire des vérifications manuelles, si je me souviens bien.

Bah, il suffira d'y intégrer en natif open office, non?

Je t'avoue que je ne m'étais jamais penché sur le fichier de configuration, pour le coup, alors que c'est un truc que je fais quasi-systématiquement pour mes outils habituels.
J'imagine qu'il s'agit la de la différence entre outil et jeu, moins envie de me prendre la tête pour un jeu que pour configurer mes outils de tous les jours :) ( et c'est un tort, probablement )

Et tu retrouve un problème de compatibilité pour tous les langages non natif.

C'est un fait. Après… c'est vrai que je me suis peut-être trop habitué à ne plus être sous windows et à avoir des paquets qui vérifient de façon simple et efficace la présence des dépendances.
D'un autre côté, même si tu embarques un langage natif ou pas, tu te retrouveras toujours avec des problèmes de dépendances, des gens qui essayerons d'utiliser un mod fait pour une version du langage interprété qui ne correspond pas à celle avec lequel le jeu à été compilé, par exemple. En natif, tu as le souci des libs installées.

De base, le JS a quand même accès à bien moins de fonction.

Le problème n'est pas d'avoir accès à moins de fonctions, mais à quel point elles sont user-proof ainsi qu'a quel point le code appelant est résistant aux erreurs, et ça, il faut bien le gérer quelque part. Par exemple, ValyriaTear qui utilise du lua n'est pas spécialement résistant, et j'ai expérimenté des crash dus à des erreurs dans le code lua. Forcément, vu que c'est pas compilé dans un binaire, la vérification doit se faire au runtime, et on peut se retrouver avec des versions foireuses.
Autre exemple, il y a encore pas si longtemps, voir des navigateurs bugguer à bloc à cause d'un code JS foireux n'était pas hors-norme. Et de gros bugs sont au moins aussi frustrant pour le joueur qu'un crash propre ( on surcharge std::terminate pour qu'il fasse une autosave, si on a une appli suffisamment exception-safe, au moins le joueur n'a peut-être pas perdu tout son temps… ) selon mon opinion très personnelle de joueur.

Bien sûr, c'est sans doute faisable, mais c'est un gros boulot pour un bénéfice assez limité.

C'est pour ça que j'ai dit que je suis d'accord et que mon objectif n'était que de nuancer.
Les systèmes extensibles, ce n'est jamais simple à faire, entre la stabilité nécessaire de l'API et les protections du jeu contre le système d'extensions, et c'est encore pire quand les dites extensions sont modifiables sans re-linker le binaire, puisqu'on a alors plus aucune garantie quant à leur validité.
Attention, je ne dis pas que les langages interprétés sont mal, juste que chacun voit le juste milieu entre vitesse d'exécution, sécurité de l'extension ( pas au sens attaque, mais au sens bug ), souplesse ( quel langage? ) et autres paramètres.

Effectivement, devoir passer par su ajoute un pass, donc de la sécurité et évite qu'un couple login/pass se fasse casser trop vite ( surtout que j'imagine que le nom "root" n'est jamais changé? ). Même si j'avais parlé d'authentification SSH via les fameux fichiers id_rsa et id_rsa.pub. Penses-tu que leur usage fragilise un système? Après tout, si on s'en fait piquer un, on compromets directement le système ( et du coup effectivement interdire l'accès root est très pertinent )?
À moins qu'il soit possible de limiter l'usage de ces fichiers pour des clients ayant tel hash?

Sinon, utiliser un honeypot et un fail2ban sur le 22, ça me semble "dangereux" si quelqu'un zappe le numéro de port? Enfin, c'est sûr que ça ajoute en sécurité…

Bon, bah si les perfs ont été nettement améliorées, je pourrais peut-être arriver à déplacer mon curseur dans l'écran d'accueil.

Pour le coup, j'ai 2 questions:

• le menu options, a-t-il enfin été implémenté pour pouvoir régler les options graphiques? La dernière fois que j'ai essayé, ce n'était pas le cas ( la 13, je crois ? )
• est-il maintenant possible de jouer en fenêtré? Par qu'avec mes 2 écrans dont les résolutions et la forme géométrique diffèrent, le fait de ne pouvoir jouer qu'en full screen est juste complètement bloquant.

Enfin, je réessayerais dès que je pourrais, quelles que soient les réponses à ces questions, ce jeu à l'air tellement prometteur sur le papier…

Le jeu à des contributeurs divers et variés, qui modifient une base de code unique en y envoyant de petits patchs, modifiant le moins de ligne possible.
Du coup, on arrive à avoir une bonne idée rapidement et même sans comprendre le code de ce que fait le patch, grâce à son intitulé.
Comme ils "commitent" régulièrement leurs modifications, les conflits sont rares et simples à résoudre, encore une fois surtout grâce à l'intitulé des commits.

Si un contributeur fait "silence radio" ( en terme de modifications visibles du code, je parle ) pendant 1 mois, et modifie, disons, 100 lignes par jour ( pas énorme, je précise, 100 lignes par jour ). Comptons 20 jours de travail dans un mois. Ça 2000 lignes à lire, et à intégrer avec les modifications qui ont eu lieu entre temps.
A savoir que quand on travaille sur une ligne, un diff peut l'afficher de plusieurs façons différentes:

• insertion de code: ligne ajoutée
• suppression de code: ligne supprimée
• modification de code: ligne ajoutée, puis ligne ajoutée

Pas forcément super lisible, surtout que parfois la modification est de l'ordre de 1 caractère sur une ligne de 60 caractères de large.

Et bien entendu, ces 2000 lignes ne sont pas monolithiques, mais éparpillées partout dans plusieurs fichiers. Vu le jeu, je dirai plusieurs dizaines de fichiers.

Ces modifications peuvent être de l'ordre du bug-fix et de l'ajout de fonctionnalités "simples", là, ça reste aisé: de petits blocs par-ci par-là. Mais ça peut aussi être structurel, comme 0AD est en alpha, l'API n'est pas stable.

Tout ça, ça rends difficile l'intégration du travail dans l'existant.

Pour finir, je doute très fortement que le patch se limite à "seulement" 2000 lignes changées entres autres parce que si j'ai bien compris il à bossé 6 mois ( donc déjà 12K lignes ).

Maintenant, j'insiste: le KLoC ( Kilo Lines of Code, milliers de lignes de code ) est une métrique complètement stupide et inutile, à destination des gens qui croient que plus il y a de lignes dans un programme, plus il y a de travail. En réalité, le plus dur est de faire du code simple.

Même si je suis d'accord sur l'ensemble, je tiens à nuancer un peu ton propos.

il faut compiler pour chaque architecture et chaque compilateur pour lequel le jeux est compatible

Pour l'architecture, c'est vrai ( quoique, sur une multi-arch ia64, on peut exécuter du i386… mais ce serait dommage ). Pour les compilateurs, c'est partiellement vrai.
La difficulté dans un système de plug-in écrit en C++ est de ne pas casser l'API bien sûr, comme pour tout langage, mais aussi l'ABI, ce qui est plus compliqué.
Mais plus compliqué ne signifie pas impossible, une méthode régulièrement utilisée est d'exposer une API C-style, qui est un langage dont l'ABI est stable ( évidemment, il n'y a pas de méthodes virtuelles, déjà, et l'ordre de résolution des paramètres d'une fonction est imposé par le standard, contrairement au C++ ), et d'ensuite refaire une bibliothèque C++ qui l'encapsule si on tiens à retrouver les avantages du C++ ( exceptions, type-safety, notamment ).
Cette méthode permets aussi de pouvoir créer des plug-ins dans d'autres langages, il suffit de créer la lib d'encapsulation correspondante.
Du coup, au final, cette façon de faire permettrait au contraire de faciliter les mods, puisqu'on ne restreindrait plus le langage utilisé au javascript ( qui a, j'ai l'impression autant d'admirateurs que de détracteurs ) mais à tout langage capable d'appeler du C. C'est à dire, la majorité de ceux que je connais.

D'autres jeux, je pense notamment à unvanquished, utilisent des machines virtuelles en C, et la dernière fois que j'ai mis le nez dans ce jeu la, la possibilité d'utiliser LLVM au lieu de QVM était une piste pour permettre un code plus C++ tout en restant exécutable d'une archi à l'autre ( quoique j'ai un doute, on peut vraiment exécuter le même binaire sur un amd64 et sur un proc ARM? À vérifier tiens ).

Pour le problème de sandbox… c'est la même chose en JS non? Je veux dire, l'isolation doit toujours se faire, même si pour le coup, c'est une outil externe qui le fait… et sûrement partiellement j'imagine, je doute qu'il n'y ait aucune protection dans le code lui-même.
En C++ c'est vrai que ça me semble pas évident, il faut à tout le moins surcharger new, delete ( qui sont des opérateurs comme les autres ) pour, je dirai, si je devais faire un truc pareil, interdire tout appel à delete et forcer un retour de std::unique_ptr du new.
Dur, mais à vue de nez, semble faisable et éviter quelques problèmes ( quoique unique_ptr expose potentiellement le pointeur interne via la méthode get. Il faudrait probablement restreindre ce smart pointer pour interdire certains appels, mais ça ne me semble pas infaisable ).

Je précise et j'insiste, que c'est juste une idée en passant, je n'ai pas étudié son bien fondé ni sa faisabilité. En plus, je doute très fortement que 0AD soit écrit en C++11. Et pour cause, il me semble que le dev à commencé bien avant.

ni quelle éventuelle trace donner

rien dans les logs de Xorg ou dmesg?

Ce qui m'inquiète, c'est que mon mot de passe, bien que court (8 caractères), était quand même loin d'être trivial (des minuscules, des majuscules, 1 chiffre et 1 ponctuation).

Je me demande s'il n'est pas possible d'interdire l'usage de la commande "su"? Si c'est le cas, alors il serait peut-être intéressant d'interdire tout accès au compte root qui ne passe pas par ssh, et de mettre en place l'usage des ~/.ssh/authorized_keys, solution tout de même plus blindée que d'utiliser des passwords.

C'est normal d'avoir à la fois glx et dri d'installé. La question était plutôt de savoir si swx11 était installée, elle aurait pu déclencher ce bug.
Tu peux par contre tenter d'installer libgl1-mesa-dri-experimental, des fois que ça amène une fonctionnalité nécessaire. Il y avait aussi un paquet qui permettait d'activer des fonctionnalités opengl ( considérées comme expérimentales ou pas assez stables ) fournies par la paquet dri, mais je suis absolument incapable de me souvenir de son nom, désolé.

Tu peux aussi vérifier que les paquets recommandés ou suggérés par KDE sont installés, il m'est arrivé de faire bugger des appli à cause du fait que j'ai un système minimal, parce qu'elles ne dépendaient pas explicitement d'une lib externe.

Ça pourrait être un problème d'accélération 3D. En fait, c'est de ce côté que je chercherais en premier personnellement:
KDE, ça bouffe de la ressource, donc ils doivent probablement exploiter le GPU, alors que la dernière fois que j'ai utilisé XFCE ( 4.10 ) il n'y avait pas besoin d'accélération 3D.

Regardes du côté des libgl1, notamment, as-tu installé libgl1-mesa-glx ou libgl1-mesa-swx11?
La première fournit l'accélération GPU ( hardware ), l'autre une accélération CPU ( software ).

J'avais aussi eu, dans le passé, un problème avec des fonctionnalités openGL qui n'étaient pas activées par défaut, reste à se souvenir quel utilitaire j'ai utilisé…