freem a écrit 5019 commentaires

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é…

Parce que le browser fait la même largeur pour tous les onglets.

Faux.
C'est peut-être le cas de ton browser, mais le mien réinvente la roue intègre un gestionnaire de fenêtre complet ( flottant en plus :/ ). Que l'on aime ou pas.
Donc, mes onglets peuvent très bien ne pas tous faire la même taille.

Ah ok merci.

Je me garderai ça dans un coin de mémoire, ça peut servir :)

Hum… je ne suis pas sûr de comprendre. Tu me dis d'utiliser un outil spécialisé, j'imagine?

Mais bon, aujourd'hui il se trouve que c'est du json ( dont je ne suis pas sûr qu'il soit complètement conforme en plus ) et demain ça pourrait très bien devenir du xml ou du yaml.

Mon objectif, là, c'est vraiment de trouver un mécanisme pour tester le retour d'une API web modulo les retours à la ligne, et pour ça je ne connais, pour le moment, que curl + un fichier de requêtes monolignes + un fichier de résultats monolignes de référence, et on compare le retour des requêtes transformé en monoligne au fichier de résultats de référence.
Quand on sait quelle ligne diffère, on sait que telle requête pose un problème ( reste à trouver lequel et déboguer, mais bon… )

Ahhhh!!
Bien, en effet, ça marche tout seul :)

Merci beaucoup.

Pas de \r, parce que pas de Windows ni de Mac derrière ( et pour le coup, c'est plutôt les unix et les mac qui enlèvent un morceau de la fin de ligne: LF signifie nouvelle ligne, et CR retour chariot, donc il faut logiquement combiner les 2… pour une fois que MS fait un truc plus propre que les autres… )

Pour le test, pour le moment je ne teste rien, je veux d'abord récupérer le retour sur une seule ligne, afin de pouvoir facilement comparer, justement. Et si un test ne passe pas, il me suffirait ainsi de juste regarder quelle ligne pose problème pour connaître le test ( puisque j'aurais alors d'un côté une liste de lignes contenant les requêtes, et de l'autre côté une liste ou chaque ligne correspondrait à la requête de même ligne ).

Enfin bref:
Sans "od -c" ( je connaissais pas cette commande, ça à l'air utile ):

{"CorrelationID":"test","MessageResponse":[
{"ResponseCode":4,"ResponseComment":"LineColor too long, it will be truncated"},
{"ResponseCode":0,"ResponseComment":"success"}]

Avec:

0000000   {   "   C   o   r   r   e   l   a   t   i   o   n   I   D   "
0000020   :   "   t   e   s   t   "   ,   "   M   e   s   s   a   g   e
0000040   R   e   s   p   o   n   s   e   "   :   [  \n   {   "   R   e
0000060   s   p   o   n   s   e   C   o   d   e   "   :   4   ,   "   R
0000100   e   s   p   o   n   s   e   C   o   m   m   e   n   t   "   :
0000120   "   L   i   n   e   C   o   l   o   r       t   o   o       l
0000140   o   n   g   ,       i   t       w   i   l   l       b   e    
0000160   t   r   u   n   c   a   t   e   d   "   }   ,  \n   {   "   R
0000200   e   s   p   o   n   s   e   C   o   d   e   "   :   0   ,   "
0000220   R   e   s   p   o   n   s   e   C   o   m   m   e   n   t   "
0000240   :   "   s   u   c   c   e   s   s   "   }   ]  \n   }
0000256

S'il y a une chose que je ne me permettrait pas de dire, c'est que c'est simple :)

Sinon les journeaux ( les vrais, ceux avec une ligne éditoriale, pas les agrégateurs de news venant d'ailleurs ) n'existeraient pas.

Ah, je ne savais pas que xrandr peut manipuler les fenêtres… bon à savoir ça.

Ce genre de problématiques ont déjà été abordées il y à quelques mois, notamment ici.

À mon avis, il faudrait déjà séparer le contenu périssable du non périssable ( la notion de périssable étant dépendante d'un seuil de temps, disons 2 mois ). Par exemple, une nouvelle version de firefox, un apéro python, une install party, un article pour prévenir d'une faille de sécurité, sont des évènement périssables.

Alors que la présentation d'une nouvelle version d'un logiciel stable ( dans ses versions ) comme un blender, une Debian, RHEL sont toujours périssables, mais avec une date de péremption largement supérieure: je dis des bêtises, mais, 1 an, 2 ans?

Finalement, des articles présentant des techniques et des tutoriels sont très peu périssables, notamment la série des "je crée mon jeu vidéo".

J'ai envie de dire que si l'on pouvait avoir, par exemple, un mécanisme séparant ces documents en fonction de leurs dates de péremption, il serait plus simple de naviguer au travers des contenu toujours d'actualité.
Par exemple, imaginons 3 colonnes, une pour les trucs qui sont très temporelles, les news, une pour les articles à durée de vie moyenne, et une dernière pour les contenu "permanents".

Il serait aussi intéressant de scinder par articles localisés géographiquement ou non. C'est bien qu'il y ait des évènements autour du libre et qu'on en parle sur un site d'information qui y est dédié, mais ce n'est pertinent que pour une "minorité" de personnes ( en plus de n'avoir habituellement un intérêt que très temporel ).

Hum… je me demande si, avec un gestionnaire de fenêtre qui expose ses commandes via une IPC, ce ne serait pas scriptable de façon précise?

Bon, ça reste loin d'être pratique sauf pour les amateurs de ligne de commande, et il faut encore que le WM le permette ( je ne suis pas sûr qu'i3 permette ce genre de joyeusetés, il faudra que je vérifie le jour ou j'en aurait l'utilité ).

Mais même une fois redimensionnée à une taille supérieure il reste le problème d'avoir la vue d'ensemble: si la fenêtre est plus grande que l'écran, il faut l'agiter dans tous les sens, alors qu'avec un outil adapté, on peut juste scroller dans la fenêtre.

Bon, je ne suis pas un grand sportif, et j'aime encore moins regarder des gens pratiquer… ( quoique… l'escalade à la rigueur, pour la pratique comme pour regarder, ou l'escrime artistique…. mais ce n'est pas le sujet que je veux aborder ) donc je ne suis pas concerné au premier point.

Par contre, un point m'a paru particulièrement ingénieux au niveau de l'identification: utiliser des flash-codes pour réduire la pénibilité de gérer des méthodes d'identifications via wi-fi.
Par contre, je me dis qu'il y a un certain nombre de risques: si une personne parviens à flasher la même image, y a t-il une sécurité qui bloque l'un des identifiés partageant la même identité, ou mieux, l'ensemble?

Autre point, pour l'identification, quel type de méthodes ont été utilisées? J'imagine un mécanisme de clés privées/publiques, un peu comme ssh, je me trompe?
Si c'est le cas, quelle lib à été utilisée?

Tel que je l'imagine, je suis tenté de supposer que le flash-code contiens une clé privée dont l'alter-ego publique est stockée dans un ~/.ssh/authorized_keys mais ça, ça aurait plutôt été une solution pour un script shell, pas une application C++?

Mozilla est un projet libre

Tu forkes quand? :p

Après tout, si un projet libre se détache de sa communauté, et à fortiori de ce que pensent ses contributeurs sur la ligne de conduite, le fork est bien la meilleure solution?

Mais peut-être les contributeurs de FF ne sont-ils pas majoritairement d'accord avec toi…

Ça, ce ne serait pas faux, après tout, pour rendre un truc accessible, il faut qu'il soit utilisable :)

( oui je sais, pas vendredi… )

Je suis pourtant persuadé d'avoir essayé… bon pas grave, ça fera juste une connerie de plus de ma part :)

Le seul point commun c'est que les deux utilisent un navigateur pour son IHM.

Ils utilisent tous les deux habituellement les mêmes langages également. HTML+CSS, JS, SQL ( à moins qu'il n'y ait pas de base de données derrière ? ) et [PHP|python|perl|autre].

Ils ont aussi en commun le fait de devoir faire des workaround à cause des différences entre les navigateurs, ou de choisir de n'en supporter qu'un seul.

Au final, même après ton explication, je ne vois pas où est la différence entre un site web ( qui peut être interne ou pas ) et une application web ( même chose ). Que ça mette 5 minutes à réagir, pourquoi pas, mais bon, au final moi quand j'attend 5 minutes après mon PC, déjà je peste, et en plus je me demande: "planté ou pas planté?" avec CTRL+ALT+SUP qui me démange ( enfin, pas tout à fait cette combinaison, mais l'idée est là ).
Je doute que tes utilisateurs ne ressentent pas la même chose, et un utilisateur content est un utilisateur qui cherchera ( et trouveras ) moins de moyens de contourner les procédures établies ( pour de bonnes ou de mauvaises raisons, peu importe ).

Sinon, je me rappelle d'un prof qui disait que la sécurité informatique, c'est pas juste la résistance aux attaques. Son point se défendait en se disant qu'une panne, c'est pas une attaque, idem pour un comportement accidentel de l'utilisateur ( ou d'un admin, une boucle dans un script est si vite arrivée… )

Et pour le coup, la petite image :)

En parlant de configuration… ce n'est pas désactivable, la MaJ automatique? Et je pense que faire des MaJ automatiques en prod, c'est quand même pas terrible comme process de dev, non? ( enfin, sûrement pas pire que ce qui se fait dans ma boîte actuelle… on a même pas de dépôt de source, et je suis le seul à préferer git à cpold :/ ==> œil, paille, poutre, tout ça… )