Defre a écrit 37 commentaires

En effet, le terme "photographe amateur" était malvenu... Littleboy à bien cerné le marché.

L'application ici était de faire du repérage "rapide" en milieu naturel, et un panorama en un clic apportait un avantage non négligeable apparemment. La qualité n'étant pas l'objectif principal (mais bienvenu quand même!).

Pour le reste, je suis d'accord avec toi, la valeur ajoutée tenait uniquement dans "l'instantané".

Merci pour ton appréciation de bon "journal trolleur" comme il faut... :)

Ceci dit oui, je suis d'accord avec toi sur l'essentiel des points, et tu resitue bien les choses. Le truc c'est qu'à l'autre bout, cet ami me refile la patate chaude pour voir ce que je peux faire de ces fichiers... Grosse déception pour lui.

Et cette segmentation (abusive en mon sens) que tu soulignes m'a quelque peu surprise, suffisamment pour que j'y trouve une analogie avec d'autres produits, beaucoup plus grand public, qui "enferme l'utilisateur" (question de point de vue une fois de plus). Après c'est le choix de l'utilisateur.
La ou ça coince, c'est que l'utilisateur final était complètement dépassé par "un truc qui marche tout seul"; et pour les tests sur internet, je pense qu'il a surtout du le trouver mentionner dans un journal "papier". Je doute qu'il ait le réflexe 'net'; une erreur de segmentation tout au plus.
La solution "reflex + une lentille panoramique + un pied" aurait sans doute été plus simple au final.

La situation de "l'APN qui te ne permet pas de prendre de photos pour toi", me paraissait suffisamment cocasse pour être relatée dans un bon troll (ce n'est pas le jour pourtant je crois, désolé ;)).

Tant qu'il ne télécharge pas, ça va!

=)

Avec des idées un peu tordues comme ça, il y a bien eu OFFSystem...
Mais là, un protocole volontairement inutilisable ne montrera pas qu'on peut faire autre chose que "pirater" avec ces technologies...

Et avec une couche d'abstraction adéquate le travail pourra aisément être porté d'une plateforme à l'autre (peu de plateformes refusent le C89, non ?).

Oui elle y ressemble, fait exprès... pas tout à fait :).

L'idée d'i2p est à mon avis séduisante. Un peu de concurrence dans le domaine en plus ne ferait pas de mal. Sans vouloir décourager notre ami étudiant, un environnement P2P complet (j'entends protocole bien défini, bien implémenté et suffisament fonctionnel pour être immédiatement attractif) et mêlant autant de domaines technologiques (chiffrement, authentification, mais aussi indexation, calcul distribué, routage... communs aux technologies P2P moderne), c'est difficile à achever en aussi peu de temps...

Donc avec la volonté qu'il affiche de fournir un travail "bien fait et innovant", je me dis que s'attaquer à une partie restreinte du (gros) problème est plus sujet à innovation.
Copier i2p n'est pas idéal non plus, juste innover :).

Il y a nombre d'applications de P2P diverses et variées, leur but final ne varie pas tant que ça (il y a évidemment des exceptions).

Ce qui pourrait être intéressant, c'est que votre protocole P2P, plutôt que de penser "fichier-de-toi-à-moi", se présente comme un protocole de transport. Une bibliothèque que l'on pourrait utiliser dans des applications variées...

Le protocole, outre les fonctionnalités que tu suggèrent, devrait permettre un repérage sûr des noeuds: une clé plutôt qu'une IP (ça entre dans le cadre "hadopi ne soit pas une menace").
(et par conséquent permettre de construire des tunnels, mais je pense que ce serait très ambitieux comme approche...).
Dans l'idée la plus simple, un dictionnaire ("table de hachage") distribué est une bonne idée.

Après, puisqu'il faudra sans doute rendre une application "c'est zoliii: je clique sur un bouton pour avoir un fichier", un front-end employant ce protocole à titre d'exemple.

Des recherches dans ce sens (étendre le P2P à autre chose que des fichiers [sans jouer sur les termes]) me paraissent plus intéressantes qu'une n-ième réinvention de la roue...

Suffit de se trouver une VM sale, de faire une capture sur le réseau de cette VM et de reproduire la démarche ci-dessus (si tant est que ceci est facilement reproductible).

On en saura sans doute davantage...

<mauvaise foi>C'est bien ce que je dis, un malware...</mauvaise foi>

C'est pas net, mais comme on nous le rabache, une IP ne dit pas tout...

Mais ce serait pas tout simplement dans les CGUs ? Non parce que si le monsieur a cliqué sur "Oui, je le veux", il y a moins de questions à se poser.

Je ne sais pas s'il faut incriminer directement ms dans l'histoire. Si ton contact utilise IE, il utilise plus que probablement le système d'exploitation lié.

Et ce n'est une découverte pour personne que c'est un bouillon de culture pour malware (quel que soit l'argent investi dans les études qui affirment le contraire).

Le protocole "je chope l'adresse, j'espionne" est tellement gros que j'ai du mal à leur attribuer la culpabilité...

Il reste à laisser ce genre de serveur à l'abri d'OS malicieux.

Ou alors juste un petit:

#define memset(a,b,c) memset(a,c,b)

après les inclusions :).

(bonjour bonjour, je suis nouveau ici)

Une utilisation aussi hasardeuse de la mémoire est assez inquiétante.
Dans le cas présent, par chance, pas de corruption de données, mais les structures ne sont pas initialisées...

Il n'y a eu aucun test de fait sur ce code ? Leur politique c'est «ça compile, ça passe» ?