mdlh a écrit 404 commentaires

Sans vouloir faire de troll, windows sur Itanium etant lent, je voyais pas trop la difference entre une appli native et une appli 32 bits. Parfois meme je confondais...

pas de probleme particulier avec Firefox sur ma becane.

J'ai beaucoup de pb avec Konqueror, plus particulierement avec la feuille de style pour le media "print" qui etait interpretee alors que le document etait a l'ecran (donc "screen"). C'est peut-etre encore un pb du meme genre.

Quand j'ai installe Windows pour Itanium (une beta version), il a installe le driver pour un chipset via. Je suis sur que y a pas de chipset via pour Itanium. Je pense donc que la version windows 64 bit pour Itanium a ete prepare pour etre recompile pour x86-64.

Pour ce qui est de windows lui-meme, il etait plutot stable. Rien a redire.

C'est d'ailleur pour ca que tu as thé et tchaé deux tentatives de prononciation d'un meme mot. Comme les marchands utilisant la mer pour le transport utilisaient thé et ceux par la terre tchaé ont a maintenu deux noms différents pour des produits presquent pareil, alors que les vendeurs d'origines n'y voyaient pas de differences.

Je suis pas tres clair la... desole, je me leve

Si DOS fonctionne sur une architecture temps-reel p'tetre.
Hors si tu veux un temps de reponse garanti, il faut que ton hard te reponde dans un temps garanti. Ce qui n'est pas le cas. Certains pensent que faire du temps reel "dur" sur un PC, c'est bien pour la pedagogie, mais pas pour une implementation reelle.

Non, utilisateur averti qui s'informe sur linuxfr. Y a pas marque qui lit le code. Mais franchement on se prend la tete pour pas grand chose.

Je considere beaucoup plus intrusif une application qui fait un ping sans prevenir que celle qui demande. Quel est l'interet de se dresser contre une telle "fonction" alors que l'utilisateur peut l'annuler?

Et pour ceux qui se demandent pourquoi une telle fonction et s'inquiete du bon fonctionnement, ils devraient etendre ce genre de discussion pour chaque fonctionnalite annoncee. Y a eu une annonce pour Java y a pas longtemps. Y a moyen de s'echauffer.

on a un garbage collector

Pour le C et le C++: http://www.hpl.hp.com/personal/Hans_Boehm/gc/(...)

J'ai teste les deux premieres solutions pour un projet interne:

- IDX-PKI est surement tres bien si tu utilises la distribution qu'ils supportent. Une RH 7.3 . Ils sont tres clair la dessus: Faut pas se plaindre si ca marche pas sur d'autres. Ils sont honnete et ils ont raison.

Tu peux apres pas mal de modif le faire tourner. Encore faut-il etre sur de ce que l'on modifie. Deux exemples de memoire:

Ils utilisent la fonctionnalite "taint" de PERL (desole pour l'orthographe). L'idee est bonne. Malheureusement il semblerait qu'avec une version plus recente de PERL, PERL est encore plus restrictif et s'affole des le debut sur une utilisation dangereuse d'une variable.

Ils regenerent un fichier de conf pour openldap . Malheuresement, si la syntaxe est plus ou moins la meme avec les dernieres versions d'openldap, les options ne sont plus les memes. Il est toutefois facile de modifier le code qui genere le fichier de conf.

C'est deux pbs que j'avais eu de memoire.

- OpenCA: J'ai bien aime. Les composants sont separes et il est donc facile (et conseille) de mettre en place l'architecture PKI sur plusieurs serveurs (Utilisateur, Authorite d'enregistrement ... )

L'esthetique de l'interface ne mettra surement pas tout le monde d'accord. Mais ca reste a mon sens le projet le plus serieux des deux, meme si un effort sur la doc serait souhaitable.

Y a moyen de savoir quel type de benchmark. Je suis interesse.

1- Le cache existe car le processeur est capable de traiter une information plus rapidement que n'est la memoire capable de lui fournir l'information (ma phrase n'est pas claire mais je crois qu'on peut la comprendre). Et ca c'est pas specifique a l'Itanium. Si est un cache reste petit c'est pas par desire de le garder ainsi. Ca "coute" en espace et une memoire plus traditionelle (RAM) a un meilleur rapport vitesse/prix. Si tel n'etait pas le cas, le cache n'aurait pas de raison d'etre.

Maintenant on peut se poser la question legitimement: Intel met-il un cache enorme pour "cacher" les imperfections du processeur ou pour mettre en valeur ces atouts. J'ai donne mon avis sur ce point il me semble.

2- Que la taille du cache choque, je veux bien. Mais en quoi est-ce "indescent". Le fait que l'Itanium soit le premier a en avoir un aussi gros a-t-il une reelle signification sur ca (mauvaise) conception? L'ajout d'un radiateur et un ventilateur sur les processeurs etait-il aussi indescent? Y a 12-13 ans j'avais une interface graphique sur mon DX-33 avec 4Mo de RAM. Avec 4 de plus j'ai juste de quoi demarrer un kernel Linux avec console... Mon disque dur de l'epoque a une plus petite capacite de stockage que ma clef USB d'aujourd'hui.

Pour ce qui est de la "preuve" de l'architecture c'est pas completement faux, mais pas completement vrai non plus. En regardant de plus pres la conception de l'IA-64, on retrouve beaucoup de concept defini dans la litterature. La predication, le renommage de registres, la speculation de donnee et de controle (desole pour la traduction)... Intel n'a fait que les mettre en pratique, mais n'a rien invente. C'est juste qu'auparavant, le modele etait theorique. Maintenant, on se rend que tout n'a pas ete "prevu".

le probleme de fond avec cette bestiole, c'est que j'ai beau mettre un moteur de Ferrxxx dans mon chassis de 106, a un moment faut que je change les dimensions de mes suspensions si je veux pouvoir passer la troisieme vitesse.

Quand je lis: il aurais fallu une innovation qui apporte vraiment un plus lors du passage vers le 64 bits, puis c'est avant tout un bide technique., la je commence a me poser des questions sur la valeur des commentaires.

Il a ete mentionne plus haut le "rouleau compresseur" du marketing. Il semblerait qu'en effet ca ai marche, car on ne parle plus ici et ailleur que du fameux passage vers les 64bits. Et c'est bien dommage.

Oui, l'Itanium est un bide commercial. Le cote technique c'est autre chose. Je poste ce commentaire depuis une station de travail avec un Ch'ti itanium de premiere generation et c'est assez agreable. Je vais pas m'amuser a decrire ici toutes les particularites de la puce. Mais j'ai juste une remarque a faire sur les 24Mo en cache. Si la valeur est si grande, c'est tout simplement qu'une fois une appli a ete optimisee correctement par un bno compilateur, le gros goulot d'etranglement qui limite la vitesse d'execution, se sont les acces memoires. Le fait de pouvoir executer jusqu'a 6 instructions par cycle n'a pas d'interet si la totalite se trouve dans le memoire "traditionnelle".

Pour la note d'humour: Le fait que les gestionnaires du batiment ou je me situe adorent foutre la clim a une temperature ultra basse est un tres bon argument pour l'utilisation d'un Itanium.

J'ai bien vu la TODO list.

C'est pas le niveau technique qui m'inquiete. C'est surtout verifier qu'il y a bien une correspondance entre:
- ce qu'aimerait voir le developeur original
- ce qu'aimerait voir la communaute
- ce que voudrait faire le "remplacant"

Ca peut etre frustrant de voir ton remplacant repousser a plus tard des fonctionalites que tu aurais souhaite voir arriver beaucoup plus vite. Voir meme, ca peut etre rassurant de savoir que ton remplacant est sur la meme longueur d'onde.

De plus, tu connais mieux que n'importe qui le point de vue de tes utilisateurs. Et ca compte...

Tu suggeres qu'il y a deja des idees d'evolutions. Peux-tu preciser selon toi lesquelles devraient etre incluses en "priorite"?

Je serais curieux de connaitre quel machine PA-RISC tu as utilise pour tester ta Debian... Note que Linux n'est pas supporte sur toutes les machines PA-RISC.

Pareil pour moi:
x86, IA-64, HPPA et meme un peu de Sparc32
Parfois je suis oblige de regarder dans le /proc/cpuinfo pour me rappeler ce que c'est comme bestiole.

Il dit qu'il a eu uniquement Linux de 97 a 99. Ou y a t il ecrit "Windows uniquement depuis 99".
Evidement il precise pas. Mais quand je lis "Linux depuis 95", je me dis qu'il y a du linux qui traine encore quelque part.

Je vais commencer par me poser des questions sur ma comprehension de la langue francaise. Ca a surement horriblement evolue depuis que j'ai quitte le territoire.

Tu dois te tromper de Thread. Pour le coup PbPg n'a traite personne d'integriste. Je suis pas toujours d'accord avec lui, mais la je vais le suivre: concentre toi sur le thread.

Sur IA-64, le noyau et l'application sont dans le meme espace d'adressage. Par contre l'application ne peut pas acceder "facilement" aux valeurs de l'espace d'adressage du noyau.

Il y a plusieurs niveaux de privilege mais l'espace d'adressage est bien le meme.

Le NCSA n'en est pas a son premier Itanium. Ils ont deja un cluster et pour avoir parle avec certain d'entre eux, ils ont l'air d'en etre assez content.

Apres il me semble qu'effectivement que l'Itanium se debrouille assez bien dans un environment multi-proc.

Apres y a surrement quelques subtilités à regler, mais j'imagine que l'essentiel est fait très tot.

L'une des subtilites est de gerer des informations sur des champs de bits. Forcement a 2 bits par processeurs sur un mot de 32 bits, 1024 processeurs, ca tient pas.

Les developeurs de SGI ont ecrit un patch pour lever cette limite.

D'autant plus que le cas decrit precedement (un driver qui dialogue avec une carte pour lequel il n'est pas ecrit), a plus de risque d'avoir lieu avec une carte ISA.

Gof a dit:
par exemple de mettre du code BSD
Et avant, narzdir:
du code compatible GPL

Bon histoire d'etre pointilleu, c'est pas le code qui doit etre compatible GPL mais la license associee.

Apres, il se trouve que la license BSD est compatible GPL. Donc sur ce point vous etre d'accord.

Effectivement.

Sur un poste plus haut je mentionne en effet aussi que le projet n'est pas abandonne.

vaut peut-être mieux que se soit pas fait automatiquement pour forcer les gens à apprendre

Ca c'est a l'utilisateur de choisir.