Je veux bien croire que c'est des doubles doses, mais c'est pas vraiment le moment de creuser le trou de la sécu pour un truc qui fait moins de mort qu'une grippe saisonnière.
Moi, je dirais qu'elle est passé dans tous les foyers avec enfants (sur une dizaine) de mes collègues. A chaque fois toute la familles y passe ou presque, il y a souvent des classes fermées quelques semaine.
Sur la totalité, quelques enfants ont été très malade, les autres beaucoup moins.
Tu as aussi des trucs plus anodin comme ce que fait les réseau sociaux de nos adresses emails. Ou encore de ce qui passe par "les chat" et l'exemple de msn qui va scanner toutes urls transmises.
Un autre truc qui me fait peur, c'est l'inconscience des autres. Il ne te viendrait jamais à l'idée de mettre sur facebook une photo "compromettante" (rien de plus qu'une soiré arrosée) et pourtant un de tes amis peut trouver cela très drôle de tout mettre en ligne et de "taguer" la photo. (photo présenté bien sur par ton futur ex employeur lors du premier entretien). il y a aussi la fonction agenda qui peut contenir les coordonnées de ses amis dont ne sait ce qu'en fait facebook.
MS a un coup énorme à jouer pour contrer google sur le thème : on vous fait payer les logiciels, mais vos données sont plus importantes et on ne vous les "emprisonnes" pas.
C'est d'autant plus facile avec les déclarations limites du pdg de google.
Ne mélange pas ce qui existe et ce qu'il est possible de faire. Lisaac produit du C89 car en l'état actuelle des choses, il n'y a aucun intérêt à produire autre chose sauf à être incompatible.
Je pense que si il produit autre chose, cela sera du "C99 gcc" avec les bonnes extensions.
Concernant la vectorisation automatique, gcc en fait déjà pas mal tout seul comme un grand. Je penche plutôt sur le fait de faire des boucles qui s'automatise facilement. Vu la quantité de matière grise mis sur ce genre de problématique, je ne pense pas que l'on puisse faire une grosse différence.
Donc, en gros, on pense s'appuyer sur GCC pour faire la vectorisation, et sur l'utilisation de lib qui manipulerait directement soit les types vectoriels de Gcc ("v4sf",etc...), soit de l'assembleur mais c'est encore moins portable.
Concernant la taille de blocs en fonction du cache, on peut faire 2 stratégies : l'une dynamique en utilisant une lib qui donne la taille des caches, l'autre qui prend une taille "catch all" : 32 Ko qui correspond à une taille très courante de cache L1.
Concernant les versions de ton code, la version octave serait aussi utile pour l'utiliser comme version "haut niveau" de référence pour coder en Lisaac.
Ton rêve serait donc de pouvoir d'écrire ton algo en style "Octave" mais en ayant les perfs du C, c'est à dire sans copie inutile, et faisant du strip mining (traitement par bloc) ?
Plus que la mesure de latence, je pensais à l"utilisation des bases de donnée d'IP. Aujourd'hui on sait parfaitement situer chaque IP sur chaque DSLAM. j'imagine que si les échanges se font au niveau DSLAM, la vitesse est beaucoup plus grande.
Un moment, j'avais imaginé un système de p2p de socket UDP. Normalement un peu n'importe quoi pourrait passer dedans. L'idée est de faire de la redirection, avec au minimum un entrant et 2 sortant.
Ce qui est amusant avec udp est que tu peux spoofer l'adresse d'émission sans que cela est trop de conséquence.
Pour être performant, il faudrait ajouter une fonction d'agrégation pour augmenter la bande passante en entré, cela serait marrant de streamer de la vrai HD.
Le deuxième point méga complexe est la localisation des données. Il me semble que le système de hash distribué fonctionne bien (mldonkey ?).
Reste ensuite la base de donné distribué pour faire les recherches, et là c'est pas franchement le top. J'imagine qu'un moteur de recherche distribué est un projet à part entière. C'est encore plus complexe que l'application p2p classique car il y a les modifications à gérer (il y a beaucoup d'écriture par rapport au read only du p2p).
Un dernier point serait d'avoir un réseau p2p qui respecte la localisation géographique. Il me semble qu'il y a des tentatives de RFC pour connaitre la topologie du réseau physique pour optimiser les échanges dans les tuyaux des FAI. On peut aussi utiliser les bases de données géographiques déjà disponnible.
Cela a un gros avantage : c'est quasi impossible de scanner un réseau si on est toujours connecté aux personnes les plus proche. (par exemple pour transmettre une demande de connexion, on choisi l'ip la "plus proche" par rapport au demandeur)
L'avantage d'un streaming de flux arborescente, c'est que la voie de retour ne semble pas nécessaire, il n'y aurai donc pas de moyen de remonter à l'origine. Pour se brancher il suffirait de connaitre un noeud du réseau. Cela descend une demande dans l'arbre pour qu'une feuille envois le flux.
Pour éviter les nœuds "méchants", on peut utiliser de la signature crypto, un nœud méchant est alors signalé plus haut. Pour éviter les signalements abusifs, on demande une reconnexion au nœud connu en précisant que l'on n'aime pas tels nœuds.
J'ai du mal à comprendre, vous utilisez des fonctions tellement évoluer en openGL que les implémentations incomplètes de ATI et la lenteur des intel posent problèmes ?
Intel est lent je veux bien le croire mais il me semblait que leur implémentation d'opengl était correct.
Pour répondre sur les assertions et ton problème d'erreur de signe. Tu peux trouver des erreurs d'équation en utilisant les propriétés mathématiques de ta fonction, par exemple, tu vérifies que l'opération reste transitive, reflexive, tu peux vérifier les éléments neutres, et autre propriété un peu poussé. Si tu codes une multiplication de matrice tu peux vérifier par exemple que ((A*B)*A)*B =A*((B*A)*B).
Tu peux aller beaucoup plus loin que les tests de bornes.
Alors certe, cela contrainte à en mettre partout, mais cela diminue beaucoup le travail pour des tests . Cela ne va pas te trouver le signe faux directement. Au mieux cela te pointe le bon slot.
L'étape d'après, qui n'est pas encore implémenté, serait d'avoir un système de waveforme comme pour le hardware. En hardware, avoir 10 Go de log ne pose de problèmes à personne. Et si c'est le cas, on peut encore passer avec une sorte de débogueur embarqué pour couper les sorties inutiles au runtime.
Concernant la compilation globale, mon propos était de dire que tu peux avoir des temps de compilation court sans devoir passer en compilation partiel. Et uniquement ça.
L'exemple que j'ai en tête c'est le mode de fonctionnement de synplify de simplicity (c'est un synthétiseur pour FPGA) qui fonctionne avec une grosse base de donnée et fonctionne avec un diff en interne du code VHDL quand il y a une nouvelle synthèse.
Pour Lisaac, le problème reste toujours la génération du .c et le temps de compilation associé avec gcc. C'est pour ça que j'avais parlé de système ou tu choisis les regroupements de prototypes pour la compilation. Cela permet de changer que le bout de programme qui t'intéresse. Ou encore, on passe dans un mode "un fichier par fonction" en espérant que la compilation global ne va pas tous les changer. Cela fait parti des améliorations pour "le mode compilation pour le debug".
Je serais curieux de voir le code pour comparer les 2 implémentations et voir le résultat, si il est disponible.
i<>
Le gros point noir que j'avais noté c'était surtout la procédure d'instalation qui était merdique à soit, buggais pas mal et très invasive. Apparament un problèmes avec plein de variable d'environement ou autre, mes notes sont pas claires. Est-ce que ça à progresser de ce côter la depuis ?
C'est un peu mieux. C'est moins invasif. Cela marche bien sous Linux, mais c'est plus galère sous windows.
Dans le projet blinken light, tu as un ordinateur par ligne relié par Ethernet, et chaque point est relier par RS232 avec un petit variateur pour commander une lampe halogène de 500W.
Tu peux imaginer des ubidules qui gère plusieurs projecteurs RGB qui sont "étalé" sur une grande surface (plus large qu'une surface d'immeuble).
Le coté intelligent serait le réglage automatique de la position de chaque point et l'autocalibration de chaque couleur.
En fait, c'est surtout que ext4 se comportait comme XFS en réordonnancement aussi les rename avec les write, ce qui pouvait faire en sorte de changer le nom du fichier avant que l'écriture soit effective. D'ou le débat de l'utilisation de fsync() mais qui est lente alors que le rename sous-entendait une relation d'ordre.
Les logs monstrueux, c'est quelle taille 1 Go ? 10 Go ? plus ? Les log pour les simu VHDL tracent tout :)
En fait, en VHDL, les simu sont longues donc on préfère loger un max pour relire ensuite. Mais si l'execution est pas trop lente, le choix de quoi loguer peut être fait au runtime.
Concernant la suite, je te donne l'état des réflexions et les pistes que l'on peut suivre. Je ne te dis pas que c'est la meilleur solution, je ne te dis pas qu'il n'y a que ça à faire, je ne te dis pas non plus tout ce qui est envisageable de faire sans casser le modèle de programmation de Lisaac.
Je trouve hallucinant que tu me reproches de te donner les pistes que l'on explore. Je te donnes les pistes, pour toi, c'est que je troll en sous entendant je ne sais quoi. Je parle du présent, tu me dis, je m'en fout il manque telle truc. Tu me dis je me tiendrait au courant des nouveautés, je te donne des pistes pour le future, tu me dis que je troll.
Un système de trace pourrait éviter tout recompilation, certe, c'est du futur, certe, cela n'existe pas encore. Moi pourquoi forcément, me le renvoyer dans la figure, sans éventuellement accepter que le boulot pourrait être fait de cette façon. Ou encore, j'avais parlé dans un autre commentaire de séparation du proto en test des autres proto, mais on dirait que tu l'as oublier, ou alors, il fallait encore que je me répète ?
J'arrêtes là la conversation. Il n'y en a pas. Quoi que je dis ou propose, je troll ou je dénigre. J'ai l'impression qu'il est impossible de proposer un truc un minimum différent sans se faire défoncer.
C'est toi qui disait "Le minimum, c'est de regarder l'état de l'art de ce qui se fait.". C'était bien le but de ton intervention ?
Donc renseignes toi sur des logiciels comme "Prover", les générateurs automatique de pattern de test (ATPG), les techniques de back propagation que l'on retrouve dans les "Static Timing Analyzer" pour comprendre ce qui peut se faire statiquement.
Renseignes toi aussi les process induit pour les logiciels critiques comme la DO-178, IEC 61508 et la EN 50128, pour comprendre comment est censé se faire une spec.
[^] # Re: les apprentis sorciers, les charlatans et la thérorie du complet
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Certains OGM prouvés nocifs. Évalué à 2.
Sauf que les morts en question ont 30 ans pas 90.
"La première sécurité est la liberté"
[^] # Re: les apprentis sorciers, les charlatans et la thérorie du complet
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Certains OGM prouvés nocifs. Évalué à 3.
En gros, le virus une fois dans les poumons, c'est le système immunitaires de personne en très bonne santé qui détruise les voies respiratoires.
Donc, tu es pile dans la tranche d'age qui meurt le plus.
"La première sécurité est la liberté"
[^] # Re: les apprentis sorciers, les charlatans et la thérorie du complet
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Certains OGM prouvés nocifs. Évalué à 3.
Sur la totalité, quelques enfants ont été très malade, les autres beaucoup moins.
"La première sécurité est la liberté"
[^] # Re: Apparemment beaucoup d'infractions
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Le SFLC contraint de passer à l'étape ultime pour faire respecter la GPL. Évalué à 8.
"La première sécurité est la liberté"
[^] # Re: les apprentis sorciers, les charlatans et la thérorie du complet
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Certains OGM prouvés nocifs. Évalué à 5.
"La première sécurité est la liberté"
[^] # Re: De suite...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Bing et Firefox.. Évalué à 2.
Un autre truc qui me fait peur, c'est l'inconscience des autres. Il ne te viendrait jamais à l'idée de mettre sur facebook une photo "compromettante" (rien de plus qu'une soiré arrosée) et pourtant un de tes amis peut trouver cela très drôle de tout mettre en ligne et de "taguer" la photo. (photo présenté bien sur par ton futur ex employeur lors du premier entretien). il y a aussi la fonction agenda qui peut contenir les coordonnées de ses amis dont ne sait ce qu'en fait facebook.
"La première sécurité est la liberté"
[^] # Re: De suite...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Bing et Firefox.. Évalué à 6.
C'est d'autant plus facile avec les déclarations limites du pdg de google.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Je pense que si il produit autre chose, cela sera du "C99 gcc" avec les bonnes extensions.
Concernant la vectorisation automatique, gcc en fait déjà pas mal tout seul comme un grand. Je penche plutôt sur le fait de faire des boucles qui s'automatise facilement. Vu la quantité de matière grise mis sur ce genre de problématique, je ne pense pas que l'on puisse faire une grosse différence.
Donc, en gros, on pense s'appuyer sur GCC pour faire la vectorisation, et sur l'utilisation de lib qui manipulerait directement soit les types vectoriels de Gcc ("v4sf",etc...), soit de l'assembleur mais c'est encore moins portable.
Concernant la taille de blocs en fonction du cache, on peut faire 2 stratégies : l'une dynamique en utilisant une lib qui donne la taille des caches, l'autre qui prend une taille "catch all" : 32 Ko qui correspond à une taille très courante de cache L1.
Concernant les versions de ton code, la version octave serait aussi utile pour l'utiliser comme version "haut niveau" de référence pour coder en Lisaac.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Mais avant de savoir ce qu'il est possible de faire ou de ne pas faire, il faut déjà avoir une idée assez précise de ce que l'on voudrait.
C'est vraiment dommage que ton code soit fermé. Cela aurait fait une bonne référence, pour un bench pour voir l'effet d'optimisation.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
J'ai tout bon ?
"La première sécurité est la liberté"
[^] # Re: p2p UDP ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Application de P2P moderne. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: p2p UDP ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Application de P2P moderne. Évalué à 2.
Mon truc c'est plus du streaming.
"La première sécurité est la liberté"
# p2p UDP ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Application de P2P moderne. Évalué à 3.
Ce qui est amusant avec udp est que tu peux spoofer l'adresse d'émission sans que cela est trop de conséquence.
Pour être performant, il faudrait ajouter une fonction d'agrégation pour augmenter la bande passante en entré, cela serait marrant de streamer de la vrai HD.
Le deuxième point méga complexe est la localisation des données. Il me semble que le système de hash distribué fonctionne bien (mldonkey ?).
Reste ensuite la base de donné distribué pour faire les recherches, et là c'est pas franchement le top. J'imagine qu'un moteur de recherche distribué est un projet à part entière. C'est encore plus complexe que l'application p2p classique car il y a les modifications à gérer (il y a beaucoup d'écriture par rapport au read only du p2p).
Un dernier point serait d'avoir un réseau p2p qui respecte la localisation géographique. Il me semble qu'il y a des tentatives de RFC pour connaitre la topologie du réseau physique pour optimiser les échanges dans les tuyaux des FAI. On peut aussi utiliser les bases de données géographiques déjà disponnible.
Cela a un gros avantage : c'est quasi impossible de scanner un réseau si on est toujours connecté aux personnes les plus proche. (par exemple pour transmettre une demande de connexion, on choisi l'ip la "plus proche" par rapport au demandeur)
L'avantage d'un streaming de flux arborescente, c'est que la voie de retour ne semble pas nécessaire, il n'y aurai donc pas de moyen de remonter à l'origine. Pour se brancher il suffirait de connaitre un noeud du réseau. Cela descend une demande dans l'arbre pour qu'une feuille envois le flux.
Pour éviter les nœuds "méchants", on peut utiliser de la signature crypto, un nœud méchant est alors signalé plus haut. Pour éviter les signalements abusifs, on demande une reconnexion au nœud connu en précisant que l'on n'aime pas tels nœuds.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
"La première sécurité est la liberté"
# google: "Reducing HTTP latency with SPDY"
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Shared Dictionary Compression over HTTP (SDCH). Évalué à 2.
google se lance aussi dans un autre protocole : SPDY.
"La première sécurité est la liberté"
[^] # Re: Tout ceci reste scandaleusement compliqué
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Clubic nous explique comment se faire rembourser Windows. Évalué à 6.
"La première sécurité est la liberté"
[^] # Re: La troidé sous X.Org
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des news de Firefox. Évalué à 2.
Intel est lent je veux bien le croire mais il me semblait que leur implémentation d'opengl était correct.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Tu peux aller beaucoup plus loin que les tests de bornes.
Alors certe, cela contrainte à en mettre partout, mais cela diminue beaucoup le travail pour des tests . Cela ne va pas te trouver le signe faux directement. Au mieux cela te pointe le bon slot.
L'étape d'après, qui n'est pas encore implémenté, serait d'avoir un système de waveforme comme pour le hardware. En hardware, avoir 10 Go de log ne pose de problèmes à personne. Et si c'est le cas, on peut encore passer avec une sorte de débogueur embarqué pour couper les sorties inutiles au runtime.
Concernant la compilation globale, mon propos était de dire que tu peux avoir des temps de compilation court sans devoir passer en compilation partiel. Et uniquement ça.
L'exemple que j'ai en tête c'est le mode de fonctionnement de synplify de simplicity (c'est un synthétiseur pour FPGA) qui fonctionne avec une grosse base de donnée et fonctionne avec un diff en interne du code VHDL quand il y a une nouvelle synthèse.
Pour Lisaac, le problème reste toujours la génération du .c et le temps de compilation associé avec gcc. C'est pour ça que j'avais parlé de système ou tu choisis les regroupements de prototypes pour la compilation. Cela permet de changer que le bout de programme qui t'intéresse. Ou encore, on passe dans un mode "un fichier par fonction" en espérant que la compilation global ne va pas tous les changer. Cela fait parti des améliorations pour "le mode compilation pour le debug".
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
i<>
Le gros point noir que j'avais noté c'était surtout la procédure d'instalation qui était merdique à soit, buggais pas mal et très invasive. Apparament un problèmes avec plein de variable d'environement ou autre, mes notes sont pas claires. Est-ce que ça à progresser de ce côter la depuis ?
C'est un peu mieux. C'est moins invasif. Cela marche bien sous Linux, mais c'est plus galère sous windows.
"La première sécurité est la liberté"
# Ecran géant
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Ubiquitous computing. Évalué à 2.
Le coté interaction serait là uniquement pour définir la géographie des points.
http://blinkenlights.net/arcade
Dans le projet blinken light, tu as un ordinateur par ligne relié par Ethernet, et chaque point est relier par RS232 avec un petit variateur pour commander une lampe halogène de 500W.
Tu peux imaginer des ubidules qui gère plusieurs projecteurs RGB qui sont "étalé" sur une grande surface (plus large qu'une surface d'immeuble).
Le coté intelligent serait le réglage automatique de la position de chaque point et l'autocalibration de chaque couleur.
"La première sécurité est la liberté"
[^] # Re: 2 petites infos inutiles?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Faut-il craquer pour du SSD ?. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: 2 petites infos inutiles?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Faut-il craquer pour du SSD ?. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: 2 petites infos inutiles?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Faut-il craquer pour du SSD ?. Évalué à 4.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
En fait, en VHDL, les simu sont longues donc on préfère loger un max pour relire ensuite. Mais si l'execution est pas trop lente, le choix de quoi loguer peut être fait au runtime.
Concernant la suite, je te donne l'état des réflexions et les pistes que l'on peut suivre. Je ne te dis pas que c'est la meilleur solution, je ne te dis pas qu'il n'y a que ça à faire, je ne te dis pas non plus tout ce qui est envisageable de faire sans casser le modèle de programmation de Lisaac.
Je trouve hallucinant que tu me reproches de te donner les pistes que l'on explore. Je te donnes les pistes, pour toi, c'est que je troll en sous entendant je ne sais quoi. Je parle du présent, tu me dis, je m'en fout il manque telle truc. Tu me dis je me tiendrait au courant des nouveautés, je te donne des pistes pour le future, tu me dis que je troll.
Un système de trace pourrait éviter tout recompilation, certe, c'est du futur, certe, cela n'existe pas encore. Moi pourquoi forcément, me le renvoyer dans la figure, sans éventuellement accepter que le boulot pourrait être fait de cette façon. Ou encore, j'avais parlé dans un autre commentaire de séparation du proto en test des autres proto, mais on dirait que tu l'as oublier, ou alors, il fallait encore que je me répète ?
J'arrêtes là la conversation. Il n'y en a pas. Quoi que je dis ou propose, je troll ou je dénigre. J'ai l'impression qu'il est impossible de proposer un truc un minimum différent sans se faire défoncer.
D'ailleurs, tu n'as pas répondu sur Octave vs C.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Donc renseignes toi sur des logiciels comme "Prover", les générateurs automatique de pattern de test (ATPG), les techniques de back propagation que l'on retrouve dans les "Static Timing Analyzer" pour comprendre ce qui peut se faire statiquement.
Renseignes toi aussi les process induit pour les logiciels critiques comme la DO-178, IEC 61508 et la EN 50128, pour comprendre comment est censé se faire une spec.
"La première sécurité est la liberté"