dire qu'il est dur a aborder sans étude d'info est complètement faux.
Je le trouve dur à aborder en ayant fait des études d'info (rien d'insurmontable ceci dit), et je n'ai fait qu'extrapoler en supposant que ce devrait être encore plus dur pour quelqu'un qui n'en avait pas fait.
En particulier, la notation de l'inférence de types n'est pas évidente pour qui n'a pas fait de lambda calcul. L'imbrication des let et autres let rec, la différence entre les fonctions renvoyant quelque chose et les instructions de renvoyant rien mais agissant par effets de bord... c'est pas spécialement évident non plus.
Et d'ailleurs tu conseilles le C mais mâitrises tu complètement la sémantique du C ?
Je n'ai jamais prétendu que le C était simple, bien au contraire. La seule raison pour laquelle je pense que le C est utile, c'est parce que si on sait coder en C, on a une bonne intuition de la manière dont fonctionne un vrai ordinateur, et je pense qu'avoir cette intuition est utile.
Dire que ca syntaxe n'est pas amicale n'a pas de sens, ca dépend des goûts de chacun.
Aurais-tu, par hasard, omis de remarqué que je précisais entre parenthèses "à mon avis" ? Effectivement, ça dépend des goûts de chacun, mais la syntaxe d'OCaml est bourrée d'exceptions, et ça n'en facilite pas l'apprentissage. En particulier, le fait qu'il y ait un opérateur par type pour une même opération, c'est super chiant. Certes, ça permet l'inférence de types, mais ça reste super chiant de devoir se rappeler de la liste des opérateurs de chaque type.
Au niveau de la syntaxe, un langage comme le Scheme est beaucoup plus rapide à apprendre, parce qu'il existe très peu de règles et qu'elles n'ont pas d'exceptions. En 10 minutes n'importe qui peut comprendre et retenir la syntaxe de Scheme.
Le C, c'est vieux, moche et pas pratique, mais c'est très proche de la machine. Je pense que quand on débute, c'est une bonne chose d'être proche de la machine, et de comprendre assez précisément ce qui se passe, plutôt que de se baser sur une abstraction pas toujours proche de la réalité. D'un autre côté, je peux me tromper, si ça se trouve on peut très bien rester toute sa vie avec un langage de haut niveau.
L'OCaml, c'est intellectuellement très joli, en pratique très efficace, mais esthétiquement c'est (à mon avis) une horreur. Quand on est habitué à des langages à la syntaxe plus amicale, c'est assez dur de se forcer à apprendre celle de l'OCaml, bien que ça vaille surement le coup. Quitte à l'apprendre un jour, je pense qu'il vaut mieux le faire le plus tôt possible. Par contre, c'est un langage qui repose sur des concepts assez avancés qui risquent d'être durs à aborder si tu ne fais pas d'études d'info.
Le plus facile pour l'apprentissage, c'est un langage à la syntaxe assez souple, et qui permet d'obtenir rapidement des trucs qui marchent. Pour ça, je conseille Ruby parce que c'est ce que je connais, mais d'autres conseillent Python et je pense que les deux se valent. Le Ruby c'est joli, agréable à utiliser, propre (si on fait un peu attention), de haut niveau, et rapide à programmer... par contre si tu as un jour à faire des calculs intensifs, il faudra utiliser autre chose :)
Finalement, je me rend compte que je te conseille de commencer à la fois par le C, l'OCaml et Ruby. Comme ça ne va pas être pratique, je vais conclure en te conseillant --si tu cherches un seul langage-- de commencer par Eiffel. C'est plus simple que le C, plus élégant (à mon avis) que l'OCaml, presque aussi souple et bien plus rapide que Ruby.
Ils ne sont pas brevetables, et ne le seront pas tant qu'un texte ne l'autorisera pas. Par contre, "définitivement" c'est un peu trop optimiste :) Même s'ils tiennent parole et ne reproposent pas de texte tout de suite, ça viendra bien un jour...
Si ton innovation est interchangeable avec autre chose sur le marché, tu as travaillé pour rien, ce n'est pas vraiment une innovation. De même si ça met du temps à pénétrer sur le marché, c'est que l'innovation ne fournit pas un énorme avantage, ou simplement qu'il aurait mieux valu faire une meilleure étude de marché avant. Si c'est trop cher, ça ne se vendra pas, donc il faut vendre moins cher... et c'est faisable, car on parle de logiciels ici. Les logiciels comme AutoCAD qui se vendent super cher, c'est seulement parce qu'il y a un marché prêt à payer :)
Dans le cas des logiciels, il n'y a pas de coût de production autre que la R&D (ce qui est déjà pas mal). Ça veut dire que si tu as déjà payé les coûts de recherche, tu peux être premier sur le marché en vendant pas trop cher.
Ca ferait un marché hyper concurentiel en perpétuel recherche de l'innovation
Au temps pour ceux qui disent que les brevets logiciels favoriseraient l'innovation ;-)
Avec le risque de voir arriver une boite qui profite de toutes les innovations quasiment gratuitement, et qui te pique tout ton marché, et tu disparais.
D'un côté, regardons Apple qui sort, disons, un soft qui permet de faire de la recherche "à la google" dans ses documents. Admettons pour le coup que c'est une innovation. Qui peut en bénéficier gratuitement ? Le seul truc gratuit, c'est l'idée "faire de la recherche à la google, en local". L'implémentation, elle, il faut la refaire à partir de rien. Un brevet servirait à empêcher les gens d'utiliser l'idée, mais le droit d'auteur empêche déjà les gens de repomper ton implémentation. Vu le temps qu'il faudrait pour recoder ce genre de soft efficacement, qui risquerait de te piquer ton marché six mois plus tard ?
D'un autre côté, regarde des boîtes comme RedHat, qui d'une certaine manière ont bénéficié de pas mal d'innovations gratuitement... Même Solaris n'est pas encore mort, preuve que même pour un logiciel qui a pas mal de défauts et lourdeurs fasse à la concurrence, le marché s'accroche et résiste au changement. Windows, quant à lui, est indétrônable simplement parce qu'il a été le premier sur le marché, mais c'est un cas extrême.
Ensuite, sur profiter de la recherche du concurrent, si c'est un algo pas du tout trivial qui est implémenté, avec à disposition un binaire complètement obfusqué, ca me semble pas du tout évident de "profiter de sa recherche". Le système des brevets impose une publication.
Ce qui est valable pour ton concurrent est valable pour toi: tu n'es pas obligé de tout publier. Le fait que les brevets obligent à publier, c'est bien, mais à choisir entre:
1- un système où chacun peut garder son idée/implémentation secrête, mais où chacun est libre d'avoir une idée ou de refaire une implémentation (ie. un système à base de droit d'auteur)
2 - un système où chacun est obliger de publier son idée/implémentation, mais où un individu peut interdire à d'autre d'avoir une idée
Je crois que je préfère largement le 1. Il y a peut-être des nuances entre les deux, mais j'ai du mal à y croire. Et j'ai aussi beaucoup de mal à comprendre les gens qui revendiquent le fait qu'être le premier à avoir une idée leur donne des droits particuliers sur cette idée...
Bien que les brevets sont pas officiellement valide, il y en a quand meme...
Tant qu'ils ne sont pas valides, ils ne sont pas valides. Ça veut dire que une "invention" protégée par un brevet de ce genre ne l'est que pour les gens qui y croient, ou qui n'ont pas les moyens d'aller devant les tribunaux pour montrer que le brevet n'est pas valide. Ils fournissent donc une protection très relative.
Donc non en europe les inventions sont loin de que sur les droits d'auteurs...
J'ai pas trop bien compris cette phrase, mais je maintiens qu'en Europe les logiciels jusqu'à maintenant ne sont protégés légalement que par le droit d'auteur, et que ça a été bien suffisant.
des arguments autres que les brevets logiciel c'est mal
D'un autre côté, vu qu'ici presque tout le monde est d'accord que la directive sans les amendements "c'est mal", je trouve que débat "le droit d'auteur c'est bien assez" contre "le droit d'auteur c'est pas assez" est plus intéressant. Avant de s'arracher les cheveux à proposer mieux que les brevets logiciels, vérifions que ce qu'on a déjà n'est pas suffisant.
Disclaimer: je ne prétend pas proposer des réponses complètes à ces questions, ce n'est pas mon domaine, je veux juste proposer quelques pistes.
comment, du point de vue d'une entreprise, dépenser (beaucoup) d'argent en recherche, en sachant que n'importe quel concurrent pourra copier l'invention à cout bien moindre ?
Je vois deux arguments qui pourraient pousser un chef d'entreprise à investir dans la recherche même sans brevets:
- le fait d'être le premier sur le marché fait parfois la différence entre avoir 5% de parts de marché et en avoir 50%. Le concurrent qui passe 6 mois à réimplémenter ce que j'ai inventé risque d'arriver trop tard. S'il espère s'imposer, il devra aussi faire de la recherche, ce qui ammène le deuxième point,
- si mon concurrent peut profiter de ma recherche, je peux aussi profiter de la sienne.
Bien sûr, le premier point semble un peu ridicule si on imagine une PME qui propose un soft innovant et que six mois plus tard c'est Microsoft qui sort un concurrent... mais de toutes façons les marchés où MS est en position de force ne fonctionnent pas bien: la PME, avec son joli brevet, est quasiment sûre que son logiciel viole 4 ou 5 brevets qui appartiennent à MS et 4 ou 5 à IBM en bonus. Si une boîte de ce genre vient lui demander une licence, que fera-t-elle ?
Oui, c'est pays on fait de la recherche ou se sont contente de 'copier' de techniques existantes ?
T'as des exemples ?
Dans toute l'Europe, on ne fait que 'copier' des techniques existantes ?
Pour justifier l'ajout d'une mesure de protection, peut-être qu'il faudrait commencer par démontrer qu'il y a dysfonctionnement. Je veux bien croire que le droit d'auteur ne suffit pas à protéger l'innovation dans le secteur de l'informatique, mais à condition que l'on m'explique comment ce secteur s'est développé jusqu'à maintenant en Europe, et pourquoi les PME européennes sont aussi méfiantes vis-à-vis de la venue des brevets.
Pour pouvoir comparer, il faut se mettre d'accord sur ce qu'est un système d'exploitation. Si un système d'exploitation inclue l'environnement de bureau, alors Windows et GNU/Linux+KDE sont à égalité: si on enlève le composant de rendu HTML, le rendu HTML marche nettement moins bien.
Si on n'inclue pas l'environnement de bureau, alors je pense que Windows+un autre environnement fonctionnera parfaitement bien. Je ne peux pas garantir, il faudrait que quelqu'un qui utilise Windows (bouuh) vérifie, mais je doute que le composant d'IE soit utilisé ailleurs... je ne vois pas pourquoi il le serait.
(Note: à ma connaissance, il n'existe qu'un seul autre environnement de bureau pour Windows, dont j'ai oublié le nom, mais qui ressemblait à AfterStep... il y a aussi le port de KDE, qui doit être en cours.)
Il semble que l'informatique a réussi à se développer, jusqu'à maintenant, y compris dans les pays où la seule protection est le droit d'auteur. Pour cette raison, je ne suis pas du tout convaincu par les gens qui disent "oui mais les PME ne pourront jamais vivre"... elles vivent très bien.
De plus, si l'on regarde attentivement, les entreprisent qui attendent le plus les brevets logiciels en Europe, ce ne sont pas des PME qui risquent de couler si on leur pique leur idée super innovante, ce sont des grosses boîtes comme Nokia ou Microsoft.
C'est du capillotractage, un reseau de confiance à un seul niveau, sans heritage de confiance, c'est aussi interessant que considerer qu'un ordinateur tout seul est un reseau d'ordinateurs. Techniquement c'est vrai, mais je ne vois pas du tout ce que ca apporte a la discution.
Histoire de bien chipotter sur le vocabulaire et de dire des evidences, une whitelist c'est une liste de confiance, et assimiler une liste a un reseau... ben... pourquoi pas, mais ca n'apporte rien.
Note que je n'ai rien contre les reseaux de confiance, et ca pourrait tres bien etre utilise dans ce contexte... simplement je ne suis pas d'accord qu'une whitelist soit equivalente a un reseau de confiance "general": c'est a la fois moins puissant et plus sur.
Et une newsletter n'a bien sur rien a voir avec une mailing list...
Ben pas grand chose.
Tatata, une mailing list c'est une liste de diffusion, c'est a dire une adresse qui sert a dispatcher des emails. Il y a des mailing lists auxquelles tout le monde peut ecrire, et d'autres ou seul une liste reduite de gens peut ecrire. Une newsletter, c'est une mailing list ou seules quelques personnes peuvent ecrire.
Vous ne changez pas le protocole; vous mettez des rustines. Changez de protocole pour moi c'est repartir de 0.
Changer pour moi c'est changer, c'est a dire apporter des modifications ou remplacer par quelque chose de different. Mais nous n'avons l'air d'accord sur aucune des definitions des mots que nous employons :)
Rien compris.
J'ai oublie une negation.
Donc monsieur dupont c'est inscrit sur le site de la redoute et a cocher la case "oui je veux bien recevoir une newsletter de la redoute". Et il doit allez a son client mail pour whitelister la redoute pour sa newsletter
Tu veux bien, le temps d'une experience de pensee, accepter que le processus de liste blanche soit automatique ?
Dans tous les cas ca demande une confirmation de la part de l'utilisateur.
C'est deja le cas pour les mailing-lists, sauf de tres rares exceptions. Au risque de me repeter encore une fois, ce que je propose est une extension du protocole pour que cette confirmation (qui existe deja) soit interpretee automatiquement par les serveurs mails comme une autorisation a envoyer des mails sans payer le cout.
Deja qui dis que c'est un million la division?
C'etait une valeur lancee au hasard, si tu veux on peut remplacer par un "x". Si un mail coute x secondes a envoyer, alors le facteur de penalite, si je ne me trompe pas, est x multiplie par le nombre de mails qu'un spammer peut envoyer en une seconde.
Une etude avait montrer que plus de 50 % du spam n'avait AUCUN interet commercial, juste faire chier les gens
Mais bien sur... Tu ne confonds pas avec les virus par hasard ?
Et certains particuliers envoient de temps en temps des centaines de mails
Oui, de temps en temps. Selon la duree du calcul, ca peut etre acceptable ou non. Mais en general, les gens qui envoient des cartes de voeux le font a des gens qui les connaissent bien. Si, comme je le proposais, l'ajout de quelqu'un dans ton carnet d'adresse le whiteliste, ca elimine au moins la moitie du temps de calcul, en admettant que la moitie des gens a qui tu envoies des cartes de voeu t'ont dans leur carnet d'adresse.
Ce n'est evidemment pas parfait, puisqu'on ne peut pas penalise tous les emails non sollicites sans en penaliser quelques uns de legitimes. Tout est une question de compromis entre penaliser un peu les particuliers une fois l'an et penaliser beaucoup les spammers tous les jours...
Aie et deja un faux positif.
Un faux positif, ca serait quelqu'un qui est marque comme spammer alors qu'il ne l'est pas.
Deuxio et si les personnes ont demande mais n'ont pas forcement whitelister ?
Puisque le "whitelistage" est automatique (cf. plus haut), le cas de gens qui ont demande mais n'ont pas whiteliste est forcement tres rare, et donc la penalite est forcement tres reduite.
Tant que tu demande a l'utilisateur final de faire une action
Je trouve que j'ai depense beaucoup d'energie inutile pour expliquer que je ne demandais pas de nouvelle action a l'utilisateur final. Je voudrais essayer de conclure ma position sur la question clairement, pour qu'on puisse voir si on c'est compris.
- Si tu penses toujours que j'ajoute une etape de confirmation, ou une quelconque nouvelle action de la part de l'utilisateur final, je t'encourage a me relire, parce que ce n'est pas mon intention. Je propose de modifier le protocole de mail actuel pour que les actions habituelles des utilisateurs qui peuvent etre interpretees comme une autorisation a envoyer des mails le soient.
- Si on est d'accord sur la nature de ma proposition, mais que tu penses que cette extension du protocole n'est pas raisonnable, je suis tout a fait pret a en discuter, parce que je suis tres loin d'etre un expert en protocoles reseau.
- Si on est d'accord sur la nature de ma proposition et que tu es d'accord que c'est une extension de protocole qui est faisable en pratique, mais que tu penses que ca penalise trop les utilisateurs et pas assez les spammers, pourquoi pas, c'est un point de vue. Je n'ai pas grand chose d'autre a y repondre qu'un exemple bricole:
Si une machine peut envoyer 10 mails par seconde. Si un individu possede une machine et envoie 100 mails par jour, alors qu'un spammer possede 1000 machines et envoie 100 millions de mails par jour, alors en rajoutant un challenge qui dure une seconde par mail:
* l'utilisateur doit depenser 100 secondes de temps de calcul dans sa journee, ce qui est tres raisonnable, surtout si c'est en plusieurs fois.
* le spammer doit depenser 100 000 secondes, soit 27h, par jour, alors qu'avant cela ne lui coutait que 10 000 secondes, soit 2.7 heures. (Ca reste faisable avec ces chiffres, la penalite n'est que de 10)
Il s'agit de chiffres pris un peu au hasard, pour donner un ordre de grandeur de la penalite pour un utilisateur et un spammer. J'estime au juge qu'une penalite de 5 minutes par jour est raisonnable pour moi car c'est moins que le temps que je depense a filtrer mes spams. Vu mon debit de mails, je sais tres bien que meme si on fixait un challenge a 5 secondes, ca me penaliserait de moins de 5 minutes, et ca penaliserait beaucoup les spammers (d'un facteur 5*le nombre de mails qu'ils peuvent envoyer en une seconde).
Selon mon point de vue, la question principale pour savoir si cette solution est interessante, c'est de calculer s'il existe des valeurs qui penalisent tres peu les utilisateurs qui consomment plus que moi, et qui penalisent beaucoup les spammers. Pour ca il faudrait des chiffres plus fiables.
Je n'en sais rien, je n'ai fait que suggerer une maniere triviale de resoudre le probleme que tu evoquais. Savoir si les gens qui ont propose hashcash sont des gros nazes, ca ne m'interesse pas franchement...
Dans ce cas autant concevoir un vrai nouveau protocole qui prend le problème du spam en compte
Ben ecoute si tu as une meilleure solution, n'hesite pas hein...
On ne parle pas de ml [...] Mais bel et bien de newsletters
Et une newsletter n'a bien sur rien a voir avec une mailing list...
Je le rappelle, ma distinction etait entre d'une part les services auxquels on souscrit, qui n'ont pas a effectuer de challenge et d'autre part les services auxquels on ne souscrit pas, ce qui caracterise assez bien les spams, et qui eux doivent effectuer un challenge.
Effectivement, si ce qui te gene c'est que ce procede empeche une entreprise d'envoyer des newsletter a des gens qui n'ont rien demande, je me permet de te rappeler que c'est le but recherche.
Tu es toujours autorise d'envoyer des mails.
Je ne parle pas d'autorisation legale ou d'autorisation technique, je parle de monsieur Dupont qui dit "ah oui, j'aimerais bien recevoir des emails promotionnels de La Redoute", par opposition a monsieur Durand qui lui n'a rien demande.
Ca ressemble fort a l'etablissement d'un reseau de confiance
Non. Ca ressemble a une whitelist.
rien n'empeche de faire du pishing sur les domains qu'on a whitelister non?
C'est pour ca que je disais que pour que ce soit efficace, il fallait que les expediteurs s'authentifient, et que je disais que c'etait "un peu lourd"
Oui je parlais que du premier round
Il n'y a pas de premier round: soit l'utilisateur s'est inscrit et tu n'as pas de calcul a faire, soit l'utilisateur s'est inscrit et la tu dois faire un calcul.
Et ensuite il faut que les clients nous ait whitelister
Le "whitelistage" faisant partie du processus d'inscription a ta mailing-list (une newsletter est une mailing list), tu peux etre sur que tous tes "clients" se sont inscrits et t'ont whiteliste.
Ensuite, qu'une entreprise puisse empecher ses employes de s'inscrire a des mailing lists, c'est une eventualite plutot raisonnable, non ?
Non juste de changer tous ses logiciels
Effectivement, si on change le protocole il faut changer les logiciels :)
Donc je vois pas de qui d'autre pourrait faire le tri entre bon et mauvais mails a whitelister.
Il ne s'agit pas de faire un tri entre spam et non-spam, il s'agit de faire un tri entre mail sollicite par le destinataire et mail non sollicite. Seuls les mails non sollicites coutent du temps de calcul a l'expediteur. La separation entre mails sollicites et non sollicites est triviale a faire: tout mail qui provient d'un type qui n'a pas ete whiteliste n'est pas sollicite.
L'etablissement d'une whitelist est l'etablissement d'un reseau de confiance.
Un reseau en forme d'etoile, meme si c'est techniquement un reseau, ce n'est pas tres interessant. Pour parler de reseau de confiance, il faudrait au moins que tu herites en partie de la confiance des gens en qui tu fais confiance.
les spammeurs c'est drone army
Quelle que soit la puissance de calcul a la disposition d'un spammeur, si on divise par un million son debit, on diminue l'interet pour lui de spammer.
Donc d'un cote on penalise les entreprise et particulier en utilisant leurs temps cpu
Le particulier, a moins d'envoyer des centaines de mails par jour, n'est pas du tout penalise. Les entreprises, elles, ne sont penalisees que si elles envoient des emails de masse a des gens qui n'ont rien demande... mais... mais... c'est du spam ca, non ?
Tu mélanges deux choses différentes:
- un système entièrement à base de whitelists, ou un réseau de confiance
- un système entièrement à base de challenges à effectuer par l'expéditeur
Or, ce que je proposais comme réponse à ta question (et j'aurais aimé que tu le prennes de manière un peu moins hautaine, ce n'était qu'une suggestion), c'était un système à base de challenges ET équipé de whitelists permettant d'éviter aux gens "connus" d'effectuer les challenges.
Gérer des whitelists n'a jamais impliqué que les utilisateurs fassent tout à la main comme tu le supposes. Puisque mettre en place un système à base de challenges implique une extension du protocole ou un nouveau protocole, il est tout à fait envisageable de concevoir un protocole dans lequel une inscription à une mailing-list est conçue comme une autorisation explicite pour cette ML d'envoyer des emails, et que ce soit géré de manière transparente par les serveurs de mails. De la même manière, ajouter un utilisateur à son carnet d'adresses peut être considéré comme une autorisation à envoyer des emails.
Fait toi meme le calcul 10 000 clients; 2 secondes par clients.
un peu lourd tu est TRES gentil.
Tu n'as pas compris visiblement que ce que je proposais était une réponse à cette objection que tu as déjà faite. Dans cette solution:
- envoyer 10 000 mails à des "clients" qui ne se sont pas inscrit à la mailing list prend 20 000 secondes
- envoyer 10 000 mails à des clients qui se sont inscrits ne prend pas plus de temps qu'actuellement.
Au final, ça ne demande pas plus de participation à l'utilisateur qu'actuellement, ça n'implique pas de réseau de confiance. Reste ton objection sur les "drone army", mais comme tu n'as pas expliqué pourquoi ça invalidait le procédé, je ne sais pas quoi répondre.
Pour tous les types d'email où le destinataire s'inscrit quelque part, il est assez simple de trouver une solution: il suffit que l'inscription soit enregistrée aussi au niveau du serveur mail du destinataire, qui ne demandera alors pas de résoudre un "challenge" à l'expéditeur.
Autrement dit, si j'autorise quelqu'un à m'envoyer des emails, ça ne lui coûte pas de temps de calcul, mais si je ne l'ai pas encore autorisé, ça lui coûte quelques instants. C'est un peu lourd à mettre en place puisqu'il faut authentifier l'expéditeur pour ça, mais si c'est faisable, alors ça semble une solution correcte.
Je pensais surtout au cas où une entreprise centralise ses envois de mails en un seul serveur smtp, ce qui doit être fréquent. Vu de l'extérieur, le smtp de l'entreprise doit être considéré comme fiable sous peine de devoir faire les calculs... mais d'un autre côté il faut aussi s'assurer qu'on ne considère pas fiable le smtp d'un spammer.
Comme dit ailleurs, On ne peut séparer la contrainte utilisateur de la contrainte spammer. En effet, ralentir l'envoi de mail, implique un besoin de plus de machines pour TOUS les acteurs du web.
Admettons qu'envoyer un e-mail coûte (en temps d'attente) une demie seconde. Un utilisateur moyen envoie combien de mails dans la journée ? Prenons une estimation assez large et admettons qu'il en envoie une centaine. Ça fait un total de 50 secondes d'attente à cause de calculs effectués par sa machine... 50 secondes, c'est moins que le temps que passe mon filtre antispam à filtrer tous mes mails.
Maintenant, prenons un spammer et admettons qu'il envoie 10 000 000 spams par jour, ça fait environ 1400 heures d'attente par jour, si je ne me trompe pas. Pour lui, il y a un besoin de plus de puissance de calcul.
(Tout ça suppose bien sûr qu'une entreprise a la possibilité de se mettre sur une whitelist pour ne pas avoir à payer le coût d'envoi des emails de tous ses employés, mais qu'un spammer n'a pas cette possibilité.)
Si j'ai bien compris ta description, tu dois entrer un mot de passe pour que la machine accepte de résoudre le challenge. Donc pour contourner il faudrait te piquer la machine, te faire avouer le mot de passe, et t'empêcher de faire bloquer le compte suite à cet aveu, ce qui est un peu plus difficile que faire une copie de la liste dans le niveau 1.
Si le mot de passe est plus court que les informations envoyés, ce n'est pas un "one time pad", c'est juste un mot de passe à usage unique, qui sert à s'identifier mais pas à crypter. La crypto se fait par voie standard.
Le one time pad, c'est un système où tu as un "mot de passe" (clé) aussi long que le message à transmettre, et qui change à chaque fois. La clé est utilisée pour masquer le message, et comme elle est aussi longue que le message, il n'y a aucune répétition d'information qui donnerait un point d'appui pour craquer le code.
J'ai un scoop: tu as le droit de faire une petition et de la presenter a la comission, qui elle a le droit d'en faire ce qu'elle veut.
Alors qu'avec le TCE, tu aurais eu le droit de faire une petition et de la presenter a la comission, qui elle aurait eu le droit d'en faire ce qu'elle veut... mais c'aurait ete mieux.
Toute ressemblance avec une histoire de chasseurs est purement fortuite.
Note que le sujet, c'est le distributeur, et pas le logiciel (la syntaxe est ambigue, mais un logiciel ne peut pas avoir pour objectif de promouvoir son propre usage). Il est interdit de distribuer un logiciel en promouvant son usage pour violer le copyright.
Evolution propose un truc similaire depuis des lustres (et Thunderbird aussi depuis quelques mois), avec les vfolders, qui correspondent à une recherche sur des mails présentée sous forme de dossier virtuel qui se met à jour automatiquement. J'aime bien l'idée, même si je n'en ai jamais vraiment eu l'usage.
Et sinon, as-tu regardé du côté de Beagle, qui permet de faire une recherche de type "donne moi tous les jpegs", mais aussi de rechercher dans le contenu des fichiers ? (fonction similaire à un autre truc de Tiger, si j'ai bien suivi)
[^] # Re: Mon cas ...
Posté par Yusei (Mastodon) . En réponse au journal Commencer à programmer ?. Évalué à 4.
Il suffit d'apprendre le lambda-calcul (des maths), et puis d'apprendre le Lisp :)
[^] # Re: Avis
Posté par Yusei (Mastodon) . En réponse au journal Commencer à programmer ?. Évalué à 2.
Je le trouve dur à aborder en ayant fait des études d'info (rien d'insurmontable ceci dit), et je n'ai fait qu'extrapoler en supposant que ce devrait être encore plus dur pour quelqu'un qui n'en avait pas fait.
En particulier, la notation de l'inférence de types n'est pas évidente pour qui n'a pas fait de lambda calcul. L'imbrication des let et autres let rec, la différence entre les fonctions renvoyant quelque chose et les instructions de renvoyant rien mais agissant par effets de bord... c'est pas spécialement évident non plus.
Je n'ai jamais prétendu que le C était simple, bien au contraire. La seule raison pour laquelle je pense que le C est utile, c'est parce que si on sait coder en C, on a une bonne intuition de la manière dont fonctionne un vrai ordinateur, et je pense qu'avoir cette intuition est utile.
Aurais-tu, par hasard, omis de remarqué que je précisais entre parenthèses "à mon avis" ? Effectivement, ça dépend des goûts de chacun, mais la syntaxe d'OCaml est bourrée d'exceptions, et ça n'en facilite pas l'apprentissage. En particulier, le fait qu'il y ait un opérateur par type pour une même opération, c'est super chiant. Certes, ça permet l'inférence de types, mais ça reste super chiant de devoir se rappeler de la liste des opérateurs de chaque type.
Au niveau de la syntaxe, un langage comme le Scheme est beaucoup plus rapide à apprendre, parce qu'il existe très peu de règles et qu'elles n'ont pas d'exceptions. En 10 minutes n'importe qui peut comprendre et retenir la syntaxe de Scheme.
# Avis
Posté par Yusei (Mastodon) . En réponse au journal Commencer à programmer ?. Évalué à 5.
L'OCaml, c'est intellectuellement très joli, en pratique très efficace, mais esthétiquement c'est (à mon avis) une horreur. Quand on est habitué à des langages à la syntaxe plus amicale, c'est assez dur de se forcer à apprendre celle de l'OCaml, bien que ça vaille surement le coup. Quitte à l'apprendre un jour, je pense qu'il vaut mieux le faire le plus tôt possible. Par contre, c'est un langage qui repose sur des concepts assez avancés qui risquent d'être durs à aborder si tu ne fais pas d'études d'info.
Le plus facile pour l'apprentissage, c'est un langage à la syntaxe assez souple, et qui permet d'obtenir rapidement des trucs qui marchent. Pour ça, je conseille Ruby parce que c'est ce que je connais, mais d'autres conseillent Python et je pense que les deux se valent. Le Ruby c'est joli, agréable à utiliser, propre (si on fait un peu attention), de haut niveau, et rapide à programmer... par contre si tu as un jour à faire des calculs intensifs, il faudra utiliser autre chose :)
Finalement, je me rend compte que je te conseille de commencer à la fois par le C, l'OCaml et Ruby. Comme ça ne va pas être pratique, je vais conclure en te conseillant --si tu cherches un seul langage-- de commencer par Eiffel. C'est plus simple que le C, plus élégant (à mon avis) que l'OCaml, presque aussi souple et bien plus rapide que Ruby.
[^] # Re: Mon cas ...
Posté par Yusei (Mastodon) . En réponse au journal Commencer à programmer ?. Évalué à 7.
[^] # Re: On a pas l'europe on a pas les JO mais
Posté par Yusei (Mastodon) . En réponse à la dépêche Les eurodéputés rejettent la directive sur le brevet des logiciels. Évalué à 6.
[^] # Re: Pas d'autre proposition
Posté par Yusei (Mastodon) . En réponse au journal Brevets logiciels rejetés. Évalué à 4.
(Pas de plan B ? j'ai déjà vu ça quelque part)
[^] # Re: A propos de la propriete intellectuelle
Posté par Yusei (Mastodon) . En réponse au journal Quelle alternative aux brevets logiciels pour protéger notre propriété intellectuelle ?. Évalué à 3.
Oui, mais la recherche, c'est hasardeux :)
Si ton innovation est interchangeable avec autre chose sur le marché, tu as travaillé pour rien, ce n'est pas vraiment une innovation. De même si ça met du temps à pénétrer sur le marché, c'est que l'innovation ne fournit pas un énorme avantage, ou simplement qu'il aurait mieux valu faire une meilleure étude de marché avant. Si c'est trop cher, ça ne se vendra pas, donc il faut vendre moins cher... et c'est faisable, car on parle de logiciels ici. Les logiciels comme AutoCAD qui se vendent super cher, c'est seulement parce qu'il y a un marché prêt à payer :)
Dans le cas des logiciels, il n'y a pas de coût de production autre que la R&D (ce qui est déjà pas mal). Ça veut dire que si tu as déjà payé les coûts de recherche, tu peux être premier sur le marché en vendant pas trop cher.
Au temps pour ceux qui disent que les brevets logiciels favoriseraient l'innovation ;-)
D'un côté, regardons Apple qui sort, disons, un soft qui permet de faire de la recherche "à la google" dans ses documents. Admettons pour le coup que c'est une innovation. Qui peut en bénéficier gratuitement ? Le seul truc gratuit, c'est l'idée "faire de la recherche à la google, en local". L'implémentation, elle, il faut la refaire à partir de rien. Un brevet servirait à empêcher les gens d'utiliser l'idée, mais le droit d'auteur empêche déjà les gens de repomper ton implémentation. Vu le temps qu'il faudrait pour recoder ce genre de soft efficacement, qui risquerait de te piquer ton marché six mois plus tard ?
D'un autre côté, regarde des boîtes comme RedHat, qui d'une certaine manière ont bénéficié de pas mal d'innovations gratuitement... Même Solaris n'est pas encore mort, preuve que même pour un logiciel qui a pas mal de défauts et lourdeurs fasse à la concurrence, le marché s'accroche et résiste au changement. Windows, quant à lui, est indétrônable simplement parce qu'il a été le premier sur le marché, mais c'est un cas extrême.
Ce qui est valable pour ton concurrent est valable pour toi: tu n'es pas obligé de tout publier. Le fait que les brevets obligent à publier, c'est bien, mais à choisir entre:
1- un système où chacun peut garder son idée/implémentation secrête, mais où chacun est libre d'avoir une idée ou de refaire une implémentation (ie. un système à base de droit d'auteur)
2 - un système où chacun est obliger de publier son idée/implémentation, mais où un individu peut interdire à d'autre d'avoir une idée
Je crois que je préfère largement le 1. Il y a peut-être des nuances entre les deux, mais j'ai du mal à y croire. Et j'ai aussi beaucoup de mal à comprendre les gens qui revendiquent le fait qu'être le premier à avoir une idée leur donne des droits particuliers sur cette idée...
[^] # Re: Le droit d'auteur
Posté par Yusei (Mastodon) . En réponse au journal Quelle alternative aux brevets logiciels pour protéger notre propriété intellectuelle ?. Évalué à 3.
Tant qu'ils ne sont pas valides, ils ne sont pas valides. Ça veut dire que une "invention" protégée par un brevet de ce genre ne l'est que pour les gens qui y croient, ou qui n'ont pas les moyens d'aller devant les tribunaux pour montrer que le brevet n'est pas valide. Ils fournissent donc une protection très relative.
J'ai pas trop bien compris cette phrase, mais je maintiens qu'en Europe les logiciels jusqu'à maintenant ne sont protégés légalement que par le droit d'auteur, et que ça a été bien suffisant.
D'un autre côté, vu qu'ici presque tout le monde est d'accord que la directive sans les amendements "c'est mal", je trouve que débat "le droit d'auteur c'est bien assez" contre "le droit d'auteur c'est pas assez" est plus intéressant. Avant de s'arracher les cheveux à proposer mieux que les brevets logiciels, vérifions que ce qu'on a déjà n'est pas suffisant.
[^] # Re: A propos de la propriete intellectuelle
Posté par Yusei (Mastodon) . En réponse au journal Quelle alternative aux brevets logiciels pour protéger notre propriété intellectuelle ?. Évalué à 3.
Je vois deux arguments qui pourraient pousser un chef d'entreprise à investir dans la recherche même sans brevets:
- le fait d'être le premier sur le marché fait parfois la différence entre avoir 5% de parts de marché et en avoir 50%. Le concurrent qui passe 6 mois à réimplémenter ce que j'ai inventé risque d'arriver trop tard. S'il espère s'imposer, il devra aussi faire de la recherche, ce qui ammène le deuxième point,
- si mon concurrent peut profiter de ma recherche, je peux aussi profiter de la sienne.
Bien sûr, le premier point semble un peu ridicule si on imagine une PME qui propose un soft innovant et que six mois plus tard c'est Microsoft qui sort un concurrent... mais de toutes façons les marchés où MS est en position de force ne fonctionnent pas bien: la PME, avec son joli brevet, est quasiment sûre que son logiciel viole 4 ou 5 brevets qui appartiennent à MS et 4 ou 5 à IBM en bonus. Si une boîte de ce genre vient lui demander une licence, que fera-t-elle ?
[^] # Re: Le droit d'auteur
Posté par Yusei (Mastodon) . En réponse au journal Quelle alternative aux brevets logiciels pour protéger notre propriété intellectuelle ?. Évalué à 3.
Dans toute l'Europe, on ne fait que 'copier' des techniques existantes ?
Pour justifier l'ajout d'une mesure de protection, peut-être qu'il faudrait commencer par démontrer qu'il y a dysfonctionnement. Je veux bien croire que le droit d'auteur ne suffit pas à protéger l'innovation dans le secteur de l'informatique, mais à condition que l'on m'explique comment ce secteur s'est développé jusqu'à maintenant en Europe, et pourquoi les PME européennes sont aussi méfiantes vis-à-vis de la venue des brevets.
[^] # Re: WFP
Posté par Yusei (Mastodon) . En réponse au journal Internet Explorer Phénix. Évalué à 3.
Si on n'inclue pas l'environnement de bureau, alors je pense que Windows+un autre environnement fonctionnera parfaitement bien. Je ne peux pas garantir, il faudrait que quelqu'un qui utilise Windows (bouuh) vérifie, mais je doute que le composant d'IE soit utilisé ailleurs... je ne vois pas pourquoi il le serait.
(Note: à ma connaissance, il n'existe qu'un seul autre environnement de bureau pour Windows, dont j'ai oublié le nom, mais qui ressemblait à AfterStep... il y a aussi le port de KDE, qui doit être en cours.)
[^] # Re: Le droit d'auteur
Posté par Yusei (Mastodon) . En réponse au journal Quelle alternative aux brevets logiciels pour protéger notre propriété intellectuelle ?. Évalué à 6.
De plus, si l'on regarde attentivement, les entreprisent qui attendent le plus les brevets logiciels en Europe, ce ne sont pas des PME qui risquent de couler si on leur pique leur idée super innovante, ce sont des grosses boîtes comme Nokia ou Microsoft.
[^] # Re: WFP
Posté par Yusei (Mastodon) . En réponse au journal Internet Explorer Phénix. Évalué à 10.
[^] # Re: Oui et non
Posté par Yusei (Mastodon) . En réponse au journal Hashcash, vers une solution contre le spam ?. Évalué à 2.
C'est du capillotractage, un reseau de confiance à un seul niveau, sans heritage de confiance, c'est aussi interessant que considerer qu'un ordinateur tout seul est un reseau d'ordinateurs. Techniquement c'est vrai, mais je ne vois pas du tout ce que ca apporte a la discution.
Histoire de bien chipotter sur le vocabulaire et de dire des evidences, une whitelist c'est une liste de confiance, et assimiler une liste a un reseau... ben... pourquoi pas, mais ca n'apporte rien.
Note que je n'ai rien contre les reseaux de confiance, et ca pourrait tres bien etre utilise dans ce contexte... simplement je ne suis pas d'accord qu'une whitelist soit equivalente a un reseau de confiance "general": c'est a la fois moins puissant et plus sur.
Tatata, une mailing list c'est une liste de diffusion, c'est a dire une adresse qui sert a dispatcher des emails. Il y a des mailing lists auxquelles tout le monde peut ecrire, et d'autres ou seul une liste reduite de gens peut ecrire. Une newsletter, c'est une mailing list ou seules quelques personnes peuvent ecrire.
Changer pour moi c'est changer, c'est a dire apporter des modifications ou remplacer par quelque chose de different. Mais nous n'avons l'air d'accord sur aucune des definitions des mots que nous employons :)
J'ai oublie une negation.
Tu veux bien, le temps d'une experience de pensee, accepter que le processus de liste blanche soit automatique ?
C'est deja le cas pour les mailing-lists, sauf de tres rares exceptions. Au risque de me repeter encore une fois, ce que je propose est une extension du protocole pour que cette confirmation (qui existe deja) soit interpretee automatiquement par les serveurs mails comme une autorisation a envoyer des mails sans payer le cout.
C'etait une valeur lancee au hasard, si tu veux on peut remplacer par un "x". Si un mail coute x secondes a envoyer, alors le facteur de penalite, si je ne me trompe pas, est x multiplie par le nombre de mails qu'un spammer peut envoyer en une seconde.
Mais bien sur... Tu ne confonds pas avec les virus par hasard ?
Oui, de temps en temps. Selon la duree du calcul, ca peut etre acceptable ou non. Mais en general, les gens qui envoient des cartes de voeux le font a des gens qui les connaissent bien. Si, comme je le proposais, l'ajout de quelqu'un dans ton carnet d'adresse le whiteliste, ca elimine au moins la moitie du temps de calcul, en admettant que la moitie des gens a qui tu envoies des cartes de voeu t'ont dans leur carnet d'adresse.
Ce n'est evidemment pas parfait, puisqu'on ne peut pas penalise tous les emails non sollicites sans en penaliser quelques uns de legitimes. Tout est une question de compromis entre penaliser un peu les particuliers une fois l'an et penaliser beaucoup les spammers tous les jours...
Un faux positif, ca serait quelqu'un qui est marque comme spammer alors qu'il ne l'est pas.
Puisque le "whitelistage" est automatique (cf. plus haut), le cas de gens qui ont demande mais n'ont pas whiteliste est forcement tres rare, et donc la penalite est forcement tres reduite.
Je trouve que j'ai depense beaucoup d'energie inutile pour expliquer que je ne demandais pas de nouvelle action a l'utilisateur final. Je voudrais essayer de conclure ma position sur la question clairement, pour qu'on puisse voir si on c'est compris.
- Si tu penses toujours que j'ajoute une etape de confirmation, ou une quelconque nouvelle action de la part de l'utilisateur final, je t'encourage a me relire, parce que ce n'est pas mon intention. Je propose de modifier le protocole de mail actuel pour que les actions habituelles des utilisateurs qui peuvent etre interpretees comme une autorisation a envoyer des mails le soient.
- Si on est d'accord sur la nature de ma proposition, mais que tu penses que cette extension du protocole n'est pas raisonnable, je suis tout a fait pret a en discuter, parce que je suis tres loin d'etre un expert en protocoles reseau.
- Si on est d'accord sur la nature de ma proposition et que tu es d'accord que c'est une extension de protocole qui est faisable en pratique, mais que tu penses que ca penalise trop les utilisateurs et pas assez les spammers, pourquoi pas, c'est un point de vue. Je n'ai pas grand chose d'autre a y repondre qu'un exemple bricole:
Si une machine peut envoyer 10 mails par seconde. Si un individu possede une machine et envoie 100 mails par jour, alors qu'un spammer possede 1000 machines et envoie 100 millions de mails par jour, alors en rajoutant un challenge qui dure une seconde par mail:
* l'utilisateur doit depenser 100 secondes de temps de calcul dans sa journee, ce qui est tres raisonnable, surtout si c'est en plusieurs fois.
* le spammer doit depenser 100 000 secondes, soit 27h, par jour, alors qu'avant cela ne lui coutait que 10 000 secondes, soit 2.7 heures. (Ca reste faisable avec ces chiffres, la penalite n'est que de 10)
Il s'agit de chiffres pris un peu au hasard, pour donner un ordre de grandeur de la penalite pour un utilisateur et un spammer. J'estime au juge qu'une penalite de 5 minutes par jour est raisonnable pour moi car c'est moins que le temps que je depense a filtrer mes spams. Vu mon debit de mails, je sais tres bien que meme si on fixait un challenge a 5 secondes, ca me penaliserait de moins de 5 minutes, et ca penaliserait beaucoup les spammers (d'un facteur 5*le nombre de mails qu'ils peuvent envoyer en une seconde).
Selon mon point de vue, la question principale pour savoir si cette solution est interessante, c'est de calculer s'il existe des valeurs qui penalisent tres peu les utilisateurs qui consomment plus que moi, et qui penalisent beaucoup les spammers. Pour ca il faudrait des chiffres plus fiables.
[^] # Re: Oui et non
Posté par Yusei (Mastodon) . En réponse au journal Hashcash, vers une solution contre le spam ?. Évalué à 1.
Je n'en sais rien, je n'ai fait que suggerer une maniere triviale de resoudre le probleme que tu evoquais. Savoir si les gens qui ont propose hashcash sont des gros nazes, ca ne m'interesse pas franchement...
Ben ecoute si tu as une meilleure solution, n'hesite pas hein...
Et une newsletter n'a bien sur rien a voir avec une mailing list...
Je le rappelle, ma distinction etait entre d'une part les services auxquels on souscrit, qui n'ont pas a effectuer de challenge et d'autre part les services auxquels on ne souscrit pas, ce qui caracterise assez bien les spams, et qui eux doivent effectuer un challenge.
Effectivement, si ce qui te gene c'est que ce procede empeche une entreprise d'envoyer des newsletter a des gens qui n'ont rien demande, je me permet de te rappeler que c'est le but recherche.
Je ne parle pas d'autorisation legale ou d'autorisation technique, je parle de monsieur Dupont qui dit "ah oui, j'aimerais bien recevoir des emails promotionnels de La Redoute", par opposition a monsieur Durand qui lui n'a rien demande.
Non. Ca ressemble a une whitelist.
C'est pour ca que je disais que pour que ce soit efficace, il fallait que les expediteurs s'authentifient, et que je disais que c'etait "un peu lourd"
Il n'y a pas de premier round: soit l'utilisateur s'est inscrit et tu n'as pas de calcul a faire, soit l'utilisateur s'est inscrit et la tu dois faire un calcul.
Le "whitelistage" faisant partie du processus d'inscription a ta mailing-list (une newsletter est une mailing list), tu peux etre sur que tous tes "clients" se sont inscrits et t'ont whiteliste.
Ensuite, qu'une entreprise puisse empecher ses employes de s'inscrire a des mailing lists, c'est une eventualite plutot raisonnable, non ?
Effectivement, si on change le protocole il faut changer les logiciels :)
Il ne s'agit pas de faire un tri entre spam et non-spam, il s'agit de faire un tri entre mail sollicite par le destinataire et mail non sollicite. Seuls les mails non sollicites coutent du temps de calcul a l'expediteur. La separation entre mails sollicites et non sollicites est triviale a faire: tout mail qui provient d'un type qui n'a pas ete whiteliste n'est pas sollicite.
Un reseau en forme d'etoile, meme si c'est techniquement un reseau, ce n'est pas tres interessant. Pour parler de reseau de confiance, il faudrait au moins que tu herites en partie de la confiance des gens en qui tu fais confiance.
Quelle que soit la puissance de calcul a la disposition d'un spammeur, si on divise par un million son debit, on diminue l'interet pour lui de spammer.
Le particulier, a moins d'envoyer des centaines de mails par jour, n'est pas du tout penalise. Les entreprises, elles, ne sont penalisees que si elles envoient des emails de masse a des gens qui n'ont rien demande... mais... mais... c'est du spam ca, non ?
[^] # Re: Oui et non
Posté par Yusei (Mastodon) . En réponse au journal Hashcash, vers une solution contre le spam ?. Évalué à 3.
- un système entièrement à base de whitelists, ou un réseau de confiance
- un système entièrement à base de challenges à effectuer par l'expéditeur
Or, ce que je proposais comme réponse à ta question (et j'aurais aimé que tu le prennes de manière un peu moins hautaine, ce n'était qu'une suggestion), c'était un système à base de challenges ET équipé de whitelists permettant d'éviter aux gens "connus" d'effectuer les challenges.
Gérer des whitelists n'a jamais impliqué que les utilisateurs fassent tout à la main comme tu le supposes. Puisque mettre en place un système à base de challenges implique une extension du protocole ou un nouveau protocole, il est tout à fait envisageable de concevoir un protocole dans lequel une inscription à une mailing-list est conçue comme une autorisation explicite pour cette ML d'envoyer des emails, et que ce soit géré de manière transparente par les serveurs de mails. De la même manière, ajouter un utilisateur à son carnet d'adresses peut être considéré comme une autorisation à envoyer des emails.
Tu n'as pas compris visiblement que ce que je proposais était une réponse à cette objection que tu as déjà faite. Dans cette solution:
- envoyer 10 000 mails à des "clients" qui ne se sont pas inscrit à la mailing list prend 20 000 secondes
- envoyer 10 000 mails à des clients qui se sont inscrits ne prend pas plus de temps qu'actuellement.
Au final, ça ne demande pas plus de participation à l'utilisateur qu'actuellement, ça n'implique pas de réseau de confiance. Reste ton objection sur les "drone army", mais comme tu n'as pas expliqué pourquoi ça invalidait le procédé, je ne sais pas quoi répondre.
[^] # Re: Oui et non
Posté par Yusei (Mastodon) . En réponse au journal Hashcash, vers une solution contre le spam ?. Évalué à 0.
Autrement dit, si j'autorise quelqu'un à m'envoyer des emails, ça ne lui coûte pas de temps de calcul, mais si je ne l'ai pas encore autorisé, ça lui coûte quelques instants. C'est un peu lourd à mettre en place puisqu'il faut authentifier l'expéditeur pour ça, mais si c'est faisable, alors ça semble une solution correcte.
[^] # Re: Oui et non
Posté par Yusei (Mastodon) . En réponse au journal Hashcash, vers une solution contre le spam ?. Évalué à 3.
[^] # Re: Oui et non
Posté par Yusei (Mastodon) . En réponse au journal Hashcash, vers une solution contre le spam ?. Évalué à 4.
Admettons qu'envoyer un e-mail coûte (en temps d'attente) une demie seconde. Un utilisateur moyen envoie combien de mails dans la journée ? Prenons une estimation assez large et admettons qu'il en envoie une centaine. Ça fait un total de 50 secondes d'attente à cause de calculs effectués par sa machine... 50 secondes, c'est moins que le temps que passe mon filtre antispam à filtrer tous mes mails.
Maintenant, prenons un spammer et admettons qu'il envoie 10 000 000 spams par jour, ça fait environ 1400 heures d'attente par jour, si je ne me trompe pas. Pour lui, il y a un besoin de plus de puissance de calcul.
(Tout ça suppose bien sûr qu'une entreprise a la possibilité de se mettre sur une whitelist pour ne pas avoir à payer le coût d'envoi des emails de tous ses employés, mais qu'un spammer n'a pas cette possibilité.)
[^] # Re: Pas si con que ça quand même
Posté par Yusei (Mastodon) . En réponse au journal Comment les banques font croire à la sécurité. Évalué à 4.
[^] # Re: C'est pour eviter les keyloggers
Posté par Yusei (Mastodon) . En réponse au journal Comment les banques font croire à la sécurité. Évalué à 4.
Le one time pad, c'est un système où tu as un "mot de passe" (clé) aussi long que le message à transmettre, et qui change à chaque fois. La clé est utilisée pour masquer le message, et comme elle est aussi longue que le message, il n'y a aucune répétition d'information qui donnerait un point d'appui pour craquer le code.
[^] # Re: Aui hasard ...
Posté par Yusei (Mastodon) . En réponse au journal L'avenir de GNU/Linux .... Évalué à 10.
Alors qu'avec le TCE, tu aurais eu le droit de faire une petition et de la presenter a la comission, qui elle aurait eu le droit d'en faire ce qu'elle veut... mais c'aurait ete mieux.
Toute ressemblance avec une histoire de chasseurs est purement fortuite.
[^] # Re: meme ambiguité en france avec els outils de sécurité suite à la LSI
Posté par Yusei (Mastodon) . En réponse au journal Les auteurs de logiciels de P2P bientôt poursuivis ?. Évalué à 5.
[^] # Re: Sens de la décision
Posté par Yusei (Mastodon) . En réponse au journal Les auteurs de logiciels de P2P bientôt poursuivis ?. Évalué à 6.
# VFolders
Posté par Yusei (Mastodon) . En réponse au journal Les "smart folders" et linux. Évalué à 7.
Et sinon, as-tu regardé du côté de Beagle, qui permet de faire une recherche de type "donne moi tous les jpegs", mais aussi de rechercher dans le contenu des fichiers ? (fonction similaire à un autre truc de Tiger, si j'ai bien suivi)