fmaz fmaz a écrit 494 commentaires

>Donc chaque fois qu'on génère la page, on crée un jeu de 6 identifiant, et on les place
> dans cette table, en rajoutant l'instant où ils sont crées.

Ton truc est très faisable mais. Paf. Là, tu stockes des trucs sur ton serveur. Toute
ma remarque vient du fait que ce n'est pas nécessaire.

A partir du moment où tu stocke des trucs sur ton serveur, il va falloir que tu décides quand
tu les libères. Or comme tout fonctionne en mode déconnecté, tu n'as aucun moyen de
savoir si le client prend juste du temps pour écrire son truc ou s'il est définitivement parti.
Tu vas donc mettre un limite de temps au bout de laquelle, si tu n'as pas de nouvelle
connection du client, tu zapes toutes les variables correspondantes.

Ce que je propose permet de ne rien stocker sur le serveur: pas de base de donnée,
pas de variables de session. Il y a aussi une limite de temps mais on ne peut pas la
supprimer. De plus, la gestion des variables de session ou d'une table SQL pour stocker
des trucs, ça a un coût qui augmente avec le nombre de connections.
Mon truc a un coût faible qui est constant.

> On a donc pas besoin de session, et c'est enregistré dans la BDD, et non pas en mémoire.

Parce que tu imagines que la BDD, elle n'a pas de cache mémoire et qu'elle écrit toujours
tout sur le disque ?

Au niveau calcul, je pense qu'un bête xor avec un hash de la date+un texte fixé
suffit. Ce n'est pas ça qui va plomber le serveur.

Par ailleurs, ton truc ne marche pas.

Sans variable de sessions (ou truc du genre où on stocke des infos sur le serveur),
comment veux-tu que le serveur se rende compte qu'une clef a déjà été utilisée ?

Il peut juste faire un teste d'intégrité pour voir si le certificat est valide mais pas plus.

De plus, les variables de sessions sont limitées dans le temps et c'est nécessaire
sans quoi le serveur n'aurai aucun moyen de savoir quand libérer de la mémoire.

Imagine que tu aies des champs:
Nom, Prénom, Adresse

Tu te fais spammer violemment. Première technique pour repérer les
méchant robots, tu ajoutes des champs aléatoires que tu caches par
une méthode de ton choix pour que les utilisateurs ne les remplissent
jamais. Tu as maintenant:
Nom, Prénom, inczue, Adresse, sdkjfhz, icuznze

Un robot basic ne va pas se rendre compte que les deux derniers liens
ne sont pas visible et ne doivent donc pas être remplis. Ils vont mettre
des trucs dedans et tu vas les avoir.

Maintenant, si un spammer humain passe par là, il va se rendre compte
du problème et il va régler le robot pour qu'il ne remplisse que les champs
Nom, Prénom et Adresse.

La technique avec variable de session consiste à envoyer
- czieuf, zleriounc, eziud, sermo, cszezosiu

en stockant sur le serveur la correspondance
Nom=zleriounc; Prénom= sermo; Adresse= cszezosiu

La seule façon pour savoir qui est qui force à calculer quels sont les champs
visibles et quels sont les champs invisibles.

Le problème, c'est qu'il faut utiliser des variables de session et certains peuvent
ne pas vouloir faire ça. Or, on peut faire la même chose SANS variable de
session.

On envoie le formulaire avec les champs
czieuf, zleriounc, eziud, sermo, cszezosiu

et en plus, on ajoute une variable cachée toto qui contient
la traduction des noms des champs.
Sauf que comme on est pas con, on chiffre toto avec une clef
secrète pour que le bot ne puisse pas accéder à la traduction

Le robot ne sait pas déchiffrer toto et il ne sait pas non plus modifier
toto pour choisir lui même les bons champs.


Il faut cependant faire quand même attention à une chose, si le
spammer humain passe par là, il peut très bien noter le nom
des champs et la variable toto et décider de toujours utiliser ces
variables. Pour éviter cela, il suffit de changer très souvent les
clefs de chiffrement (toutes les n minutes). Pour éviter le problème
du gars qui charge la page 10 secondes avant la révocation de la
clef, et qu'on va envoyer chier on utilise 2 clefs qu'on entrelace.
Ainsi, on est assuré que la clef utilisée dans une page fonctionnera
entre n et 2n minutes.

Ce que tu proposes est surtout inutile.

Si tu fournis le code javascript qui "fait ce qu'il faut", tu donnes aussi au robot
la possibilité d'utiliser ce script pour "faire ce qu'il faut" aussi.

On a absolument pas besoin de variable de session pour faire ce que tu racontes.

On génère des noms aléatoires de champs et on ajoute une variable cachée
chiffrée comportant la correspondance. Le robot ne peut pas déchiffrer la variable
et donc savoir quels sont les champs à renseigner. L'algo de chiffrement n'a même
pas à être super robuste car le robot ne peut pas se permettre de prendre 10 pour
faire son poste. Si cette variable est modifiée, le serveur s'en rend compte et rejette
la requête. Sinon, le serveur n'a plus qu'a récupérer la correspondance pour faire
la traduction.

Ce que tu dis est évident mais l'ancienne vision continue à être pertinente.

Si on interdit qu'un fichier utilisateur soit executé (/home, /tmp... en noexec),
une macro malveillante a beaucoup moins de possibilités de nuisance car
elle ne peut agir que quand on l'exécute. Si tous les virus, malware et autres
spyware avaient les mêmes restrictions, on est plus obligé de refaire des
installations parce qu'il y a des bouts de trucs dans tous les fichiers systèmes,
une machine fraîchement installée ne se retrouverai pas complètement
vérolée avant même qu'on ait pu installer les mises à jour de sécurité....

Il est évident qu'on peut et qu'on devrait mieux faire mais c'est déjà beaucoup.

Le problème, ce n'est pas l'opposition matériel/immatériel.

Le problème, c'est le passage au niveau meta.

Si A possède des valeurs, il peut très bien les transmettre à B, ça
ne me pose pas de problèmes. En revanche, si A possède quelque
chose qui crée des valeurs, c'est là que la transmission à B devient
génante.

Avoir écrit un livre n'est pas une valeur en soit. En revanche, cela
permet de le vendre et de récupérer des drois dessus.

Qu'un être vivant puisse vivre de son art et donc ait un droit d'auteur,
c'est normal. Que le droit d'auteur se transmette ne l'est pas.

Un paquet d'action ne relève pas de la même chose. On peut
très bien simuler la transmission d'action en disant:
- A vend ses actions et gagne Z ;
- A lègue Z à B (moins les droits de succession) ;
- B achète les actions.

Chouette, c'est parti !

Et ben moi, j'ai un algo encore plus mieux bien.

Comme la suite de Fibonacci est linéaire, on sait la résoudre
analytiquement.

a=(1+sqrt(5))/2.;
b=(1-sqrt(5))/2.;
l=(1+.sqrt(5))/(2*sqrt(5));

fib(n)=l*a^n+(1-l)*b^n;

Paf.

Alors, après, tu fais tes multiplications et ton exponentiation comme tu veux.



Comment ça, ça n'a plus rien a voir avec la problématique initiale ?


P.S. Je suis nul en calcul donc en plus le truc que j'ai écrit doit être faux.

ARG !!!!!


pourquoi tant de haine^Wtable de hashage.

fibo, la bonne façon de le coder, c'est de ne pas calculer
fib(n) mais de calculer fibAux n= ( fib (n-1), fib n )
parce qu'à l'étape d'après, on a directement
fibAux (n+1) = (fib n, fib (n-1)+fib n).

En chameau, ça donne un truc du genre:

let rec fibAux n =
if n=1 then (1,1)
else
let (a,b)=fibAux (n-1) in (b,a+b);;

let fib n=
if n=0 then 1
else
let (a,b)=fibAux n in b;;

Tout simplement parce que comme le nouveau système est plus
contraignant, personne ne l'utiliserait.

Depuis quand a-t-on besoin d'informations de mise en page pour un travail de traduction ?

Dans un certain nombre de cas, un bête txt est tout aussi efficace, plus portable et moins lourd.

Non.

Exemple à la con, on ne peut pas faire du "vrai" multi-colonne en CSS.

La licence BSD peut paraître trop libre à certains. C'est peut-être vrai. Je ne sais pas.

En revanche, ce que je sais, c'est que sans cette licence BSD, un bon nombre de
personne utiliserait encore telnet parce que Cisco, Sun, Microsoft et consort n'auraient
pas forcément voulu payer pour avoir une implémentation de SSH. Et si tout le monde
n'a pas de serveur SSH qui tourne, alors l'intérêt de payer pour un truc qu'on est même
pas sûr de pouvoir utiliser est encore moins clair.

La licence BSD a joué (et joue encore) un rôle fondamental dans la propagation
d'idée nouvelles.

Alors bon, ne tirez pas à boulet rouge sur cette licence.

Je suis d'accord mais parfois, c'est plutôt cool de pouvoir regarder dans les
fichiers de config.

Genre, quand on doit faire un TP de oueb+PHP et que, le jour du TP, on
réalise qu'on ne sait pas où les étudiants doivent mettre leurs fichiers
parce que l'admi a eu la double bonne idée de changer le répertoire
usuel (public_html) et de rentrer chez lui à 14h.

Comment ça, c'est du vécu?

Je pense surtout que ça dépend des développeurs.

Si j'ai bien tout compris, xgl était déjà sur les rails quand Novell a fait son fork en embauchant certains mais pas tous les anciens développeurs de xgl. Du coup, les autres l'on mal pris et il me paraît clair qu'ils vont moins (voir pas du tout) s'impliquer dans le projet xgl façon Novell. C'est d'autant plus le cas que certains choix technologiques seraient contestés.

D'un autre côté, aiglx était en développement depuis plus longtemps et a progressé avec la communauté xorg. Il me paraît donc évident qu'ils ont énervé beaucoup moins de monde.

Je ne suis absolument pas qualifié pour donner un avis technologique sur les choses. Il est évident que les distributions auront leur mot à dire. Mais si aiglx, parce qu'il est mieux conçu et qu'il a moins énervé attire plus de développeurs que xgl, c'est certain que c'est lui qui restera.

Pour ce qui est du théorème des quatre couleurs, quelques précisions.

C'est le théorème qui dit que si les tous les pays étaient d'un seul tenant (pas comme les USA avec l'alaska), alors on pourrait toujours colorier une carte avec seulement 4 couleurs.

D'une part, le résultat de Gonthier et Werner est de 2004 et pas de 2002.

De plus, c'est une réécriture dans le système COQ de la démonstration de Robertson, Sanders, Seymour et Thomas de 1996. La preuve des 4 fous est une simplification de la preuve de Appel et Haken. Elle part du principe que si il existe un graphe planaire seulement 5 coloriable, alors il est existe un le plus petit possible. Avec des arguments bien forts, ils se ramènent à un nombre finis de cas. Le problème est que le nombre fini de cas reste trop gros pour être traité à la main. La fin de la démonstration utilise donc un ordinateur pour traiter les cas de base. Le problème est que les ordinateurs, c'est buggé. Donc la preuve...

L'intérêt du travail de Gonthier et Werner est que COQ est un système de démonstration assistée. En gros, avec COQ, on est sûr de ne pas oublier de cas tordu. Mais COQ est aussi un programme. Il peut donc être lui aussi buggé. C'est vrai sauf que COQ permet de produire un certificat dont il est très simple de vérifier qu'il est juste (ou pas). Cette partie du programme a même pu être prouvée à la main. On peut donc très raisonnablement penser que la preuve est juste.

Merci beaucoup.

Mais où est donc la documentation?

Merde !

La technique usuelle est :
- faire un rapport de recherche avec l'article qu'on souhaite soumettre ;
- faire 2-3 modifications cosmétiques ;
- soumettre.

L'article soumis est un produit dérivé du rapport de recherche et l'éditeur n'a des droits que sur la version qu'on lui a soumise. Bien évidemment, si dans le processus de relecture, on corrige une erreur, on ne peut pas corriger l'erreur dans le rapport de recherche mais au moins, on garde les droits sur les figures et le contenu reste libre.

J'utilise un mac depuis quelques semaines maintenant. Je m'y suis bien habitué mais je trouve que ces choix d'IHM sont discutables.

- Je n'ai pas envie de toujours utiliser la souris. Ca prend du temps, j'aime pas.
- J'utilise donc "pomme"+tab pour passer d'une application à l'autre. C'est très efficace.
- Si une application a 5 fenêtres (ce qui arrive très vite avec TeXshop par exemple), passer d'une fenêtre à l'autre nécessite d'utiliser la souris et ça m'énerve. Dans ces cas là, j'utilise exposé pour voir toutes les fenêtres de mon application mais dans ces cas là, je regrette mon linux.

Ceci dit, je pense que coupler exposé avec un truc du genre alt+tab pourrait être très bien.

Au lieu d'avoir les vignettes correspondant à la fenêtre ou à l'application en ligne, on pourrait très bien imaginer passer en dans une vue type exposé avec un rectangle plus clair entourant la fenêtre sélectionnée.

Dans le cas où on veut cycler entre les fenêtre d'une même application, ça serait chouette.

Le problème fondamental, c'est que c'est un sujet TRÈS technique auquel
les députés ne comprennent rien (je sais c'est un peu rapide).
Certains essayent de leur expliquer qu'ils vont faire une connerie et qu'il
ne faut pas mettre sa main dans le feu, ça brule. S'ils ne veulent pas
écouter, ils vont se brûler et dans 5-10 ans, ils vont abroger les lois.

Entre temps, on risque de passer par une période difficile mais comme
monsieur tout le monde ne change pas sa télé/magnétoscope/chaîne HIFI
tout les jours, les industriels vont essayer de faire des trucs pseudo
compatible avec les anciens matériels. Certains en profiterons pour casser
la plupart des DRM correspondant et au final, les gens continueront à
télécharger et à pirater. Les logiciels libres continuerons à être utilisés
chez les particuliers car ils pourront quand même télécharger une libDRM
illégale mais qui va bien. Les grosses structures qui opèrent une migration
vont continuer par inertie et parce que ça leur fait quand même gagner des
sous et voilà. Tant pis si on ne peut plus utiliser les lecteurs de CD pour
lire des "presque CD" audio.

L'argument force brute est ridicule.

Tu n'as visiblement rien compris à l'exponentielle.

La différence entre une clef RSA de 1024 bits et une clef de 4096, c'est l'éternité. La seule chance d'arriver à casser une clef de 4096, c'est qu'un matheux ponde un théorème qui abaisse la complexité du problème. Pour l'instant, une bonne part de la cryptographie est basée sur des problèmes dont on se dit que ça doit être difficile car les gens essayent depuis longtemps et n'y arrivent pas. Le jour où un gars pondra un système et qu'il aura un certificat théorique du genre: la complexité minimale de ce problème est sur-exponentielle, tu l'aura définitivement dans l'os.

Ce problème est exactement le même problème que la spécification d'une API.

Aussi bien pensée soit-elle, une API est toujours amenée à évoluer.

Dans ton cas, imagine que quelqu'un chez kde décide que XML, c'est la voie et que tous les fichiers de configuration doivent migrer vers du XML. Comment tu gères la transition ? Faut-il garder l'ancien analyseur syntaxique pour supporter les fichiers de configuration de kde 0.00001 pre alpha ?

On peut essayer de faire des scripts qui aident mais on ne pourra jamais avoir quelque chose de parfait.

C'est évident mais que monsieur Bill fasse le racourcis "machine spécifique" pour
base de donnée spécifique ne me semble pas choquant.

Il suffit que quelqu'un gus ait décidé de coder les sommes déclarées sur des entiers 32 bits et paf, monsieur Bill fait le tour du cadran.

Merci pour ta réponse. À force de recherches, j'en étais arrivé à cette conclusion.
Malheureusement pour moi, resize2fs a chié dans la colle et m'a complètement bousillé ma partition. Heureusement, elle ne contenait que le système que j'ai pu réinstaller.