boubou a écrit 1384 commentaires

Tu as toi même tout dit : le problème avec les engagements sur des dates, c'est qu'ils sont toujours un peu fantasque. Alors on peut se demander s'il ne vaut pas mieux être en retard sur une date et avoir un produit stable que le contraire.

Pour les gens qui lisent en diagonale : je ne dis pas que la 8.1 de Mandrake n'est pas stable, je ne les soupçonne par tenir les dates plutôt que la stabilité, etc. Je constate simplement que dans le monde commercial, il faut tenir les dates et que cela entraine des contraintes délicates.

Ba si, Hyperion c'est bien le père du soleil, cf http://www.theoi.com/Ouranos/Hyperion.html(...)

Il y a des citations très claires, par exemple From Hyperion and Aethra [were born]: Sol [Helios], Luna [Selene], Aurora [Eos]."

Appolon (Appolo en grec) est le dieu de la musique , de la médecine et des prophécies. C'est effectivement un des nombreux fils de Zeus.

Le dieu du soleil, c'est helius (helios en grec).

Ouai, c'est ça, t'as tout compris.

Hyperion, c'est déjà le nom de plein de trucs :

- à la base, c'est le nom du père du Soleil dans la mythologie grecque (c'est un des titans)

- c'est aussi un poème de John Keats (http://www.library.utoronto.ca/utel/rp/poems/keats11.html(...) )

- une lune de Saturne (http://seds.lpl.arizona.edu/nineplanets/nineplanets/hyperion.html(...) )

- un logiciel de stats financière (comme tu le dis, cf http://www.hyperion.com/(...) )

- un superbe roman de Dan Simmons (prix Hugo 90)

- etc.

bref, c'est un mot cool, alors bon...

Je te donne acte que la présentation actuelle du produit par redhat fait bien apparaître en position claire et nette PostgreSQL (cf http://www.redhat.com/software/database/(...) puisque tu le demandes). Tu me permettras quand même de douter du bien fondé de l'appelation Red Hat Database pour la boite comme tu appelles leur "solution complète". Je trouve que cette appelation est quand même pas mal fallacieuse.

Pour mémoire, la press release (http://www.businesswire.com/cgi-bin/f_headline.cgi?bw.081301/212252(...) ) qui annonçait "Red Hat E-Commerce Suite" parle de "Red Hat Database, an open source database solution based on PostgreSQL 7.1 and optimized for Web applications and Red Hat Linux 7.1". Je trouve ça un peu limite. J'aimerais bien savoir combien de lignes de code RedHat a contribué à PostgreSQL. Immagine que je distribue un rpm de PostgreSQL appelé Boubou Database, based on PostgreSQL 7.1, tu dirais quoi ?


Franchement, je n'ai rien contre Red Hat. Je trouve qu'ils ont fait de bonnes choses pour Linux (oups, GNU/Linux). Je trouve simplement qu'ils sont un peu à la limite sur ce coup là.

.. c'est le pipotage de certains guru du C/C++ ou des ultra-puristes de la GPL (RMS en tete) qui tirent à boulet rouge sur tout ce qui n'as pas la couleur de la GPL alors que Java et la GPL on exactement la meme cible : faire un monde plus ouvert :(

C'est marrant ça, j'étais sûr que Sun avait historiquement poussé Java pour niquer Microsoft. On m'aurait menti ? Ces braves gens de chez Sun voulaient donc le bien de l'humanité ?

Ca m'atriste de voir tant d'articles incomplets et peu precis sur java, au mieux le traitant comme un simple nieme langage (et oubliant meme les concepts de la plateforme java)

Et oui, mesdames et messieurs, car Java (tm) n'est pas un langage, c'est une révolutionnaire PLATEFORME (et oui !) !!!! Trop puissant (note : PLATEFORME est le nouveau nom de api (et oui, c'est vachement plus classe (classe, Java (tm), ah, ah, ah))). D'ailleurs personne n'avait inventé avant le concept de bytecode (ni celui de PLATEFORME, on disait stupidement api, comme des cons). Par exemple Caml (http://caml.inria.fr/(...) ) n'a jamais compilé sur une machine virtuelle avant l'extraordinaire découverte (une première galactique, il faut le rappeler) par les ingénieurs de Sun (tm) du concept sus-mentionné. D'ailleurs Caml (qui est n'est pas open source, au contraire de Java (tm)) a tellement de retard sur les génies de Sun (tm) qu'il n'existe pas de compilateur natif Caml. D'ailleurs le compilateur natif Caml (qui n'existe pas) ne fait pas de inlining. Ce qui fait que s'il existait, de toute manière le code engendré serait tout pourri. D'ailleurs le leader de Caml (Xavier Leroy) est un naze, il ne sait pas programmer et ce n'est pas lui qui a implanté les threads linux.

Et hop.

PS : Xavier tu es un dieu, je te jure que c'est une blague foireuse.

En effet, classpath existe, mais ils disent eux-même qu'il est peu probable qu'ils arrivent un jour à tout programmer. De plus, pour la partie swing, ils sont très très loin d'avoir atteint quelque chose d'utilisable. Donc pour l'instant, Java n'est pas libre. Point.

Quant aux specs publiques, bof, bof. Je te rappelle que la certification ISO de Java a été interrompu par Sun, pour des raisons étranges. Pour l'instant, C++ comme d'autres langages (C, Ada, etc.) est basé sur une norme ce qui le rend beaucoup plus "libre" et publique que Java qui reste contrôlé par une seule entreprise (cf les histoires aux sujets de l'API de logging au sujet de laquelle une news était passée ici).

Petite note : je ne programme presque qu'en Java et je trouve le langage parmi les plus avancés actuellement. Ce n'est pas une raison pour être aveugle.

Bravo pour les arguments puissants du genre "Je t'en veux pas car 50% des personnes qui sont "contre java" n'ont en general pas depassé le niveau des concepts du langage". Guillaume, à qui tu réponds directement, et moi, à qui tu réponds indirectement, ne sommes pas trop nul en Java (et nous ne sommes pas contre Java non plus), ça va. Pour ma part, j'enseigne Java depuis 4 ans, j'ai été pionnier à Dauphine pour l'enseignement de Java comme premier langage et j'ai écrit une sorte de bouquin sur l'apprentissage de Java (cf http://docs.ufrmd.dauphine.fr/java/(...) ). Pour les lecteurs normaux, je sais bien que tout le monde s'en fout et que ça ne donne pas beaucoup de poids à mes arguments, mais bon, les attaques foireuses de ce genre sont pitoyables.

Surtout quand elles sont suivies d'une confusion totale entre la machine virtuelle Java et le langage Java. Tout le monde sait, cher posteur, que de très nombreux langages peuvent être compilés en byte-code de la JVM. Il y a même un site consacré à ça http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html(...)

Mais bon, quel rapport avec bilou et en quoi ce fait apporte-t-il quelque chose à la discussion sur les performances de Java ?

Rajoutons maintenant une couche sur le reste (le post de guillaume est pas mal du tout, mais bon).

Ton argument sur le serveur est complètement débile. Outre les avantages cités par Guillaume, il y a aussi le fait que JIT est particulièrement bien adapté à un programme serveur qui tourne des jours et des jours sans s'arrêter. L'asect très dynamique de Java (chargement au vol d'une nouvelle version d'une classe + JIT) étend encore les possibilités côté serveur. Bref, aucun rapport avec la facilité d'installation d'une JVM (un clic sous windows, un tar ou rpm sous linux).

Pour l'histoire de la généricité, effectivemment, ça fera partie de Java (dans le futur), mais malgré certains avantages par rapport au C++ (polymorphisme contraint), il reste un fait puant : on ne pourra pas utiliser le polymorphisme pour les types fondamentaux. Le plus dingue dans cette histoire, c'est que pizza (http://pizzacompiler.sourceforge.net/(...) ) implante la généricité en Java depuis des années, de même que GJ (http://lampwww.epfl.ch/pizza/gj/(...) ), qui a d'ailleurs servi de base à la proposition qui sera intégrée dans 1.5. Tu te rends compte qu'il y avait une implantation de ces concepts dès 1996 et qu'il faudra attendre 6 ans avant que ça marche ! Franchement, si tu appelles ça de la réactivité...

Comme le disais Guillaume, il manque de plus d'autres choses en Java, comme :

- la surcharge d'opérateur
- l'héritage multiple (si tu viens me chercher avec les interfaces, tu te prends une claque)
- les classes à sémantique valeur (en plus des classes à sémantique référence)
- etc, je suppose.

Il faut apprendre à lire.

- "run natively" ça veut dire compilé, pas interprété. Tu peux raconter tout ce que tu veux sur le JIT, etc. il n'empêche que swing ça rame (vu le nombre couches, c'est pas étonnant). Qt est compilé... Pour le reste sur swing, on est d'accord, c'est sûrement la plus belle bibliothèque de fenêtrage actuelle. Mais bon, ça rame...

- "There are speed and memory issues associated with Java"

Sur le fond, il a raison. Quand tu démarres une JVM, c'est obligatoirement gros actuellement (genre une dizaine de mo). Quand tu crèes un objet, ça prend plein de place mémoire (de l'ordre de 16 octets par objet vide avec le jdk 1.3 de sun sous linux), etc. Si tu codes comme en C, avec une bonne JVM, ça va presque aussi vite que du C, parfois plus vite. Par contre, dès que tu codes vraimebt objet, C++ reste meilleur sur de nombreux points, par exemple parce que l'overhead mémoire est plus faible et parce qu'on peut passer les objets par valeur, et qu'on peut inliner les méthodes.

- swing n'est pas libre, bordel !!!!!!!!!

Et où en serait KDE sans Qt ? Franchement ?

Je pense qu'ils ont effectivement attendu que le retard soit trop grand, mais pas en terme de programmation, en terme d'image. Qui s'amuserait maintenant à aller utiliser Glurf-qt, le fork du sympathique groupe de hackers coréens ? TrollTech avais aquis avant de passer en GPL une image d'excellence technique que personne ne cherche à remettre en question. En ce sens, ils n'ont plus qu'à craindre eux-mêmes (une baisse de qualité par exemple).

Pour prendre un exemple dans l'autre sens, que penser de l'attitude de RedHat avec postgesql. Ils reprennent la bête et la vendent sous un autre nom. C'est quand même fort, dans le genre...

C'est déjà intégré depuis KDE 2.2 (cf http://www.kde.org/announcements/announce-2.2.html(...) )

D'après LWN (cf http://lwn.net/2001/0607/kernel.php3(...) ), The response from the kernel hackers so far has been "make sure your swap area is at least twice as large as the amount of RAM in the system.", ce qui veut dire en gros que les développeurs du noyau recommandent fortement d'avoir deux fois plus de swap que de RAM.

Autre source : http://kt.zork.net/kernel-traffic/kt20010330_113.html#6(...) avec des explications de Rik Van Riel himself. En gros, le code de récupération des zones non utilisées du swap a été supprimé sur 2.4 et donc, il faut respecter la règle du 2 fois la RAM.

Ce n'est pas complètement du troll, malgré la grammaire délirante du Nota. Les LWN notaient depuis la sortie du 2.4 qu'il restait de nombreux problèmes liés à la gestion de la mémoire virtuelle, par exemple pour l'algorithme de aging (calcul de l'age des pages qui permet de savoir quelle page on va virer quand le besoin s'en fera sentir), cf http://lwn.net/2001/0906/kernel.php3(...)

Il y avait aussi des problèmes avec l'algorithme qui temporise les écritures sur disque (le cache disque, quoi) qui a visiblement des intéractions subtiles avec la VM (http://lwn.net/2001/0809/kernel.php3(...) ).

Il semblerait bien que pas mal de gens râlent à mort sur la VM depuis le début du 2.4 puisqu'un des développeurs s'est senti obligé de pondre une explication sur les buts de la VM (http://lwn.net/2001/0628/kernel.php3(...) ). Un résumé des problèmes avait été posté fin mai sur lwn (http://lwn.net/2001/0531/kernel.php3(...) ).

A mon avis, l'idéal pour comprendre les problèmes de VM sous linux est de lire l'article du hacker de choc Rik van Riel : http://www.surriel.com/lectures/linux24-vm.html(...)

D'ailleurs, pour vraiment suivre l'actualité de la gestion mémoire sous linux, le mieux est sûrement d'aller fouiner sur le site qui lui est consacré http://linux-mm.org/(...)

Si on résumé, le noyau 2.2 marchait plutôt pas mal, mais il y avait visiblement des problèmes de montée en charge et de gestion des grosses mémoires. Certaines modifications ont été faites pour améliorer tout ça dans le 2.4, ce qui a produit un noyau moins bon pour la gestion mémoire au début. Normalement, le noyau actuel marche aussi bien que le 2.2, mais sans avoir les problèmes répérés dans ce-dernier, ce qui signifie que le 2.4 devrait marcher aussi bien et parfois mieux en toutes circonstances.

Loin de moi l'idée de comparer les 5000 personnes qui n'avaient rien demandé à personne et qui sont mortes à cause des attentats. On peut dire tout ce qu'on veut contre l'armée américaine, le gouvernement, etc. rien ne peut minimiser la tragédie de New York (pour Washington, c'est quand même autre chose).

Je trouve juste dommage qu'on réponde un peu n'importe quoi à un post plutôt drôle et pas trop idiot. Il est vrai que les gens relativement formés savent que le tabac est très dangeureux, mais il est quand même consternant de voir que les moyens mis en oeuvre pour lutter contre le tabac restent assez limités, en particulier au niveau de la contre-propagande (parce que quand tu regardes autour de toi, tu remarques qui finalement, peu de personnes ont conscience du danger).

Le problème avec certains lecteurs de linuxfr, c'est qu'ils ne savent même pas se servir de google. En cherchant un peu, on peut facilement trouver le site web de l'oms (le who) destiné spécialement au tabac (http://tobacco.who.int/(...) ). Sur ce cite, on trouve divers rapports qui indiquent par exemple que le tabac est responsable de la mort de 1.2 millions de personnes par an en europe (le continent, pas la EU), soit 14% des morts (cf http://tobacco.who.int/en/statistics/Summaries\EURO.pdf(...) ). Aux USA, l'estimation donnait environ 500 000 morts par an à comparer à 2 300 000 morts au total. Pour la France 60 000 morts en 95 (500 000 au total).

Et oui, le tabac, c'est bien plus grave que le terrorisme en terme de nombre de morts. Mais bon, Bush ne va quand même pas être méchant avec de gentilles entreprises qui gagnent plein d'argent légalement.

On est d'accord sur les capacités humaines, en particulier la reconnaissance basée sur très peu d'information. Cependant, France Info n'est très certainement pas une source valide pour des informations scientifiques. Pour répondre à leur objection, il suffit d'avoir plusieurs versions d'un même visage. Si un dispositif est capable de reconnaître un visage, il te reconnaîtra avec ou sans barbe, à partir du moment où il possède des photos de toi avec et sans barbe (on peut fabriquer des trucs approchants avec des logiciels de retouche et un bon dessinateur).

La vraie difficulté, c'est qu'il existe des techniques de déguisement assez balaises (genre masque latex pour modifier certains traits caractéristiques comme la forme du nez ou la hauteur des pomettes). Il suffit de voir ce que les maquilleurs de cinéma peuvent faire.

J'amerais savoir ce que vient faire l'homophobie dans ce débat scabreux.

Quand tu poses un dissipateur thermique tu augmentes considérablement la surface d'échange avec l'air et la température se reduit donc très rapidement (sans compter qu'il y a un tansfert thermique très rapide entre le CPU et le radiateur, car le gradient de température est très élevé au départ et que le métal conduit très bien la chaleur). Donc ce n'est pas si délirant que ça.

L'architecture flottante des x86 est peut être pourrie, mais les procs récents permettent d'utiliser des long doubles à la place des doubles, avec un coût identique, ce qui n'est pas le cas des Power PC, par exemple (ni des sparcs, il me semble). Tous les numériciens sont d'accord pour dire que la précision des calculs est améliorée par le passage systèmatique aux long doubles (contrairement à certaines rumeurs débiles, il est toujours profitable de faire le calcul avec le plus de chiffres significatifs possible). De ce fait, mais si sur le papier les Power PC sont plus efficaces que les x86, il n'en reste pas moins que ces derniers sont beaucoup plus adaptés au calcul en haute précision.

Faux. La diode des nouveaux core ne réagit pas assez rapidement. De plus, contrairement aux CPU intel, elle demande un support par la carte mère. C'est BEAUCOUP moins bien que chez intel.

C'est quoi le rapport entre RISC et course au MHz. Parce qu'il me semble justement que plus le processeur et simple, plus il peut tourner vite, et que, justement, le but du RISC est de produire des processeurs plus simples.

De plus, les CPU modernes sont de plus en plus RISC, au sens ou la compatibilité avec le jeu d'instruction x86 est maintenu par interprétation de micro-code sur un noyau relativement simple. L'ajout des instructions MMX, etc. répond à un véritable besoin : améliorer les performances de certaines applications (MPEG, calculs 3D), exactement comme on a maintenant des cartes graphiques qui font de plus en plus de chose en hardware (idem pour les cartes son). Il existe des bilbiothèque de calculs matriciels qui utilisent les trucs genre 3DNow et permet moi de te dire qu'elles torchent grave. J'aimerais bien voir ce que le RISC peut faire contre ça.

Bref, j'aimerais bien qu'on m'explique en quoi le RISC c'est super mieux que le CISC, avec des références et des arguments.

Sauf que ça, mon cher Yeupou, c'est la théorie. Parce que si tu avais lu l'article, tu aurais remarqué que l'Althlon MP est équipé d'une diode thermique. Cette diode doit être lue par la carte mère qui doit réagir (c'est moins bon qu'Intel, mais c'est dans les specs). D'après Siemens (le fournisseur de la carte mère utilisée dans le test), leur carte fonctionne parfaitement. Il semblerait que la diode thermique de l'Althlon MP ne soit pas capable de réagir assez rapidement pour empêcher le processeur de griller. Je ne sais pas qui baratine, mais c'est quand même les boules : le CPU grille en une seconde !

Et oui, lire l'article avant de râler, c'est mieux.

Ultrapuissant comme argumentation. Vraiment, je suis impressionné.

Pour les gens qui veulent des trucs sérieux, je conseille l'extraordinaire citeseer (http://citeseer.nj.nec.com/(...) ) qui permet de faire des recherches et des analyses de citations sur des articles scientifiques (et pas sur des commentaires totalement vides d'anonymes).

Tout d'abord, il faut savoir que la détection de visages dans une image est à un stade très avancé, justement en utilisant des réseaux de neurones, cf http://citeseer.nj.nec.com/rowley96neural.html(...) par exemple. Si vous lisez l'article cité, vous verrez que la détection est assez impressionnante (il y a d'autres articles des mêmes chercheurs sur le site).

Ensuite, un article assez récent (http://citeseer.nj.nec.com/wiskott99face.html(...) ) montre qu'on peut obtenir de très bons résultats de reconnaissance à partir d'une image de bonne qualité (centrée sur le visage), avec des techniques de graphe (par contre, c'est long).

On peut aussi lire un article résumant l'état de l'art : http://citeseer.nj.nec.com/fromherz97survey.html(...)
Il semble qu'on obtienne des taux de reconnaissance très élevé (genre 99%) avec des systèmes évolués.

Le fait que les portaits robots soient mauvais n'a strictement rien à voir avec la qualité de la reconnaissance par réseaux de neurones. Les témoignagnes humains sont mauvais, c'est tout.

Plusieurs remarques sur le fond :

1) pour reconnaître quelqu'un avec un système automatique, il faut sa photo (et même plusieurs photos), ce qui est une condition très forte.

2) je ne pense pas Stallman ait complètement tord sur comparaison. Un humain peut reconnaître quelqu'un à partir d'une description, dans des conditions très mauvaises à partir d'un photo, malgré un déguisement de base, etc. Je ne sais pas si on peut obtenir le même genre de chose avec un système automatique. Les performances humaines ne sont en rien contradictoire avec la mauvaise qualité des temoignages généralement obtenus après des crimes et délits, le problème est différent, c'est tout (verbalisation d'une impression visuelle contre pattern matching).

Umpf, il me semble que les deux choses sont exactes :

- asf est limité (320x200, impossible de faire de l'avance rapide avec le Media Player 7.x)
- asf contient des informations en plus d'avi pour le streaming -> de la place perdue
- asf t'oblige à utiliser un format audio précis (je crois)

DivX 3.x, c'est effectivement des vieilles versions des codecs (pour les raisons que tu évoques) mais c'est aussi le retour à l'avi (audio librement choisi, pas d'information de synchro) et la suppression des limitations sur la taille de l'image.

Enfin, c'est ce que j'ai lu à divers endroits...