Moby-Dik a écrit 2937 commentaires

Si bof : car avec 128 voire 256 bits de clé le cassage brut est hors de portée (certains spéculeront même que la quantité d'énergie présente dans l'univers n'est pas assez grande... m'enfin ;-)). Par contre si le 128 bits est réduit à un équivalent de 90 ou 80 bits par cryptanalyse, le cassage devient envisageable dans un délai "raisonnable" (moins d'une génération humaine peut-être). Donc dire que ça suit la loi de Moore est faux ; cela suppose que les chiffres sont inattaquables autrement que par force brute, mais si c'est le cas ils sont totalement inattaquables avec les moyens disponibles à l'humanité.

Evidemment dans le cas du DES, c'est 56 bits, donc plus accessible. Mais tu oublies que la NSA a modifié les S-boxes du DES lors de sa conception, car elle savait justement que les S-boxes proposées par les cryptographes du civil étaient vulnérables à un certain type de cryptanalyse connue uniquement (à l'époque) de la NSA.

Du reste si AES propose des tailles de clé supérieures à 128 bits, c'est bien parce qu'on craint que les clés de 128 bits soient un jour crackables ; or on sait aussi qu'elles ne peuvent pas l'être pas force brute....

la cryptographie à clé secrète ça suit la loi de Moore

Bof : http://www.counterpane.com/crypto-gram-0209.html#1(...)

Et ca me rassure quant a la possibilite de craquer mon numero de CB

Heu, c'est quoi "cracker un numéro de CB" ??
Je te signale qu'il est en clair sur toutes les facturettes, lisible par les commerçants quand tu payes avec, et en plus la génération du numéro est largement foireuse : à la Poste par exemple, sur les 16 chiffres, les 4 premiers forment le préfixe de la banque (fixé), les 10 suivants le numéro de compte (guère secret), donc seuls les 2 derniers constituent une donnée plus ou moins variable (en fait calculable, cf. lien suivant).

Quelques tests sur les numéros de CB à http://www.parodie.com/monetique/verifcle.htm(...)

Depuis quelques temps il y a un numéro aussi au dos de la carte, qui sert à réduire les risques (notamment de récupération du numéro à vue).

Qu'adviendrait il s'il existait une civilisation en avance de 50 ans sur nous? c'est tout simplement inimaginable!

Ils coloniseraient nos quartiers, détruiraient notre économie, notre société, nos valeurs culturelles en se prévalant de la supériorité de leur développement, et enverraient des drones ultra-puissants contre les "terroristes" qui oseraient défier leur impérialisme.

Pour qu'ils soient amicaux, il faudrait qu'ils aient au moins quelques siècles d'avance, à vue de nez ;-(

A part les phenomenes atmoiques, il n'existe pas d'evenements dans le monde macroscopiques qui ainet des probabilites de 10^-20.

Heu, et la combinatoire alors ? Je peux prendre deux événements indépendants de probabilité chacun 10^-11, et m'intéresser à l'événement résultant de l'apparition simultanée de ces deux événements. Sa probabilité est bien inférieure à 10^-20. Ou alors ça veut dire que l'indépendance probabiliste n'existe pas (ce que je veux bien admettre ;-)).

De plus, l'apparition de la vie (telle qu'on la définit en tout cas) est liée à la conjonction d'une multitude de facteurs, donc n'est certainement pas réductible à un évènement "simple".

??

C'est vrai que ça a son petit côté pionnier / repousser la "frontière" (au sens anglo-saxon), qui doit sacrément titiller la conscience historique américaine. Le tout démultiplié par la culture populaire construite (par Hollywood notamment) sur le motif de la rencontre avec des civilisations inconnues, qui joue probablement sur le désir de "mesurer" les Etats-Unis à quelque chose de nouveau et formidable (cf. Independance Day).

Ici :

http://www.opengroup.org/public/member/q402/fees.htm(...)

En fait 700 Euros c'était jusque fin août, maintenant c'est 800 ;-)

Les prix proposés pour l'hôtel sont mignons aussi. A ce prix-là, j'espère que Sharon Stone vient te faire une gâterie dans la baignoire format XXL en marbre de Carrare !

Je te donnes des pistes: - snapshot pas instantané - cache lvm, cache OS, cache hardware - locks pas fait de façon atomique (cf plus haut) - y a des UNDO et REDO chez mysql maintenant ? - ... - snapshot = temps de création du logical volume à l'intérieur du volume group = une seconde - LVM est intégré au noyau et fait un flush du filesystem (y compris le journal ext3) juste avant la création du logical volume => aucun problème de cohérence - cache hardware : rien à voir, car LVM travaille au niveau noyau et opère en mode copy-on-write, c'est-à-dire que tout bloc modifié après la création du snapshot est recopié dans sa version originale avant d'être écrit sur le disque. D'autre part, je te signale que dans le cas d'un SGBD il vaut mieux utiliser du hard qui obéit aux requêtes de synchronisation, donc probablement du SCSI. Sinon ton système n'est plus ACID. - UNDO et REDO : je ne vois pas le rapport, on parle de backups là. Si tu veux restaurer un backup sous MySQL, c'est tout simple, tu arrêtes le serveur, tu remets les fichiers à leur place et hop. c'est quand même d'avoir après la restauration des données coherentes Cohérentes vis-à-vis de quoi. Je te répondrais bien de RTFM, mais répétons encore un coup : - FLUSH TABLES WITH READ LOCK assure la cohérence des données au niveau SGBD. Cela garantit que la représentation des tables sur le filesystem est stable et cohérente (y compris au sens ACID du terme si tu utilises InnoDB (lis la news...)). - la prise du snapshot sous LVM assure de plus la cohérence des données au niveau filesystem. En effet LVM est intégré au noyau et a donc une connaissance totale des blocs flushés ou non. Il installe donc une barrière à un certain moment, flushe tout ce qui n'a pas été flushé et bloque toute modif arrivante, crée le logical volume, puis redonne la main. - par la suite, la permanence du snapshot est assurée par un mécanisme de copy-on-write, toujours grâce au fait que LVM est intégré directement au noyau. - le backup est fait à partir du snapshot, qui est stable et permanent (cf. ci-dessus). Une fois le backup fini, tu détruis le snapshot histoire de ne pas subir la perte (très minime) de performances. Donc la cohérence est garantie (sauf bug bien sûr ;-)) sur toute la chaîne. pourquoi oracle, postgresql ou mysql n'abordent pas (toujours) les snapshots (lvm, netapp...) dans leur doc, et developpe tous des outils plus ou moins compliqués ? Parce que les snapshots ne sont pas une fonctionnalité de base des filesystems (je ne pense pas qu'il y en ait sous Windows, sous linux les distribs n'utilisent pas LVM par défaut, etc.). Et aussi parce qu'une des caractéristiques de beaucoup de bases de données (surtout commerciales) est d'intégrer le plus d'outils pour créer de la valeur ajoutée (tm ;-)) ou faire plaisir à l'utilisateur (tout est out-of-the-box).

C'est à voir la liste des invités ci-dessus, le ton de la news, et les prix d'entrée (700 Euros pour les quatre jours) que l'on comprend la différence de philosophie entre partisans de l'appellation "open source" et ceux de "logiciel libre". A part ça, il aurait été sympa de rappeller qu'après l'avoir initiée, Perens a renié l'Open Source Initiative...

Je te conseille de consulter le nombre de bugs déclarés pour la version stable de presque n'importe quel produit majeur (i.e. beaucoup de lignes de code), et tu verras que Mandrake n'est pas un cas particulier.

Ca fait des années que les ondelettes sont présentées comme la révolution à venir (qui explose les systèmes à base de FFT & DCT), mais visiblement il y a pas mal de problèmes de mise au point. Quelqu'un aurait plus de précisions à apporter ?

C'est la faute des médias (télés, journaux) qui ont commencé à dire "sur Internet" et l'usage s'est répandu. Oui oui bien sûr, d'ailleurs avant personne ne parlait d'Internet alors ? T'es vraiment sûr ? Mais c'est exactement le sens, le "bug" en anglais c'est de la vermine genre cafard Où l'on voit donc les ravages de la traduction littérale.

STP, relis ce que j'ai dit. J'ai dit que tu verrouillais les tables pendant le *snapshot*. Créer un snapshot sous LVM dure une seconde (le snapshot est initié sur un logical volume séparé). Donc le verrouillage ne dure qu'une seconde. Le backup a lieu ensuite sur le snapshot et non sur le filesystem "live". (note : LVM est intégré au noyau Linux, il faut juste l'activer à la compil)

des instructions pour faire de la décompression rapide de truc encodés avec des ondelettes, plutôt que des truc sinusoïdaux ? Je ne crois pas qu'il y ait des instructions spécialisées dans les "trucs sinusoïdaux" (DCT...), si ? De toute façon tout ça c'est des multiply/accumulate que tu parallélises le plus possible (SIMD).

Joli troll, avec même le pseudo débile créé simplement pour l'occasion. Juste, c'est trop brouillon, il aurait fallu affiner.

Après il y a les blagues du type 32 connexions max par default, faire un vaccum après avoir recrée les indexes, ou les blobs pas sauvegardés enfin bon... Jolies blagues en effet. Enfin, c'est bien, tu finis par contredire tes propres affirmations sur l'utilisabilité des versions < 7.0, et à me donner raison sur ce point ;-))

C'est à dire ? (je ne suis pas un pro de MySQL) En fait la version 3.23 (qui existe depuis un bout de temps déjà) a introduit la possibilité de faire des SELECT en parallèle avec des INSERT, ce qui résoud partiellement un gros problème de MySQL : le verrouillage se fait au niveau table, donc une grosse requête en écriture peut bloquer une requête en lecture sur des lignes différentes, et vice-versa.

Le vacuum est un mauvais exemple. Avec un design correct avec DES bases (enormes style http//www.geocrawler.org/ qui tournait bien avant la version 7) ce n'est pas un vrai problème. Par ailleurs, vois-tu, c'etait le moment de faire les backups. Ah parce que pour toi ce n'est pas un problème d'arrêter une base de données le temps de l'optimiser ? C'est qui le "rigolo incompétent" ?

Bref, Pour faire un vrai backup ajourd'hui sous mysql faut arreter la base. Non, faux. Tu utilises une couche filesystem permettant les snapshots (type LVM ou Veritas), et il te suffit d'exécuter FLUSH TABLES WITH READ LOCK juste avant le snapshot. Ensuite, tu UNLOCK TABLES et c'est fini. Et tu es bon pour backuper tranquille le snapshot pendant que la base continue à tourner.

www.linuxworld.com/linuxworld/lw-1999-07

On y voit en effet Postgres nominé en 99. Gnome est aussi nominé dans sa catégorie. Gnome était peut-être mûr en 99, tu crois ? On se fiche un peu de savoir si Postgres a gagné des prix (et quand pour le prix en question, qui récompense les "avancées du mouvement open source", on nomine Oracle, ça fait un peu ridicule...).

developer.postgresql.org/docs/postgres/h
developer.postgresql.org/cvsweb.cgi/pgsq

Super, un historique de Postgres. Les développeurs de Postgres utilisent Postgres ? Qu'est-ce que ça me prouve ? Tiens, pour info, ça fait des années que les développeurs de MySQL utilisent MySQL. Dingue non ?

Enfin si tu étais un bon défenseur, et donc un bon connaisseur de Postgres, tu saurais que pour avoir une utilisation efficace en lançant périodiquement un vacuum() sur la base, tu étais obligé de débrancher la base pendant le vacuum avant les version 7.x. Et le dit vacuum peut prendre beaucoup beaucoup de temps. C'est un problème très connu.

Côté stabilité, les versions antérieures à la 7.0 étaient de plus réputées (y compris encore une fois du côté des pro-postgres) contenir beaucoup de bugs, problèmes de stabilité et autres crashes. Ce qui est problématique pour une utilisation "en production", surtout si la dite production ne suppporte pas d'être arrêtée, vacuumisée puis relancée toutes les nuits. Le fait que Linux Chose Magazine file un prix à Postgres n'y change rien (mais le singe aime la voiture rouge qui gagne des prix).

Elle était justement très peu utilisée à cause de rigolo comme toi, completement incompetent sur le sujet et qui se permettent de l'ouvrir.

Ah ok ! :-))

www.pgsql.com/user_gallery/stats.php

J'y peux rien mais ça me renvoie ça :

Warning: pg_exec() query failed: ERROR: parser: parse error at or near "," in /usr/local/www/pgsql.com/www/user_gallery/stats.php on line 16

Warning: pg_numrows(): supplied argument is not a valid PostgreSQL result resource in /usr/local/www/pgsql.com/www/user_gallery/stats.php on line 17

Warning: pg_exec() query failed: ERROR: Function 'count()' does not exist Unable to identify a function that satisfies the given argument types You may need to add explicit typecasts in /usr/local/www/pgsql.com/www/user_gallery/stats.php on line 20

Warning: pg_numrows(): supplied argument is not a valid PostgreSQL result resource in /usr/local/www/pgsql.com/www/user_gallery/stats.php on line 21

Il y a des entreprises de Redmond qui se font descendre pour moins que ça ;-)) Mais ça doit être parce que je suis un rigolo incompétent (sic).

Argument foireux puisque le système pourrait aussi bien s'appeler GNU (tout court) pour la même raison ;-)

Argument foireux puisque le système pourrait tout aussi bien s'appeler GNU tout court pour la même raison ;-)

Leur contribution n'est pas très importante, elle est essentielle. Linux et les autres projets d'Unix libres ou bénévoles (que ce soient les joujous type Minix ou les systèmes sérieux comme FreeBSD) n'auraient jamais pu exister sans les outils GNU. On ne fait pas de système d'exploitation moderne sans compilateur, débuggeur, bibliothèque standard....

Apache à côté, c'est totalement optionnel et accessoire.

En l'occurrence, (corrigez-moi si je me trompe) Cygwin est en fait une dll qui fournit l'ensemble des appels nécessaires aux applications compilées pour cygwin.

Oui. Plus exactement, ça fournit une émulation de la plupart des appels Posix et Unix courants afin de faciliter le portage d'applications Unix. Ce qui donne effectivement une DLL d'"émulation" d'"APIs Unix". D'ailleurs, c'est pour cela que l'utilisation de Cygwin (celle de Windows aussi diront les trolls du soir ;-)) est déconseillée si on est exigeant en performances, car l'ajout d'un niveau d'indirection ainsi que les grandes différences de conception entre les deux familles de noyaux (Win <-> Unix) font que l'émulation est relativement coûteuse....

PostgreSQL qui possède toujours une très longue avance sur MySQL: des années d'experience et de production.

C'est d'autant plus idiot comme affirmation qu'avant la version 7, Postgres était rigoureusement inutilisé en production à cause de problèmes chroniques de bugs et de stabilité.

Malheureusement cela prend du temps: la doc de MySQL melangeant allègrement ce que fait/fera la stable/beta/alpha.

??? Absolument n'importe quoi. Je te conseille de relire calmement la doc en question au lieu de troller comme un malade. D'ailleurs comme la news parle spécifiquement du type de tables innodb, tu auras aussi vite fait de consulter la doc innodb, qui est très claire.

Des responsables y ont fait leur boulot, c'est a dire prendre des responsabilités.

Ah ouais, c'est les forces vives des marmottes qui gagnent dans le papier alu, quoi :-)))