Frédéric Lopez a écrit 759 commentaires

Le problème c'est qu'il n'est plus maintenu depuis quelques temps déjà. La dernière version date d'il y a 6 mois et le mainteneur ne répond pas à ses e-mails. Dommage...

Du coup je suis en train de me tourner du côté du Debian Live Project (http://debian-live.alioth.debian.org/ ) pour me faire un live CD personnalisé en me basant sur PING (http://ping.windowsdream.com/ ) pour faire une sorte de ghost.

Ici on a l'impression que Java est très lent pour ce genre de calculs alors que ce sont les optimisations en assembleur qui boostent les perfs du programme en C.

Question idiote, mais pourquoi la classe BigInteger n'est-elle pas implémentée en assembleur plutôt qu'en Java natif si ça offre tellement plus de performances ?

D'après la FAQ de Xen, il semblerait que la virtualisation hardware couplée à la paravirtualisation (pour les entrées/sorties) permette d'obtenir des performances quasi-natives sur processeurs Intel VT sans modifier l'OS invité. Mais ils ne donnent pas de chiffres vérifiables.

Source : http://www.xensource.com/xen/xen/faqs.html

Q: How does Xen differ from other virtualization technologies?
A : [...] Xen runs unmodified guests such as Windows, on “the bare metal” at native processor speed on Intel VT enabled hardware. Paravirtualization in this case provides I/O performance that Intel VT cannot provide, while still using the best in hardware support for accelerated performance of virtualization.

Q: What is paravirtualization?
A : [...] For Windows and other guests that are unaware of Xen, the hardware virtualization of Intel VT, combined with paravirtualizing device drivers in Windows, allows Xen to achieve the same high level of performance as virtualized Linux guests.

Par contre, en paravirtualisation (donc sans assistance matérielle et avec modification du système invité), il y a des chiffres, et là Xen offre des performances quasi-natives.

Source : http://www.cl.cam.ac.uk/research/srg/netos/xen/performance.h(...)

L'article (qui n'est pas d'IBM mais d'Emulex, une société spécialisée dans la virtualisation) aurait pu rester aussi court et accessible sans ces erreurs, qu'elles soient volontaires ou pas.

Dans l'état, il induit en erreur sur les réelles possibilités des différentes solutions et présente les solutions commerciales comme les seules étant à même de répondre à une problématique de virtualisation.

QEMU est écarté puisque présenté comme un émulateur, donc très lent (« a 100 times slowdown is not uncommon », « actual speed difference can be on the order of 1000 times slower »), ce qui est faux en utilisant le module dont j'ai parlé.

Xen est également écarté puisqu'il est dit que des modifications doivent être effectuées sur le système invité (« only those operating systems that are patched can be virtualized over Xen. », « from the perspective of wide support (...), it's a clear disadvantage. »), ce qui est également faux si on utilise la virtualisation matérielle.

Très franchement, si un utilisateur pourrissait mon blog, mon premier réflexe serait de chercher son nom dans google pour savoir à qui j'ai affaire.

Et dans ce cas, j'aurais rapidement vu que John Doe est un nom générique puisque le premier lien retourné est celui que je viens de poster...

Je ne suis pas sûr que cet article soit si bon que ça, il y a plusieurs erreurs notables dedans.

QEMU est cité comme une solution d'émulation alors qu'il sait également faire de la virtualisation, au même titre que VMWare et Virtual PC, avec le module propriétaire QEMU Accelerator.

Xen est décrit comme une solution ne sachant faire que de la paravirtualisation alors qu'il est également capable de faire de la virtualisation si la plate-forme matérielle le supporte.

En général les projets ne demandent pas mieux que de fournir des paquets binaires en plus de leur tarball.

Ben il suffit d'utiliser loki_setup (http://icculus.org/loki_setup/ ) jusqu'à ce que le projet devienne tellement intéressant que des volontaires se proposent pour créer des paquets.

C'est ce qu'utilisent les éditeurs propriétaires sous Linux (Loki, id Software, Nvidia, Epic, Google, etc.) et ça marche sur pas mal de plates-formes (tous les Linux, FreeBSD, AIX, HP-UX, IRIX, SunOS/Solaris, Mac OS X, etc.).

Euh, Windows 2000 Server ?

J'ai bon là ?

PS: il y a un autre truc qui m'énerve ! C'est ton nom "John Doe", le nom du plus gros spameur sur mon blog ! Je ne sais si c'est toi mais ça m'énerve !

En anglais, John Doe est l'équivalent de l'expression « monsieur X » ou « Monsieur Durand » ; c'est le Britannique ou l'Américain moyen, ou bien une personne inconnue (éventuellement un mort non identifié).

Voir : http://fr.wikipedia.org/wiki/John_Doe

PS : on gagnerait toujours à consulter Wikipedia avant de s'énerver... ;)

J'ai la même carte, reliée avec le câble fourni au port vert sur ma carte son et ça fonctionne sans problème. Je pencherais pour un problème de carte son ou un problème avec le logiciel TV, c'est lequel d'ailleurs ?

Quand on fait un fork, c'est que le code ne nous appartient pas. Donc c'est un peu logique qu'on ne puisse pas changer la licence...

Une question en passant, est-ce que vous vous basez aussi sur le driver Utah GLX pour Xfree 3.3 ? Ils avaient un driver fonctionnel quoique pas au niveau des perfs de celui de nvidia. Mais il permettait quand même de faire tourner Quake 3 de façon raisonnable sur une TNT2.

Ant: c'est un peu fort de dire que Darwinia est un jeu raté, sans aucun argument, rien

Il a dit exactement le contraire :

Il vaut mieux faire un jeu simple mais bien réalisé, genre darwinia, qu'un jeu ambitieux, mais raté.

Tu peux aussi étudier Alfresco : http://www.alfresco.com/

En fait le single n'était pas un bug aléatoire, on récupérait par défaut le mode de l'arme de la dernière personne qu'on suivait après être mort. Pour l'éviter, il fallait switcher vers quelqu'un en mode auto dans l'équipe adverse ou la sienne avant de réapparaitre.

Le mécanisme d'escalade est vraiment super bien trouvé

Oui, c'est clair que ça, je trouve aussi que c'est une réelle amélioration.

Pour la refonte des cartes, il faut voir sur la durée, mais pour l'instant je suis pas trop convaincu. Oon perd un peu le côté embuscade et points de passages obligés qui faisait à mon avis une bonne partie de l'intérêt du jeu.

Sinon, j'ai un peu essayé le mode CTF et ça a l'air sympa, faut voir ce que ça donne avec beaucoup de joueurs sur une map.

Visiblement c'est un problème qui apparaît quand on a le son à 44khz et qu'on tire ou que d'autres tirent. D'après le forum, la solution serait de baisser le son à 22khz (marche pas vraiment à 32khz) dans le script de lancement et/ou de désactiver les wallmarks. Ça a l'air d'être spécifique à Linux.

La commande à taper : et +set fs_game tcetest +set com_hunkmegs 256 +set s_khz 22

Si, il y en a quelques uns :
http://www.archilinux.org/archi-cao/archi-cao.html

L'Université de Perpignan a l'air elle aussi assez intéressée par les logiciels libres :
http://wikicriup.univ-perp.fr/

Dans ce cas là, le plus simple est encore de dire clairement qu'on n'aime pas Nicolas Sarkozy et d'expliquer pourquoi plutôt que de l'appeler Nicolas S. Ça fait un peu cour de récré sinon...

C'est vrai que le foot n'est pas un sport de performance pure, mais ce n'est pas seulement pour la performance que les joueurs se dopent, c'est aussi pour tenir la saison physiquement. Et pour ça, la créatine ça aide pas mal...

D'ailleurs, le médecin-chef de la Juv avait été condamné pour avoir donné des produits dopants (EPO notamment) à ses joueurs entre 1994 et 1998, période pendant laquelle l'équipe a remporté trois titres de champions d'Italie et une ligue des champions (avec un certain Zidane, qui avait avoué avoir pris de la créatine aussi).

Et puis si le cyclisme semble être le sport dans lequel il y a le plus de dopage, c'est peut être parce que c'est le sport le plus contrôlé. Et qu'il y a beaucoup moins d'argent en jeu aussi...

J'ai désactivé l'option NvAgp de mon /etc/X11/xorg.conf : # Option "NvAgp" "1"

Donc c'est bien un problème de chargement de agpgart. Les lignes suivantes de dmesg devraient pouvoir te fournir plus d'informations sur les raisons de l'échec, voir sinon le contenu de /var/log/syslog et /var/log/messages/.

Pour empêcher le chargement automatique, tu peux essayer ce que je disais précédemment, mais rien ne dit que ton chipset sera supporté par le driver AGP de Nvidia (il vaudrait mieux réussir à faire fonctionner agpgart) :
- renommer agpgart.ko en agpgart.ko.old ;
- désactiver agpgart avec modconf (dans kernel/drivers/char/agp) ;
- le blacklister dans /etc/modprobe.d/blacklist (mais ça t'as visiblement déjà essayé).

Tu as essayé avec un noyau 2.6.16 sinon ?

En dernier recours, je te conseille d'utiliser le driver Nvidia directement depuis leur site et pas le paquet Debian.

Par contre, est-ce que "Fast Writes" n'améliorerait pas les choses ?
Comment fait-on pour l'activer ?

S'il n'a pas été activé, c'est qu'il n'est pas disponible.

Là, il ne trouve pas certaines fontes et a un problème avec le EDID. (Je ne sais pas ce que sait et si c'est la cause de mon problème).

Ça n'a pas d'influence sur les performances.

Ce n'est toujours pas supporté correctement par la dernière mise à jour de Sarge (noyau trop vieux visiblement).

SATA driver can block access to CD drive in installations from CD :
http://www.us.debian.org/releases/stable/debian-installer/

Deux pistes quand même sur le Debian Wiki :

Is installation on SATA harddrives supported by DebianInstaller?
http://wiki.debian.org/DebianInstaller/FAQ#head-a5623cd5a3ec(...)

DebianInstaller/SataAtapiHowto :
http://wiki.debian.org/DebianInstaller/SataAtapiHowto

Pour résumer, que tu utilises agpgart ou pas, tes jeux/applications 3d sont lentes ? Le premier truc, ce serait quand même d'évaluer la lenteur en question.

Tu peux comparer tes résultats avec ceux que j'avais posté il y a quelques années pour la même carte :
http://linuxfr.org/comments/448923.html#448923

Sinon, le résultat des commandes suivantes permettra peut-être de voir s'il y a des problèmes :
- cat /proc/driver/nvidia/agp/status (pour voir si l'AGP est bien pris en compte)
- glxinfo | grep OpenGL (pour voir s'il n'y a pas de conflit avec Mesa)
- cat /proc/driver/nvidia/cards/0 (pour voir si la carte est bien reconnue)
- cat /var/log/Xorg.0.log (pour voir s'il y a des erreurs au chargement du driver, tout ce qui commence par (WW) ou (EE))
- contenu des fichier autres que README dans /proc/driver/nvidia/warnings/ (pour voir si le driver détecte des warnings importants)

Si rien ne semble clocher, tu peux essayer d'installer le driver fourni sur le site de Nvidia plutôt que le paquet Debian. Il est assez doué pour corriger des installations incorrectes et virer les références à Mesa.

Difficile ? Pas tant que ça... :)

Comparatif de 5 notebook coolers :
http://www.adnpc.net/dossiers/76/lire.php