* Victor Stinner <[email protected]> [2010-01-11 16:41 +0100]:
> Le jeudi 31 décembre 2009 10:17:11, Cyril Chaboisseau a écrit : > > dernier point : l'un des arguments invoqué pour hésiter à passer en 64b > > c'est le support des applications 32 bits tu n'as pas tenu compte de la phrase qui suivait mon assertion : "et bien non seulement ça marche très bien..." j'aurais plutôt dû tourner ma phrase comme ça : l'un des arguments qui était auparavant invoqué pour hésiter à passer en 64b... > Euh, quelles applications ? Il y a 5 ans, OpenOffice, Firefox, Flash, Java, > ... n'étaient pas compatibles. Aujourd'hui je ne vois pas ce qui pourrait > bloquer. bien sûr que _maintenant_ tout marche très bien et c'est justement le message que j'essayais de faire passer pour tenter de convaincre les derniers sceptiques > > (personnellement, j'ai juste Wine que j'utilise extrêmement rarement > > dans un but de test et Acroread pour me rendre compte à quel point il > > est moins bien qu'Okular) > > Pour Windows, j'utilise Qemu : vitesse correcte avec kqemu, et très correcte > avec kvm. Pour kvm, il faut un CPU récent qui a les instructions pour > accélérer la virtualisation, kvm les exploite justement. Fedora a bossé pour > fusionner kvm et qemu. qemu (y compris avec kqemu) est un veau (ou une usine à gaz) par rapport à Wine les 2 ne jouent clairement pas dans la même cour : qemu est une vraie machine virtuelle qui a besoin de l'OS (et donc d'un licence) tandis que Wine, comme son nom l'indique n'est pas un émulateur mais va traduire à la volée les appels à l'API Win32 de MS en équivalents sous Linux ça a l'énorme inconvénient que l'émulation est loin d'être parfaite mais en contrepartie, la rapidité est au rendez-vous au point qu'un programme peut tourner + vite sous Linux+Wine que sous Windows en natif sur la même machine physique sans compter que lorsque Wine64 sera stabilisé, on pourra faire tourner des programmes windows 32 bits en natif 64 bits sous Linux avec un espace d'adressage largement + grand que celui pour lequel ils avaient été initialement conçu ! > Pour Acroread, je n'en ai jamais eu besoin. Okular est effectivement très bon > (et arrive à ouvrir tous les types de PDF)... alors que que je trouve Evince > très lent lors qu'on affiche un diaporama plein écran, bien qu'Evince et > Okular sont basés sur la même bibliothèque. ben qu'est ce que ça doit être avec Evince : j'ai remarqué que Okular quoique convenable est quand même assez lent par rapport à Acroread sur de gros PDF complexes (beaucoup de textes et d'images) lorsque l'on passe très rapidement les pages mais bon, c'est pas encore ça qui va me le faire changer mais il y a certainement des optimisations à faire (probablement sur le moteur de rendu) sinon, j'aime bien certaines fonctionnalités que d'autres non pas (y compris Acroread) : - la possibilité de lire plein de formats différents tel que le PostScript et d'autres grâce entre autre au paquet okular-extra-backend - le fait que l'on puisse lui passer un URL en paramètre ou bien un fichier compressé .gz ou .bz2 sans avoir besoin de le téléchargé d'abord ou de décompresser le fichier en question ça parait tout bête mais de nombreux autres reader ne le font pas et ça simplifie grandement les choses pour traiter les appels mime-type / mailcap à partir d'autres programmes (mutt par ex.) - le fait de pouvoir annoter un fichier PDF n.b. : Evince le permet aussi mais ni l'un ni l'autre ne gère ça correctement (i.e. sous la forme d'un fichier .fdf) comme on pourrait l'espérer ce qui serait vraiment une "killer feature" et permettrait de s'affranchir de la suite Adobe Acrobat (payante) pour tout un tas de travaux sur les fichiers PDF - dernière fonctionnalité sympa : le non respect (si on le désire) des anti-fonctionnalités (anti-features) du format pdf tels que la restriction sur l'impression ou l'extraction (copie) de texte cf. http://lwn.net/Articles/335415/ -- Cyril Chaboisseau
