>où en serais GNU/Linux aujourd'hui ?
Pas bien loin. Mais sans SuSE, il ne serait pas non plus au niveau ou il est aujourd'hui.
Pour reprendre ta syntax, en quoi le fait d'avoir **un** programme sur 8000 propriétaire dans leur distribe remet en cause tout ce qu'ils ont fait pour faire avancer les logiciels libres. Préférer Red Hat ou Mandrake parce que tout est libre chez eux, je le conçois. Mais présenter SuSE comme le grand satan alors qu'ils ont énormément apporté à Linux, c'est exagéré.
Yast n'a pas à être légitimé ou pas : SuSE a le droit de faire cela et je ne vois rien à y redire tant que justement ils apportent quelque chose au logiciel libre en fournissant des développeurs. Libre à toi ensuite de ne pas utiliser leur distribe.
Je suis beaucoup plus gêné par une distribe comme SCO/Caldera, qui n'a pas apporté grand chose au logiciel libre mais en a bien profité. Si tu ne vois pas la différence entre les deux situations, alors nous n'avons pas grand chose à nous dire.
SuSE ne détruit rien du tout. Je ne vois pas pourquoi tu pars dans des tirades gradiloquentes pareilles : sans SuSE, pas mal de projets libres auraient seraient actuellement au niveau ou ils étaient il y a quatre ou cinq ans. Et SuSE ne s'est pas amusé à releaser tout ce qu'ils ont développer en licence propriétaires, la plupart de leurs développements ont été releasé en GPL.
Bien sur qu'ils le font en partie pour améliorer leur distributions. Mais ce qu'ils font n'a rien d'illégal et ils ont généralement bien respecté l'idéologie du libre dans tous les projets auquels ils ont participé. Des développeurs payés par SuSE pour bosser à temps plein sur du libre, sur KDE pour avoir un desktop potable, sur le kernel pour que tu puisses utiliser tranquillos ta Wacom ou ton modem USB, sur Xfree pour que tu puisses tranquilllos utliser ta carte vidéo, et sur combien d'autres projets, il y en a un paquet.
Alors nous chier une pendule pour un installeur proprio, c'est pas seulement abusif, c'est indécent.
Tu peux même commencer par parler du kernel Linux lui-même : port AMD64, ReiserFS, USB et j'en passe.
Dans la plupart des projets libres majeurs, on trouve des développeurs de SuSE, Mandrake ou Red Hat. Si ces sociétés ont une qualité, c'est au moins celle-là. On peut les critiquer sur d'autres points, mais il faut au moins leur reconnaitre cela.
Tout le monde n'a pas encore compris que SCO et Caldera sont la même société.
Ceci étant dit, mélanger SuSE, qui investit énormément dans des projets libres, et Caldera, qui n'a essentiellement rien fait dans ce domaine, ce n'est effectivement pas très juste.
Je ne peux que parler de Nividia, ayant depuis longtemps considéré ATI comme peu fiable. Je sais que de toute évidence, ils ont fait de gros progrès, mais pour toutes les années où ils se sont foutus de la gueule du monde, je considère qu'ils ne méritent plus mon pognon.
Moi, j'ai une GeForce4MX 440. La qualité d''image est excellente en 2D, la 3D fonctionne et la sortie TV Twinview marche parfaitement avec une qualité suprenante. Je ne fais que de la sortie sur magnétoscope (je n'ai pas de télé), mais la qualité obtenue est comparable à un enregistrement direct de la télé.
Les fonctionnalités qui ne dépendent que de la carte sont au niveau de Win, mais les limitations de X s'appliquent toujours (pas de changement de résolution de X à la volée si X ne le permet pas).
Malgré les spec, le libre n'est pas parvenu pour le moment à développer des ppilotes avec un support 3D correct. C'est un fait.
Le support de NVidia à Linux a surtout eu pour objectif de fournir des pilotes OpenGL performant pour leur ligne Quadro qui est très utilisées dans les stations graphiques sous Linux de plus en plus prisées par l'industrie du cinéma.
Je préférerai des pilotes libres moi aussi, mais je préfère encore une compagnie qui investit de l'argent dans des pilotes proprio qu'une compagnie qui s'en fout royalement.
Tu ne réponds pas à mes remarques sur les benchs. Ca c'est un premier point.
De plus :
1/ L'unité vectorielle, c'est bien. C'est généralement plutôt utile en flottant qu'en entiers puisque cela exige du parallélisme. Mais comme le montre le SSE2 d'Intel, le gain dépend énormément des applications. Le gain des applications l'utilisant ne devrait pas dépasser le rapport de fréquence par rapport au G4. Comme de plus, les proc x86 ont également cet avantages et que les optimisations récemment faites sur les applis.
Un bon algo de prédiction de branche en entiers peut amener 10-15% de perfos en plus.
Quant à la gravure, cela change surtout la fréquence, en l'occurrence un passage au 1.8GHz.
Avec son bus à 900MHz, le PPC 970 sera probablement au nivea&u de perfo d'un P4 3GHz. Le problème est que quand il sera disponlible en quantité, il fera face au P4 3.4GHz et à l'Opteron.
2/ Ca fait 7 ans que je suis de prêt l'évolution des processeurs. J'ai eu ma période 'Spec c'est pas réel' jusqu'à ce que je me rende compte qu'in fine, les résultats de Spec rendaient bien le **potentiel** d'un processeur et qu'avec du temps et de l'optimisation, le proc finissait par se positionner là ou Spec le mettait. Si tu crois quntel est le seul à optimiser à mort pour Spec, tu te trompes lourdement. Et les scores de l'Opteron à 1.8GHz montrent que le PPC va avoir fort à faire.
Par contre, ce que tu dis sur le Power4 est juste effectivement et ca m'était sorti de l'esprit. Comme Spec n'est pas multithread, un seul coeur est utilisé. Ce qui laisse penser que le PPC970 devrait tourner à environ 1100 en SpecInt, ce qui est bon mais qui restera en retrait des offres d'Intel et d'AMD, d'autant plus que ces deux là vont passer à la gravure en 90nm d'ici la fin de l'année ou au début de l'année prochaine et que donc, la course à la fréquence va reprendre.
Bon en résumé, le PPC970 devrait avoir des performances tout à fait respectables mais certainnement pas à mon avis dans les niveaux de celles montrées dans ces benchs douteux.
D'accord sur l'ensembe du message. J'ai envoyé une news sur xine car il m'a semblé que ce projet était en général bien passé sous silence par rapport à mplayer ou gstreamer, et les commentaires qui en étaient fait montraient généralement une méconnaissance du projet assez rare. Je pense comme toi, ceci étant dit, qu'il n'y a pas besoin d'une news pour chaque beta ou autre.
Mais bon : on a pas eu de news pour la première beta de KOffice 1.3 (c'est quand même majeur, il s'agit de tester et de valider), et je suis sur qu'en fouillant, on peut trouver des projets qui mériteraient d'être cité ici, plutôt que de faire de la pub incertaine pour Apple.
>pas forcement, tout dépends de ce dont tu as besoin
Je parlais pour moi, bien sur. Chacun fait ce qu'il veut.
Entre les 2.4kg du ibook et les 3.3kg du Sony, pour 900g, je préfère aller 3 fois plus vite en compilation ou en execution de mon KDE.
Pour la batterie, je veux bien te donner raison. Moi, la batterie ne me préoccupe pas trop, 2 à 3h d'autonomie me suffiront amplement vu que je suis connecté au secteur 99% du temps.
Ben justement le gain est trop faible dans ce cas pour un calcul de rendu qui est normalement totalement paralélisable.
Dans photoshop, le passage d'un dual-1.8GHz à un dual 2.0Ghz montre un gain superlinéaire.
Bryce est single-thread, pourtant il montre un gain surprenant en passant de 1 à 2 procs.
Aucune info de config. Si ca se trouve, le P4 tourne sur un plateforme avec SDRam, on en sait rien.
En bref, d'un point de vue de benchmarks, non seulement les résultats sont douteux, mais en plus tu ne sais ni comment c'est testé ni sur quelle plateforme.
Autrement dit, ca vaut rien.
Faut arrêter de rêver : le PPC970 est une version allégée du Power4 mono-core (alors que la Power4 est dual-core et a 128Mo de cache L3) et ce dernier, s'il surpasse légèrement à 1.45Ghz la P4 en SpecFP, est bien à la traine en SpecInt, autrement dit dans 95% dans applications. Même à 1.8Ghz, il n'y a AUCUNE chance que le PPC970 approche les performances du P4, de l'AXP ou de l'Opteron.
Ca n'a pas vraiment d'importance, d'ailleurs, car ce qui intéresse IBM comme Apple, c'est qu'il soit suffisament puissant pour assurer la continuité de leur plateforme propriétaire.
Mouais, un Sony Vaio avec un AthlonXP 2000, un écran 15"TFT, 256Mo mémoire, 40GB disque, Combo DVD/graver CD, Firewire, USB 2.0, Réseau, modem, ca fait 1450 euros.
Donc c'est tout réfléchi.
M'enfin bon, ce genre de discussion, on en fait 10000 par an, non?
Mouais.
Ce qui me fais marrer, c'est que j'ai envoyé il y a prêt de 10 jours une news sur la beta11 de xine, un projet Linux quand même assez important, et je ne l'ai toujours pas vu passer.
Par contre,ces benchs complètement bidons, bourrés de résultats incohérents (regardez le passage de mono à dual processeurs sur Cinema4D, c'est n'importe quoi) qui viennent juste de paraitre, eux, n'ont pas attendu une journée avant d'être posté sur ce site.
C'est à vous dissuader d'envoyer des news.
Sincèrement les gars, c'est sympa d'être volontaires pour être modérateurs, mais si c'est pour faire ça, faites autre chose.
Pour ma part, je tenterais plus d'envoyer des news à linuxfr.
Vire le support framebuffer en console de ton boot loader avant de redémarrer. Moi, j'utilise Lilo, donc je ne sais pas trop s'il y a un problème avec grub, mais si je n'enlevait pas l'entrée dans lilo qui appliquait une résolution autre que 'Normal', mon écran était noir jusqu'à ce que X démarre. Et encore, bootant en init 4, j'ai le plaisir de voir X apparaitre, sinon je serais resté comme toi avec un écran noir.
Avec des changements de contexte du aux 4 process qui tourne, le gain est forcément moins grand qu'avec 2 process multithreadés. Dans ce cas, tu peux avoir des gains jusqu'à 30% selon les applis.
Dans beaucoup d'applis, cela représente au plus un gain de 5-10%. Environ la même chose qu'une fréquence 10% plus élevée.
Bien d'accord avec les chipsets VIA, c'est pourquoi j'ai parlé des NForce de NVidia qui tourne impec sous Linux, qui sont les plus rapide sous AMD et qui sont super stables. C'est vrai que le prix de la carte mère rajoute dans les 50euros, mais ca me parait correct vu qu'on ne parle pas de gain de qq% mais plus prêt de 15-20%. D'autre part, le SiS 735 ou 745 ne supportent pas le FSB 333MHz des derniers AXP autant que je sache, le Nforce2 si.
Mais c'est sur que dans la majorité des cas, tu prends une Asus A7S333 à 75euros, un AXP 2400+ à 110euros et une barette de 512Mo PC2700 de bonne qualité à 90 euros, et pour moins de 300 euros, t'as une belle bête.
Plus valable maintenant ce test : le P4 était un coeur Willamette avec 256ko de cache et 400MHz de FSB. Les P4 actuels sont des Northwood avec support Hyperthreading, 512ko de cache et 800MHz de FSB. Pas vraiment les mêmes perfos.
Cela dit, je rejoints ton avis sur les perfos avec gcc : le P4 obtiens les meilleurs perfos avec des applis compilées avec ICC (le compilo Intel) ou optimisées à la main ,et ce en plus sur ses meilleurs chipsets Canterwood ou Granite Bay, qui sont souvent bien chères (270? chez Asus). Alors qu'un AXP sur Nforce2, le combo qui tue, est moins chère (la carte mère coute 160? en version Deluxe chez Asus) et sera au moins aussi rapide à PR équivalent avec GCC.
Donc pour moi, AMD reste la meilleure solution, et je dois dire que la perspective d'une machine Bi-Opteron avec chipset Nforce3 (cout total proc+carte mère+1Go mémoire ECC: environ 800?) me fait tellement baver que je vais en bousiller mon clavier.
Je tourne actuellement sur un 2.5.68 ici à mon boulot (juste pour tester) et je n'ai aucun problème particulier. Note que je l'utilise pour de la bureautique et pour tester des solutions de sauvegarde réseau, donc ce que je peux globalement dire, c'est que l'IDE, la mémoire partagée, la VM et la couche réseau fonctionnent bien.
J'ai noté un gain de pratiquement 15% sur les débits des sauvegardes réseau que je fais entre le 2.4.20 et le 2.5.64, donc je peux dire que sur ce qui est de la charge réseau et gestion de mémoire partagée, de nets progrès ont été fait.
>je te conseil vivement de profiter de l'énorme avantage des logiciels libres
>(parmis d'autres) qui consiste à reprendre le code source du logiciel et à
>l'améliorer
C'est un argument qu'il va falloir perdre l'habitude d'utiliser quand on parle à des gens qui ne sont pas programmeurs, c'est à dire l'immense majorité des utilisateurs d'ordinateurs. Moi même, je suis ingénieur support, je travaille sous Linux, ma machine personnelle est sous Linux, je compile mon kernel, mes sources, je regarde mes DVD et la télé sous Linux, ma femme fait un dessin animé sous Linux, MAIS si tu me demandes de passer 6 mois à m'autoformer sur le C ou le C++ pour modifier moi-même mon dictionnaire, je te dirai non.
Argumente que tu peux faire des bug reports qui seront corrigés bine plus vite que sur un logiciel propriétaire. C'est relativement juste en général. Mais évitons les 'tu peux modifier ton code'. La plupart des gens en sont incapables et ne verront donc pas cela comme un quelconque avantage.
... je serais plus intéressé par un support type autoexec dans les environnements : tu insères un CD avec un DivX et le player de ton choix est lancé automatiquement avec l'insertion, sans avoir à lancer le lecteur manuellement.
> cd audio (par rip de la piste, ce qui permet de traiter le son)
Je confirme que xine lit sans problèmes les CD "protégés contre la copie". Y a-t-il un moyen de récupérer le flux généré par xine pour se faire des MP3 destinés à son baladeur?
C'est bien possible. J'arrive effectivement à le lire sur un graveur Yamaha 14X,10X,40X dont j'ai très récemment upgradé le firmware.
Mon DVD a également un firmware à peu près à jour, j'essaierai dessus avec xine (ca ne fonctionnait pas avec kscd qui pointe sur le DVD, pas sur le graveur).
Mouais. J'avoue douter du succès à terme de cette démarche : xine en version beta9 arrive déjà à lire le dernier Ben Harper qui est pourtant Copy-protected. Et k3b ou Kaudiocreator parviennent à ripper toutes les pistes sauf la première, en qualité impeccable.
Qu'un rigolo arrive à rediriger le flux sonore lu par xine vers des fichiers wave, et voila, encore une protection qui aura tenu à peine 6 mois. Moi, je ne sais pas faire mais si quelqu'un sait, je suis preneur. Thibaut? Daniel? Bastien?
Au passage, xine-lib beta10 va sortir, la version beta9 tournant décidément drolement bien. Ca me lit tous mes CD, tous mes DVD et tous les fichiers vidéo que je lui ai mis dans le pif. Rien à redire.
Le version beta9 de xine arrive à lire sans problème le dernier CD de Ben Harper qui a un principe similaire. K3b ou Kaudiocreator arrivent à ripper toutes les pistes sauf la première.
M'est avis qu'avec un peu de travail, cette protection ne doit pas être très difficile à contourner.
Comme tu l'as dit au dessus, le système de package te mets des dépendances qui sont dues à la version trouvées sur la machine qui a servi à faire la package. Elles ne sont rarement une indication réelle de la version minimum qui est en fait compatible.
Mais comme tu ne vas pas installer the rpm ou des deb en faisant des --nodeps tout le temps (sinon rien ne va marcher car tu auras plein de dépendances non résolues), tu upgrades des versions de librairies. Et du coup, tu te retrouves parfois avec des galères sur d'autres programmes qui utilisent les librairies upgradées mais pour lesquelles il y a un bug, etc.
C'est pas grand chose, je te l'accorde, c'est juste casse pied.
Au passage, si tu fais des nodeps tout le temps, alors plus aucune raison d'utiliser une debian ou une red hat. :-)
Je viens de tester checkinstall sur xine : du tonnerre!
Se faire ses propres packages était déjà pas très compliqué mais là c'est encore mieux : au lieu de faire un 'make install', du lance checkinstall avec quelques options et ça t'installe le soft tout en te créant un package tgz, que tu peux enlever à loisir avec removepkg.
Simple, efficace, sans tarabistouille débile, du pur Slackware, quoi. Ca te f ait même le bon nom à la mode Slack 8.1+, avec archi, release, version et build. Le top.
Je n'avais pas fait gaffe que c'était en extra (pourtant je suis activement la current). Merci d'en avoir parlé, ca va me simplifier la vie! :-D
[^] # Re: IBM réfute les accusations de SCO
Posté par Richard Van Den Boom . En réponse à la dépêche IBM réfute les accusations de SCO. Évalué à 1.
Pas bien loin. Mais sans SuSE, il ne serait pas non plus au niveau ou il est aujourd'hui.
Pour reprendre ta syntax, en quoi le fait d'avoir **un** programme sur 8000 propriétaire dans leur distribe remet en cause tout ce qu'ils ont fait pour faire avancer les logiciels libres. Préférer Red Hat ou Mandrake parce que tout est libre chez eux, je le conçois. Mais présenter SuSE comme le grand satan alors qu'ils ont énormément apporté à Linux, c'est exagéré.
Yast n'a pas à être légitimé ou pas : SuSE a le droit de faire cela et je ne vois rien à y redire tant que justement ils apportent quelque chose au logiciel libre en fournissant des développeurs. Libre à toi ensuite de ne pas utiliser leur distribe.
Je suis beaucoup plus gêné par une distribe comme SCO/Caldera, qui n'a pas apporté grand chose au logiciel libre mais en a bien profité. Si tu ne vois pas la différence entre les deux situations, alors nous n'avons pas grand chose à nous dire.
Cordialement,
[^] # Re: IBM réfute les accusations de SCO
Posté par Richard Van Den Boom . En réponse à la dépêche IBM réfute les accusations de SCO. Évalué à 5.
Bien sur qu'ils le font en partie pour améliorer leur distributions. Mais ce qu'ils font n'a rien d'illégal et ils ont généralement bien respecté l'idéologie du libre dans tous les projets auquels ils ont participé. Des développeurs payés par SuSE pour bosser à temps plein sur du libre, sur KDE pour avoir un desktop potable, sur le kernel pour que tu puisses utiliser tranquillos ta Wacom ou ton modem USB, sur Xfree pour que tu puisses tranquilllos utliser ta carte vidéo, et sur combien d'autres projets, il y en a un paquet.
Alors nous chier une pendule pour un installeur proprio, c'est pas seulement abusif, c'est indécent.
Cordialement,
[^] # Re: IBM réfute les accusations de SCO
Posté par Richard Van Den Boom . En réponse à la dépêche IBM réfute les accusations de SCO. Évalué à 2.
Dans la plupart des projets libres majeurs, on trouve des développeurs de SuSE, Mandrake ou Red Hat. Si ces sociétés ont une qualité, c'est au moins celle-là. On peut les critiquer sur d'autres points, mais il faut au moins leur reconnaitre cela.
Cordialement,
[^] # Re: IBM réfute les accusations de SCO
Posté par Richard Van Den Boom . En réponse à la dépêche IBM réfute les accusations de SCO. Évalué à 2.
Ceci étant dit, mélanger SuSE, qui investit énormément dans des projets libres, et Caldera, qui n'a essentiellement rien fait dans ce domaine, ce n'est effectivement pas très juste.
Cordialement,
[^] # Re: Un résumé de l'état des drivers ?
Posté par Richard Van Den Boom . En réponse à la dépêche NVidia et ses pilotes Linux.. Évalué à 2.
Moi, j'ai une GeForce4MX 440. La qualité d''image est excellente en 2D, la 3D fonctionne et la sortie TV Twinview marche parfaitement avec une qualité suprenante. Je ne fais que de la sortie sur magnétoscope (je n'ai pas de télé), mais la qualité obtenue est comparable à un enregistrement direct de la télé.
Les fonctionnalités qui ne dépendent que de la carte sont au niveau de Win, mais les limitations de X s'appliquent toujours (pas de changement de résolution de X à la volée si X ne le permet pas).
Cordialement,
[^] # Re: NVidia et ses drivers Linux.
Posté par Richard Van Den Boom . En réponse à la dépêche NVidia et ses pilotes Linux.. Évalué à 0.
Le support de NVidia à Linux a surtout eu pour objectif de fournir des pilotes OpenGL performant pour leur ligne Quadro qui est très utilisées dans les stations graphiques sous Linux de plus en plus prisées par l'industrie du cinéma.
Je préférerai des pilotes libres moi aussi, mais je préfère encore une compagnie qui investit de l'argent dans des pilotes proprio qu'une compagnie qui s'en fout royalement.
Cordialement,
[^] # Re: Le PPC970 va décoiffer !
Posté par Richard Van Den Boom . En réponse à la dépêche Les premiers bench du PPC970 commencent à filtrer .... Évalué à 5.
De plus :
1/ L'unité vectorielle, c'est bien. C'est généralement plutôt utile en flottant qu'en entiers puisque cela exige du parallélisme. Mais comme le montre le SSE2 d'Intel, le gain dépend énormément des applications. Le gain des applications l'utilisant ne devrait pas dépasser le rapport de fréquence par rapport au G4. Comme de plus, les proc x86 ont également cet avantages et que les optimisations récemment faites sur les applis.
Un bon algo de prédiction de branche en entiers peut amener 10-15% de perfos en plus.
Quant à la gravure, cela change surtout la fréquence, en l'occurrence un passage au 1.8GHz.
Avec son bus à 900MHz, le PPC 970 sera probablement au nivea&u de perfo d'un P4 3GHz. Le problème est que quand il sera disponlible en quantité, il fera face au P4 3.4GHz et à l'Opteron.
2/ Ca fait 7 ans que je suis de prêt l'évolution des processeurs. J'ai eu ma période 'Spec c'est pas réel' jusqu'à ce que je me rende compte qu'in fine, les résultats de Spec rendaient bien le **potentiel** d'un processeur et qu'avec du temps et de l'optimisation, le proc finissait par se positionner là ou Spec le mettait. Si tu crois quntel est le seul à optimiser à mort pour Spec, tu te trompes lourdement. Et les scores de l'Opteron à 1.8GHz montrent que le PPC va avoir fort à faire.
Par contre, ce que tu dis sur le Power4 est juste effectivement et ca m'était sorti de l'esprit. Comme Spec n'est pas multithread, un seul coeur est utilisé. Ce qui laisse penser que le PPC970 devrait tourner à environ 1100 en SpecInt, ce qui est bon mais qui restera en retrait des offres d'Intel et d'AMD, d'autant plus que ces deux là vont passer à la gravure en 90nm d'ici la fin de l'année ou au début de l'année prochaine et que donc, la course à la fréquence va reprendre.
Bon en résumé, le PPC970 devrait avoir des performances tout à fait respectables mais certainnement pas à mon avis dans les niveaux de celles montrées dans ces benchs douteux.
Cordialement,
[^] # Re: Le PPC970 va décoiffer !
Posté par Richard Van Den Boom . En réponse à la dépêche Les premiers bench du PPC970 commencent à filtrer .... Évalué à 1.
Mais bon : on a pas eu de news pour la première beta de KOffice 1.3 (c'est quand même majeur, il s'agit de tester et de valider), et je suis sur qu'en fouillant, on peut trouver des projets qui mériteraient d'être cité ici, plutôt que de faire de la pub incertaine pour Apple.
Cordialement,
[^] # Re: Le PPC970 va décoiffer !
Posté par Richard Van Den Boom . En réponse à la dépêche Les premiers bench du PPC970 commencent à filtrer .... Évalué à 0.
Je parlais pour moi, bien sur. Chacun fait ce qu'il veut.
Entre les 2.4kg du ibook et les 3.3kg du Sony, pour 900g, je préfère aller 3 fois plus vite en compilation ou en execution de mon KDE.
Pour la batterie, je veux bien te donner raison. Moi, la batterie ne me préoccupe pas trop, 2 à 3h d'autonomie me suffiront amplement vu que je suis connecté au secteur 99% du temps.
Cordialement,
[^] # Re: Le PPC970 va décoiffer !
Posté par Richard Van Den Boom . En réponse à la dépêche Les premiers bench du PPC970 commencent à filtrer .... Évalué à 8.
Dans photoshop, le passage d'un dual-1.8GHz à un dual 2.0Ghz montre un gain superlinéaire.
Bryce est single-thread, pourtant il montre un gain surprenant en passant de 1 à 2 procs.
Aucune info de config. Si ca se trouve, le P4 tourne sur un plateforme avec SDRam, on en sait rien.
En bref, d'un point de vue de benchmarks, non seulement les résultats sont douteux, mais en plus tu ne sais ni comment c'est testé ni sur quelle plateforme.
Autrement dit, ca vaut rien.
Faut arrêter de rêver : le PPC970 est une version allégée du Power4 mono-core (alors que la Power4 est dual-core et a 128Mo de cache L3) et ce dernier, s'il surpasse légèrement à 1.45Ghz la P4 en SpecFP, est bien à la traine en SpecInt, autrement dit dans 95% dans applications. Même à 1.8Ghz, il n'y a AUCUNE chance que le PPC970 approche les performances du P4, de l'AXP ou de l'Opteron.
Ca n'a pas vraiment d'importance, d'ailleurs, car ce qui intéresse IBM comme Apple, c'est qu'il soit suffisament puissant pour assurer la continuité de leur plateforme propriétaire.
Allez, coridalement quand même, :-)
[^] # Re: Le PPC970 va décoiffer !
Posté par Richard Van Den Boom . En réponse à la dépêche Les premiers bench du PPC970 commencent à filtrer .... Évalué à 2.
Donc c'est tout réfléchi.
M'enfin bon, ce genre de discussion, on en fait 10000 par an, non?
Cordialement,
[^] # Re: Le PPC970 va décoiffer !
Posté par Richard Van Den Boom . En réponse à la dépêche Les premiers bench du PPC970 commencent à filtrer .... Évalué à 8.
Ce qui me fais marrer, c'est que j'ai envoyé il y a prêt de 10 jours une news sur la beta11 de xine, un projet Linux quand même assez important, et je ne l'ai toujours pas vu passer.
Par contre,ces benchs complètement bidons, bourrés de résultats incohérents (regardez le passage de mono à dual processeurs sur Cinema4D, c'est n'importe quoi) qui viennent juste de paraitre, eux, n'ont pas attendu une journée avant d'être posté sur ce site.
C'est à vous dissuader d'envoyer des news.
Sincèrement les gars, c'est sympa d'être volontaires pour être modérateurs, mais si c'est pour faire ça, faites autre chose.
Pour ma part, je tenterais plus d'envoyer des news à linuxfr.
N'importe quoi.
Pas cordialement du tout,
[^] # Re: Dernière (longue) ligne droite pour Linux 2.6
Posté par Richard Van Den Boom . En réponse à la dépêche Dernière (longue) ligne droite pour Linux 2.6. Évalué à 4.
Cordialement,
[^] # Re: Et vous les moules, AMD ou INTEL?
Posté par Richard Van Den Boom . En réponse à la dépêche Introduction à l'Opteron et son architecture. Évalué à 7.
Dans beaucoup d'applis, cela représente au plus un gain de 5-10%. Environ la même chose qu'une fréquence 10% plus élevée.
Cordialement,
[^] # Re: Et vous les moules, AMD ou INTEL?
Posté par Richard Van Den Boom . En réponse à la dépêche Introduction à l'Opteron et son architecture. Évalué à 5.
Mais c'est sur que dans la majorité des cas, tu prends une Asus A7S333 à 75euros, un AXP 2400+ à 110euros et une barette de 512Mo PC2700 de bonne qualité à 90 euros, et pour moins de 300 euros, t'as une belle bête.
Cordialement,
[^] # Re: Et vous les moules, AMD ou INTEL?
Posté par Richard Van Den Boom . En réponse à la dépêche Introduction à l'Opteron et son architecture. Évalué à 8.
Cela dit, je rejoints ton avis sur les perfos avec gcc : le P4 obtiens les meilleurs perfos avec des applis compilées avec ICC (le compilo Intel) ou optimisées à la main ,et ce en plus sur ses meilleurs chipsets Canterwood ou Granite Bay, qui sont souvent bien chères (270? chez Asus). Alors qu'un AXP sur Nforce2, le combo qui tue, est moins chère (la carte mère coute 160? en version Deluxe chez Asus) et sera au moins aussi rapide à PR équivalent avec GCC.
Donc pour moi, AMD reste la meilleure solution, et je dois dire que la perspective d'une machine Bi-Opteron avec chipset Nforce3 (cout total proc+carte mère+1Go mémoire ECC: environ 800?) me fait tellement baver que je vais en bousiller mon clavier.
Cordialement,
[^] # Re: Dernière (longue) ligne droite pour Linux 2.6
Posté par Richard Van Den Boom . En réponse à la dépêche Dernière (longue) ligne droite pour Linux 2.6. Évalué à 9.
J'ai noté un gain de pratiquement 15% sur les débits des sauvegardes réseau que je fais entre le 2.4.20 et le 2.5.64, donc je peux dire que sur ce qui est de la charge réseau et gestion de mémoire partagée, de nets progrès ont été fait.
Cordialement,
[^] # Re: Le poste de travail Linux en question
Posté par Richard Van Den Boom . En réponse à la dépêche Le poste de travail Linux en question. Évalué à 8.
>(parmis d'autres) qui consiste à reprendre le code source du logiciel et à
>l'améliorer
C'est un argument qu'il va falloir perdre l'habitude d'utiliser quand on parle à des gens qui ne sont pas programmeurs, c'est à dire l'immense majorité des utilisateurs d'ordinateurs. Moi même, je suis ingénieur support, je travaille sous Linux, ma machine personnelle est sous Linux, je compile mon kernel, mes sources, je regarde mes DVD et la télé sous Linux, ma femme fait un dessin animé sous Linux, MAIS si tu me demandes de passer 6 mois à m'autoformer sur le C ou le C++ pour modifier moi-même mon dictionnaire, je te dirai non.
Argumente que tu peux faire des bug reports qui seront corrigés bine plus vite que sur un logiciel propriétaire. C'est relativement juste en général. Mais évitons les 'tu peux modifier ton code'. La plupart des gens en sont incapables et ne verront donc pas cela comme un quelconque avantage.
Cordialement,
[^] # Pas mal mais...
Posté par Richard Van Den Boom . En réponse à la dépêche Des DivX bootables sous Linux. Évalué à -1.
Cordialement,
[^] # Re: Oui, mais bon...
Posté par Richard Van Den Boom . En réponse à la dépêche Sortie de GStreamer 0.6.1. Évalué à 1.
Je confirme que xine lit sans problèmes les CD "protégés contre la copie". Y a-t-il un moyen de récupérer le flux généré par xine pour se faire des MP3 destinés à son baladeur?
Cordialement,
[^] # Re: De plus en plus de CDs protégés (et de problèmes pour les lire)
Posté par Richard Van Den Boom . En réponse à la dépêche De plus en plus de « faux » CD (et de problèmes pour les lire). Évalué à 2.
Mon DVD a également un firmware à peu près à jour, j'essaierai dessus avec xine (ca ne fonctionnait pas avec kscd qui pointe sur le DVD, pas sur le graveur).
Cordialement,
[^] # Re: De plus en plus de CDs protégés (et de problèmes pour les lire)
Posté par Richard Van Den Boom . En réponse à la dépêche De plus en plus de « faux » CD (et de problèmes pour les lire). Évalué à 5.
Qu'un rigolo arrive à rediriger le flux sonore lu par xine vers des fichiers wave, et voila, encore une protection qui aura tenu à peine 6 mois. Moi, je ne sais pas faire mais si quelqu'un sait, je suis preneur. Thibaut? Daniel? Bastien?
Au passage, xine-lib beta10 va sortir, la version beta9 tournant décidément drolement bien. Ca me lit tous mes CD, tous mes DVD et tous les fichiers vidéo que je lui ai mis dans le pif. Rien à redire.
Cordialement,
[^] # Re:
Posté par Richard Van Den Boom . En réponse au journal Mickey 3D. Évalué à 1.
M'est avis qu'avec un peu de travail, cette protection ne doit pas être très difficile à contourner.
Cordialement,
[^] # Re: Sortie de la slackware 9
Posté par Richard Van Den Boom . En réponse à la dépêche Sortie de la slackware 9. Évalué à 2.
Mais comme tu ne vas pas installer the rpm ou des deb en faisant des --nodeps tout le temps (sinon rien ne va marcher car tu auras plein de dépendances non résolues), tu upgrades des versions de librairies. Et du coup, tu te retrouves parfois avec des galères sur d'autres programmes qui utilisent les librairies upgradées mais pour lesquelles il y a un bug, etc.
C'est pas grand chose, je te l'accorde, c'est juste casse pied.
Au passage, si tu fais des nodeps tout le temps, alors plus aucune raison d'utiliser une debian ou une red hat. :-)
Cordialement,
[^] # Re: Sortie de la slackware 9
Posté par Richard Van Den Boom . En réponse à la dépêche Sortie de la slackware 9. Évalué à 2.
Se faire ses propres packages était déjà pas très compliqué mais là c'est encore mieux : au lieu de faire un 'make install', du lance checkinstall avec quelques options et ça t'installe le soft tout en te créant un package tgz, que tu peux enlever à loisir avec removepkg.
Simple, efficace, sans tarabistouille débile, du pur Slackware, quoi. Ca te f ait même le bon nom à la mode Slack 8.1+, avec archi, release, version et build. Le top.
Je n'avais pas fait gaffe que c'était en extra (pourtant je suis activement la current). Merci d'en avoir parlé, ca va me simplifier la vie! :-D
Cordialement,