M a écrit 3005 commentaires

Renseignes toi un petit peut avant de dire des conneries :)
J'ai pas trouvé beaucoup de doc sur le sujet sauf des vieux trucs du genre : http://people.ischool.berkeley.edu/~rachna/courses/cs261/pap(...) ou http://www.numerama.com/forum/index.php?s=f2f603d80993fc53c5(...)
(j'ai pas trop cherché non plus)
T'as des liens ?

3) Non le protocole n'est pas sensible aux attaques man in the middle; comme tout protocole d'échange de clef qui se respecte, on utilise une variante d'un echange Diffie Helman
Heu je te suis pas. http://en.wikipedia.org/wiki/Diffie-Hellman#Authentication

In the original description, the Diffie-Hellman exchange by itself does not provide authentication of the communicating parties and is thus vulnerable to a man-in-the-middle attack.

Du coup il faut authentifier les personnes avec lesquels on parle, ce qui n'est pas forcement simple si tu considère qu'il peut y avoir plein de personnes compromises tout autour de toi.

4) Non, un noeud freenet ne peut pas être port-scanné même de manière active. Il n'y a pas de message de rejet dans le protocole; si les noeuds ne se comprennent pas ils s'ignorent
Oui mais qu'est ce qui déclenche le fait qu'il se comprenne. Comment 2 clients officiels font pour établir une connection ?

2) Tu n'acceptes que les connections venant de noeuds "authentifiés"; pas les connections venant de n'importe qui! (cf http://wiki.freenetproject.org/OpennetDesign )
Et comment tu connais les noeuds authentifié au départ ?
When a node wants to join the opennet, it needs to connect to a seed node. A list of these nodes is provided by the main Freenet Project server for convenience (see here).
Donc il suffit au FAI de faire du phishing sur ce serveur pour fourni une liste de nodes toutes corrompues.

It establishes an encrypted connection with the node, without initially being routable.
Elle est ou l'authentification ? Le noeud d'entré m'a l'air d'accepter des connections de n'importe qui.

Le protocole de Freenet est chiffré, a priori rien ne permet de l'identifier.
Sauf qu'avant d'être chiffré, il y a une initialisation pour se mettre d'accord sur le chiffrement.
- Cet échange est il commun, de tel sorte que l'on ne puisse pas reconnaître freenet.
- Est il sensible à des attaques man in the middle.
- Un FAI qui connait les gens qui parle en chiffé ne peut il pas essayer de lancer une connection de type freenet sur ces machines et suivant la réponse déterminer si freenet tourne dessus.

Ensuite même si le flux est crypté, celui-ci à quand même des caractéristiques. A la louche :
- il ne sort pas sur des ports standard (pas https, ssh, ...)
- Tu émets des connections chiffré, mais tu en acceptes aussi ( ca pue le p2p : 90 % des gens ne font pas serveur)
- nombre de connection vers ta machine


Et puis je serais un gouvernement de type chinois j'interdirais toutes les connections chiffrés que je ne sais pas casser.

Une nouvelle fonctionnalité résolvant le problème soulevé, le "darknet", a été ajoutée. Elle permet aux utilisateurs de définir les personnes auxquelles elles souhaitent que leur noeud Freenet se connecte. Ceci rend très difficile pour un tiers de déterminer qui utilise Freenet.
Le FAI n'est il pas capable d'analyser le traffic et de déterminer si l'utilisateur fait du http ou alors s'il utilise un protocole qui s'approche de freenet ?
Freenet a un protocole qui est difficilement identifiable ?

Une fois publié, le contenu est immuable, dupliqué et déplacé sur le réseau de sorte que le tracer ou le détruire devienne une opération très difficile et coûteuse. Le contenu inséré est maintenu sur le réseau et disponible aussi longtemps que des gens le téléchargent;
Et si personne ne telecharge mes documents pendant une certaines periodes, ca se passe comment. Il faut que je les remettes sur le reseau (et dans ce cas je fait office de "leecher").

Tout-à-fait d'accord. Dans le même ordre d'idée, pourquoi utiliser autre chose que Windows et Internet Explorer

Par ce que d'autres logiciels comme firefox propose des fonctionnalités intéressantes et innovantes : onglet, nombreux plugins, ...

Pour en revenir a la voip. Si ma copine est dernière un NAT symétrique je peux :
- changer de copine
- utiliser le téléphone classique
- coder un truc qui marche derrière le NAT symétrique
- utiliser une solution qui marche déjà
Que vont faire plus de 90 % des gens ?

cependant celà demande d'avoir des serveurs dédiés et accessibles quelque-part sur la planète avec suffisement de bande passante pour gérer les utilisateurs qui sont dans le cas des NAT symetriques...
C'est pour ca qu'un truc distribué bien foutu n'est pas forcement une solution bête

Grâce à IPv6 qui distribue par défaut des adresses IP publiques aux gens qui partagent leur connexion internet, cela casse la dépendance sur ces serveurs costos car les canaux de voix peuvent être montés directement entre les deux programmes clients.
IPV6 ne veut pas dire qu'il n'y aura plus de parfeu...
Donc même si ca simplifie les choses, ca veut pas dire que ca marchera dans tout les cas.

Vous connaissez tous certainement l'immonde skype: un système de téléphonie IP complètement propriétaire.
Oui, mais propose ton alternative qui marche aussi bien que skype...
Parce que le commun des mortels ils ont en quasiment rien a tapé que ca utilise des protocoles standard, que c'est libre, ... Ce qu'ils veulent d'abord c'est un truc qui marche (et sans avoir a configurer le truc).

tu leur reproches quoi ?

Que du bon donc en perspective et ça devrait faciliter la venu des lecteurs flash autres que ceux d'adobe.
Ca n'a pas l'air d'émouvoir les developpeur de player flash libre :
http://lists.freedesktop.org/archives/swfdec/2008-May/001459(...)

For Swfdec the Flash playe it means pretty much nothing. Swfdec
already implements everything that is written down in that
specifications. This is just the Adobe version of
http://www.m2osw.com/swf_alexref.html - so no wonders are to be
expected.

Oui mais bon sur le serveur il y a toutes les applis qui fonctionne. Donc déjà ça charge pas mal la machine.
Et je vois pas comment tu peux envoyer des données chiffrer aux applis distantes : pour moi le serveur est obligé de déchiffrer

Et oui, car deux ordinateurs ne tournent pas à la même vitesse ! Si l'on présente à chacun un flux de 200mn à 44100hz, cela peut durer 198mn chez le premier, et 201m et des brouettes chez le second... ( sans compter les ntp et autres interférences de ce type )

C'est surtout les horloges de la carte audio qui cadence la lecture...


Le protocole de diffusion réseau ( rtp ) n'a pas de contrôle de synchronisation et ne permet pas ce genre de correction ( du moins pas encore.. )

J'ai des souvenirs comme quoi rtp/rtcp ont tout un mecanisme de timestamp pour garantir la synchro des flux. Mais peut etre que ca marche pas dans se cas, ou alors ca vient du fait que rtcp n'est pas utilisé.

L'industrie de la musique sait déjà que ça ne marche pas.
Va dire ca a Deezer ...

En revanche, les ressources processeur des deux extrémités, ça peut arriver à être bloquant.
Surtout pour le serveur s'il doit gerer plusieurs client en //.

Mais on peut imaginer à la rigeur un model ou au lieu d'acheter un pc à la maison, on en loue un dans un datacenter et on achete des clients moins puissant.

Un grand nombre d'acteur s'appuie sur flash pour eviter que les contenus multimedia diffusé sur le web puisse être sauvegardé facilement.

Est ce que cette liberation de flash, ne va pas forcer ses acteurs à se tourner vers des solutions avec drm ?

C'est clair. Surtout que pour optimiser pour une machine particulière tu peux etre amener a utiliser des équivalence, réordonné l'algo; voir meme perdre un peu de precission si ca ne gene pas.

Et puis bon le pb de shootout, c'est que les "tests" ne sont pas forcement représentatif.
J'ai regarder le cas des arbres binnaires, et on peut voir un beau malloc dans l'implementation.
Celui ci est appelé un certain nombre de fois (59157182).
Un coup de profiler confirme que ce test benchmark l'allocateur memoire de la libc...

Heu, a part pour les arbres binnaires, il n'y a pas de grosses differences : http://shootout.alioth.debian.org/gp4/benchmark.php?test=all(...)

Et puis bon le pb de shootout, c'est que les "tests" ne sont pas forcement représentatif.

Heu windows XP il tourne sur l'olpc ?

Parce que bon il n'y a pas que l'applicatif à porter, il faut porter aussi les drivers.

Par exemple pour ce que j'ai pu voir l'olpc utilise de la NAND (sous jffs2) sans passer par des couches qui la masque (comme les sous eeepc). Et à ma connaisance MS ne propose aucune solution pour faire tourner des trucs au dessus de la NAND.

Pour le 2), le .htaccess n'est pas très portable. Vu que tu n'a pas l'air d'autoriser des telechargements direct, il suffirait que tu stockes les fichiers avec une extension inoffensive.

Sauf que c'est bien subjectif comme critère ;)

Je pense qu'on a maintenant bien débattu sur le changement qui aurait dû arriver si l'ISO avait fait son boulot correctement et qui n'arrivera pas, mais j'ai du mal à partager le catastrophisme ambiant. On a deux normes ISO, soit. L'une est une vraie norme, l'autre c'est de la merde. OK. Mais est-ce de l'optimisme que de penser que tout n'est pas si noir dans cette affaire?
Oui si au lieu de s'apitoyer, on rendait le format ODF plus attractif :
- avoir un support correct dans plusieurs suite bureautique
- avoir un support dans les framwork python/java/perl/... pour le manipuler facilement
- avoir des outils qui travailles dessus (diff, correction orthographique, ...)
- [...]

Comme tu le dis la force du libre c'est pas le coté commercial, mais sa grande qualité et ses possibilité d'évolution infinie (chacun peu rajouter son grain de sel).

Euh.... Fonctionelement c'est quoi la différence ?
Le périph a des états internes que tu ne connais pas, et que tu ne peux pas sauver en RAM.
Tu es donc obligé de passer par une phase de reset et reconfiguration pour retomber sur tes pattes.

D'ailleurs en cherchant plus d'info sur le sujet j'ai enfin compris pourquoi ACPI etait une un truc qui fonctionne super mal et bourre de probleme surtout sous Linux. Il a tout simplement ete fait dans cette optique!

Le gros pb de l'ACPI c'est que c'est du code proprio qui est écrit par les fabricants des chipsets des cartes mères.
C'est du code fait à l'arrache, qui n'est testé que sous windows, et qui peut être compilé avec le compilo Microsoft (qui comme tout ses compilos ne suit pas les specs à la lettre).

Pour certains truc les développeur Linux en sont rendu à copier le fonctionnement de Windows...


Sinon à une époque Intel avait eu une grande idée (avec l'EFI ???) d'étendre ce mécanisme de code proprio interprété au code des drivers des composants de la carte mère.


PS : tant que j'y suis, il parait que certaines stack réseau pour booter sur le réseau depuis le bios sont bien buggé. Le problème de fond est donc qu'avec la carte mère, on récupère du code proprio bas niveau tout pourris et sans specs.

Bref, il y a un gros soucis de sauvegarde et de restauration d'état dans beaucoup de drivers.
Encore faut il que ca soit possible : certains peripherique ne supporte pas simplement la sauvegarde/restoration de contexte en sauvant/restorant les registes.

Il est parfois bien plus simple de faire un bon reset du controlleur et le reconfigurer.

qiv est assez sympa pour visualiser des images rapidement.

On peut même avec certaines combinaison de touche copier/déplacer des images dans un répertoire. Pratique pour supprimer/sélectionner des photos

"A l’heure actuelle, des milliards de dollars d’infrastructures de compression vidéos vont être littéralement jetés par les fenêtres lorsque de nouvelles normes comme la h.264 seront adoptées",
Oui mais bon vu qu'a chaque nouvelle norme les puissances de calculs change aussi le problème reste le même : sur le cell d'aujourd'hui qui est capable d'encoder du h264 en temps réel qui me dira qu'il sera assez puissant pour faire la même chose en h265 ou équivalent ?

Vous n’avez pas à vous débarrasser de votre ordinateur à chaque fois que Microsoft lance une nouvelle version de ses logiciels.
Qu'est qui se passe s'il n'y a pas de mise a jour soft ? On se retrouve pas la même situation (ne me parler pas de développer soit même les évolutions)

PS : il faut voir aussi qu'en fasse les recepteurs (tnt/satelitte/...) décode avec des solutions en dur. Donc l'évolution est quand même bloqué...