Serait de faire une transformée de fourrier des deux immages.
Avec la FFTW par exemple. Tu aura ainsi une analyse spectrale pour pas trop cher. Après pour affiner c'est tout un bazard. Ci le but est d'être capable de reconnaitre un paysage de nuit par rapport à un paysage de jour ça ne marche pas du tout.
_NP est une norme de nommage qui veut juste dire que la fonction n'est pas portable (not portable).
Il y a donc des _NP à peu près partout, celà signifie juste que la fonction n'est pas standard, et donc qu'elle risque de ne pas se retrouver dans une bibliothèque standard. Typiquement rien ne garantie que l'init de Mutex MUTEX_INIT_RECCURSIVE_NP sera présente dans toutes les bibliothèques Posix Threads, ni même qu'elle aura un comportement similaire si elle est présente.
il faut ecrire un code Java tres tres reflechi, ce qui est au final une operation bien plus complexe que d'ecrire le meme code en C.
Ca fait longtemps que j'ai pas joué avec ce truc, mais je me souviens à l'époque que pour s'en sortir on avait du passer par l'assembleur java en ecconomisant les registres autant que possible.
Bien entendu pour pouvoir appeler nos fonctions depuis les parties non assembleurs, ou piloter les entrées sorties, il fallait se caler en mémoire avec précision. C'est là qu'intervenanit l'extension (probablement proprio) Low Programming Array (lpa) qui permettait de pointer un octect spécifique et de le changer bit à bit. Cette fonction se trouvait fort logiquement dans le package "bit" de l'extension.
Tous nos fichiers commençaient donc par un beau : import javalpa.bit
Et on parlait sans arrêt de javalpa et de bits dans notre bureau.
C'est impressionant ce que le bureau d'à coté a pu se foutre de nous...
Sous RH et FC il y a nptl *ET* linuxthread.
Sous beaucoup d'autres distribs aussi. Sous ma gentoo j'ai mis les deux.
Ce que tu ne veux pas comprendre, est que nptl est compatible linuxthread (sauf quelques cas particulier)
Je l'ai compris il y a bien longtemps. ce que toi tu ne veux pas comprendre est que MySQL utilsie des inits de mutex en _NP qui justement font partis desdits cas particuliers
Je répète, mysql est codé ala linuxthread mais utilise nptl.
C'est faux. L'init de mutex de MySQL force LinuxThread en config standard (ie la config utilisé pour les tests)
Je n'ai jamais dit le contraire. Relis le thread. Je dis qu'il est codé en utilisant les entêtes linuxthread mais qu'il utilise l'implémentation des thread nptl.
Non. Le code d'initialisation des mutex, oblige l'utilisation des bibliothèques linuxthreads. La façon la plus simpel de savori si MySQL utilise LinuxThreads ou NPTL est de compter les process MySQL après lancement du démon. Si il y en a un c'est que les trois threads utilisent le même PID. C'est donc que NPTL a été utilisé, si il y en a trois c'est que LinuxThreads a été utilisé.
C'est comme Gtk. Ton applis peut nécessiter les entêtes Gtk+ 2.0 et ne pas compiler avec Gtk+ 2.6 mais elle peut utiliser gtk+ 2.6 (la librairie binaire, avec un file selector "mignon", etc) et dans ce cas, je dis que l'applis utilise gtk+ 2.6 pour la simple raison qu'elle utilise gtk+ 2.6.
Si tu ne comprends pas ça, je n'y peux rien.
Je ne parle pas des entêtes mais des bibliothèques systèmes. MySQL utilisant des fonctions non portables (ie non présente dans la norme Posix) doit être linké avec linuxthreads pour les versions citées plus haut. MySQL, dans son configure par défaut, a un besoin vital d'uen fonction non posix LinuxThreads qui n'existe pas dans NPTL (ni en réel, ni en interface mappée).
Ici, mysql utilise nptl et est compilé avec les entêtes de linuxthread.
Ca me parait très étonnant. Je veux bien croire que MySQL "Linke" NPTL pour une raison qui m'échappe, mais je ne pense pas qu'il s'en serve (du moins pas MySQL 4.0.22). Au niveau execution LinuxThreads et NPTL sont totalement incompatible et on ne peut donc pas les utiliser simultanément dans un même programme. A mon sens ilf aut compter les process. Si en compilant MySQL 4.0.22 avec un simple ./configure tu arrives à n'avoir qu'un seul process MySQL qui tourne c'est que tu as raison, ton MySQL utilise NPTL. Mais dans ce cas j'aimerais vraiment jeter un oeuil à ta config, parceque c'est théoriquement impossible.
J'ai aucune raison à donner. Mais ce n'est pas une émulation de linuxthread, c'est linuxthread. C'est différent.
Les threads sont créés avec la fonction 'clone' et ca s'arrête là. Tous les signaux systèmes passent quand même par le système natif et doivent être convertis. Le terme d'émulation n'est peut-être pas le bon, on devrait plutot parler d'enrobage (wrapping). Ceci étant les locks de mutex (par exemple, car ce n'est qu'un des quatre ou cinq points qui posent porblème, mais autant garder le même de bout en bout) doivent remonter jusqu'en userspace et redescendre à chaque fois...
soit tu considères que l'implémentation *BSD est plus lente que linuxthread.
Plus lente non, plus problématique oui. Les threads dans FreeBSD sont assez pathétiques. Au final un MySQL compilé avec les options de base met à genoux un FreeBSD très facilement. Le threading sous FreeBSD est faiblard parfois, mais ça n'est pas la question.
Et alors ? C'est toi qui dit que le problême est autour des mutex.
Une fois de plus les mutexs ne sont qu'un exemple. C'est un des mainteneur des ports FreeBSD qui a évoqué que ca pourrait venir de là. Pour une liste de tous les problèmes liés à FreeBSD et la solution :
Je dis juste que le réalisateur du test aurait pu prendre des versions patchées de MySQL pour FreeBSD et que celà aurait rendu le test plus juste. Je ne prétend pas :
- Ni que FreeBSD est meilleur que Linux
- Ni que MySQL Tuné pour FreeBSD est meilleur que le MySQL tuné pour lInux
- Ni que le système de threading FreeBSD est meilleur que LinuxThreads.
Je dis juste que le test n'est pas juste en l'état.
Je vais pas y passer des plombes mais même mysql 3 (fournis par Red Hat ou Fedora) utilise nptl (linké avec nptl). Il n'y a pas de patch spécifique pour ça.
Moi non plus je ne vais pas y passer des plombes. TOUS les MySQL 4.0.X et les MySQL 4.1.Y avec Y < 8 utiliseront Linuxthreads par défaut si il est disponible.
Pour X<23 MySQL 4.0.X ne compilera même pas. Je parle des MySQL vanilla, à savoir le code source tel qui est fourni par MySQL sur le site MySQL.
Car il n'y a pas de thread du tout pour glibc < 2 et que d'ailleur il n'y a que Linux 2.6 qui fourni des fonctionnalités pour les threads. Les linux plus anciens s'appuient sur clone() et le reste est fait en userland.
J'ai cité la phrase en entier car je n'aime pas les citations partielles à quoi on peut faire dire tout et n'importe quoi. Je la refais plus brutal : Dans le manuel MySQL concernant MySQL 4.0.23 concernant la section "installation Linux à partir des sources" il est écrit : MySQL uses LinuxThreads on Linux.
Que MySQL sous *BSD est plus lent que MySQL sous Linux.
Donne moi une raison valable, une seule ça me suffit, pour que MySQL sur une émulation de thread Linuxthread sur les threads posix sur les threads Natifs BSD soit plus rapide que MySQL directement sur les threads natifs BSD. Bonne chance. Hint : Les locks et les unlocks de mutexs sont des appels système qui se font forcément en natif.
et jouer avec ce qui est spécifique à linuxthread ou nptl est rare.
MySQL le fait( faisait) avec les mutexs pour des raisons de rapidité d'éxecution.
Sous Red Hat/Fedora et depuis RH9 nptl est utilisé par défaut :
Sur toutes les distribution en 2.6 aussi d'ailleurs. mais rien n'empèche de réclamer spécifiquement les LinuxThreads.
Donc, comme je le supposais plus haut, nptl est compatible linuxthread.
Sur les fonctions posix standards oui, sur les autres non. Toutes les initialisation de Mutex en code finnissant par _NP dans LinuxThreads ne sont pas compatibles avec NPTL.
De plus les linuxthreads créent des threads avec chacun leur PID (chaque thread apparait comme un proces), NPTL n'a pas ce défaut.
- linker directement (en dure) avec /lib/i686/ ou /lib (par défaut c'est linké avec /lib/tls).
J'ai dit que l'ensemble des MYSQL 4.x "vanilla" nécessitaient LinuxThreads pour tourner correctement. Apparament depuis la 4.1.8 ce n'est plus le cas. Cependant la 4.0.22 (utilisé dans le test) requiert absolument les Linuxthreads (0.71+). Apparament ce n'est plus le cas pour la 4.0.23 (Test fait sur ma gentoo, noyeau 2.6.9) mais la stabilité n'est pas au rendez-vous. Le manuel d'installation de la 4.0.23 précise d'ailleurs qu'il faut utiliser LinuxThreads cf http://dev.mysql.com/doc/mysql/en/source-notes-linux.html(...) MySQL uses LinuxThreads on Linux. If you are using an old Linux version that doesn't have glibc2, you must install LinuxThreads before trying to compile MySQL.
A noter que ceci prouve que
a) NTPL n'est pas 100% retro compatible avec LinuxThreads (4.022 ne passe pas, 4.023 est instable)
b) Les libs linuxthreads sont bien linkées spécifiquement (MySQL 4.0.23 vanilla utilise préférentiellement LinuxThreads)
Donc le test a utilisé linuxthread (entête et librairie) sous Linux alors que nptl est plus rapide que linuxthread.
Pour les locks et unlocks de mutexs (ce qui nous interesse ici) c'est LinuxThreads en mode Mutex rapide qui est le plus rapide. Même si NPTL ets globalement plus performante, il existe encor eun poitn ou deux ou LinuxThreads est plus rapide.
Donc ce test n'a pas "honteusement" favorisé linux comme sous-entendu ici.
C'est pas sous-entendu. C'est affirmé, ave cdémonstration à l'appui. Et il n'y a pas de guillemets autour de honteusement non plus.
De plus le "testeur" c'est fait chié avec freeBSD pour avoir linuxthread (qui est plus rapide que la version native)
Ah bon ? Chez moi c'est installé de base et c'est une option à passer à la compil. Mais bon.
Mais pour en revenir à ta remarque très juste, le testeur démontre avec brio que MySQL->NativeBSD threading est beaucoup plus lent que MySQL->LinuxThreads->Linux-To-PosixMapping->PosixThreads->Native BSD Threading.
Oui parcequ'au final sous BSD, ce sont quand même des threads BSD qui vont être créés.
La première idée qui vient quand on obtient ce genre de résultats est "tiens ils ont codés les threads natifs BSD avec les pieds", celle qui ne devrait jamais venir est "Mon Dieu LinuxThreads et tellement bien que quand on l'utilise en surcouche de surcouche de surcouche de BSD Threadings on gagne des perfs par rapport au natif".
Alors soit ça a changé récamment et j'ai loupé le coche, soit tu as une version non standard de MySQL installé (je ne parle que de la version vanilla pour ma part.)
Au 16 juin 2004
We only support Linux glibcs with LinuxThreads for now
as we have experienced server lockups with NPTL.
That's why we check for the string "Linuxthrads" being
present in the header file.
A warning from configure about NPTL not being support
might be better though in this case instead of just
insisting on Linuxthreads.
source : http://bugs.mysql.com/bug.php?id=2173(...)
Sur la version 4.1.7 de MySQL, le bug est toujours actif.
On retrouve pas mal de rapprots de bugs sur NPTL, notamment dans les forums Debian, avec des patches qui ont été inclus dans les paquets standards Debian.
Je ne vois aucune trace de correction de la gestion des threads par defaut dans les changelogs de MySQL (qui sont très succint ). Peut-être que MySQL 4.1.8 et 4.1.9 peuvent linker de façon fiable sur NPTL ....
l y n'a aucun doute que MySQL utilise nptl ici. Linké avec -lpthread, reconnu lors du "./configure", HAVE_LIBPTHREAD est défini mais aussi HAVE_LINUXTHREAD.
NTPL et LinuxThreads sont mutuellement exclusifs. On ne peut utiliser qu'un des deux à la fois (notament pour des raisons de gestions des PIDs). Les deux optiosn qui défilent ne font que signifier que le configure a trouvé que le système supportait les PThreads et qu'il a trouvé la bibliothèque LinuxThread.
Avec Linux 2.6 et glibc > 2.3.? c'est nptl par défaut. Et nptl veut dire Native POSIX Thread Linux. Ça suit le norme Posix :
MySQL 4.x utilisera systématiquement LinuxThreads sous Linux, et fera appel aux fonction non portables sur les fasts mutexs .
MySQL 5.x par contre a corrigé le tir comme je le disais, et utilisera bien le NTPL
NB : linuxthread (pour les sources et être portable) suit aussi la norme Posix.
Il suffit de regarder le nombre de signaux en _NP (non portable) pour se rendre compte que la norme n'est pas suivi de très très près. Généralement ce sont des ajouts en plsu de la norme, mais dnas le cas des mutexs (pour l'init notamment) il y a des manques.
normalement si l'appli est compilé pour nptl (auto-détection), elle switche automatiquement vers linuxthread si c'est linux 2.4 qui est utilisé.
Certes mais là l'appli est écrite pour linuxthreads à la base. Sinon il n'y aurait aucun problème. Les NTPL Linux sont quasi identiques aux Pthreads natifs BSD (avec quand même un ou deux gags sur l'ordre des bits et les pids parfois).
Ca commence a me brouter cette impossibilité absolue de tester quoi que ce soit dans le monde des OS !
Et bien réjouis toi, il est possible de tout tester dans le monde des OS. A part l'OS.
Tenter de comparer deux OS revient à peu de choses près à tenter de comparer deux boites à outils. A la question "Quelle est la meilleure boite à outils, celle du maçon ou celle du vitrier ?" la seule réponse possible est "Ca dépend, vous voulez poser des vitres ou ravaler une façade ?"
La première question à se poser quand on veut créer un test est de définir très clairement ce que l'on veut mesurer. La dernière question à s epsoer quand on a fini un test est de comprendre précisément ce que l'on a mesuré.
L'auteur de ce bench part avec l'idée de comparer globalement des OS entre eux (ce qui pour les raisons vus plus haut n'est pas particulièrement pertinent) et fini par comparer les performances ) et fini en comparant le sperformances de MySQL sous différents OS. Au final la question auquel on répond est donc : Quel est l'OS le plus adapté pour faire tourner MySQL sur la config matérielle du testeur'. Et la réponse que l'on obtient n'est pas valable parcequ'une personne qui ferait ces tests dans le but d'utiliser MySQL (typiquement un responsable informatique qui doit prendre une décision système) prendrait probablement des versions compilées/patchées pour tirer parti au maximum du matériel et de l'OS . Ici le testeur prend la version générique qui, pour les raisons vues plus haut, favorise grandement les OS Linux.
Donc a moins d'avoir une bonne raison pour garder la version 'vanilla' (et je n'en vois pas vraiment) le bench n'apporte donc pas grand chose au final.
ben pourquoi les mutex sont "rapides" par défaut sous Linux et lents par défaut sous BSD ?
Les mutexs "rapides" sont une spécificité non portabl des linux threads. C'est une façon de faire qui n'ets pas conforme au standard Posix.
Une façon courte d ete répondre serait la suivante : Sous Linux il n'y a pas 36 façons d'intialiser un mutex et le lier aux fonctions de lock d'un ou plusieurs threads, sous BSD il y en a des quintaux.
Au final sous linux la méthode par défaut est pas très optimisée coté thread masi elle s'appuie sur des spécifité du système Linux qui la rende rapide au final (mais impossible à porter). Sous BSD on a toute la panoplie et on peut régler les Pthreads et les mutexs au millimètre, par contre si on ne fait pas les réglages soit même le système préfère ne pas prendre de risque et utilise des valeurs "passe partout" qui ne sont pas d'une éfficacité redoutable.
Au final MySQL a un comportement très attypique (des locks et des unlocks en rafales en 50) . La politique "safe" de BSD lui retombe donc sur le nez. L'équipe MySQL AB aurait du passer plsu de temps à peaufiner l'utilisation des threads natifs des différents BSD...
Pourquoi Linux peut-il bien gérer un MySQL fraichement downloadé et compilé alors que les BSD en sont incapables ?
Est-ce parceque MySQL n'est que très peu portable et est conçu spécifiquement pour Linux ?
Sans aller jusqu'à dire que MySQL est "optimisé" Linux, on peut dire que les versions de MySQL 1 à 4 ont été concues avec Linux en tête. Lors de la configuration de la compilation MySQL vérifie et éventuellement active tout un tas d'options qui n'existent ou ne sont vraiment efficaces que sous Linux. Celà ne veut en aucun cas dire qu'il n'est pas portable, cleà veut juste dire que si le configure par défaut ne se trouve pas face à un Linux il va se rabattre sur des programmes et des bibliothèques moins efficaces alors que des alternatives BSD existent. Une des exemples les plus flagrants est la gestion des mutexs pour les locks, MySQL génére un grand nombre de locks et de retraits de locks, sous Linux l'impact est quasi-nul car les mutexs créés apr défauts sont en mode "fast" mais sous BSD la méthode employée par défaut oblige le système à rescanner tout le contexte. C'est aussi pour çà que l'on perd des performances lors du passage en multiprocesseur, une partie du contexte est doublé pour que l'on puisse passer le thread d'un CPU à l'autre, mais si il y a un lock sur le thread un seul des deux CPUs peut faire le check du contexte. Moralité chaque "unlock" coute (nombre de CPU)*(overhead du contexte par CPU) en plus. Vu les rafales que balance MySQL ca chiffre très vite.
Il semble cependant que la version 5 cherche à corriger le tir.
Bon même si le bench est foireux par rapport à Linux (j'attends quand même d'autres avis éclairés) on peut comparer les BSD entre eux.
Si tous les mutex par défauts étaient égaux oui. Mais poru avoir uen idée précise il vaudrait quand même mieux remplacer toutes les demandes de créatiosn de mutex par défaut par des demandes de création de mutex "le plus rapide possible" en fonction de l'OS.
While some of the operating systems had precompiled or ready-to-compile BSD ports of MySQL available, many were slightly older versions of MySQL (4.0.20 for example) and compiled with a variety of different options which presented problems with consistency. After all, I'm testing the operating systems, not their pre-packaged MySQL distributions or source builds.
Traduction : alors que certains OS ont des ports BSDs précompilées our prètes à compiler de MySQL disponibles, beaucoup étaient légèrement plus anciennes (4.0.20 par exemple) et compilées avec une variété d'options différentes ce qui posait un problème de cohérence. Après tout je teste les OS et non leurs sources préparées ou leurs paquets MySQL.
En clair ca donne :
J'ai laissé la gestion des threads, des priorités et de la mémoire de base, parceque je trouve çà plus juste et plus cohérent pour un benchmark d'OS.
Au final on se retrouve avec un OS qui a une gestion des threads et de la mémoire adaptée a son fonctionnement (Linux) et les autres qui sont obligés de batailler avec des modes de compatibilté, des couches d'émulation et tutti quanti.
Le simple fait que l'émulation de threads Linux tourne plus vite sous FreeBSD que les threads natifs auraient du mettre la puce à l'orreille.
MySQL est un des ports les plus patchés sous les *BSD. Généralement il y a au moins les MIT-Pthreads sinon l'OS en prend plein la tête au niveau synchronisation des threads.
il y a aussi beaucoup à dire au niveau de la gestion des fichiers partagés en mémoire (mmap et consors) .
Au final la conclusion que l'on peut tirer de ce benchmark est que MySQL via les APIs système "façon Linux" est beaucoup plus rapide sur Linux que sur *BSD. Le contraire eut été surprenant.
Son défaut majeur : on ne peut pas créer une nouvel enregistrement si la clé primaire est de type serial (incrementation automatique). Ce qui est diablement facheux.
Alors sur une base de données qui supporte les timestamp, les UUID, les randr etc. Utiliser les autoID incrémentaux c'est monstrueux. D'expérience un AutoID sérial ca n'apporte que des ennuis, a partir du moment ou lus d'une personne bosse sur la table à un instant t il faut balancer toutes la gammes des locks et des transactions si on veut pourvoir récuperer l'ID de la ligne que l'on vient de créer.
Donc le "manque" du driver ODBC (qui n'en est pas un vu le fonctionnemetn de Postgres) ne me gène pas du tout, et si çà peut convaincre certains DBD de laisser tomber les Auto-IDs tant mieux.
Si tu donnes ta machine, autant donner tes mots de passe avec. Les garder ne sert pas à grand chose ca prend 30 secondes de remplacer la bonne clef dans la base de regsitre pour mettre un nouveau de mot de passe.
En plus si par hasard la personne en face est pas en XP service pack2 on peut même aller decrypter le mot de passe ave cla clef "universelle" pour tous les mots de passe et çà roule, même pas besoin de changer les mots de passe.
Je vous livre le post que j'ai fait sur le forum. Bonne lecture
Bonjour,
L'identification unique et certaine d'un individu et des droits qu'il possède est une arme à double tranchant. D'un coté elle permet d'assurer la protection et l'accès au service des ayants droits. D'un autre elle peut créer des clivages forts entre ceux qui peuvent montrer patte blanche et ceux qui ne peuvent pas. Il est donc très important de savoir qu'elles informations sont stokées, ou elles sont stockées et comment elles sont certifiées.
Je me permet de livrer çi dessous la liste des éléments nécessaires à un fonctionnement sain de cette carte.
- Qualité de l'authentification :
La photo d'identité et une ou plusieurs empreintes digitales ne sont pas des informations fiables. Même l'empreinte rétinienne, considéré longtemps comme "sure" montre aujourd'hui de nombreuses faiblesses.
L'authentification par "Je suis" I.E une analyse purement physique et non interactive d'un individu (apsect, taille, empreinte dentaire, implantation capilaire, empreintes digitales etc.) est un plus mais ne saurait constituer un tout. Une authentification supplémentaire par code ("Je connais") ou mieux par signature physique classique ("Je sais faire") est absolument nécessaire pour s'assurer non seulement de l'identité de la personne, mais aussi de son accord à la procédure en cours.
- Informations en circulation
La carte d'identité numérique permettra pour les démarches administrative une identification complète de façon à faciliter et accélerer lesdites démarches.
Mais il est très important que les tiers non ratachés à l'état ne puissent pas accéder à l'ensemble des informations, notamment dans le cas de tiers marchands (banques, commerces, fournisseurs de services etc.) Dans cette optique il appartient au gouvernement de définir avec soin secteur par secteur et activité par activité à quelles informations un tiers peut prétendre avoir accès pour ses besoins d'identification. La reservation de places de théatre ne nécessite pas par exemple pour le commerçant de connaitre mon lieu de naissance, mon age ou mon lieu de résidence. Ces informations ne doivent donc pas être transmises, le cas contraire pourrait entrainner un mécanisme de ségrégation extrèmement puissant et très difficile à démonter, les personnes trop jeunes, trop vieilles ou trop epu rentables commerciallement seraient alors redirigées vers des offres moins attractives voire ignorées.
- Indépendance des identifications
Il est important pour les raisons vues plus haut, que les informations fournies soient aussi limitées que possible. Dans cette optique deux options sont possibles :
1) Une simple certification des informations : je continue à saisir l'ensemble des informations que je dois transmettre moi même , celle ci sont ensuite passées par un hash (filtre mathématique non inversible) et comparées au hash de l'information de la carte. De cette façon le serveur d'authentification ne dispose d'aucune information exploitable et ne peut que confirmer ou infirmer la validité des informations saisies par le porteur de carte.
2) Les données réelles existent (stoquées sur la carte ou sur un serveur distant) et sortent spontanément de la carte à la demande du porteur. Dans ce cas là il est très important tout d'abord que l'ensemble des données transmises à la personne requérant une identification soient aussi réduites que possible (cf plus haut), et que l'ensemble des données transmises ne soient ni interceptables ni modifiables ni copiables par un tiers. Et bien entendu il faut éviter que qui que ce soit puisse enregistrer le processus d'identification pour le reproduire par la suite.
Dans les deux cas il est important que l'ensemble des étapes qui composent le processus d'identification soient validées par des tiers de confiance.Hors qui dit tiers de confiance dit dépendance à un tiers. Il faut bien alors prendre conscience du pouvoir dont disposerait un tel tiers si il était malveillant et en situation monopolistique. Il pourrait simplement rendre imposssible l'utilisation de la carte d'identité numérique à qui il voudrait. Le piège vient du fait que si l'on essaye de pennaliser un coportement arbitraire vis à vis des identifications, on risque de se retrouver ave cune gestion laxiste des authentifications. La seule solution pour éviter l'épineux problème l'équation : abus de pouvoir ou laxisme est la suivante;
- Tout d'abord rendre l'ensemble des principes d'authentification public, et spécifier publiquemet les critéres de validité d'une authentification.
- Ensuite multiplier autant que possible le nombre des tiers de confiance de façon à éviter qu'une défaillance ou une malveillance de l'un des tiers n'empêche une personne de se servir de sa carte pendant une durée inderterminée.
Pour les mêmes raisons, il est important que le nombre de fournisseurs de puces soit aussi élevé que possible et que les caractéristiques des puces soient publiques.
- Cohérence des identifications
Quelque soit le système biométrique ("je suis") ou technométrique ("je sais faire") mis en place, il est important de prévoir dès aujourd'hui un mécanisme de secours en cas d'impossibilité d'authentification. Une personne qui a perdu son pouce dans un accident a autant besoin qu'un autre (voir plus au début compte tenu des démarches qu'impliquent un accident) de prouver son identité. Il faut donc que l'on puisse rapidement changer le mode d'authentification. Les problèmes sont que
a) la rapidité nécessaire de ce changement ne doit empiéter ni sur la fiabilité de la carte ni sur son utilisabilité.
b) il faut pouvoir propager aux tiers de confiance le changement de mode d'authentification de façon fiable et rapide.
Hors la personne qui vient de subir cet accident n'est plus en mesure de prouver son identité "facilement". Il appartient donc à l'état de garder sur l'ensemble du territoire des structures d'accueil classiques et efficaces à même de prouver l'identité de tel ou tel personne.Sans ces structures la personen accidentés devrait alors surmonter un double handicap, tout d'abord celui lié à l'accident lui même et ensuite celui lié à une société dans laquelle la carte dont il ne peut plus se servir serait devenue obligatoire pour toute transaction commerciale.
Copier une empreinte digitale est aussi simple que de retourner un gant en latex.
Et la detection du flux sanguin ne change pas grand chose dans ce cas là.
(N.B : Pour les malfaiteur en herbe, çà ne marche pas avec un gant latex, il faut un autre plastique qui resiste mieux à la pression. Mais l'idée générale est là)
But it definitly looks like french is not your mother language.
So let us try in english.
From what I understood (more like decypher, translation programs are way overrated) :
- You boot MDK 10.1 from you CD-Rom
- At some point Mandrake Installer tells you that it can't access the CD-Rom Drive and that it needs drivers to do so.
- Then it keeps asking for the drivers and the parameters of your CD-Rom.
This could com from a lot of different issue. Hopefully you should be able to sort it out easily enough.
What is likely to happen is one of the following :
- Your CD-Rom is connected through USB and Linux kernel can't seem to find it
- Your CD-Rom is connected through SCSI and Linux kernel can't seem to find it
Your CD-Rom is connected through SATA and Linux kernel can't seem to find it
So basically you need the driver of whatever peripherial your CD-Rom is connected to.
First thing to test is alternate kernels . If my memory is OK, you should be able to select between a 2.4 and a 2.6 kernel at boot . Try them both, chances are high that one of them is working.
If not, try them both again but adding -noapic -noacpi on the same line (should be something like boot : mdk2.6._xxxx -noapic -noacpi the bold part being what you type)
If none of this works, you will indeed need the drivers. There only the manufacturer and Google can help you.
Le fait est que quasiment plus personne n'utilise ce code d'erreur dans le main, notamment les débutants
Oui mais le fait est qu'encore moins de personnes prennent le temps de trapper toutes les erreurs, ou de renvoyer une erreur explicitement, dans ce cas le code erreur du main est toujours bon à prendre.
alors autant laisser le compilo mettre la BONNE valeur par défaut, plutôt que de forcer le noobs à renvoyer une valeur,
Le compilateur ne fera pas un programme à ta place. Il forcera une sortie système à 0, ce qui ne veut rien dire d'autre que 'le programme s'est executé correctement' . Maintenant uen fois de plus ce n'est pas parceque le programme ne génère pas d'exceptions qu'il s'est executé correctement, mais là il n'y a que le programmeur qui peut savoir que quelque chose c'est mal passé. Charge à lui soit de créer et de lever une exception pour chaque erreur, soit de passer un paramêtre pour que le programme se termine correctement et renvoit un entier.
Créer des exceptions pour chaque cas est la solution la plus propre, mais trapper toutes les erreurs possibles peut être fastidieux et particulièrement lent.
... pourrait très bien s'amuser à mettre return 1 (c'est vrai pourquoi return 0 ?)
Le 0 est horriblement pratique ca permet de faire le test d'erreur, le renvoit d'erreur et le numéro d'erreur dans une seule instruction.
par exemple
if (!erreur) traiteerreur(erreur);
On utilise le 0 comme un false et hop le tour est joué.
Celui qui sait ce que ca fait met une valeur de retour s'il en a envie, je vois vraiment pas où est le problème.
Manifestement il doit quand même y en avoir un, sinon pourquoi le compilateur s'amuserait-il a transformer la signature de la fonction pour renvoyer un entier quand même. Et quitte à avoir un entier renvoyé quoi qu'il arrive autant
a) ecrire le code de façon à se que ce renvoit d'entier soit visible
b) utiliser ce renvoit d'entier pour transporter une info (autant en profiter) plutôt que de renvoyer 0 à chaque fois.
c) Il n'est pas improbable (surtout vu l'intégration de C# avec COM+) que votre programme C# soit un jour utilisé via un script WSH sous windows. Dans ce cas là, retourner un entier est une très bonne chose.
On parle de C#, y'a un système d'exception qui peut être intercepté par la VM : et un message d'exception est autrement plus complet, précis et enrichi qu'un simple numéro de retour .
Une terminaison anormale d'un rpogramme ne veut pas forcément dire qu'une exception a été retournée et remontée jusqu'à la VM. En Java celà s'apelle un code rouge. Un exemple simple est quand suite à une destruction un peu trop hative de certains objets on se retrouve à "perdre" des objets fondamentaux à l'execution du programme. Dans 99,99% des ca son va remonte rune erreur, mais j'ai eu le cas d'un programe qui donait toute les apparences de s'executer proprement mais qui en fait se vautrait à un moment, perdait la procédure de boucle et se fermait (nettoyage par le garbage collector des objets inateignable) en apparence proprement.
Je pense qu'un cas similaire peut être codé en .Net pour peu que l'on se penche un peu sur le problème.
mais le code C# ou Java est censé être indépendant de ces considérations de "bootstrapping" visant à intégrer l'exécutable dans son environnement.
En théorie c'est vrai pour Java, en pratique quand on veut faire dialoguer deux threads ou deux processus il y a des fois on a des surprises d'une VM X sur un système x86 à la même VM X sur un système Solaris (vécu inside) . La plupart de ces problèmes ont étés plus ou moins résolus aujorud'hui. Mais de temps en temps ca ressurgit.
Par contre C# est indépendant de la plateforme, mais surement pas du "COM WRAPPER". Comme tu le dis si bien C# a été conçu pour s'intégré très bien avec les objets COM, pour peu que l'on utilise le wrapper par défaut de Microsoft.
Mais même si l'on utilise le wrapper Microsoft on peut avori des surprises. J'ai eu deux collègue squi se sont arrachés les cheveux pendant des semaines sur un programme qui appelait un objet COM en call-back pour les tests d'appoints, mais qui était appelé en natif par l'objet COM lors du fonctionnement normal. Dans ces cas là la déclaration des fonctions compte ennormément, or une des fonctions (pas main, le connecteur base de données) avait deux signatures différentes suivant que l'objet COM appelait le programme ou l'inverse.
Au final il leur a fallu un bon moment pour comprendre pourquoi quand ils utilisaient les fonctions pour tests d'appoints le wrapper finissait par partir en vrille au bout d'un moment.
Je ne connais pas avec précision leur qualité en tant que devoleppeur, et donc je ne peux pas dire si ils ont commis une erreur de débutant ou non. Mais je sais que les objets COM 1.5 ont des procédures d'appels et de référencement très bas niveau, et que si on arrive à gruger le wrapper, on finira par avoir un chouette bazar parceque si le wrapper dit oui, dérrière on attaque le système direct.
Personellement même en Java je fais des "public static int main" ca ne coute rien et c'est utile plus souvent qu'on pourrait le penser.
Suite au moinssage en force de mon poste précédent je me permet d'argumenter un peu.
Tout d'abord commençons par un petit résumé des épisodes précédents :
Jusqu'à ce que Borland décide de créer un compilateur C tous les compilateurs du monde sortait une erreur ou au moins un warning grave quand on avait le malheur d'oublier de mettre le type de retour de la fonction main.
Les compilateurs UNIX créés à des époques ou la mémoire valait une telle fortune que toutes les instructions de base étaient codées sur deux caractères (ls, vi, ed, df etc.) refusaient tout bonnement de compiler votre code si vous déclariez "main" de la façon suivante : void main(void) ou void main(int argc, char **argv)
Les principales raisons sont :
- Parceque c'est pas standard en C
- Parcequ'un script ou un autre programme n'a aucun moyen de savoir si le programme s'est bien terminé.
- Parceque le système aime bien qu'on lui renvoit un message quand on s'arrète de fonctionner parceque sinon il ne peut pas savoir si c'est le controlleur de processus qui ne se met pas à jour ou si c'est le processus qui ne répond plus.
- En C++ ISO le void main est tout simplement rejeté par le compilo.
Depuis Borland a créé un compilateur C pour dos (le fameux bc1.0). Et sous DOS il y a pas de langage de script à proprement parler, il y a un seul programme et un seul utilisateur à un instant donné et si le programme crashe il y a 99.9% de schance pour qu'il entrainne DOS avec lui.
Dans cette optique Borland c'est dit que void main c'était valable. Et des générations de développeur squi ont découvert la programmation sur le Dos de papa ont utilisé la syntaxe void main. Et certains ont même écrit des livres, en utilisant le void main dans tous les sens.
Seulement voilà, les OS monocouche/monoutilisateur/monoapplication on (heureusement) disparus et les autres ont besoin d'un retour de la fonction main. Windows y compris, en fait avec le nombre de callback et les possibilités d'interactions COM+ windows a absolument besoin d'un retour.
Alors pourquoi déclarer la syntaxe void main comme valide avec tous els dangers que celà représente pour le système ? La réponse est là : http://www.awprofessional.com/articles/article.asp?p=25322&seqN(...)
Tout à la fin de l'article vous verrez : A void return type, paradoxically, internally results in a return status of 0; that is, the execution environment always interprets the program as having succeeded.
Et oui, si vous déclarer void main le compilo transformera celà en int main et renverra toujours 0 (success). Donc :
- Si votre programme crash le système n'en sera jamais informé, toute les protections qui évitent qu'un programme qui crashe soit relancé en boucle indéfiniment deviennent inutiles
- La signature de votre fonction main() est fausse
- Les appels a des objets COM/COM+ ou autres bibliothèques depuis votre programme deviennent indébuggables (difficile de remonter une erreur jusqu'à sa source quand aucune erreur n'est levée) etc.
On peut trouver des excuses totu à fait valable aux gotos aux indirections multiples et enchevétrées, à la reccursivité non terminale cassée à coup de Break et à d'autres sagouineries qui peuvent s'avérer necessaires dans des cas très particuliers. Mais il n'y a aucune excuse pour utiliser void comme type de retour de main. Même dans les langages ou l'utilité d'un int en type de retour est plus discutable (java par exemple) on ne perd pas grand chose à le faire quand même.
Pardon, je n'avais pas vu que le second pro avait été désactivé pour les tests en entier. Par contre les performances ne sont pas forcément croissantes linéairement.
Bon en ce qui concerne le rapport bi-core/HT il est clair que l'on peut difficilement parler de match équitable, ne seait-ce que pour des raisons de bus et de complétude du second core.
Ceci étant il est vrai aussi que les archis privilégiées par IBM pour le calcul lourd sont surtout les POWER (4,4+,5). Donc on peut penser qu'éventuellement le JS20 n'a pas des bus aussi performants que ce qu'IBM peut faire, ceci étant la carte mère Intel est une carte workstation etc.
Le Pentium 4E est légèrement plus puissant en calculs purs que le 4C, ceci est valable aussi pour les entiers (5% de boost de performance à peu près).
Par exemple en entier :
2.80C 1204 1166
2.80E 1269 1219
En ce qui concerne ma remarque c'était juste pour donner un équivalent, elle n'aurait pas été là si j'avais mieux lu le spec et que j'avasi vu le second CPU désactivé sur les tests en entier.
# Une façon simple et efficace
Posté par Jerome Herman . En réponse au journal Distance entre deux images.... Évalué à 7.
Avec la FFTW par exemple. Tu aura ainsi une analyse spectrale pour pas trop cher. Après pour affiner c'est tout un bazard. Ci le but est d'être capable de reconnaitre un paysage de nuit par rapport à un paysage de jour ça ne marche pas du tout.
[^] # Re: Désolé pour les trolls
Posté par Jerome Herman . En réponse au journal La guerre des OS. Évalué à 2.
Il y a donc des _NP à peu près partout, celà signifie juste que la fonction n'est pas standard, et donc qu'elle risque de ne pas se retrouver dans une bibliothèque standard. Typiquement rien ne garantie que l'init de Mutex MUTEX_INIT_RECCURSIVE_NP sera présente dans toutes les bibliothèques Posix Threads, ni même qu'elle aura un comportement similaire si elle est présente.
# Que de souvenirs
Posté par Jerome Herman . En réponse au journal Vous connaissez JavaCard ?. Évalué à 10.
Ca fait longtemps que j'ai pas joué avec ce truc, mais je me souviens à l'époque que pour s'en sortir on avait du passer par l'assembleur java en ecconomisant les registres autant que possible.
Bien entendu pour pouvoir appeler nos fonctions depuis les parties non assembleurs, ou piloter les entrées sorties, il fallait se caler en mémoire avec précision. C'est là qu'intervenanit l'extension (probablement proprio) Low Programming Array (lpa) qui permettait de pointer un octect spécifique et de le changer bit à bit. Cette fonction se trouvait fort logiquement dans le package "bit" de l'extension.
Tous nos fichiers commençaient donc par un beau : import javalpa.bit
Et on parlait sans arrêt de javalpa et de bits dans notre bureau.
C'est impressionant ce que le bureau d'à coté a pu se foutre de nous...
[^] # Re: Désolé pour les trolls
Posté par Jerome Herman . En réponse au journal La guerre des OS. Évalué à 3.
Sous beaucoup d'autres distribs aussi. Sous ma gentoo j'ai mis les deux.
Ce que tu ne veux pas comprendre, est que nptl est compatible linuxthread (sauf quelques cas particulier)
Je l'ai compris il y a bien longtemps. ce que toi tu ne veux pas comprendre est que MySQL utilsie des inits de mutex en _NP qui justement font partis desdits cas particuliers
Je répète, mysql est codé ala linuxthread mais utilise nptl.
C'est faux. L'init de mutex de MySQL force LinuxThread en config standard (ie la config utilisé pour les tests)
Je n'ai jamais dit le contraire. Relis le thread. Je dis qu'il est codé en utilisant les entêtes linuxthread mais qu'il utilise l'implémentation des thread nptl.
Non. Le code d'initialisation des mutex, oblige l'utilisation des bibliothèques linuxthreads. La façon la plus simpel de savori si MySQL utilise LinuxThreads ou NPTL est de compter les process MySQL après lancement du démon. Si il y en a un c'est que les trois threads utilisent le même PID. C'est donc que NPTL a été utilisé, si il y en a trois c'est que LinuxThreads a été utilisé.
C'est comme Gtk. Ton applis peut nécessiter les entêtes Gtk+ 2.0 et ne pas compiler avec Gtk+ 2.6 mais elle peut utiliser gtk+ 2.6 (la librairie binaire, avec un file selector "mignon", etc) et dans ce cas, je dis que l'applis utilise gtk+ 2.6 pour la simple raison qu'elle utilise gtk+ 2.6.
Si tu ne comprends pas ça, je n'y peux rien.
Je ne parle pas des entêtes mais des bibliothèques systèmes. MySQL utilisant des fonctions non portables (ie non présente dans la norme Posix) doit être linké avec linuxthreads pour les versions citées plus haut. MySQL, dans son configure par défaut, a un besoin vital d'uen fonction non posix LinuxThreads qui n'existe pas dans NPTL (ni en réel, ni en interface mappée).
Ici, mysql utilise nptl et est compilé avec les entêtes de linuxthread.
Ca me parait très étonnant. Je veux bien croire que MySQL "Linke" NPTL pour une raison qui m'échappe, mais je ne pense pas qu'il s'en serve (du moins pas MySQL 4.0.22). Au niveau execution LinuxThreads et NPTL sont totalement incompatible et on ne peut donc pas les utiliser simultanément dans un même programme. A mon sens ilf aut compter les process. Si en compilant MySQL 4.0.22 avec un simple ./configure tu arrives à n'avoir qu'un seul process MySQL qui tourne c'est que tu as raison, ton MySQL utilise NPTL. Mais dans ce cas j'aimerais vraiment jeter un oeuil à ta config, parceque c'est théoriquement impossible.
J'ai aucune raison à donner. Mais ce n'est pas une émulation de linuxthread, c'est linuxthread. C'est différent.
Les threads sont créés avec la fonction 'clone' et ca s'arrête là. Tous les signaux systèmes passent quand même par le système natif et doivent être convertis. Le terme d'émulation n'est peut-être pas le bon, on devrait plutot parler d'enrobage (wrapping). Ceci étant les locks de mutex (par exemple, car ce n'est qu'un des quatre ou cinq points qui posent porblème, mais autant garder le même de bout en bout) doivent remonter jusqu'en userspace et redescendre à chaque fois...
soit tu considères que l'implémentation *BSD est plus lente que linuxthread.
Plus lente non, plus problématique oui. Les threads dans FreeBSD sont assez pathétiques. Au final un MySQL compilé avec les options de base met à genoux un FreeBSD très facilement. Le threading sous FreeBSD est faiblard parfois, mais ça n'est pas la question.
Et alors ? C'est toi qui dit que le problême est autour des mutex.
Une fois de plus les mutexs ne sont qu'un exemple. C'est un des mainteneur des ports FreeBSD qui a évoqué que ca pourrait venir de là. Pour une liste de tous les problèmes liés à FreeBSD et la solution :
http://jeremy.zawodny.com/blog/archives/000203.html(...)
http://jeremy.zawodny.com/blog/archives/000264.html(...)
http://jeremy.zawodny.com/blog/archives/000697.html(...)
Je dis juste que le réalisateur du test aurait pu prendre des versions patchées de MySQL pour FreeBSD et que celà aurait rendu le test plus juste. Je ne prétend pas :
- Ni que FreeBSD est meilleur que Linux
- Ni que MySQL Tuné pour FreeBSD est meilleur que le MySQL tuné pour lInux
- Ni que le système de threading FreeBSD est meilleur que LinuxThreads.
Je dis juste que le test n'est pas juste en l'état.
[^] # Re: Désolé pour les trolls
Posté par Jerome Herman . En réponse au journal La guerre des OS. Évalué à 2.
Moi non plus je ne vais pas y passer des plombes.
TOUS les MySQL 4.0.X et les MySQL 4.1.Y avec Y < 8 utiliseront Linuxthreads par défaut si il est disponible.
Pour X<23 MySQL 4.0.X ne compilera même pas. Je parle des MySQL vanilla, à savoir le code source tel qui est fourni par MySQL sur le site MySQL.
Car il n'y a pas de thread du tout pour glibc < 2 et que d'ailleur il n'y a que Linux 2.6 qui fourni des fonctionnalités pour les threads. Les linux plus anciens s'appuient sur clone() et le reste est fait en userland.
J'ai cité la phrase en entier car je n'aime pas les citations partielles à quoi on peut faire dire tout et n'importe quoi. Je la refais plus brutal : Dans le manuel MySQL concernant MySQL 4.0.23 concernant la section "installation Linux à partir des sources" il est écrit :
MySQL uses LinuxThreads on Linux.
Que MySQL sous *BSD est plus lent que MySQL sous Linux.
Donne moi une raison valable, une seule ça me suffit, pour que MySQL sur une émulation de thread Linuxthread sur les threads posix sur les threads Natifs BSD soit plus rapide que MySQL directement sur les threads natifs BSD. Bonne chance. Hint : Les locks et les unlocks de mutexs sont des appels système qui se font forcément en natif.
[^] # Re: Désolé pour les trolls
Posté par Jerome Herman . En réponse au journal La guerre des OS. Évalué à 3.
MySQL le fait( faisait) avec les mutexs pour des raisons de rapidité d'éxecution.
Sous Red Hat/Fedora et depuis RH9 nptl est utilisé par défaut :
Sur toutes les distribution en 2.6 aussi d'ailleurs. mais rien n'empèche de réclamer spécifiquement les LinuxThreads.
Donc, comme je le supposais plus haut, nptl est compatible linuxthread.
Sur les fonctions posix standards oui, sur les autres non. Toutes les initialisation de Mutex en code finnissant par _NP dans LinuxThreads ne sont pas compatibles avec NPTL.
De plus les linuxthreads créent des threads avec chacun leur PID (chaque thread apparait comme un proces), NPTL n'a pas ce défaut.
- linker directement (en dure) avec /lib/i686/ ou /lib (par défaut c'est linké avec /lib/tls).
J'ai dit que l'ensemble des MYSQL 4.x "vanilla" nécessitaient LinuxThreads pour tourner correctement. Apparament depuis la 4.1.8 ce n'est plus le cas. Cependant la 4.0.22 (utilisé dans le test) requiert absolument les Linuxthreads (0.71+). Apparament ce n'est plus le cas pour la 4.0.23 (Test fait sur ma gentoo, noyeau 2.6.9) mais la stabilité n'est pas au rendez-vous. Le manuel d'installation de la 4.0.23 précise d'ailleurs qu'il faut utiliser LinuxThreads cf
http://dev.mysql.com/doc/mysql/en/source-notes-linux.html(...)
MySQL uses LinuxThreads on Linux. If you are using an old Linux version that doesn't have glibc2, you must install LinuxThreads before trying to compile MySQL.
A noter que ceci prouve que
a) NTPL n'est pas 100% retro compatible avec LinuxThreads (4.022 ne passe pas, 4.023 est instable)
b) Les libs linuxthreads sont bien linkées spécifiquement (MySQL 4.0.23 vanilla utilise préférentiellement LinuxThreads)
Donc le test a utilisé linuxthread (entête et librairie) sous Linux alors que nptl est plus rapide que linuxthread.
Pour les locks et unlocks de mutexs (ce qui nous interesse ici) c'est LinuxThreads en mode Mutex rapide qui est le plus rapide. Même si NPTL ets globalement plus performante, il existe encor eun poitn ou deux ou LinuxThreads est plus rapide.
Donc ce test n'a pas "honteusement" favorisé linux comme sous-entendu ici.
C'est pas sous-entendu. C'est affirmé, ave cdémonstration à l'appui. Et il n'y a pas de guillemets autour de honteusement non plus.
De plus le "testeur" c'est fait chié avec freeBSD pour avoir linuxthread (qui est plus rapide que la version native)
Ah bon ? Chez moi c'est installé de base et c'est une option à passer à la compil. Mais bon.
Mais pour en revenir à ta remarque très juste, le testeur démontre avec brio que MySQL->NativeBSD threading est beaucoup plus lent que MySQL->LinuxThreads->Linux-To-PosixMapping->PosixThreads->Native BSD Threading.
Oui parcequ'au final sous BSD, ce sont quand même des threads BSD qui vont être créés.
La première idée qui vient quand on obtient ce genre de résultats est "tiens ils ont codés les threads natifs BSD avec les pieds", celle qui ne devrait jamais venir est "Mon Dieu LinuxThreads et tellement bien que quand on l'utilise en surcouche de surcouche de surcouche de BSD Threadings on gagne des perfs par rapport au natif".
Enfin bon moi je dis çà...
[^] # Re: Désolé pour les trolls
Posté par Jerome Herman . En réponse au journal La guerre des OS. Évalué à 3.
Au 16 juin 2004
We only support Linux glibcs with LinuxThreads for now
as we have experienced server lockups with NPTL.
That's why we check for the string "Linuxthrads" being
present in the header file.
A warning from configure about NPTL not being support
might be better though in this case instead of just
insisting on Linuxthreads.
source : http://bugs.mysql.com/bug.php?id=2173(...)
Sur la version 4.1.7 de MySQL, le bug est toujours actif.
On retrouve pas mal de rapprots de bugs sur NPTL, notamment dans les forums Debian, avec des patches qui ont été inclus dans les paquets standards Debian.
Je ne vois aucune trace de correction de la gestion des threads par defaut dans les changelogs de MySQL (qui sont très succint ). Peut-être que MySQL 4.1.8 et 4.1.9 peuvent linker de façon fiable sur NPTL ....
[^] # Re: Désolé pour les trolls
Posté par Jerome Herman . En réponse au journal La guerre des OS. Évalué à 1.
NTPL et LinuxThreads sont mutuellement exclusifs. On ne peut utiliser qu'un des deux à la fois (notament pour des raisons de gestions des PIDs). Les deux optiosn qui défilent ne font que signifier que le configure a trouvé que le système supportait les PThreads et qu'il a trouvé la bibliothèque LinuxThread.
NTPL n'est jamais utilisé.
[^] # Re: Désolé pour les trolls
Posté par Jerome Herman . En réponse au journal La guerre des OS. Évalué à 4.
Oui mais quand on voit le nombre d'accés en lock et unlock sur les mutexs, ca suffit très largement.
Ce n'est pas la première foi que les *BSD se font "bouffés" par Linux :-)
Certes, mais comme Linux se fait bouffer par MS-DOS c'est pas grave.
[^] # Re: Désolé pour les trolls
Posté par Jerome Herman . En réponse au journal La guerre des OS. Évalué à 2.
MySQL 4.x utilisera systématiquement LinuxThreads sous Linux, et fera appel aux fonction non portables sur les fasts mutexs .
MySQL 5.x par contre a corrigé le tir comme je le disais, et utilisera bien le NTPL
NB : linuxthread (pour les sources et être portable) suit aussi la norme Posix.
Il suffit de regarder le nombre de signaux en _NP (non portable) pour se rendre compte que la norme n'est pas suivi de très très près. Généralement ce sont des ajouts en plsu de la norme, mais dnas le cas des mutexs (pour l'init notamment) il y a des manques.
normalement si l'appli est compilé pour nptl (auto-détection), elle switche automatiquement vers linuxthread si c'est linux 2.4 qui est utilisé.
Certes mais là l'appli est écrite pour linuxthreads à la base. Sinon il n'y aurait aucun problème. Les NTPL Linux sont quasi identiques aux Pthreads natifs BSD (avec quand même un ou deux gags sur l'ordre des bits et les pids parfois).
[^] # Re: Désolé pour les trolls
Posté par Jerome Herman . En réponse au journal La guerre des OS. Évalué à 6.
Et bien réjouis toi, il est possible de tout tester dans le monde des OS. A part l'OS.
Tenter de comparer deux OS revient à peu de choses près à tenter de comparer deux boites à outils. A la question "Quelle est la meilleure boite à outils, celle du maçon ou celle du vitrier ?" la seule réponse possible est "Ca dépend, vous voulez poser des vitres ou ravaler une façade ?"
La première question à se poser quand on veut créer un test est de définir très clairement ce que l'on veut mesurer. La dernière question à s epsoer quand on a fini un test est de comprendre précisément ce que l'on a mesuré.
L'auteur de ce bench part avec l'idée de comparer globalement des OS entre eux (ce qui pour les raisons vus plus haut n'est pas particulièrement pertinent) et fini par comparer les performances ) et fini en comparant le sperformances de MySQL sous différents OS. Au final la question auquel on répond est donc : Quel est l'OS le plus adapté pour faire tourner MySQL sur la config matérielle du testeur'. Et la réponse que l'on obtient n'est pas valable parcequ'une personne qui ferait ces tests dans le but d'utiliser MySQL (typiquement un responsable informatique qui doit prendre une décision système) prendrait probablement des versions compilées/patchées pour tirer parti au maximum du matériel et de l'OS . Ici le testeur prend la version générique qui, pour les raisons vues plus haut, favorise grandement les OS Linux.
Donc a moins d'avoir une bonne raison pour garder la version 'vanilla' (et je n'en vois pas vraiment) le bench n'apporte donc pas grand chose au final.
[^] # Re: Désolé pour les trolls
Posté par Jerome Herman . En réponse au journal La guerre des OS. Évalué à 9.
Les mutexs "rapides" sont une spécificité non portabl des linux threads. C'est une façon de faire qui n'ets pas conforme au standard Posix.
Une façon courte d ete répondre serait la suivante : Sous Linux il n'y a pas 36 façons d'intialiser un mutex et le lier aux fonctions de lock d'un ou plusieurs threads, sous BSD il y en a des quintaux.
Au final sous linux la méthode par défaut est pas très optimisée coté thread masi elle s'appuie sur des spécifité du système Linux qui la rende rapide au final (mais impossible à porter). Sous BSD on a toute la panoplie et on peut régler les Pthreads et les mutexs au millimètre, par contre si on ne fait pas les réglages soit même le système préfère ne pas prendre de risque et utilise des valeurs "passe partout" qui ne sont pas d'une éfficacité redoutable.
Au final MySQL a un comportement très attypique (des locks et des unlocks en rafales en 50) . La politique "safe" de BSD lui retombe donc sur le nez. L'équipe MySQL AB aurait du passer plsu de temps à peaufiner l'utilisation des threads natifs des différents BSD...
[^] # Re: Désolé pour les trolls
Posté par Jerome Herman . En réponse au journal La guerre des OS. Évalué à 8.
Est-ce parceque MySQL n'est que très peu portable et est conçu spécifiquement pour Linux ?
Sans aller jusqu'à dire que MySQL est "optimisé" Linux, on peut dire que les versions de MySQL 1 à 4 ont été concues avec Linux en tête. Lors de la configuration de la compilation MySQL vérifie et éventuellement active tout un tas d'options qui n'existent ou ne sont vraiment efficaces que sous Linux. Celà ne veut en aucun cas dire qu'il n'est pas portable, cleà veut juste dire que si le configure par défaut ne se trouve pas face à un Linux il va se rabattre sur des programmes et des bibliothèques moins efficaces alors que des alternatives BSD existent. Une des exemples les plus flagrants est la gestion des mutexs pour les locks, MySQL génére un grand nombre de locks et de retraits de locks, sous Linux l'impact est quasi-nul car les mutexs créés apr défauts sont en mode "fast" mais sous BSD la méthode employée par défaut oblige le système à rescanner tout le contexte. C'est aussi pour çà que l'on perd des performances lors du passage en multiprocesseur, une partie du contexte est doublé pour que l'on puisse passer le thread d'un CPU à l'autre, mais si il y a un lock sur le thread un seul des deux CPUs peut faire le check du contexte. Moralité chaque "unlock" coute (nombre de CPU)*(overhead du contexte par CPU) en plus. Vu les rafales que balance MySQL ca chiffre très vite.
Il semble cependant que la version 5 cherche à corriger le tir.
Bon même si le bench est foireux par rapport à Linux (j'attends quand même d'autres avis éclairés) on peut comparer les BSD entre eux.
Si tous les mutex par défauts étaient égaux oui. Mais poru avoir uen idée précise il vaudrait quand même mieux remplacer toutes les demandes de créatiosn de mutex par défaut par des demandes de création de mutex "le plus rapide possible" en fonction de l'OS.
# Désolé pour les trolls
Posté par Jerome Herman . En réponse au journal La guerre des OS. Évalué à 10.
While some of the operating systems had precompiled or ready-to-compile BSD ports of MySQL available, many were slightly older versions of MySQL (4.0.20 for example) and compiled with a variety of different options which presented problems with consistency. After all, I'm testing the operating systems, not their pre-packaged MySQL distributions or source builds.
Traduction : alors que certains OS ont des ports BSDs précompilées our prètes à compiler de MySQL disponibles, beaucoup étaient légèrement plus anciennes (4.0.20 par exemple) et compilées avec une variété d'options différentes ce qui posait un problème de cohérence. Après tout je teste les OS et non leurs sources préparées ou leurs paquets MySQL.
En clair ca donne :
J'ai laissé la gestion des threads, des priorités et de la mémoire de base, parceque je trouve çà plus juste et plus cohérent pour un benchmark d'OS.
Au final on se retrouve avec un OS qui a une gestion des threads et de la mémoire adaptée a son fonctionnement (Linux) et les autres qui sont obligés de batailler avec des modes de compatibilté, des couches d'émulation et tutti quanti.
Le simple fait que l'émulation de threads Linux tourne plus vite sous FreeBSD que les threads natifs auraient du mettre la puce à l'orreille.
MySQL est un des ports les plus patchés sous les *BSD. Généralement il y a au moins les MIT-Pthreads sinon l'OS en prend plein la tête au niveau synchronisation des threads.
il y a aussi beaucoup à dire au niveau de la gestion des fichiers partagés en mémoire (mmap et consors) .
Au final la conclusion que l'on peut tirer de ce benchmark est que MySQL via les APIs système "façon Linux" est beaucoup plus rapide sur Linux que sur *BSD. Le contraire eut été surprenant.
[^] # Re: OOo
Posté par Jerome Herman . En réponse au journal MS Access pour linux?. Évalué à 2.
Alors sur une base de données qui supporte les timestamp, les UUID, les randr etc. Utiliser les autoID incrémentaux c'est monstrueux. D'expérience un AutoID sérial ca n'apporte que des ennuis, a partir du moment ou lus d'une personne bosse sur la table à un instant t il faut balancer toutes la gammes des locks et des transactions si on veut pourvoir récuperer l'ID de la ligne que l'on vient de créer.
Donc le "manque" du driver ODBC (qui n'en est pas un vu le fonctionnemetn de Postgres) ne me gène pas du tout, et si çà peut convaincre certains DBD de laisser tomber les Auto-IDs tant mieux.
[^] # Re: SAV phishing?
Posté par Jerome Herman . En réponse au journal SAV Carrefour. Évalué à 2.
En plus si par hasard la personne en face est pas en XP service pack2 on peut même aller decrypter le mot de passe ave cla clef "universelle" pour tous les mots de passe et çà roule, même pas besoin de changer les mots de passe.
[^] # Re: mouarf ...
Posté par Jerome Herman . En réponse au journal Carte d'identité biométrique. Évalué à 7.
1 minute : un verre d'eau
2 minutes : un seau d'eau
3 minutes : une tonne d'eau.
Perdre de précieuses secondes à déplacer et/ou défoncer un véhicule peut avoir un impact fort sur la façon dont l'incendie se développe.
# En attendan tla modération de mon message...
Posté par Jerome Herman . En réponse au journal Carte d'identité biométrique. Évalué à 10.
Bonjour,
L'identification unique et certaine d'un individu et des droits qu'il possède est une arme à double tranchant. D'un coté elle permet d'assurer la protection et l'accès au service des ayants droits. D'un autre elle peut créer des clivages forts entre ceux qui peuvent montrer patte blanche et ceux qui ne peuvent pas. Il est donc très important de savoir qu'elles informations sont stokées, ou elles sont stockées et comment elles sont certifiées.
Je me permet de livrer çi dessous la liste des éléments nécessaires à un fonctionnement sain de cette carte.
- Qualité de l'authentification :
La photo d'identité et une ou plusieurs empreintes digitales ne sont pas des informations fiables. Même l'empreinte rétinienne, considéré longtemps comme "sure" montre aujourd'hui de nombreuses faiblesses.
L'authentification par "Je suis" I.E une analyse purement physique et non interactive d'un individu (apsect, taille, empreinte dentaire, implantation capilaire, empreintes digitales etc.) est un plus mais ne saurait constituer un tout. Une authentification supplémentaire par code ("Je connais") ou mieux par signature physique classique ("Je sais faire") est absolument nécessaire pour s'assurer non seulement de l'identité de la personne, mais aussi de son accord à la procédure en cours.
- Informations en circulation
La carte d'identité numérique permettra pour les démarches administrative une identification complète de façon à faciliter et accélerer lesdites démarches.
Mais il est très important que les tiers non ratachés à l'état ne puissent pas accéder à l'ensemble des informations, notamment dans le cas de tiers marchands (banques, commerces, fournisseurs de services etc.) Dans cette optique il appartient au gouvernement de définir avec soin secteur par secteur et activité par activité à quelles informations un tiers peut prétendre avoir accès pour ses besoins d'identification. La reservation de places de théatre ne nécessite pas par exemple pour le commerçant de connaitre mon lieu de naissance, mon age ou mon lieu de résidence. Ces informations ne doivent donc pas être transmises, le cas contraire pourrait entrainner un mécanisme de ségrégation extrèmement puissant et très difficile à démonter, les personnes trop jeunes, trop vieilles ou trop epu rentables commerciallement seraient alors redirigées vers des offres moins attractives voire ignorées.
- Indépendance des identifications
Il est important pour les raisons vues plus haut, que les informations fournies soient aussi limitées que possible. Dans cette optique deux options sont possibles :
1) Une simple certification des informations : je continue à saisir l'ensemble des informations que je dois transmettre moi même , celle ci sont ensuite passées par un hash (filtre mathématique non inversible) et comparées au hash de l'information de la carte. De cette façon le serveur d'authentification ne dispose d'aucune information exploitable et ne peut que confirmer ou infirmer la validité des informations saisies par le porteur de carte.
2) Les données réelles existent (stoquées sur la carte ou sur un serveur distant) et sortent spontanément de la carte à la demande du porteur. Dans ce cas là il est très important tout d'abord que l'ensemble des données transmises à la personne requérant une identification soient aussi réduites que possible (cf plus haut), et que l'ensemble des données transmises ne soient ni interceptables ni modifiables ni copiables par un tiers. Et bien entendu il faut éviter que qui que ce soit puisse enregistrer le processus d'identification pour le reproduire par la suite.
Dans les deux cas il est important que l'ensemble des étapes qui composent le processus d'identification soient validées par des tiers de confiance.Hors qui dit tiers de confiance dit dépendance à un tiers. Il faut bien alors prendre conscience du pouvoir dont disposerait un tel tiers si il était malveillant et en situation monopolistique. Il pourrait simplement rendre imposssible l'utilisation de la carte d'identité numérique à qui il voudrait. Le piège vient du fait que si l'on essaye de pennaliser un coportement arbitraire vis à vis des identifications, on risque de se retrouver ave cune gestion laxiste des authentifications. La seule solution pour éviter l'épineux problème l'équation : abus de pouvoir ou laxisme est la suivante;
- Tout d'abord rendre l'ensemble des principes d'authentification public, et spécifier publiquemet les critéres de validité d'une authentification.
- Ensuite multiplier autant que possible le nombre des tiers de confiance de façon à éviter qu'une défaillance ou une malveillance de l'un des tiers n'empêche une personne de se servir de sa carte pendant une durée inderterminée.
Pour les mêmes raisons, il est important que le nombre de fournisseurs de puces soit aussi élevé que possible et que les caractéristiques des puces soient publiques.
- Cohérence des identifications
Quelque soit le système biométrique ("je suis") ou technométrique ("je sais faire") mis en place, il est important de prévoir dès aujourd'hui un mécanisme de secours en cas d'impossibilité d'authentification. Une personne qui a perdu son pouce dans un accident a autant besoin qu'un autre (voir plus au début compte tenu des démarches qu'impliquent un accident) de prouver son identité. Il faut donc que l'on puisse rapidement changer le mode d'authentification. Les problèmes sont que
a) la rapidité nécessaire de ce changement ne doit empiéter ni sur la fiabilité de la carte ni sur son utilisabilité.
b) il faut pouvoir propager aux tiers de confiance le changement de mode d'authentification de façon fiable et rapide.
Hors la personne qui vient de subir cet accident n'est plus en mesure de prouver son identité "facilement". Il appartient donc à l'état de garder sur l'ensemble du territoire des structures d'accueil classiques et efficaces à même de prouver l'identité de tel ou tel personne.Sans ces structures la personen accidentés devrait alors surmonter un double handicap, tout d'abord celui lié à l'accident lui même et ensuite celui lié à une société dans laquelle la carte dont il ne peut plus se servir serait devenue obligatoire pour toute transaction commerciale.
Cordialement.
[^] # Re: Super
Posté par Jerome Herman . En réponse au journal Carte d'identité biométrique. Évalué à 6.
Et la detection du flux sanguin ne change pas grand chose dans ce cas là.
(N.B : Pour les malfaiteur en herbe, çà ne marche pas avec un gant latex, il faut un autre plastique qui resiste mieux à la pression. Mais l'idée générale est là)
# I Might be wrong
Posté par Jerome Herman . En réponse au message problème installation mdk 10.1. Évalué à 2.
So let us try in english.
From what I understood (more like decypher, translation programs are way overrated) :
- You boot MDK 10.1 from you CD-Rom
- At some point Mandrake Installer tells you that it can't access the CD-Rom Drive and that it needs drivers to do so.
- Then it keeps asking for the drivers and the parameters of your CD-Rom.
This could com from a lot of different issue. Hopefully you should be able to sort it out easily enough.
What is likely to happen is one of the following :
- Your CD-Rom is connected through USB and Linux kernel can't seem to find it
- Your CD-Rom is connected through SCSI and Linux kernel can't seem to find it
Your CD-Rom is connected through SATA and Linux kernel can't seem to find it
So basically you need the driver of whatever peripherial your CD-Rom is connected to.
First thing to test is alternate kernels . If my memory is OK, you should be able to select between a 2.4 and a 2.6 kernel at boot . Try them both, chances are high that one of them is working.
If not, try them both again but adding -noapic -noacpi on the same line (should be something like boot : mdk2.6._xxxx -noapic -noacpi the bold part being what you type)
If none of this works, you will indeed need the drivers. There only the manufacturer and Google can help you.
Hoping you speack english
[^] # Re: On va encore dire que je suis un raleur mais...
Posté par Jerome Herman . En réponse au journal Des nouvelles de Gnome. Évalué à 2.
Oui mais le fait est qu'encore moins de personnes prennent le temps de trapper toutes les erreurs, ou de renvoyer une erreur explicitement, dans ce cas le code erreur du main est toujours bon à prendre.
alors autant laisser le compilo mettre la BONNE valeur par défaut, plutôt que de forcer le noobs à renvoyer une valeur,
Le compilateur ne fera pas un programme à ta place. Il forcera une sortie système à 0, ce qui ne veut rien dire d'autre que 'le programme s'est executé correctement' . Maintenant uen fois de plus ce n'est pas parceque le programme ne génère pas d'exceptions qu'il s'est executé correctement, mais là il n'y a que le programmeur qui peut savoir que quelque chose c'est mal passé. Charge à lui soit de créer et de lever une exception pour chaque erreur, soit de passer un paramêtre pour que le programme se termine correctement et renvoit un entier.
Créer des exceptions pour chaque cas est la solution la plus propre, mais trapper toutes les erreurs possibles peut être fastidieux et particulièrement lent.
... pourrait très bien s'amuser à mettre return 1 (c'est vrai pourquoi return 0 ?)
Le 0 est horriblement pratique ca permet de faire le test d'erreur, le renvoit d'erreur et le numéro d'erreur dans une seule instruction.
par exemple
if (!erreur) traiteerreur(erreur);
On utilise le 0 comme un false et hop le tour est joué.
Celui qui sait ce que ca fait met une valeur de retour s'il en a envie, je vois vraiment pas où est le problème.
Manifestement il doit quand même y en avoir un, sinon pourquoi le compilateur s'amuserait-il a transformer la signature de la fonction pour renvoyer un entier quand même. Et quitte à avoir un entier renvoyé quoi qu'il arrive autant
a) ecrire le code de façon à se que ce renvoit d'entier soit visible
b) utiliser ce renvoit d'entier pour transporter une info (autant en profiter) plutôt que de renvoyer 0 à chaque fois.
c) Il n'est pas improbable (surtout vu l'intégration de C# avec COM+) que votre programme C# soit un jour utilisé via un script WSH sous windows. Dans ce cas là, retourner un entier est une très bonne chose.
[^] # Re: On va encore dire que je suis un raleur mais...
Posté par Jerome Herman . En réponse au journal Des nouvelles de Gnome. Évalué à 2.
Une terminaison anormale d'un rpogramme ne veut pas forcément dire qu'une exception a été retournée et remontée jusqu'à la VM. En Java celà s'apelle un code rouge. Un exemple simple est quand suite à une destruction un peu trop hative de certains objets on se retrouve à "perdre" des objets fondamentaux à l'execution du programme. Dans 99,99% des ca son va remonte rune erreur, mais j'ai eu le cas d'un programe qui donait toute les apparences de s'executer proprement mais qui en fait se vautrait à un moment, perdait la procédure de boucle et se fermait (nettoyage par le garbage collector des objets inateignable) en apparence proprement.
Je pense qu'un cas similaire peut être codé en .Net pour peu que l'on se penche un peu sur le problème.
mais le code C# ou Java est censé être indépendant de ces considérations de "bootstrapping" visant à intégrer l'exécutable dans son environnement.
En théorie c'est vrai pour Java, en pratique quand on veut faire dialoguer deux threads ou deux processus il y a des fois on a des surprises d'une VM X sur un système x86 à la même VM X sur un système Solaris (vécu inside) . La plupart de ces problèmes ont étés plus ou moins résolus aujorud'hui. Mais de temps en temps ca ressurgit.
Par contre C# est indépendant de la plateforme, mais surement pas du "COM WRAPPER". Comme tu le dis si bien C# a été conçu pour s'intégré très bien avec les objets COM, pour peu que l'on utilise le wrapper par défaut de Microsoft.
Mais même si l'on utilise le wrapper Microsoft on peut avori des surprises. J'ai eu deux collègue squi se sont arrachés les cheveux pendant des semaines sur un programme qui appelait un objet COM en call-back pour les tests d'appoints, mais qui était appelé en natif par l'objet COM lors du fonctionnement normal. Dans ces cas là la déclaration des fonctions compte ennormément, or une des fonctions (pas main, le connecteur base de données) avait deux signatures différentes suivant que l'objet COM appelait le programme ou l'inverse.
Au final il leur a fallu un bon moment pour comprendre pourquoi quand ils utilisaient les fonctions pour tests d'appoints le wrapper finissait par partir en vrille au bout d'un moment.
Je ne connais pas avec précision leur qualité en tant que devoleppeur, et donc je ne peux pas dire si ils ont commis une erreur de débutant ou non. Mais je sais que les objets COM 1.5 ont des procédures d'appels et de référencement très bas niveau, et que si on arrive à gruger le wrapper, on finira par avoir un chouette bazar parceque si le wrapper dit oui, dérrière on attaque le système direct.
Personellement même en Java je fais des "public static int main" ca ne coute rien et c'est utile plus souvent qu'on pourrait le penser.
[^] # Re: On va encore dire que je suis un raleur mais...
Posté par Jerome Herman . En réponse au journal Des nouvelles de Gnome. Évalué à 4.
Tout d'abord commençons par un petit résumé des épisodes précédents :
Jusqu'à ce que Borland décide de créer un compilateur C tous les compilateurs du monde sortait une erreur ou au moins un warning grave quand on avait le malheur d'oublier de mettre le type de retour de la fonction main.
Les compilateurs UNIX créés à des époques ou la mémoire valait une telle fortune que toutes les instructions de base étaient codées sur deux caractères (ls, vi, ed, df etc.) refusaient tout bonnement de compiler votre code si vous déclariez "main" de la façon suivante :
void main(void) ou void main(int argc, char **argv)
Les raisons sont multiples. On peut en trouver un certain nombre par ici : http://users.aber.ac.uk/auj/voidmain.shtml(...)
http://www.delorie.com/djgpp/v2faq/faq22_25.html(...)
Les principales raisons sont :
- Parceque c'est pas standard en C
- Parcequ'un script ou un autre programme n'a aucun moyen de savoir si le programme s'est bien terminé.
- Parceque le système aime bien qu'on lui renvoit un message quand on s'arrète de fonctionner parceque sinon il ne peut pas savoir si c'est le controlleur de processus qui ne se met pas à jour ou si c'est le processus qui ne répond plus.
- En C++ ISO le void main est tout simplement rejeté par le compilo.
Depuis Borland a créé un compilateur C pour dos (le fameux bc1.0). Et sous DOS il y a pas de langage de script à proprement parler, il y a un seul programme et un seul utilisateur à un instant donné et si le programme crashe il y a 99.9% de schance pour qu'il entrainne DOS avec lui.
Dans cette optique Borland c'est dit que void main c'était valable. Et des générations de développeur squi ont découvert la programmation sur le Dos de papa ont utilisé la syntaxe void main. Et certains ont même écrit des livres, en utilisant le void main dans tous les sens.
Seulement voilà, les OS monocouche/monoutilisateur/monoapplication on (heureusement) disparus et les autres ont besoin d'un retour de la fonction main. Windows y compris, en fait avec le nombre de callback et les possibilités d'interactions COM+ windows a absolument besoin d'un retour.
Alors pourquoi déclarer la syntaxe void main comme valide avec tous els dangers que celà représente pour le système ? La réponse est là : http://www.awprofessional.com/articles/article.asp?p=25322&seqN(...)
Tout à la fin de l'article vous verrez :
A void return type, paradoxically, internally results in a return status of 0; that is, the execution environment always interprets the program as having succeeded.
Et oui, si vous déclarer void main le compilo transformera celà en int main et renverra toujours 0 (success). Donc :
- Si votre programme crash le système n'en sera jamais informé, toute les protections qui évitent qu'un programme qui crashe soit relancé en boucle indéfiniment deviennent inutiles
- La signature de votre fonction main() est fausse
- Les appels a des objets COM/COM+ ou autres bibliothèques depuis votre programme deviennent indébuggables (difficile de remonter une erreur jusqu'à sa source quand aucune erreur n'est levée) etc.
On peut trouver des excuses totu à fait valable aux gotos aux indirections multiples et enchevétrées, à la reccursivité non terminale cassée à coup de Break et à d'autres sagouineries qui peuvent s'avérer necessaires dans des cas très particuliers. Mais il n'y a aucune excuse pour utiliser void comme type de retour de main. Même dans les langages ou l'utilité d'un int en type de retour est plus discutable (java par exemple) on ne perd pas grand chose à le faire quand même.
# On va encore dire que je suis un raleur mais...
Posté par Jerome Herman . En réponse au journal Des nouvelles de Gnome. Évalué à -3.
public static void main
Et là d'un coup beurk...
Voilà. C'est tout.
[^] # Re: ???
Posté par Jerome Herman . En réponse au journal The Cell : révolution en vue !. Évalué à 1.
Bon en ce qui concerne le rapport bi-core/HT il est clair que l'on peut difficilement parler de match équitable, ne seait-ce que pour des raisons de bus et de complétude du second core.
Ceci étant il est vrai aussi que les archis privilégiées par IBM pour le calcul lourd sont surtout les POWER (4,4+,5). Donc on peut penser qu'éventuellement le JS20 n'a pas des bus aussi performants que ce qu'IBM peut faire, ceci étant la carte mère Intel est une carte workstation etc.
Le Pentium 4E est légèrement plus puissant en calculs purs que le 4C, ceci est valable aussi pour les entiers (5% de boost de performance à peu près).
Par exemple en entier :
2.80C 1204 1166
2.80E 1269 1219
En ce qui concerne ma remarque c'était juste pour donner un équivalent, elle n'aurait pas été là si j'avais mieux lu le spec et que j'avasi vu le second CPU désactivé sur les tests en entier.