reno a écrit 3886 commentaires

Tiens une autre traduction sympa que j'ai vu:
cache memory --> mémoire tampon

Vous en pensez quoi?
Cela me paraissait pas mal jusqu'au moment ou j'essaye de traduire "buffer memory" que je traduirai aussi par mémoire tampon..

Et bien c'est le cas pour les cartes graphiques, si je ne me trompe pas, non?

Je crois que ATI pour ses 9500 et au dela ne fournit plus les specs de la partie 3D, Matrox pareil pour sa Parhelia, Nvidia ne les a jamais fournit..

Bref, jouer sous Linux a des jeux gourmands (je pense au futur Doom3) sans avoir un kernel "tainted", ce n'est pas possible a l'heure actuelle je pense :-(

>Mais Perl6.... Waaaa, s'ils réussissent vraiment à mettre tout ce qu'ils
>ont promis, sans foutre un bordel pas possible (pas évident ;) ), ça
>promet d'être un Python/Ruby-killer !! :D

Amusant, j'ai un avis totalement opposé: je pense que Perl6 va être la mort du Perl: apprendre Perl6, c'est réapprendre un nouveau language aussi compliqué a apprendre que le Perl classique et aussi illisible/inmaintenable!

Ce qui me fait penser que personne ne se bousculera pour passer au Perl6, et lentement Perl perdra de l'importance face a Python/Ruby..

Ceci dit la transition se fera très, très lentement: on programme encore beaucoup en Shell et en C, alors..

Si j'ai bien lu "les nouveautés" de Python 2.3, je dirais que les deux languages se ressemblent encore plus..

Je ne suis pas un expert en Ruby (et encore moins en Python), mais j'ai l'impression que Python a comme avantages:
1) plus d'utilisateurs
2) plus de librairies
3) une meilleure gestion de l'Unicode (enfin je crois)
4) peut-être une meilleure gestion des thread

Python avait comme défauts, je pense une moins bonne conception "objet" du language: la différence entre les type et les classes, les énumérateurs, mais ces "défauts" ont été corrigés dans les version récentes..

Sinon, franchement quand on regarde les 2 languages, ils se ressemblent beaucoup..
Et je dirais même de plus en plus, vu les progrès récents de Python.

Le choix entre les deux est assez dur, je trouve, j'ai fini par pencher pour Ruby à titre perso, mais si j'avais a utiliser Python au boulot par exemple, cela ne me dérangerait pas du tout!
Ceci dit pour le moment je suis coinçé sur du shell et du Perl: ça fait le boulot aussi, mais beurk!!

> OASIS veux intégrer le format de OO

OASIS et un autre organisme de standardisation (allemand je crois?), j'avais fait un mail aux deuxième pour leur dire que si les deux pouvaient causer ensemble et faire un seul format, ce serait pas mal.

Ils m'avaient répond en me disant qu'ils le savaient déjà, mais d'après le "ton" de la lettre, ils en avaient rien à faire d'OASIS.

Pfff, les "standards" basés sur le format d'OO, je crois qu'il y en aura plusieurs, comme d'habitude!

> KOffice souhaite à terme utiliser le format OOo

Je suis surpris: cela ne posera pas de problème pour le mode de formatage "par frame" de KWord d'utiliser le format OOo?

Si c'est le cas, tant mieux! Moins il y aura de format de fichiers différents, mieux c'est!

(petite pique)
Les formats de fichiers pour les documents, c'est comme le format des prises électriques ou les formats de packaging: moins il y en a, mieux c'est!
(/petite pique)

Des gouts et des licenses ne se discutent pas :-)

Note qu'avec la license Apache, au moins ce genre de confusion sur l'utilisation dans les produits dérivés ne se posent pas..

En plus, si tu veux developper un outil avec la license BSD qui utilise une librairie LGPL, tu est obligé d'utiliser l'édition de lien dynamique pas l'edition de lien statique..

>en fait, tu cliques dessus et il disparaît

Ce n'est pas le cas de tout les splashscreen, je viens de relancer StarOffice5.2 sous Solaris pour voir et le splashscreen ne disparait pas quand tu clique dessus.

C'est vrai que c'est plus intelligent comme comportement, mais a ce moment la il faut que ce soit marqué sur le splashscreen que cliquer dessus ferme le splashscreen, autrement l'utilisateur n'etant pas devin...

Merci pour la capture d'écran, ça me confirme que c'est bien juste un splashscreen, sans rien d'autre, ce qui me permet de pousser le cri suivant: les splashscreen, c'est NUL!!

Je préfererais de loin que l'application lance une fenetre toute bete, avec le même contenu que le splashcreen, car on peut MINIMISER simplement une fenetre, pas un splashscreen.

Si le splashscreen reste 20s a l'écran (penser aux utilisateurs avec des machines peu puissante, ou avec peu de mémoire), les utilisateurs vont le haïr le splashscreen.

Le top serait même d'ajouter dans cette fenetre de démmarage une barre de progression avec un texte qui explique ce que l'appli est en train de faire: comme ça tu sais si l'application est bloquée ou pas.

A une époque, il y avait même des languages de programmation en Français, mais c'est passé..

Apparemment j'avais besoin de cette clarification!

OK donc faire une librairie (un .jar) en Java est totalement identique a la faire en C/C++ du point de vue de la LGPL.

(Ouf!) Pas de quoi en faire un fromage, effectivement.

Un troll, je ne pense pas..

Je suis convaincu que la majorité des développeurs Java pensait de bonne foi, qu'importé un point jar était l'équivalent de la liaison dynamique pas statique.

J'ai lu /. et d'ailleurs une bonne partie des intervenant le croyait toujours car l'explication de l'homme de loi de la FSF était aussi claire que d'habitude quand un homme de loi parle, c'est à dire nébuleuse..
Pff, un avocat ça ne doit pas savoir répondre par oui ou par non..

Quelqu"un connait-il une license "équivalente" à la LGPL, mais qui n'aurait pas ce problème?

Ce serait bien si la FSF en proposait une de ce type..

>Le féminisme est un courant visant à discriminer les hommes des femmes.

T'en as d'autres des bétises du même genre?
Pour moi le fénismisme consiste a tenter de corriger une société dominée par les hommes, retablir l'équilibre si tu veux..

Si je me souviens bien la France a été un des derniers pays à accorder le droit de vote au femmes, et il y a toujours une grande différence de salaire entre hommes et femmes a qualification égale, il y a encore du boulot!
Pour moi, le féminisme, c'est être contre les discriminations anti-femme, alors féminisme==discrimination, quelle bétise!

J'ai presque cru a un troll a un moment, mais si tu y crois vraiment, c'est encore pire..

Pour les algorithme limités par la bande passante mémoire, en général la BP est utilisée surtout par les données pas par les instructions, donc si tu gagnes 20% de place avec des intructions x86 vis a vis du ARM, tu ne gagnes pas 20% de BP mémoire.

Et ce d'autant plus que les caches instructions font pas mal leur boulot..

>Donc Il vaut mieux que le cpu fasse des trucs complexe plutot que d'attendre la mémoire.

Donc tout ceux qui ont conçus des nouveaux CPU ces dernières années sont des billes: ils ont tous concus des RISC a la place de CISC, même Intel! Les VLIW sont des descendants des RISC pas des CISC: architecture load/store, jeux d'instructions facile a decoder, pleins de registres, etc..

>Ensuite, l'IPC moyen d'un code est rarement supérieur à 3, donc rajouter plein d'unité de calcul sert dans très peu de cas. Donc, la vrai limite d'un processeurs devient la lattence mémoire.

Ta logique me parait curieuse là: si l'IPC d'un code est limité, alors on est limité par la latence des unités de calcule, pas par celle de la mémoire! C'est vrai qu'en général un CPU attend la mémoire, mais je ne vois pas quel est le rapport avec l'IPC.

Pour ce qui est de l'opteron, c'est sûr que leur controleur de mémoire intégré a l'air intéréssant, je suis curieux de voir si AMD arrivera a suivre l'évolution rapide des mémoires..

>Ben non, au contraire, le SIMD permet de diminuer le nombre d'instructions nécessaires pour une même tâche ;)

Tu as raison pour le mode SIMD, mais je pense quand meme que quand le x86 a evolue du x86, au 286, au 386, la densite de code a du baissé un peu.

Une question cependant: j'ai cru comprendre qu'Intel poussait le SSE2pour remplacer totalement le x87, meme pour les operations ou tu ne peux pas exploiter le SIMD, est-ce possible?
Parce que a ce moment la, il y aurait bien une augmentation de taille provoquée par l'architecture pourrie du x87.

>Un exemple, pour l'Opteron, pour toute instructions en mode 64bit pour les opterons, il faut ajouter un prefixe d'un octet.
>Non, c'est uniquement pour les opérations sur les entiers 64 bits. Ce qui est logique car dans 99% des cas les entiers 32 bits suffisent.

Je crois que c'est faux là: pour toute operations ou tu veux acceder aux 16 registres, ou bien si tu veux utiliser un espace d'adresse memoire sur 64 bit, tu as besoin de l'opcode supplémentaire, meme pour des operations 32-bits.


A propos du trace-cache, il m'a toujours parut tres petit (d'autant plus que les instructions y sont stockees en mode "décompressé"), je serai curieux d'avoir des chiffres sur les temps d'attente provoquées par cette petite taille..

>les procs l'aujourd'hui ne sont ni totalement CISC ni totalement RISC.

Dans RISC ou CISC, IS ça veut dire Instruction Set, ce qui se traduit par Jeu d'Instruction: les instructions *externes* exécutés par le CPU.

L'implémentation n'a RIEN A VOIR la dedans: pour parler technique il y a eu des RISC implementé avec du micro-code, par exemple.

Et RISC == 1 cycle/instruction, cela n'a quasiment jamais été vrai quasiment toutes les RISC ont une instruction de multiplication qui ne s'execute pas en 1 cycle (si je me souviens bien le MIPS est special la-dessus).

Si tu compares les jeux d'instructions d'un ARM, d'un Sparc, d'un Alpha, meme s'ils ont quelques instructions complexes, ils sont quand meme beaucoup plus proches du concept RISC que ne le sera jamais le jeu d'instruction d'un 80x86.

>Cela me fait de lire ça... le code x86 est plus compact qu'un code arm thumb.

Moui, euh vu les ajouts successifs d'opcode pour ajouter telle ou telle feature (MMX,SSE,SSE2)., la densite du code en x86 a du baissé un peu..

Un exemple, pour l'Opteron, pour toute instructions en mode 64bit pour les opterons, il faut ajouter un prefixe d'un octet.
L'augmentation du nombre de registre compensera un peu, moins de load/store a faire pour cause d'utilisation de trop de registre..

Ceci dit tu confonds la densité du code (une des forces des CISC) et la complexité d'analyse des instructions (une des faiblesses des CISC).
La densité est avantageuse du points de vue bande passante mémoire, occupation des caches mais se paye par une complexité des décodeurs d'instructions bien plus grandes.

Si tu regardes tout les CPU non-compatible 80x86 sorti recemment , ce sont tous des RISC (les VLIW sont beaucoup plus proches des RISC que des CISC), dans ce sens les RISC ont "gagné" (a prendre avec des grosses pincettes).
Par contre, la ou je suis d'accord avec toi, c'est que les x86 explosent tout au niveau performances/prix, la compatibilité avec l'existant l'a emporté sur les avantages ou inconvenient du jeux d'instruction.

>> Il y a un gros patch pour Arm qui est resté en dehors du kernel du test, je crois.
>Faudrait savoir ce que tu veux. Tu reproche à Linux d'accepter trop facilement les patch et après c'est le contraire...

Je ne reproche rien a Linux ni a Linus, je dis juste qu'il y a des compromis a faire: soit tu evolue tres vite avec des feature complexe, multiplateforme, soit tu te concentre sur un kernel qui evolue lentement pour la securite.

C'est la raison principale pour les differents BSD: NetBSD est plus portable que Linux et OpenBSD est (je pense) plus securise que Linux.

Donc quand on dit que Linux fait tout bien, moi je dis que c'est de l'exageration: Linux fait tout pas mal, mais les OS qui se focalise sur un point en particulier remplisse mieux ce point qu'un OS plus generaliste.

>> Par exemple, si je ne m'abuse la stabilisation du kernel 2.6 se fera d'abords uniquement sur x86
> C'est absolument faut. Si t'as un bug report pour Arm ou Sparc, il sera accèpté !

Il y a un gros patch pour Arm qui est resté en dehors du kernel du test, je crois.
Donc forcement, cela limite l'interet des kernel de test pour Arm..

[]
>Pour OpenBSD tu sous-entends qu'intrinsecquement OpenBSD ne peut pas évoluer aussi vite que Linux. Pour Linux tu sous-entends que n'importe quoi est ajouté sans vérification. Or Linux est un des noyaux les plus contrôlés.

OpenBSD ne *veut* pas evoluer aussi vite que Linux, ils ont meme choisis de ne pas pousser le SMP pour avoir du code plus simple a auditer..
Quand a "Linux est un des noyeaux les plus controles", c'est a voir, je me souviens d'un probleme de securite (2.4.20?) il n'y a pas si longtemps, mais ce n'est qu'anecdotique.
Je ne connais pas de statistique comparant les trous de securite pour OpenBSD vs Linux, donc forcement, c'est difficile a comparer objectivement.

Si tu considere Linux comme l'OS, il y a énormément de distributions Linux alors qu'il y a peu de systeme *BSD: les BSD peuvent être considéré comme des distributions.

Si tu considère Linux comme le kernel, (ce qui est plus logique ici), "tout bien" est un peu exagéré: il y a quand même de grosses divergences comme par exemple les systemes temps réel "dur", ou les architecture non-x86 qui sont souvent traitées au second plan.

Par exemple, si je ne m'abuse la stabilisation du kernel 2.6 se fera d'abords uniquement sur x86, note que ce n'est pas une critique, je comprends l'interet, mais quelque-chose me dit qu'avec NetBSD, ce genre d'attitude aurait du mal a passer!

De plus je suis sur que le rythme d'introduction des nouvelles features dans Linux, n'irait pas avec OpenBSD: cela poserait un problème pour revoir toutes ces lignes..
Donc ce n'est pas "tout bien" mais plutot "tout pas mal", et ceci dit c'est uniquement un choix des développeurs, cela n'a rien a voir avec la licence GPL vs BSD!

Les *BSD restent tous accessibles a chacun d'entre eux: rien n'empeche de prendre du code de xBSD pour le mettre dans yBSD, d'ailleurs ils le font..
S'il n'y a pas plus d'échanges entres les kernel BSD, c'est que leurs centres d'intéret sont tellement éloignés que ça limite forcément les échanges..

Ce qu'évoque Linux, c'est plutot le risque qu'une entreprise prenne le code de *BSD, ne le rende plus publique et essaye de vendre leur produit en mettant en avant leurs modifications par rapport au code 'normal', c'est un risque certes, et c'est même probablement arrivé, mais en tout cas, cela n'a pas du tout bloqué le développement des systèmes BSD, ce qui est le principal!

Je trouve un peu curieux son opinion sur la license BSD, si on prend l'exemple de l'OS, il y en a seulement 3 differents avec chacun des préocuppations bien differentes.

Il a le droit d'avoir son opinion, mais en pratique "BSD==nid a fork", cela n'a pas l'air d'être le cas!

Tu es de mauvaise foi, il y a 2 standards:
- le standard qui correspond a un ensemble de regles edites par un organisme de standardisation, dans ce cas le WEC, standard de jure.
- le standard de fait qui correspond a l'implementation predominante sur le marche, dans ce cas IE, tres largement devant tous les autres.

Le standard de fait, n'est pas le contraire du specifique dans le cas ou il correspond a une implementation qui ecrase tout le monde, ce qui est la situation des navigateurs web..

> Par contre, il faut se mefier: StarOffice ne doit pas remplacer MSOffice en terme de position dominante. Sinon, on n'aura pas vraiment avance.

Bin si quand meme, le format de fichier de StarOffice est ouvert, lui.
Pas encore standardisé d'accord, mais bon c'est tout de meme deja pas mal!

On reparle de quoi a propos de Flaubert?

De l'auteur le plus chiant du monde ?

Pour ça je suis d'accord: "l'éducation sentimentale": un vrai cauchemar en taupe, je m'en servais comme berceuse pour m'endormir: 2 pages par jour, c'est radical!

90% de la classe n'a pas réussi a lire le bouquin en entier, alors que ça pouvait être super-important pour les concours!

Je trouve incroyable que l'école n'essaye pas d'attirer vers la litérature en prenant des auteurs intérressant, on croirait qu'ils cherchent a dégouter de la lecture!

Et les appareils photos? Tu as oublié la séance de photos avec Juliette Binoche!
Bon c'est vrai qu'il y avait là aussi des miroirs stratégiquement placés :-)

J'ai tellement aimé "L'Insoutenable Légéreté de l'Etre" que j'ai voulu lire le livre: mmhhh, Kundera c'est "spécial" on dira (beuuurrrrkk).