Olivier Jeannet a écrit 1400 commentaires

Je cherche un serveur SMTP capable de faire de l'ODMR (rfc2645).

Pourrais-tu nous expliquer (même sommairement) ce que c'est que ce truc et ce à quoi ça sert STP ?

J'suis bien d'accord avec toi.. Et tiens, voilà qui devrait faire ton bonheur : [URL donkey] conjointement avec : [URL mldonkey]

J'entends souvent parler de mldonkey ou edonkey mais je ne pratique pas (encore ?) le P2P. Ca marche vraiment ces trucs, ou bien c'est lent et ça bouffe un max la bande passante ? (je n'y connais rien...)

Y'a également XMAME qui est absolument fabuleux !

Ca a l'air bien sympa, mais ça a l'air super dur de trouver des ROMs sur le Net. Avec Google, on trouve un certain nombre de liens mais la majorité des liens est morte, et les quelques sites restants sont un peu bizarres, il faut s'enregistrer et même après ça, le fichier n'arrive pas.

J'ai cru comprendre que Nintendo et compagnie faisaient la chasse aux sites qui hébergaient des ROM, pour préserver leur "propriété intellectuelle". Mais j'ai du mal à comprendre ce qu'ils protègent étant donné que ces jeux ne sont plus vendus depuis longtemps.

Si quelqu'un a des indications à donner pour trouver quelques ROMs (je chercher Exerion et Gyrus), je suis preneur. J'ai du mal à me sentir "pirate" en jouant avec un jeu qui a une bonne quinzaine d'années et qui n'est plus disponible...

concernant ton exemple le mp3 est bien breveté, mais la boite qui gere ca laisse l'utilisation gratuite (contrairement au mp3pro).

un autre exemple bien connu est le format d'image gif

Mais ceci n'est vrai qu'aux Etats-Unis !

Pour une majorité de pays et de gens, le MP3 n'est pas breveté (ni brevetable), de même que le GIF.

Déjà que les USA oublient complètement que les lois ailleurs ne sont pas comme chez eux (ils sont tellement tournés vers eux-mêmes), on ne va pas non plus faire pareil.

Question : si flash est un format breveté, comme le mp3, il est risqué de diffuser un programme qui permet d'en générer, sans avoir obtenu une licence de Macromedia. Non ?

NON !
On ne peut pas breveter un format, en tous cas pas ailleurs qu'aux USA et au Japon, et encore je me demande.

Quant au MP3, il existe plein de programmes y compris libres (GPL) qui permettent d'en créer ou d'en jouer. Même si le format était breveté ça n'a pas l'ai de gêner...

presque ttes les applications mentionnées sont soit militaire, soit décryptage. c'est un poil révoltant !

Je ne vois pas pourquoi. On n'est pas dans un monde de gentils... Et le vieux diction latin est toujours d'actualité : "si vis pacem, para bellum" (si tu veux la paix, prépare la guerre". En 1940, les anglais étaient bien contents de savoir déchiffrer les messages allemands codés avec Enigma.

Mis à part mon avis personnel, qu'on le veuille ou non le militaire est à l'origine de beaucoup de progrès techniques, ne serait-ce qu'à cause des budgets disponibles.

C'est qu'il en faut de la puissance, y a 8 Go (!) d'informations à la seconde qui vont sortir de cette machine, après traitement il n'y en aura que (que !) 100 Mo/s qui vont devoir être traités, je vous laisse imaginer...

Une collision durant un temps infime, ce flux de données énorme ne dure pas longtemps, non ? Ce n'est pas 100 Mo/s pendant des minutes quand même ?

> WSIS - SMSI Sommet Mondial sur la Société de l’Information

Je suis hors sujet à fond, mais je me suis rendu compte en naviguant sous Dillo que dans le titre l'apostrophe n'est pas une apostrophe normale, mais un de ces caractères à la c*n qu'utilise Word à la place de l'apostrophe, je ne fais fichtrement pas pourquoi ! Il s'agit du caractère 0x92 (dec 146), un caractère non imprimable (!), au lieu du bon vieux 0x27 (dec 39).

Dans le même genre, il y a les "..." qui sont parfois générés comme un autre caractère non imprimable, on s'en rend compte sur certains sites. Sous Mozilla on ne s'en rend pas compte car il gère correctement ces caractères spéciaux.

Vous avez remarqué ce genre de substitution aussi ?

<i>> (la traduction c'est un domaine de pro) Tu parles des outils pour la realiser ou du fait de traduire ? Quoiqu'il en soit, dans les deux cas, tu as tort. [...] Pour ce qui est de l'activite de traduire en elle-meme, a partir du moment ou tu comprends a quoi sert le logiciel et ou tu sais ecrire une langue correctement et comprendre une autre, tu es pret. A mon avis il a plutôt raison. Il ne s'agit pas d'être un professionnel qui ne fait que de la traduction, mais les personnes qui maîtrisent bien 2 langues ne sont pas si fréquentes, et les traductions informatiques laissent parfois à désirer. La cohérence de la traduction est importante. L'auteur ne semble pas avoir un niveau très élevé en français (ce n'est pas une critique hein !), il est préférable si on est un peu perfectionniste de faire appel à quelqu'un qui maîtrise mieux cette partie-là. Pour bien maîtriser une langue étrangère et la traduction, il faut d'abord bien maîtriser sa langue maternelle. (même les sous-titres au cinéma, je vois - rarement - des petites erreurs, pourtant je suppose qu'ils ne font que ça)

Depuis le temps que je me dis qu'il faudrait que je gère un peu sérieusement mon compte, je vais essayer ton programme, en espérant qu'il compile parce que je suis sous KDE 3.0 et non 3.1. Ca me donnera l'occasion de m'y mettre.

Je suis aussi partant pour t'aider à peaufiner le côté correction de la langue, car je suis relativement bon en français et en anglais. Je viens de parcourir très rapidement l'arborescence des sources et j'ai vu que tu as prévu l'utilisation de gettext, mais je n'ai pas vu de fichier de traduction. Si tu me files un fichier .po je suis tout disposé à le traduire. Il faut que je me replonge dans le fonctionnement de gettext d'ailleurs !

Pour tout les appels de fonction de librarie partagée, le relatif ne peut pas marcher.

Oui, c'est un cas où on est obligé d'avoir des adresses absolues. Mais à l'intérieur de ton programme, ou de ta bibliothèque de fonctions, tu peux n'avoir que du relatif.

Encore que, sous Amiga on récupérait une adresse de début de bibliothèque (avec OpenLibrary() ), et ensuite on appelait une des fonctions de la bibliothèque en utilisant un offset relatif si je me souviens bien (en asm : "jsr OpenWindow(a6)", a6 étant le registre d'adresse pris par convention pour les appels de biblio), la bibliothèque comprenant en son début une table de fonction . Que les ex-amigaïstes me confirment la chose...

Tout ceci pour dire que passer en 64 bits ne devrait avoir qu'une influence tout à fait réduite sur l'occupation mémoire ou disque, en particulier aucun risque de doublement de taille.

Si ton programme n'utilise que du relative 32 bits sur un os 64 bits (par exemple) alors tu ne peux pas utiliser de librairie (comme expliqué plus haut).

Je ne vois pas le rapport entre le fait qu'un OS soit 64 bits, qu'on utilise des adressages relatifs en 16 ou 32 bits, et qu'on ne puisse pas utiliser de librairie. A l'heure actuelle, la librairie C (tu parles bien de ça je suppose) est en 32 bits sous Linux x86, mais ça n'empêche pas d'avoir des programmes qui ne contiendraient que des offset relatifs sur 16 bits. Sur Amiga tu pouvais bien avoir des programmes qui n'utilisaient que des sauts relatifs, alors que l'OS était 32 bits.

La question était de savoir s'il était possible d'économiser le cache en ne copiant que les octets "significatifs". J'ai répondu que non en prenant comme exemple un int de 8 octets.

Tu te poses de drôles de questions. Remarque, si tu utilises un int pour une variable, c'est que tu comptes utiliser un bonne partie des valeurs possibles, tu ne vas pas prendre un int si tes valeurs vont de 1 à 100 par exemple. Ta question "d'optimiser le cache" n'a même pas de sens à mon avis. Si tu manipule un int (sur 32 bits ou 64 bits) et que tu modifies sa valeur dans le CPU, une fois que tu sauvegarde en mémoire, tu es obligé d'aller écrire tous les bits, qu'ils soient à zéro ou à un ! Le CPU ne sait pas ce qu'il y avait en mémoire avant.

Et dans le cas d'un cache, la granularité du cache est bien supérieure à la taille d'un mot mémoire.

Travaillant chez un herbergeur et FAI, je me vois mal dire à mes clients : désolé l'antivirus cela ne sert à rien sauf à engraisser les sociétés éditrices. Nimda, klez c'est vrai moi ça m'a fait rire mais pas ceux qui se sont fait infectés.

Tes clients veulent avoir un anti-virus chez leur hébergeur, et pas chez eux sur leurs PC ? Ou au moins ils pourraient mettre cet anti-virus sur la passerelle entre leur réseau interne et le reste du Net. Et je dirais à mes clients qu'en évitant certaines pratiques, on n'a pas de problème de virus. Je sais bien que le client est roi mais rien n'interdit de lui donner des conseils de bon sens, surtout si on lui fait faire des économies.

Cela dit, je ne vois pas en quoi un anti-virus agit contre Nimda vu que Nimda est surtout un vers. Nimda infecte les serveurs Web en les attaquant directement, et génère un gros trafic Web (mes serveurs Linux ont pas mal loggué de tentatives).

Et pour finir, je pense qu'un anti-virus ne sert souvent à rien car ce qui est dangereux ce sont les nouveaux virus, et ceux-là par définition ton anti-virus ne les connaît pas.

Soit un antivirus n'est pas limité par la cpu, mais analyse plusieurs centaines de mails par secondes avec les pièces jointes volumineuses on en rediscutera après de ta cpu.

Dans ce cas, je te l'accorde.

qqu'un aurait la commande pour copier le mbr d'un disque à l'autre (genre du hda au hdc) ?
g trouvé ca mais ca marche pas :
dd if=/dev/hda1 of=/dev/hdc1 bs=512 count=1

dd if=/dev/hda of=/dev/hdc bs=512 count=1
Tout simplement, la réponse était dans ta question...
(sinon, mais tu l'as compris, tu copies le début de la 1ere partition)

Quand est-ce que les numeros d'IRQ sur les PC passe à 8 bits ? par ce que 4 bits ca devient la bousculade, meme avec le IRQ-sharing

Déjà, ajouter un bit ça serait pas mal, ça doublerait le nombre. Avec 5 bits ça comblerait les besoins de beaucoup de gens (32 possibilités, il y a de quoi en mettre des cartes d'extensions).
8 bits, ça me paraît énorme et inutile, ça fait 256 IRQ différentes.

L'adressage relative étant utilisé dans les fonctions pour les sauts (if, while, etc...) mais pas entre fonction. Une fonction peut-être appelé n'importe où. Il faut aussi pensé aux pointeurs de fonction qui peut-être utilisé.

Tu as sans doute raison pour les pointeurs de fonction, mais tu te trompes pour l'adressage relatif qui ne serait pas utilisable entre fonctions.

Dans le cas des pointeurs de fonctions, en effet je ne vois pas trop comment on ferait sans stocker le pointeur complet. Un offset relatif ne marcherait pas pour la ligne "func = titi() ;" puisque cet offset devrait être modifié entre le moment de l'affectation et la ligne où on y fait référence ( "func();" ).
Quoique finalement ça ne devrait pas être très difficile de faire un compilateur qui serait capable de suivre les offset des pointeurs de fonction...

Par contre, n'importe quel appel de fonction "normal" marche très bien avec des offset relatifs, c'est ce qu'il se passe quand tu génères du code "PIC" (position independant code"). Sur 68000 ça se code avec un "jsr offset(PC)" si ma mémoire est bonne. Un appel de fonction ou un saut de boucle, ce n'est jamais qu'un saut (avec dans le cas d'une fonction une sauvegarde sur pile de l'adresse de départ, et un "ret" au bout).

On ne peut pas faire l'édition de lien d'un .o avec sizeof(void *) = 4 et d'un autre avec sizeof(void *) = 8. Image "titi = toto ;" avec titi (void *) d'un .o 32 bits et toto (void *) d'un .o 64 bits.

Je te rappelle qu'un programme peut être compilé avec uniquement des offsets relatifs sur 32 bits. On peut d'ailleurs imaginer qqch sur le modèle de ce qui faisait sur PC avant (mode NEAR pour < 4 Go et FAR pour > 4 Go).

<i>> et de ne transfere que les bits significatifs !

Ça ne change rien. [...] A moins que le cache ajoute un octet pour indiquer le type.

Originaux tes exemples, j'ai l'impression que tu n'as jamais vu d'assembleur et les modes d'adressage d'un CPU. Tu oublies les modes d'adressages qui précisent la taille des données à transférer. Sur 68000 un "move" peut être écrit "move.b", "move.w" ou "move.l" , correspondant à 8, 16 ou 32 bits. Quand dans ton code C tu manipules des char ou des long, c'est compilé en instructions qui ne transfèrent que les tailles utiles (en l'occurence 8 bits pour char et 32 bits pour long).

Dans le cas de Linux, le problème sera vite oublié, mais je pense plutôt au logiciel un peu plus propriétaire comme oracle, db2, les antivirus.

Décidément, tu y tiens à ton anti-virus. Dans ton commentaire précédent, je croyais que c'était une taquinerie, vu le peu d'utilité des anti-virus (à part enrichir quelques sociétés qui ne vivent que de ça). Surtout que je ne pense pas qu'un anti-virus soit limité par le CPU.

Je suis souvent sous Windows NT au boulot, et j'ai désactivé l'anti-virus (contrairement à la politique de ma boîte) car il prend de la mémoire et ralentit aussi la machine. Je ne fais aucune manipulation qui me permettrait de récolter un virus (je n'ouvre pas d'exe et je n'ai pas Outlook), et je n'en ai jamais eu.

Par contre, concernant une base de données, la recompiler pour de meilleurs performances me semble beaucoup plus utile et nécessaire.

j'avais lu qq part que la taille moyenne mémoire augmentait de .8 bits (bus d'adresse) par an soit 80%. Si 512 Mo est courant sur une machine de bureau neuve, il faut 3 ans pour dépasser 4Go à ce rythme. J'avais fait le calcul en 2002, à l'époque la taille standard de la mémoire était de 256 Mo. Sachant que la taille mémoire double tous les 18 mois, elle quadruple tous les 3 ans. Ca donne ceci comme progression : Année : 2002 2005 2008 Mo : 256 1024 4096

Intel estime que le 64 bits n'est pas une priorité pour le grand public. Il n'a pas vraiment tort. Qui ici a besoin d'un système 64 bits ? Qui utilise pour son PC perso plus de 4 Go de mémoire vive ? Vu le rythme de croissance de la taille mémoire dans les PC grand public, on arrivera à 4 Go à peu près en 2008. C'est dire si les PC un peu plus costauds vont vite se casser les dents sur la limite d'adressage, avant cette date. C'est vrai que ça paraît délirant qu'un jour le PC de base soit doté de 4 Go, mais comme ça n'a jamais cessé de croître... Passer de 32 à 64 bits, çà bouffe plus de mémoire et plus de place disque. ( Pas d'accent sur le "a" de "ça" (car ton "ça" = "cela") ) Le fait de passer du 32 bits au 64 bits ne fait pas forcément grossir le code car les architectures CISC à la Intel permettent d'utiliser plusieurs modes d'adressage, en particulier relatifs, avec des "offsets" sur 16, 32 ou 64 bits. A priori, sur la plupart des programmes (qui sont < 4 Go), il n'y aura pas besoin de stocker les sauts et autres pointeurs sur plus de 32 bits. Ceux qui ont fait de l'assembleur 68000 me comprendront aisément, à l'époque on pouvait le plus souvent utiliser de l'adressage relatif sur 16 bits, même pour des programmes plus gros que 64 Ko.

AMD a une maintenant une opportunité de gagné des parts de marché. "une occasion de gagner des parts de marché" (sinon c'est un anglicisme) Mais le souci restera toujours les logiciels qui ne sont pas à recompiler comme les antivirus pour les serveurs de messagerie Je n'ai pas compris ta phrase, en quoi c'est un souci s'il n'y a pas à recompiler ?

Je suis étonné que personne a relevé que les drivers de MySql était passé de L-GPL à GPL. Ce qui empeche tout développement d'application propriétaire utilisant cette base de données.

Tu es sûr qu'avoir un driver en GPL empêche d'avoir une application propriétaire basée sur MySQL ? Ca m'étonnerait. Il y a pas mal d'applications propriétaires basées sur MySQL et ça m'étonnerait qu'elles soient brutalement obligées de demander une license commerciale, ou de mettre leur appli en GPL.

[la NSA] Ils ont 10 ans d'avance en matière d'analyse crypto-mathématique théorique et là personne ne peut lutter...

Ils ont probablement un peu d'avance, mais d'où sors-tu ton chiffre de 10 ans ? Je pense qu'on fantasme un peu sur les capacités de la NSA. Une FAQ courte et intéressante à lire, amusante en plus, qui donne un ordre de grandeur de l'avance de la NSA : http://www.ifrance.com/maliks/faq-cle.html(...) (un peu lent le site d'IFrance mais la page originale http://www.di.ens.fr/~pornin/faq-cle.html(...) n'existe plus).

4. Les diverses rumeurs
* 4.1. La NSA/DST/autre peut casser des clés de 128 bits.
* 4.2. La NSA/DST/autre possède des ordinateurs quantiques.
* 4.3. La NSA/DST/autre connaît des méthodes de cryptanalyses avancées.
* 4.4. Je suis employé par la NSA/DST/autre pour faire croire au public que les chiffrements en 128 bits sont sûrs.

"MySQL Connector/J is a Type IV JDBC driver"

Du coup j'ai regardé pour PostgreSQL, le driver est aussi de type 4. Il en existe plusieurs variantes, dont une pour l'API JDBC 1 (lié au JDK 1.1) et une pour l'API JDBC 2 (JDK 1.2/1.3) si j'ai bien compris. Il est question de jdbc3 (dans les sources en tous cas) et je crois que c'est lié au JDK 1.4 mais je ne suis pas certain.

PostgreSQL provides a type 4 JDBC Driver. Type 4 indicates that the driver is written in Pure Java, and communicates in the database system's own network protocol. Because of this, the driver is platform independent; once compiled, the driver can be used on any system.

Script pour encoder un DVD : On n'encode pas un DVD, on le convertit. D'ailleurs l'information contenue sur un DVD est déjà codée (et non encodée). (rappel : en bon français on dit "coder", "codage" : "message codé" "nouveau codage")