reno a écrit 3886 commentaires

Pour info, les grecs savait déja que la terre était ronde..
Ils connaissaient même sa taille.

De plus l'article en question donne peu d'explication, cela pourrait être très bien un problème lié à l'implémentation, ce n'est pas précisé..

Note qu'en C99, tu as int16, int32, int64 si tu veux avoir des entiers de taille fixée.
Ca a mis longtemps a venir, certes, mais c'est la!

Les programmeurs qui utilisent des entiers pour stocker des pointeurs, sont des gorets, si tu veux mon avis, ptr_t n'est pas fait pour les chiens..

Laisse moi deviner, ce sont des benchs mono-processeur?

Je ne vois pas ce qui te genes..

> Déjà il y a quantité de registres de renommage,

Certes, mais quand tu as besoin de plus de 8 registres, tu es obligé de passer par la mémoire, registre de renommage ou pas!
Les registres de renommage te permettent juste de "decoupler" les instructions qui sont en cours d'execution..

Dans quelque bench de jeux, je crois me souvenir que le passage au mode 64bit donnait 20% de perf en plus..
A prendre avec des pincettes bien sur, mais si c'est correct 20% en plus, c'est loin d'être négligeable comme bénéfice!

Ok, un test montre que les fontes sur le client sont plus rapide sous X que sur le serveur.

Trois possibilités:
1- il y a une raison intrinseque pour laquelles les fontes sur le client sont plus rapide que sur le serveur. Laquelle???
2- Le protocole X a un probleme qui favorise les fontes sur le client plutot que le serveur.
3- L'implementation de X a un probleme qui favorise les fontes sur le client plutot que le serveur.

Personellement je pense pour 2 ou 3 donc le test ne prouve rien, s'il y a une raison pour laquelles les fontes seraient plus rapide que sur le client que sur le serveur, je serait curieux de la connaitre!

Dans l'absolu, tu as raison, en pratique dans ce cas la tu as tort!

Si passer du 32 au 64bit, n'apporte pas grand chose au niveau performance (voire pénalise) dans l'absolu, là on parle du passage de l'IA32 a AMD64: un doublement du nombre de registres!!

Et la pourvu que le compilateur sache faire, les applications en tireront un gros gain!!

> X EST UN PROTOCOLE
> ce PROTOCOLE n'est pas un frein à la PUISSANCE.

Bin si quand meme un peu: si aucun toolkit n'est fichu d'implementer le copier/coller de maniere "correcte", on peut se demander si le protocole n'est pas un peu pourrit!

Et personnellement, cela m'a toujours choqué que l'antialising des fontes soient faites par le client, pas par le serveur..

J'ai entendu dire que FreeBSD fait le multiplexage de source sonore de façon soft dans le noyeau quand la carte ne peut pas le faire.

Ce qui serait bien AMHA, c'est que Linux se standardise sur un equivalent pour faire le multiplexage de source sonore, ça éviterait ce genre de problèmes qui franchement font une mauvaise impression pour un OS qui cherche a atteindre "Monsieur tout-le-monde"..

>'il y a déjà des jeux en vue subjective libres (Doom, Quake et Quake II)

Les moteurs ont été libérés je crois, pas les jeux..

Tu as tout a fait raison, je ne postait pas contre la traduction de la documentation Samba.

Je disais juste qu'il y a pas mal d'entreprises "multi-nationale", ou faire les docs en Anglais me parait assez logique..

Mes parents sont allés voir un film en VO sous-titré et ils ont eu du mal a lire les sous-titre (blanc sur fond clair souvent) donc c'est clair que la VO ce n'est pas pour tout le monde, mais quand on a pris gout a la VO, on supporte difficilement la VF.

Je viens de voir "Battle Royale" en VF et le doublage est infame, bon je ne suis pas sur que j'aurais apprécié la VO, ne parlant pas un mot de Japonais, mais entendre une adolescente parler avec la voix d'une femme plus agée, ça fait bizarre..

Bof, ça depend des habitudes, je bosse à Alcatel ou la langue officielle est l'Anglais pour TOUTES les doc.

Certes cela ralentit un peu, et parfois je vois des énormités en Anglais, mais ça marche très bien et c'est beaucoup plus intelligent que de dire bon ça c'est un projet qui va être réalisé par des Français donc on fait la doc en Français et puis 6 mois après il va falloir faire traduire la doc en Anglais car on va bosser avec des Chinois,Japonais,Indiens,etc.. Cas vécu quand je bossais pour Dassault, une perte de temps et d'argent stupide..

Je dirais que les plus désavantagé sont les plus de 50ans, un gars de moins de 35ans dans l'informatique qui ne parle pas "correctement" Anglais, on peut se demander ce qu'il fait là..

>toutes les docs ont diminué de moitiée sinon plus

C'est peut-être que les docs étaient trop grosse avant? ;-)
Blague à part, l'Anglais est un peu plus concis que le Francais, mais pas à 50%..

>Bref la langue que m'a appris ma maman , y a que ca de vrai

Certes, mais a moins de bosser dans une TPE, on bosse a l'international maintenant..

Je dirais que le plus génant pour l'Anglais, c'est pour les réunion..
Pour les docs franchement, ça ne pose pas de problemes pourvu qu'on ne demande pas de faire du Shakespare, ce n'est pas vraiment de l'Anglais, c'est du "baragouinage en Anglais" et c'est totalement suffisant pour se comprendre dans la quasi-totalité des cas..

Du Linux-bashing, je ne sais pas, il donne son avis, point:
- qualité des manpages: je ne pense pas qu'il ait tort, c'est du en partie au fait que la moitié des pages d'aides sont en man, l'autre en info (beurk! L'outil info est horrible a utilisé d'ailleurs).

- "When I read Linux code I am scared by its often bad style, use of magic numbers, questionable hacks and obfuscation, compared to the clean code we try to use in OpenBSD."

Bin, il a lu du code Linux et l'a trouvé sale en comparaison du code OpenBSD.
Tu sous-entends que c'est une critique infondée, as-tu comparé du code des deux?

Moi non, alors je ne critique pas le critiqueur :-) ...

Certes Linux fait du SMP et d'autres trucs qu'OpenBSD ne fait pas, mais ce n'est pas forcement une mesure de la qualité du code..

Je ne sais pas si tu es au courant, mais il y a pas mal de chomage au Japon, donc par voit de consequence il y a des SDF..

J'avais vu un reportage la dessus (sur Arte, je crois), et ce qui était interressant, c'est que pas mal de ces SDF gardaient leur dignité, s'organisaient, etc..

Interessant de voir les différences, ceci dit c'est comme tout reportage: un fenetre déformante: j'imagine qu'il y a aussi des SDF qui sombrent aux japons, mais le reportage ne parlait pas de ceux la et il y a des SDF en France qui reussissent a garder leur dignité, mais on les remarquent moins que les clochards qui puent l'alcool..

>Je n'arrive pas à savoir si c'est du VoIP ou de la voix sur TCP/IP

????
Bin tu entends quoi exactement par VoIP? Pour moi c'est l'abréviation de "Voix sur IP", donc même si c'était de la voix sur TCP/IP, TCP étant au dessus de IP, cela resterait de la "voix sur IP", non?

Ou alors VoIP a un sens plus précis que j'ignore? Je suis curieux..

Sinon j'utilise TeamSpeack pour jouer en ligne a IL2 (un simulateur de vol), ça marche très bien même avec une dizaine de joueur, mais on est tous en ADSL (en codec plus méchant pour les modem le résultat n'était pas extraordinaire: on est quand même nombreux et le jeux bouffe aussi de la bande passante).

Bof! La vulnérabilité était aussi présente dans les noyeaux 2.2, alors les "c'était mieux avant"..

Ou alors tu fait reference a l'antiquité, 2.0 et avant?

Ceci dit, je trouve que Marcelo Tosatti a bien joué sur ce coup la: il n'y a pas longtemps, il s'était fait incendié (avec raison AMHA) parce qu'il avait trainé à sortir un noyau avec une mise à jour de sécurité, la c'est le noyeau 2.4 qui sort en premier avec le correctif :-)

Bah, d'un autre coté, ils ont acheté Netscape, donc ils font de la marque ce que bon leur semble.

Franchement avoir un attachement à un nom de marque, c'est une très mauvaise idée..

>[] Le meilleur moyen pour améliorer le desktop semble être d'améliorer le noyau tout de même []

Mmmm? Le plus simple peut-être, mais ce qu'attendent avant tous les utilisateurs, c'est de meilleures applications AMHA.

Avec par exemple un copier/coller qui marche pour autre chose que du texte..
Et des applications qui répondent mieux: si je me souviens bien il n'y a pas si longtemps le souhait numéro 1 des utilisateurs de KDE était une ammélioration de la vitesse..

Bref, pour avoir un bon desktop, il faut que toute la chaine kernel + X + toolkit + application soit bonne: le noyau ne fait pas tout..

Sinon pour les patches pour "améliorer la réactivité du desktop", en gros ils évitent a un lecteur de MP3 d'avoir des blancs en cas de surcharge, mais a part cela je n'avais pas ressenti de grosse différences, mais c'était il y a longtemps..

Bah, tu retardes, cela a déja été fait, plusieurs fois même!

Les RISC sont un redémmarage a zero, pendant des années ils ont eu des performances très supérieures au x86, consommant moins,etc..

Sauf que les lois de l'économie ont joué: les x86 étant vendus en plus grand nombre, ils étaient moins cher, donc même si les RISC étaient plus puissant, ils n'ont quasiment jamais été meilleur en rapport puissance/prix.
Le mouvement s'est même amplifié en faveur des x86, maintenant l'avantage en puissance des RISC est loin d'être flagrant.

Intel n'ayant pas de RISC pour le haut de gamme a décidé de repartir a zero, ils ont "repris" un design d'HP que l'on pourrait qualifier de post-VLIW: les VLIW traditionnels n'étaient pas compatible entre eux d'une génération à l'autre: génant pour le logiciel propriétaire!
Leur IA64 a bien du mal a démarrer et le x86-64 d'AMD une évolution du x86 risque de leur causer bien des soucis!

Bref, en matière de CPU: évolution plutôt que révolution, et le jeux d'instructions le plus répandu a toutes les chances d'être celui qui gagnera..
Certes le marché Linux est moins sensible au jeu d'instruction que le marché classique (et encore! souvent les architecture autre que x86 sont "en retard") mais le marché est nettement plus petit donc tu perds beaucoup en économie d'échelle..

D'apres le changelog, uniquement des correctifs, pas de nouvelle feature.

>GL 1.5 c sorti y a 6 mois déjà.

Oui, mais là, il s'agit de la sortie de la nouvelle édition du blue book, pas de la spec..

Dommage d'ailleurs que le blue book ne couvre qu'OpenGL 1.4, car si je ne me trompes pas les vertex shader et les fragments shader sont introduits dans OpenGL 1.5, grrr.
Je crois que j'attendrais encore avant de me payer le blue book, dommage..

> Si ces fabriquants ont 2 sous de bon sens, ils refuseront de payer cette dîme à Microsoft et implémenterons un autre format de fichiers

Et se feront critiquer par les revues, et les sites webs qui testent le matériel: cet appareil X n'est pas vraiment plug-and-play, il faut installer un logiciel pour le faire fonctionner, son concurrent lui est vraiment plug-and-play.

Quand tout le monde imposait l'installation d'un logiciel pour fonctionner, ce n'était pas un argument commercial de différentiation..

Maintenant cela l'est devenu, ce n'est certes pas une fonctionnalité essentielle, mais je vois mal les constructeurs de matériel se rebeller contre Microsoft: quand on a un monopole sur le poste client, on domine aussi les périphériques autours..

Oui, dommage d'ailleurs, je voulais demander a PBPG un conseil pour acheter un bouquin d'utilisation avancée/administration système sous Windows..

J'ai demandé a mon admin Windows, mais elle n'a pas été capable de me donner un nom d'un bon bouquin pour Windows, ce que je trouve curieux..

Les bons bouquins pour admin. système ne manquent pas pour Unix, mais apparemment pour Windows, ils sont rares, bizarre..

Pareil.. Ou plutot, je ne l'ai pas renouvelé..

Bof, GNU c'est un peu court: si on suit ton explication, cela ne devrait pas s'appeler GNU mais GNU / Mach ou GNU / L4...