pepp a écrit 82 commentaires

Les microbenchmark ne veulent pas dire grand chose.

Peut-être que son microbenchmark est une simplification d'un cas réél qu'il a rencontré ?
Par ex j'avais prévu d'écrire un journal sur perf avec un microbenchmark mais en ayant pris soin de vérifier que les résultats du microbench étaient cohérents avec ceux de la vraie application.

En tout cas merci à l'auteur pour ce journal, très intéressant :)

des bénéfices non nuls en terme de sécurité et sans aucune dégradation des perfs

On perd quand même le support de l'hibernation.

Et les contraintes d'alignement limitent à 512 le nombre d'emplacements mémoire possibles pour le noyau.
C'est quand même léger comme aléatoire…

Publier une vidéo sur Youtube sans fournir aucune information ne fait pas avancer le schmiblick. Pourquoi ne pas montrer clairement le code source et aider à corriger la faille de sécurité ? Sûrement pour se faire mousser et vendre son travail sur GRSecurity.

Ce post (le lien est dans la vidéo que tu cites et également dans la dépêche) détaille son point de vue qu'on pourrait résumer par : KASLR est une mauvaise implémentation d'une idée de départ douteuse (ASLR).

Et toujours d'après son texte il n'y a pas "une faille de sécurité" à corriger : il y en a des tonnes.

Information leaks are the critical weakness of ASLR, and KASLR amplifies this weakness. […] Linux has been struggling with infoleaks for years and even still they're readily found

Je suis loin d'être expert en sécurité, mais ses arguments ont l'air de se tenir et son post est largement sourcé.

Pour info on utilise un simple:

add_definitions(-DASSETS_DIR="${CMAKE_SOURCE_DIR}/assets/")

dans le CMakeLists.txt.
Ensuite les données du jeu sont lues depuis $ASSETS_DIR et ça permet de lancer la version de dév depuis n'importe quel endroit (et de compiler en dehors du source).

J'aime bien gedit, mais je ne suis pas d'accord avec leur point de vue.

100% d'accord. Si les dév de gedit le considèrent presque à la hauteur de ST, ils manquent clairement de recul.

J'ai utilisé gedit comme éditeur de code pendant longtemps, et après avoir testé ST 1 heure il est impossible de revenir en arrière.

Alors bien sûr les 2 savent éditer du texte, à part ça :
* mode hexadécimal sur gedit ?
* curseurs multiples ?
* ouverture des fichiers en utilisant uniquement le clavier + prévisualisation instantanée des fichiers ?
* super rapide (même sur des gros fichiers) ?
* minimap du fichier ouvert à droite ?
* gestion minimale de projet ? Pour ceux qui ne connaissent pas : ça permet d'appliquer une configuration à un ensemble de fichier, d'exclure certains fichiers, etc…

Et c'est juste ce qui me vient à l'esprit en réfléchissant 2 minutes.

Avez-vous regardé ce qui se fait sur Windows ou MacOS par ex ?

Je ne sais pas si c'est sécurisé chez eux, mais ils se sont peut-être déjà posé les mêmes questions.

Je recherche pour l'un de mes clients Montpelliérain

Au hasard, Intel :) ?

Je crois que tu n'as aucune idee de ce que fait la concurrence techniquement !

En effet, par contre j'ai une bonne idée de ce que fait LibreOffice et du temps passé à résoudre des problèmes uniquement causés par du code jamais repris de 0.

Or les avances de LibreOffice dans le domaine sont extremement prometteur bien plus que la concurrence.

C'est encore mieux de les lister :)

De mon côté j'apprécie les progrès de Calc. Je suis beaucoup moins impressionné par l'évolution de Writer (quelles 'avancées' prometteuses ont été réalisées ?) et d'Impress (même question).

Je dois dire que je n'ai pas compris ta blague ni ce qui te fais penser que je sous estime le besoin d'evolution?

Ce n'est pas le besoin d'évolution que je pense que tu sous-estimes, mais la difficulté de faire évoluer LibreOffice tout court (à cause du code, des concepts utilisés, etc).
Plus exactement je réagissais à la doctrine que tu reformules dans ton commentaire :

Reecrire une base de code depuis zero est la pire erreur qui peut etre faite.

Que je trouve absurde quand elle est énoncée comme une vérité absolue.

Concernant LibreOffice les développeurs principaux ont choisi l'évolution rapide au prix de quelques régressions, on verra dans quelques années si ce choix est viable ou non.

(hum, une remarque en passant pour les moinsseurs : je participe au développement de LibreOffice - mais bon, restez avec vos certitudes : puisque Joel Spolsky le dit c'est que c'est vrai il faut toujours conserver le code existant et ne jamais repartir de zéro)

Pour le reste, je ne crois pas que tu comprennes la difficulte et l'enormite de la tache.

Et peut-être que tu ne comprends pas la difficulté et l'énormité de la tâche qui consiste à faire évoluer LibreOffice suffisamment pour qu'il soit au niveau de la concurrence :) ?

Je viens justement d'essayer ce service :

L’ensemble des champs « Civilité », « Prénom», «Nom d’usage » ainsi que les espaces ne doivent pas dépasser 38 caractères
L’ensemble des champs "Civilité", "Prénom", "Nom" et "Nom de naissance" ainsi que les espaces ne doit pas dépasser 38 caractères

Résultat : utilisation du formulaire papier et déplacement au bureau de poste obligatoire

Tu as un dépôt public ? Parce que là, je trouve ça étonnant et ça m'intrigue vraiment.

Si tu n'as pas froid au yeux, tu peux regarder par là : git://git.damsy.net/sac.git pour le code du moteur et là pour un de nos jeux qui l'utilise : git://git.damsy.net/sac/heriswap.git :-)

(un jour il faudra que je publie aussi les sources de notre 2nd jeu…)

Tu fais donc une différence entre les entités persistantes et celles qui ne le sont pas

Oui. Par ex : une entité avec le composant Particule va générer N particules/sec. Quand on veut sauvegarder l'état du jeu on surtout intéressé par le générateur de particules … hum… en écrivant ça je me dis que c'est vraiment arbitraire comme choix et qu'on pourrait tout aussi bien sauvegarder toutes les entités et donc n'avoir que des entités persistantes :)

Dans le cas de champ numérique d'input, est-ce qu'il y a des moyens simples de ne pas relancer tout un calcul avec un boolean 'dirty' ?

J'ai essayé plusieurs approches pour ça, avec comme seul règle : pas de complexité pour le développeur qui l'utilise (et donc pas un flag 'dirty' à modifier à la main quand on modifie le champs).
La plus intéressante était celle avec un système qui définissait un composant public: MonComposant et un composant privé MonComposantPrivé qui hérite de MonComposant.
L'idée étant : tous les utilisateurs externes au système ne voit que MonComposant, alors que le système manipule MonComposantPrivé
Appliqué à ton exemple, on pourrait faire :

MonComposant { float value; }
MonComposantPrivé : MonComposant { float oldValue; }

Et il est trivial de ne déclencher le traitement coûteux que si la valeur a changé.

Ou alors créer une entité qui aura un composant ValueChanged (?) par ex à chaque fois que le champs est modifié - ça pourrait avoir des effets secondaires intéressants pour gérer le Undo par ex.

Et que penses-tu de mes remarques alors ? Notamment que ces événements ne font pas vraiment partie de l'état du système

Je ne suis pas sûr d'avoir un avis bien tranché là dessus. À vrai dire c'est surtout les listeners que je rejette pour conserver la cohérence (ex : le changement des niveau est toujours traité au même endroit du code, et au même moment dans chaque frame).

Par contre, utiliser un «système de messages» basé sur des entités a plusieurs intérêts :
* les messages font partie du design E/S
* la synchro de ses entités messages suffit pour implémenter un mode réseau basique :)

d'ailleurs, je suis surpris de voir un composant Button

Oui, de ce que j'ai pu voir du code de libes nos composants sont très différents.
Dans mon cas un composant fournit une fonctionnalité complète, par exemple : Button, Rendering, Transformation, Sound, Grid, etc

Ensuite chaque composant déclare ses propriétés, ce qui permet :
* de les afficher pour du debug (en utilisant AntTweakBar)
* de les charger depuis un format de fichier texte
* de sérialiser/désérialiser les entités persistantes pour sauvegarder l'état du jeu et le restaurer plus tard
* de sérialiser/désérialiser les entités (celles avec un composant Network) pour implémenter un mode réseau

Dans le moteur E/S que je développe j'ai choisi de ne pas avoir de système d'événements :)

La raison principale étant : pour avoir un flux de traitement organisé et facile à suivre, plutôt que des listeners d'événements qui vont déclencher d'autres événements en chaîne etc…

Les événements ont été remplacé soit par du polling tout bête (ex : le composant Button a un booléen 'clicked') ou par des entités éphémères (ex : le joueur clique sur un bouton, création d'une entité avec un composant Attaque et le vrai traitement de l'attaque est fait dans l'update de l'AttackSystem et non dans un listener).

Le blog des développeur du moteur de jeu bitsquid contient pleins d'articles intéressants sur les E/S ; cet article parle des événements par exemple.

Je pense aussi que c'est rare, mais ça arrive.
Un exemple : Rovio (dév d'Angry Birds) qui rachète Casey's Contraptions : http://gamesfromwithin.com/what-the-rovio-deal-with-caseys-contraptions-means-to-me

http://www.ecma-international.org/publications/standards/Ecma-376.htm ?

C'est pas mal pour l'update: les systèmes n'ont à s'occuper que des attributs local*
Par contre lors du rendu graphique, c'est plus compliqué. Lorsque le système de rendu graphique fait l'itération des composants Transformation, à chaque fois qu'il y a un parent, il devra passer par le parent.

Pas vraiment.
Le système qui s'occupe du rendu utilise les coordonnées world* uniquement, puisqu'il n'est intéressé que par la position absolue des objets, pas leur position relative (et c'est le cas de la plupart des systèmes : ils ne sont intéressés que par la position absolue d'un objet).

Par contre, lors de sa mise à jour le TransformationSystem fait effectivement la recherche du parent pour chaque entité (avec une mini-optim ressemblant à celle que tu décris).

Par exemple, comment implémenter un scenegraph avec des composants qui permet d'avoir des sous objets dont la position dépend d'un objet parent ?

Une possibilité :

composant Transformation
    vec2 localPosition, worldPosition;
    float localRotation, worldRotation;
    Entity parent; // optionnel

Les coordonnées local* sont définies dans le repère du parent.
Les systèmes qui veulent modifier la position d'une entité manipulent les attributs local*.
Le système de Transformation détermine les attributs world* en fonction de local* et du parent si il y en a un), sinon world* = local*

J'ai plutôt l'expérience inverse.
Pour nos jeux, nous utilisons cette architecture. Aucune classe n'a de méthode update, excepté les systèmes. La main-loop ressemble donc à ça :

read_input
for_each system do
    system.update(dt)
render()

Pas non plus de système de callback/messagerie pour venir intercaler des appels de fonction type onMessage() qui casse l'aspect séquentiel.

Je trouve le résultat plutôt simple à comprendre et à debugger - mais c'est peut-être parce que c'est moi qui l'ai écrit :)

Non c'est la pratique, si tu sais conduire et te tenir

En effet ; "si tu sais conduire" tu n'es pas dangereux :)

L'avantage d'une discussion comme ça est que tout le monde a raison/tort et tous les arguments sont réversibles.

Mais pour en revenir à ton affirmation "la spécialité francaise qu'est le mazout 80ch pour 1.2t est problématique" : je ne vois pas où se situe le problème :
- "Si tu sais conduire" tu ne vas tenter un dépassement rendu dangereux par un différentiel de vitesse trop faible
- si tu ne sais pas conduire, voiture rapide ou non le résultat sera le même : des dépassements dangereux

Conclusion : rien à voir avec la voiture

Tu sais c'est pas la voiture qui décide ni de comment tu roules, ni de ta vitesse

Ça c'est pour la théorie.
Mon expérience semble indiquer le contraire (mais peut-être suis-je un cas particulier).
Des exemples au hasard :
- j'ai tendance à rouler plus vite dans une voiture puissante qu'avec ma Twingo (parce que le son du moteur est grisant, parce qu'on se rend moins compte de la vitesse, …).
- j'observe plus souvent des dépassements dangereux de voitures puissantes qui doublent n'importe où que de dépassements dangereux par manque de temps.

Exactement pour ca que la spécialité francaise qu'est le mazout 80ch pour 1.2t est problématique dès qu'on sort des aglomération et des voies principales.

C'est sûr que les routes seraient beaucoup plus sûres si tout le monde roulait en Audi, BMW ou Formule1…

il est déjà possible de compiler ses logiciels en liant tout en statique

Mise à part les problèmes de licences, effectivement c'est possible.

Pour l'exemple des "jeux vidéos propriétaires", s'ils utilisent la SDL (licence LGPG) je vois mal comment ils pourraient faire un gros binaire statique…

Par contre, une solution à base de bibliothèques dynamiques + rpath fonctionne.
C'est ce que fait LGP : http://blog.linuxgamepublishing.com/2009/02/08/our-new-way-to-meet-the-lgpl/