Sachant que pour économiser du cablage, le réseau multimedia et celui de l'avion passe par les mêmes cables mais utilise des switchs ethernet dédié (ayant des contraintes temps réel).
Mais j'ai peur que ce genre de switch ne soit pas prévus pour résister à des attaques...
Il y a des tas de boites comme "Sigma Design", si celle-ci ne sort pas la puce que veut le marché, elle perdra gros.
Le coté complexe de l'adaptation à un DSP est aussi que le code C doit être taillé pour lui à cause de son architecture spécial (tailles des mémoires embarquées, etc...). (pour info, j'ai bossé à coté des personnes qui font le codec H264 720P pour la série OMAP 34xx/35xx sur C64)
La différence est aussi l'utilisation de la transformer en ondelette plutôt que la transformé DCT. Si il utilise une instruction spécial, elle devient inutile.
Même si ça s'éloigne des buts de FineFS, il serait intéressant (d'un point de vue théorique) de stocker les méta-données dans une base de données (je donnais l'exemple de SQLite, dont la philosophie s'accorde bien à celle de FineFS).
Je croyais que tu voulais des perf ? Les meta donnés ne sont pas des ACL ?
Bon, je reste quand même persuadé que sur une architecture classique cela n'a pas un grand intérêt par rapport à une base de données traditionnelle (toutes les applis web utilisent un MySQL/Postgresql/Oracle quelque part)...
Les perfs ? :) Elle sont franchement bof pour la plus part des sites web. Cela me rappelle la remarque de Google lors d'une conf avec des journaux papiers: "il est plus rapide de lire vos journaux papiers" sous-entendu "tellement vos site sont lents".
Si tu sépares les types de machines, tu diminuent la complexité du SW en complexifiant la topologie du hardware. A la limite, gères cela dans FineFS pour que l'ajout/disparition de noeud soit facile.
Pour le cache en local, tu peux toujours faire tourner localement un memcache :)
L'autre truc bizarre c'est la période d'essais qui dépasse un mois, ce qui me semble être le maxi légal.
Concernant la remarque sur les femmes de ménages, avec certaine qui prennent 12€/h net voir plus, on est plus proche d'un salaire horaire d'ingé débutant que de technicien...
Concernant l'utilisation d'un cache, j'y crois moyen. L'exemple de google où toutes les machines sont identiques prouvent que c'est possible.
J'imagine que FineFS est utilisé sur les serveurs web également en front-end pour être toujours en accès fichiers local.
Quel serait l'intérêt d'un cache ? Si ce n'est rajouter une couche à FineFS pour simuler un comportement différent dans certain cas.
Autant gérer un cache RAM au niveau de FineFS, non ? (voir s'arranger pour que linux dessous fasse le boulot). Par exemple, toutes les méta données pourraient toujours être présente en RAM.
Disons que dans un fort taux d'écriture sur un cluster de 10 machines, tu passes ton temps à te refiler le fichier. Avec simplement l'information d'invalidation, tu ne va chercher le fichier que si il est demandé.
Pour garder la réplication, une triple copie suffit pas la peine d'inonder le cluster (cela pourrait se faire avec un TTL si il y a une topologie anneau).
Je faisais la différence entre la réplication d'écriture en vue d'augmenter le potentiel de lecture (ce que vous faite) devant la réplication en lecture qui ne fait que propager un message d'invalidation plus léger que le fichier à transmettre.
Si vous voulez aussi de la réplication, il n'y a pas besoin de faire la copie totale.
Un fichier ayant beaucoup d'écriture pourrait être l'information de session avec sauvegarde de l'état précédent.
Ok, vous êtes en replication en écriture. A priori, si le taux de lecture est très fort, c'est un bon système.
Par contre, dans le cas d'écriture fréquente, c'est pas forcément le top. Vous devriez laisser la possibilité de désactiver la réplication asynchrone pour certain fichier/répertoire souvent mis à jour. J'imagine qu'avec les appli web, cela deviendra de plus en plus fréquent.
Concernant l'atomicité, je pensais à un fichier modifié (modif d'une image par exemple), relus immédiatement (affichage). Tu veux dans ce cas la nouvelle image ou l'ancienne, mais pas un truc entre les 2. Ici, cela n'est pas gênant mais imagine une sauvegarde qui aurait un "bout d'image".
C'est pas vraiment une histoire de lock, si ton système ne donne pas la possibilité de connaitre l'état des données, c'est difficile à faire au niveau applicatif (le plus simple est de retourner la vieille version tant que la nouvelle n'est pas complètement dans le système)
Ok, vous dégagez tous les truc pas simple POSIX. Pourquoi pas.
Est-ce que vous gérez l'atomicité de remplacement de fichier ? Genre un nouveau fichier est écrit, si un autre fichier cherche à le lire, il aura le précédent ou le nouveau, mais pas une erreur ou un truc mélanger ou tronqué.
Est-ce que vous gérez un système d'envois en "2 bandes" ? En gros, est-ce que le système de fichier pourrait envoyer directement un fichier à un client sans repasser par un serveur web ? Je me suis toujours demandé comme faire une réponse en utilisant 2 machines, sans repasser par la 1er et sans proxy.
Quel genre d'api vous utiliser ? Une sorte de sémantique proche de celle du web ? (genre un fichier est un bloc complet et il n'y a pas lock, de seek ou autre ?)
Du code correcteur d'erreur, il passe à un trucs qui ressemble au chaine de Markov. Et pour éviter la destruction des symboles, ils utilisent la présence ou l'absence d'une marque. Donc tout détruire, revient à mettre des 1 ou des zéros partout. Cela revient au même, non ?
Le papier part de principe qu'il peut retrouver "suffisamment" de marque qui ne sont pas dû au hasard. On dirait qu'il part du principe que la seul attaque possible est le mélange de seconde du film entre plusieurs attaquant.
Ce que je dis plus haut c'est que des modifications mineurs du film détruisent quasiment à coup sûr tout marquage (décalage, zoom, suppression de bord, filtre passe-bas, filtre anti-bruit, filtre d'amélioration).
Tu peux définir un code aussi long que tu veux, si tu ne récupères pas assez de symbole "juste" tu ne peux rien en faire.
[^] # Re: j'imagine
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Le linux embarqué de l'A380 a planté en plein vol. Évalué à 0.
"La première sécurité est la liberté"
[^] # Re: j'imagine
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Le linux embarqué de l'A380 a planté en plein vol. Évalué à -5.
Mais j'ai peur que ce genre de switch ne soit pas prévus pour résister à des attaques...
"La première sécurité est la liberté"
[^] # Re: Surprenant !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Comment les brevets logiciels se retournent contre leurs promoteurs ?. Évalué à 9.
Ils font payer les inventions pour réduire l'innovation...
"La première sécurité est la liberté"
[^] # Re: Scène démo
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Bold: un linker particulier. Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Scène démo
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Bold: un linker particulier. Évalué à 2.
Il utilise quoi comme téchnique ? Les shaders ou cela reste du pure ASM x86 ?
"La première sécurité est la liberté"
[^] # Re: Scène démo
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Bold: un linker particulier. Évalué à 2.
Aujourd'hui la moindre équipe de dev de jeu est composé d'une quinzaine de personne, sans compter les graphistes et autres musiciens.
De plus les systèmes d'aujourd'hui sont infiniement plus complexe qu'à l'époque et avec l'utilisation du HW 3d tous les rendus se ressemblent.
Bref, il n'y a plus vraiment de place pour briller avec une démo.
Mais je suis sûr que l'on pourra me montrer quelques contre exemple.
"La première sécurité est la liberté"
[^] # Re: Gni ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Google s'offre On2. Évalué à 2.
Le coté complexe de l'adaptation à un DSP est aussi que le code C doit être taillé pour lui à cause de son architecture spécial (tailles des mémoires embarquées, etc...). (pour info, j'ai bossé à coté des personnes qui font le codec H264 720P pour la série OMAP 34xx/35xx sur C64)
"La première sécurité est la liberté"
[^] # Re: Gni ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Google s'offre On2. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Gni ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Google s'offre On2. Évalué à 4.
"La première sécurité est la liberté"
[^] # Re: GlusterFS ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Publication de FineFS, un système de fichiers répartis. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: GlusterFS ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Publication de FineFS, un système de fichiers répartis. Évalué à 1.
Je croyais que tu voulais des perf ? Les meta donnés ne sont pas des ACL ?
Bon, je reste quand même persuadé que sur une architecture classique cela n'a pas un grand intérêt par rapport à une base de données traditionnelle (toutes les applis web utilisent un MySQL/Postgresql/Oracle quelque part)...
Les perfs ? :) Elle sont franchement bof pour la plus part des sites web. Cela me rappelle la remarque de Google lors d'une conf avec des journaux papiers: "il est plus rapide de lire vos journaux papiers" sous-entendu "tellement vos site sont lents".
"La première sécurité est la liberté"
[^] # Re: 1932.97 € ...
Posté par Nicolas Boulay (site web personnel) . En réponse au message Offre d'emploi - développement de plugins pour OCS/GLPI (PHP/MySQL). Évalué à 5.
C'est le comble pour la marine.
"La première sécurité est la liberté"
[^] # Re: GlusterFS ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Publication de FineFS, un système de fichiers répartis. Évalué à 2.
Pour le cache en local, tu peux toujours faire tourner localement un memcache :)
"La première sécurité est la liberté"
[^] # Re: 1932.97 € ...
Posté par Nicolas Boulay (site web personnel) . En réponse au message Offre d'emploi - développement de plugins pour OCS/GLPI (PHP/MySQL). Évalué à 4.
Concernant la remarque sur les femmes de ménages, avec certaine qui prennent 12€/h net voir plus, on est plus proche d'un salaire horaire d'ingé débutant que de technicien...
"La première sécurité est la liberté"
[^] # Re: GlusterFS ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Publication de FineFS, un système de fichiers répartis. Évalué à 2.
J'imagine que FineFS est utilisé sur les serveurs web également en front-end pour être toujours en accès fichiers local.
Quel serait l'intérêt d'un cache ? Si ce n'est rajouter une couche à FineFS pour simuler un comportement différent dans certain cas.
Autant gérer un cache RAM au niveau de FineFS, non ? (voir s'arranger pour que linux dessous fasse le boulot). Par exemple, toutes les méta données pourraient toujours être présente en RAM.
"La première sécurité est la liberté"
[^] # Re: GlusterFS ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Publication de FineFS, un système de fichiers répartis. Évalué à 2.
Pour garder la réplication, une triple copie suffit pas la peine d'inonder le cluster (cela pourrait se faire avec un TTL si il y a une topologie anneau).
Je faisais la différence entre la réplication d'écriture en vue d'augmenter le potentiel de lecture (ce que vous faite) devant la réplication en lecture qui ne fait que propager un message d'invalidation plus léger que le fichier à transmettre.
Si vous voulez aussi de la réplication, il n'y a pas besoin de faire la copie totale.
Un fichier ayant beaucoup d'écriture pourrait être l'information de session avec sauvegarde de l'état précédent.
"La première sécurité est la liberté"
[^] # Re: GlusterFS ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Publication de FineFS, un système de fichiers répartis. Évalué à 2.
"La première sécurité est la liberté"
# Lawrence Lessig ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Larry Lessig affirme que la loi asphyxie la créativité.. Évalué à 6.
http://www.lessig.org/
"La première sécurité est la liberté"
[^] # Re: GlusterFS ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Publication de FineFS, un système de fichiers répartis. Évalué à 2.
Par contre, dans le cas d'écriture fréquente, c'est pas forcément le top. Vous devriez laisser la possibilité de désactiver la réplication asynchrone pour certain fichier/répertoire souvent mis à jour. J'imagine qu'avec les appli web, cela deviendra de plus en plus fréquent.
"La première sécurité est la liberté"
[^] # Re: GlusterFS ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Publication de FineFS, un système de fichiers répartis. Évalué à 2.
Concernant l'atomicité, je pensais à un fichier modifié (modif d'une image par exemple), relus immédiatement (affichage). Tu veux dans ce cas la nouvelle image ou l'ancienne, mais pas un truc entre les 2. Ici, cela n'est pas gênant mais imagine une sauvegarde qui aurait un "bout d'image".
C'est pas vraiment une histoire de lock, si ton système ne donne pas la possibilité de connaitre l'état des données, c'est difficile à faire au niveau applicatif (le plus simple est de retourner la vieille version tant que la nouvelle n'est pas complètement dans le système)
"La première sécurité est la liberté"
[^] # Re: GlusterFS ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Publication de FineFS, un système de fichiers répartis. Évalué à 4.
Est-ce que vous gérez l'atomicité de remplacement de fichier ? Genre un nouveau fichier est écrit, si un autre fichier cherche à le lire, il aura le précédent ou le nouveau, mais pas une erreur ou un truc mélanger ou tronqué.
Est-ce que vous gérez un système d'envois en "2 bandes" ? En gros, est-ce que le système de fichier pourrait envoyer directement un fichier à un client sans repasser par un serveur web ? Je me suis toujours demandé comme faire une réponse en utilisant 2 machines, sans repasser par la 1er et sans proxy.
"La première sécurité est la liberté"
[^] # Re: GlusterFS ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Publication de FineFS, un système de fichiers répartis. Évalué à 4.
"La première sécurité est la liberté"
# duplication ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Compromission de code source.. Évalué à 7.
"La première sécurité est la liberté"
[^] # Re: GlusterFS ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Publication de FineFS, un système de fichiers répartis. Évalué à 4.
"La première sécurité est la liberté"
[^] # Re: Après les DRMs : le watermarking
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Changement de ton chez les vendeurs de disques. Évalué à 2.
Le papier part de principe qu'il peut retrouver "suffisamment" de marque qui ne sont pas dû au hasard. On dirait qu'il part du principe que la seul attaque possible est le mélange de seconde du film entre plusieurs attaquant.
Ce que je dis plus haut c'est que des modifications mineurs du film détruisent quasiment à coup sûr tout marquage (décalage, zoom, suppression de bord, filtre passe-bas, filtre anti-bruit, filtre d'amélioration).
Tu peux définir un code aussi long que tu veux, si tu ne récupères pas assez de symbole "juste" tu ne peux rien en faire.
"La première sécurité est la liberté"