Gwenole Beauchesne a écrit 188 commentaires

Bon c'était ma vie, tout ca pour dire que juste avec "-O2 -fomit-frame-pointer", c'est *tres* léger comme optimisation.

Non, sur x86_32, c'est l'essentiel du gain de performances: +15% en moyenne dans mon souvenir. Le reste est du pur "bruit": +1 ou +2.5% max.

Au fait, -finline-functions par défaut n'est pas une bonne idée car la taille de ton code augmente pas mal. Autant laisser GCC choisir. Pour -frename-registers, outre le fait d'être potentiellement boguée, cette option n'apportera rien sur du x86.

Il existe déjà un plugin natif Java pour x86_64 mais c'est une version 1.4 et il a quelques soucis avec des environnements récents. Pour le reste, si le JDK7 vient effectivement avec les sources du plugin (ce qui n'est pas le cas actuellement), il sera compilable pour x86_64 aussi.

Je ne pense pas que le JDK7 contienne le JIT ppc réalisé par Apple pour MacOS. À l'heure actuelle, il n'y a que x86, x86_64 & sparc. Bien sûr, c'est open source et tout le monde pourra y contribuer. Ca ne veut pas dire que ce sera trivial non plus mais dans l'absolu c'est "juste" un backend à ajouter.

IMHO. il manque "faire long feu" (échouer) / "ne pas faire long feu" (ne pas s'attarder). Tiens, je me demande si ce n'était pas une FAQ de fr.lettres ou assimilés.

Enfin, je crois me souvenir de la fabuleuse époque Usenet où quelqu'un argumentait (à raison sans doute) pour dire 'le film de Les Inconnus' et non 'le film des Inconus'. Qu'en est-il? Je n'ai plus la référence du thread...

Donc il n'y a pas de paquet qemu et kvm car ne c'est pas nécessaire.

Bien sûr que si. virt-manager n'est qu'un frontend qui d'ailleurs devra être modifié si une alternative à QEMU exploitant KVM sort. Les paquets existent mais sont dans Extras, ce que je trouve curieux pour quelque chose qu'ils mettent en avant.

Bon cela dit, nos packages qemu & virtualbox sont dans "contrib" aussi. Je devrais sans doute les déplacer tiens.

> Où sont les packages QEMU et KVM de Fedora?
Il n'y a pas. C'est dans le noyau, donc dans le paquet kernel.

Bien sûr, l'application qui utilise KVM et affiche quelque chose est dans le noyau. T'y crois vraiment?

> Le seul problème est que ça ne supporte pas encore les guests 64-bit.
Ni les guests 32-bits sur du 64-bits

Ca fonctionne. Le reste en s'en fout si l'utilisateur veut juste avoir une alternative libre à VMware Workstation.

- Travail en upstream. Peut être vu comme une conséquence du nombre de développeurs assez important de Red Hat/Fedora. Il y a souvent une bonne synchronisation entre les développements en upstream et la préparation d'une nouvelle Fedora.

Ou bien, une conséquence de recrutements d'ingénieurs travaillant déjà en upstream (ou ailleurs). Cela a pour effet que le nombre de leurs développeurs augmente et est important.

Fedora avait Xen et KVM est l'avenir, ben Fedora passe à KVM.

Où sont les packages QEMU et KVM de Fedora? Extras n'était pas censé être mergé dans la branche principale?

BTW, VirtualBox est l'avenir aussi d'un point de vue user-friendliness et performances. ;-) Le seul problème est que ça ne supporte pas encore les guests 64-bit.

En faisant abstraction de l'aspect "augmentation de débit", Noos vient de lancer un service universel à 4 EUR/mois incluant télé (TNT et autres), net (256 kbps), téléphonie (pas illimité hein). Par contre, il faut que ta copropriété bénéficie déjà d'un contrat de service collectif ("service antenne" anciennement).

Cela me paraît être une ligne de secours intéressante pour les dégroupés totalement voire ceux partiellement avec téléphone wifi. ;-)

Autrement, y'a pas moyen d'avoir un 'freewifisecours' ? Le problème étant l'authentification...

Il y en a d'entre vous qui ont reussit a faire fonctionner un windows sur Xen ?

Oui, Mandriva était la seule distro à faire une démo de Windows XP sous Xen au salon Solutions Linux 2006 (vers février dernier IIRC). Bon par contre, à l'époque il y avait une technique pour avoir le Windows en full color (plusieurs reboots), et l'utilisation du curseur n'est pas terrible (avec la SDL en tout cas).

glibc: je ne savais même pas que la 2.5 était sortie. Pour quelque chose d'aussi critique, on ne s'empresse pas de le packager, en plus avec des options bleeding-edge

La glibc est toujours CVS released. Il n'y a pas d'annonce à faire, elle s'adresse exclusivement aux mainteneurs respectifs des distros. De toutes façons, je n'ai jamais vu une distro fournir la glibc pristine que l'on peut trouver en tarball sur FTP...

gc, oublie le Pentium D, c'est un processeur totalement obsolète. Donc, effectivement, dirige toi gailardement vers l'achat d'un Core 2 Duo. Avec une préférence pour un modèle avec 4 Mo de cache si tu veux. ;-)

Concernant, les performances, le message en [2] n'a pas de sens. Recompiler pour x86_64 optimise de facto pour cette architecture (data 64-bit, deux plus de registres, etc.). Il n'y a pas d'optimisation "64-bit" à faire. Le gain de performances typiquement constaté est de l'ordre de +20% (depuis 4+ ans que j'utilise et compile avec).

Concernant les packages 32-bit, urpmi te les installera sans problème si tu fournis une source 32-bit et passe l'option --strict-arch (pour les updates). Il n'y a pas de soucis, ça installe juste les libs 32-bit nécessaires. Au passage, la glibc de Mandriva Linux est naturellement biarch.

Concernant le support i965, sache qu'il existe actuellement 2 problèmes dans Mesa. Un trivialement fixable (pb d'aliasing dans le sens règles du C), un autre qui l'est beaucoup moins (pb de textures dans certains cas). Je ne connais pas les performances de la puce, apparemment UT2004 est jouable, mais je ne sais pas si c'est un jeu gourmand non plus...

Il te faut un CPU rev.F pour supporter Pacifica. Typiquement ce sont des CPUs en socket AM2. Xen supporte déjà AMD-v.

Ou voir ce que donnent réellement les implémentations PowerPC de P.A. Semi. Perfs annoncées: 1100 en SPECint2k @ 2 GHz pour 15W.

Ca donnera un coup de pouce à l'image de Linux dans le monde des jeux. Les gamers sauront à quoi ça ressemble, que des jeux peuvent très bien marcher dessus, etc.

Cela suppose que les jeux PS3 tournent sur Linux, ce qui ne peut être vérifié pour l'instant. Je pense plutôt que Linux pourra dire que "hey, la PS3 ne sert pas qu'à jouer!". Ou faire des noeuds de calcul pour des tâches bien vectorisables, etc.

Les gamers verront surtout la puissance des SPEs et du chip graphique. Et avec un écran respectable, le niveau de détail devrait être bien appréciable. ;-)

Mais si les jeux se passnt de directX et utilisent nos librairies déja.. :-)

Wikipedia indique juste que la PS3 utilise PSGL, une version modifiée d'OpenGL ES. Mais bon, Wikipedia n'est pas la source ultime d'informations non plus.

Effectivement, les Core 2 du marché supportent totalement x86_64 et la Mandriva Linux 2007 pour x86_64 les supporte très bien aussi (que ce soit les CPUs de l'offre desktop, mobile ou serveur).

Par contre, je ne trouve pas la page citée très intéressante dans la mesure où l'évaluation de performances de Gentoo est plutôt approximative et les gens s'extasient facilement devant de micro-gains négligeables (inférieurs à 5%).

En particulier, je ne pense pas que spécifier une archi nocona (Netburst) soit raisonnable pour la nouvelle micro-architecture Core 2...

Précision: il existe cependant une Corporate Server pour ppc64 (IBM POWER5). Nous avons donc la capacité à le faire, modulo que les clients financent le développement et la maintenance du produit.

En fait, un autre avantage du préfixe "drak" est de pouvoir composer des noms courts. Le suffixe "drake" est effectivement totalement obsolète. Idéalement, "mandriva-config-" [*] pourrait être utilisé (e.g. mandriva-config-3ddesktop) mais c'est in fine assez sous-optimal à taper, même avec completion. Mais, c'est plus agréable à l'oeil, je trouve.

[*] Je dis "mandriva-config-" mais ça peut être autre chose car drakrpm, par exemple, n'est pas de la config en soi. Il est vrai cependant que tout nouveau package devait exclure les mentions "drak" et "drake".

Un des bugs de compiz est trivialement fixable. Par contre, ce n'était pas d'une grande utilité. Autant laisser compiz crasher et fallbacker dans un mode fonctionnel que de le laisser continuer pour causer d'autres problèmes qui rendent le système inutilisable. Cela dit peut-être que ça fonctionne avec la dernière beta publique mais elle n'était pas encore dispo à l'époque pour tester.

Je crois même qu'il faut être trois -- le transitaire du document. ARDI (ROMlib MacOS clean-room) avait quelques paragraphes à ce sujet.

La nature de l'algorithme utilisé par RAR fait que les processus de compression et de décompression sont très similaires. i.e. a priori, la construction des modèles se fera de la même manière.

Par ailleurs, je crois que RAR permet de recompresser certains fichiers multimedia. Genre un filtre à un JPEG pour le recompresser avec un range coder plutôt qu'un Huffman. Mais là j'en sais rien, je ne me suis pas suffisamment plongé dans la compression de données multimedia pour maîtriser les détails...

D'un autre côté, de nos jours, l'algorithme de compression est plutôt connu. Tout comme Winzip, ils utilisent maintenant PPMd dans RAR v3. Winzip a l'air de jouer le jeu en essayant de documenter le format. Par contre pour RAR, je crois que l'algorithme d'origine a été quelque peu altéré (dans la partie range coder) et le format de l'archive est totalement inconnu, a priori.

PPMd est dans le domaine public. D'ailleurs, Dmitry a releasé une version 64-bit clean (v.J) en mars dernier.

JITrino est dans l'arbre subversion mais après un rapide coup d'oeil, c'est très ia32 spécifique pour l'instant. Comme Hotspot (server), la forme intermédiaire est SSA. Par contre, je me demande pourquoi ils n'ont pas préféré opter pour une interface à LLVM, voire au JIT de Mono qui n'a pas l'air mauvais non plus.

Mais est-ce que des bugs sont rapportés à Intel au moins? Comme pour tout logiciel, s'il n'y a pas de bug report, ils ne vont pas le deviner. Et il ne suffit pas de dire "xine segfaulte de temps en temps" non plus hein. ;-)

Pour Basilisk II par exemple, ils ont corrigé 2 bugs (une miscompilation et une internal compiler error).

Ca serait interessant de faire un sondage, pour savoir ce qui vont rester chez Mandriva après ce coup la, ou ceux qui partiront.

Je voudrais bien partir et m'installer un autre OS Linux, mais je ne sais pas lequel choisir : j'adore KDE et j'aimai bien la manière de Mandriva à avoir des updates simples.

Supposons que tu aimes une marque de yaourts. En tant qu'utilisateur ("consommateur" en l'occurrence), vas-tu en changer parce que le fondateur de Yoplait, Danone, Mamie et al. est parti? Par ailleurs, tu pourrais aussi choisir une marque particulière parce qu'ils ont une plus-value ou des points uniques. e.g. perso, je choisis des Yoplait parce qu'ils n'y a qu'eux qui font des yaourts avec de l'ananas.

En résumé, en tant qu'utilisateur, pourquoi quitter Mandriva pour la concurrence si cette distribution te convient?

Il est dommage de nommer un nouveau projet "Lightning" alors que "GNU Lightning" (un run-time assembler -- assembleur à la volée) existe déjà depuis plus de 5 ans. Pour ceux qui le packagent, comme Debian, il pourra y avoir un conflit de nom.