Voici un lien en anglais avec plus d'infos:
http://www.download.com/8301-2007_4-10097931-12.html
Ils expliquent que le 64 bits s'est développé plus rapidement sous linux que sous les autres OS, notamment grâce à la philosophie de recompilation à partir des sources.
En conséquence, le support 64 bits est proposé en exclusivité pour linux! Seul bémol, c'est encore une version alpha.
Journal Flash version 64 bits pour linux exclusivement!
17
nov.
2008
# et pour télécharger ?
Posté par BAud (site web personnel) . Évalué à -2.
et un changelog aussi ?
(ah on me souffle dans l'oreillette que question licence, ce n'est toujours pas ça et que Adobe prendrait ses utilisateurs pour des bêta-testeurs gratuits).
[^] # Re: et pour télécharger ?
Posté par cedbor . Évalué à 2.
Il y a quand même un forum pour discuter des problèmes
[^] # NE SURTOUT PAS TÉLÉCHARGER !
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 6.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: NE SURTOUT PAS TÉLÉCHARGER !
Posté par Sébastien B. . Évalué à 1.
[^] # Re: NE SURTOUT PAS TÉLÉCHARGER !
Posté par Ph Husson (site web personnel) . Évalué à 8.
[^] # Re: NE SURTOUT PAS TÉLÉCHARGER !
Posté par guppy . Évalué à 3.
Les processeurs de pc de bureau ont également ce genre de chose. Mais c'est arrivé en premier pour les portables, évidemment.
[^] # Re: NE SURTOUT PAS TÉLÉCHARGER !
Posté par Ph Husson (site web personnel) . Évalué à 2.
[^] # Re: NE SURTOUT PAS TÉLÉCHARGER !
Posté par Fabimaru (site web personnel) . Évalué à 5.
Sinon il y a toujours FlashBlock.
# Enfin...
Posté par Snarky . Évalué à 10.
Sinon, c'est quoi cette philosophie de la recompilation !? C'est nouveau, on compile pas sur les autres plateformes ? On écrit directement les .exe à la mano ? Ça expliquerai beaucoup de choses !
[^] # Re: Enfin...
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 10.
«The 64-bit support will arrive on other operating systems later, Adobe said, but Linux fans get it first because they were the most vocal in their desire for it.»
En gros, on l'aurait en premier parce qu'on a gueuler les plus forts ;-)
[^] # Re: Enfin...
Posté par Badeu . Évalué à 10.
[^] # Re: Enfin...
Posté par ubitux . Évalué à 10.
Alors certes le player est closed source, et ils méritent le bûcher pour ça, mais en même temps, on aurait plus aucune raison de leur cracher dessus, et ce serait dommage.
En passant, y'a la version de swfdec 0.9.2 qui est sortie (en « instable »)
Pour en revenir sur Flash, c'est quand même une bonne chose cette édition 64 bits. On pourra d'ailleurs noter l'humour du développeur principal :
"I feel a bit sentimental about it all. It's weird, but I think I'm going to miss the hundreds of comments on every post gently requesting a 64-bit version. So don't be afraid to pop in with a "64-BIT NOW!!!1!!" comment every so often, you know, just for old time's sake."
Source : http://blogs.adobe.com/penguin.swf/2008/11/now_supporting_16(...)
[^] # Re: Enfin...
Posté par benoar . Évalué à 5.
Bon, j'allais encore gueuler sur le fait qu'on ne sait toujours pas si c'est vraiment ouvert, mais en fait, si : faut aller chercher au fin fond de la FAQ http://www.openscreenproject.org/about/faq.html
Alors je veux bien que ceux qui gueulent soient chiants des fois, mais là les pro-Adobe ne font absolument _rien_ pour montrer que l'engagement de cette boite a l'air de changer un petit peu en faveur du libre^W^W de l'open source.
[^] # Re: Enfin...
Posté par benoar . Évalué à 2.
C'est la réaction des devs de Gnash/swfdec.
Ha, et aussi : le lien vers les précisions concernant les licences donne un 404 ... franchement, faudrait qu'ils fassent un petit effort.
[^] # Re: Enfin...
Posté par TImaniac (site web personnel) . Évalué à 6.
"What Adobe announced is the release of the SWF specification without the license agreement. The specification has never included a license to third-party technologies like codecs, which is still true today. Thus, developers of SWF-compliant applications are responsible for ensuring that their implementations do not infringe on the intellectual property rights of others, including those of codec providers."
Ce qui n'est pas vraiment étonnant en soit, Adobe ne maîtrisant pas les codecs utilisés.
[^] # Re: Enfin...
Posté par NickNolte . Évalué à 1.
Je pense que niveau cevrage, c'est pas mal, non?
à moins de le libérer, je n'y replongerais pas!
# la vraion raison
Posté par TImaniac (site web personnel) . Évalué à 6.
"We chose Linux as our initial platform in response to numerous requests in our public Flash Player bug and issue management system and the fact that Linux distributions do not ship with a 32-bit browser or a comprehensive 32-bit emulation layer by default."
ce qui se traduit par :
Nous avons choisi Linux comme plateforme cible initiale en réponse aux nombreuses requêtes dans notre tracker, ainsi qu'au fait que les distributions Linux ne proposent pas de navigateur 32bits ou une couche d'émulation 32bits par défaut.
Bref, si Linux est la cible initiale, c'est parcque c'est indispensable sur cette plateforme. Sous Mac ou Windows 64 bits, y'a pas le problème, le plugin 32 bits fonctionne.
[^] # Re: la vraion raison
Posté par suJeSelS . Évalué à 1.
[^] # Re: la vraion raison
Posté par Snarky . Évalué à 5.
>> ainsi qu'au fait que les distributions Linux ne proposent pas de navigateur 32bits ou une couche d'émulation 32bits par défaut
[^] # Re: la vraion raison
Posté par suJeSelS . Évalué à 1.
Bref il ne faut pas en faire une généralité, toutes les distributions ne proposent pas de navigateur 64 bit par défaut.
[^] # Re: la vraion raison
Posté par Pinaraf . Évalué à 4.
nspluginwrapper est utile aussi pour faire tourner un plugin 32bits dans un navigateur 32bits, si on souhaite l'isoler pour qu'il plante son processus plutôt que le navigateur.
[^] # Re: la vraion raison
Posté par Dup (site web personnel) . Évalué à 3.
(bon pour faire cette manip faut être équipé en win64, peu ici pourront le faire moi je l'ai remarqué au taffe ;))
[^] # Re: la vraion raison
Posté par Zorro (site web personnel) . Évalué à 1.
Le Windows Media Player par défaut aussi est en 32 bits, mais en installant un pack de codecs 64 bits et en modifiant une entrée de la base des registres, on peut le lancer en 64 bits.
[^] # Re: la vraion raison
Posté par totof2000 . Évalué à 10.
Quelle convivialité !!!
[^] # Re: la vraion raison
Posté par SKBo . Évalué à -2.
Très franchement, je vois mal la différence avec une distrib linux classique…
Mais bon, c'est prêt pour le desktop d'après certains.
[^] # Re: la vraion raison
Posté par pasBill pasGates . Évalué à -2.
[^] # Re: la vraion raison
Posté par TImaniac (site web personnel) . Évalué à 8.
[^] # Re: la vraion raison
Posté par abramov_MS . Évalué à 4.
[^] # Re: la vraion raison
Posté par pasBill pasGates . Évalué à -1.
C'est bien, tu vas pouvoir nous expliquer lequel...
et je suis aussi a peu pres sur aussi qu'un plugin flash, qui permet entre autre, de voir de la video HD peut avoir un grand benefice d'un passage en 64 bits pure.
Ca aussi tu vas pouvoir nous l'expliquer...
Pour t'aider:
a) il n'y a pas besoin d'avoir un systeme 64bit pour lire des fichiers de >4Gb
b) Les processeurs 32bit existant peuvent faire des operations sur des donnees 64bit(genre multiplier des entiers 64bit), comme les CPU 64bit
[^] # Re: la vraion raison
Posté par thedidouille . Évalué à -2.
[^] # Re: la vraion raison
Posté par pasBill pasGates . Évalué à 4.
[^] # Re: la vraion raison
Posté par abramov_MS . Évalué à 1.
Et juste pour le plaisir:
de tout de facon ton boss t'a bien dit que "640 Ko (environ 0.6 MO) devraient suffire a tout le monde" donc je comprend meme pas pourquoi vous en 32 bits pour windows...
:)
[^] # Re: la vraion raison
Posté par pasBill pasGates . Évalué à 0.
Mais si tu as qqe chose qui prouve l'inverse, fais seulement hein... je suis toujours ouvert a apprendre des trucs nouveaux.
[^] # Re: la vraion raison
Posté par TImaniac (site web personnel) . Évalué à 0.
Allez je t'aide, c'est par là :
http://fr.wikipedia.org/wiki/64_bits
Oui le passage de 32 bits à 64 bits indique juste un changement de la taille des registres manipulés par le processeur, ce qui n'a pas grand chose à voir avec les perfs de traitement.
Encore une fois, t'as perdu l'occasion de te taire.
[^] # Re: la vraion raison
Posté par khivapia . Évalué à 10.
(voir par exemple http://www.hardware.fr/articles/478-3/amd-athlon-64-athlon-6(...) pour la liste des registres et leur modification)
(ça se voit d'ailleurs nettement en java, désolé je n'ai pas de benchmark objectif pour le montrer, mais c'est sensible).
[^] # Re: la vraion raison
Posté par Pinaraf . Évalué à 3.
Attention, si t'as fait ton test uniquement avec la JVM de Sun, as-tu bien utilisé la JVM server en x86 ?
En effet, Sun a décidé (pour une raison inconnue) de ne pas porter la JVM client sur x86-64. La JVM server consomme plus de mémoire vive, démarre les logiciels un peu plus lentement mais, en contrepartie, compile bien plus de bytecode en code natif.
Au passage tiens, pourquoi y'a besoin d'un plugin pour utiliser Java dans un navigateur web ? Dans Konqueror il suffit d'indiquer l'emplacement de Java...
[^] # Re: la vraion raison
Posté par Gwenole Beauchesne . Évalué à 4.
Ce n'est pas tout à fait exact. En fait, il y a des optimisations de code plus poussées et comparables à un compilateur statique dans HotSpot server. Par exemple, dans mon souvenir, HotSpot server fait une allocation de registres par coloration hiérarchique de graphe alors que HotSpot client utilise l'algo linear scan (variante de Poletto?). Une autre différence, je crois, c'est que hotspot server optimise au niveau super bloc (traces) alors que hotspot client le fait "juste" au niveau bloc de base. HotSpot server ferait aussi de l'inlining et de la spécialisation de méthode.
[^] # Re: la vraion raison
Posté par TImaniac (site web personnel) . Évalué à 0.
Oué bah oué les processeurs ont évolués au passage, mais c'est pas directement lié à la taille des registres sur 64 bits en soit, les processeurs évoluent généralement d'une génération à une autre hein :)
[^] # Re: la vraion raison
Posté par fcartegnie . Évalué à 4.
Un bench on le fait sur le meme cpu en mode 32 et en 64... c'est le même processeur
[^] # Re: la vraion raison
Posté par TImaniac (site web personnel) . Évalué à 1.
Et encore, je suis même pas sûr que ce soit représentatif, vu que je suis pas sûr que le mode 32 bits soit implémenté comme le mode 64 bits sur le processeur.
[^] # Re: la vraion raison
Posté par Ph Husson (site web personnel) . Évalué à 4.
phh @ phh-desktop ~ % cat test2.c
#include <stdio.h>
#include <sys/time.h>
#include <time.h>
int main(int argc, char **argv) {
long long i;
struct timeval tv1,tv2;
for(i=0;i<=1024*1024*1024;i++);
printf("%lld\n", i);
}
phh @ phh-desktop ~ % gcc test2.c -o test2 -m32 ; time ./test2
1073741825
./test2 4,68s user 0,00s system 99% cpu 4,699 total
phh @ phh-desktop ~ % gcc test2.c -o test2 ; time ./test2
1073741825
./test2 3,37s user 0,00s system 99% cpu 3,394 total
Résultats reproductibles à moins de 10% de marge sur mon système (Core 2 Q6600 sur une kubuntu intrepid). En ce qui concerne les registres spécifiquement ca serait pas trop dur mais fastidieux à faire, m'enfin ca montre déjà que y a un gain à avoir (à moins que ce soit au niveau de gcc, mais j'ai essayé une paire d'options ca changeait rien à part -Ox qu'est trop intelligent)
[^] # Re: la vraion raison
Posté par fcartegnie . Évalué à 2.
[^] # Re: la vraion raison
Posté par Sébastien B. . Évalué à 4.
Bah oui, dans le référentiel terrestre, le soleil tourne autour de la Terre.
[^] # Re: la vraion raison
Posté par Gof (site web personnel) . Évalué à 2.
[^] # Re: la vraion raison
Posté par dkremer . Évalué à 3.
lien : http://www-cs-faculty.stanford.edu/~knuth/news.html
traduction :
A Flame About 64-bit Pointers
Une diatribe enflammée à propos des pointeurs 64 bits
C'est absolument idiot de disposer de pointeurs sur 64 bits quand je compile un programme qui utilise moins de 4 gigabytes de mémoire vive. Lorsque des valeurs de pointeur de ce genre apparaissent dans une structure (NdT : structure type langage C je pense) , elles ne gâchent pas seulement la moitié de la mémoire vive, mais elles foutent également à la poubelle la moitié de la mémoire cache.
La page de manuel de GCC prévient qu'il existe une option "-mlong32" qui semble correspondre à ce que je veux utiliser. En effet, je pensais qu'elle allait compiler le code pour mon architecture x86-64, en utilisant les avantages des extra-registres (NdT : propres aux x86-64) etc, mais en permettant à mon programme d'exister dans un espace d'dressage virtuel de 32 bits. Malheureusement, l'option -mlong32 a été introduite pour les ordinateurs MIPS, il y a des années. Probablement qu'elle n'est jamais utilisée parce que les programmes qui sont compilés avec auront besoin d'être chargé avec une version spécial de la libc.
S'il vous plaît , quelqu'un. Essayez de transformer mon voeux en réalité.
NdT : Désolé pour la traduction approximative
[^] # Re: la vraion raison
Posté par Gwenole Beauchesne . Évalué à 2.
Pour x86_64, des patches existent je crois chez Code Sourcery pour VxWorks. Par contre, ça utilise le préfixe addr32 ce qui n'est pas recommandé (en termes de performances, selon les docs d'Intel).
[^] # Re: la vraion raison
Posté par abramov_MS . Évalué à 1.
http://linuxfr.org/submit/comments,27503,983230,5.html#reply
[^] # Re: la vraion raison
Posté par Pinaraf . Évalué à 2.
Là tu joues à la provoc on dirait.
Quelques chiffres sur le 32 vs 64 bits :
- http://64-bit-computers.com/windows-vista-32-bit-vs-64-bit-b(...) sous windows vista (je vois venir le gnagna oui mais c'est pas forcément les mêmes pilotes ou une connerie de ce genre), 10% de bonux pour le 64 bits apparemment
- http://forums.amd.com/devblog/blogpost.cfm?threadid=93648&am(...)
Flemme de chercher plus en fait. Dans l'ensemble la compression et le multimedia s'en sortent considérablement mieux en 64 bits qu'en 32 bits... Bien sûr tout n'est pas blanc, sur phoronix on peut trouver un benchmark où, dans les jeux 3D, le 64 bits se prend quelques FPS dans la gueule...
[^] # Re: la vraion raison
Posté par pasBill pasGates . Évalué à 0.
Mon point pour Albert etait de lui faire comprendre que simplement passer d'un CPU 32bit a 64bit n'amene rien si ce n'est un espace d'addressage plus large.
Un CPU 64bit qui n'aurait pas ces registres supplementaires(et c'est tout a fait concevable) n'aurait aucun autre avantage q'un espace memoire plus large.
[^] # Re: la vraion raison
Posté par abramov_MS . Évalué à -1.
Je pense que tous le monde aura compris que ton message http://linuxfr.org/comments/983230.html#983230 etait encore une tentative (joliment avorte) de me faire passer pour un con et de m'humilier. J'ai comme l'impression que il y a eu un leger retour de boomerang sur le coup...
[^] # Re: la vraion raison
Posté par pasBill pasGates . Évalué à 3.
Ah tiens c'est uniquement la quantite de memoire que l'on peut utiliser le pourquoi on utilise des processeurs 64 bits... Je sais pas pourquoi mais je suis a peu pres sur qu'il y a d'autre problematique que la memoire
et la reponse est effectivement que la memoire (espace d'addressage pour etre precis) est reellement le pourquoi des CPU 64bit, il n'y a AUCUNE garantie qu'un CPU 64bit soit plus rapide qu'un CPU 32bit
L'objectif n'etait pas de te faire passer pour un con (tu y arrives tres bien tout seul quand tu veux), mais te faire comprendre que la difference entre 32bit et 64bit, c'est uniquement ca.
[^] # Re: la vraion raison
Posté par Ph Husson (site web personnel) . Évalué à 4.
On parle de Windows Vista, d'XP, et de flash, donc on parle bien de x86 VS x86-64, et pas juste du 32bits vs 64bits.
[^] # Re: la vraion raison
Posté par TImaniac (site web personnel) . Évalué à 2.
On pourrait parler de IA-64 aussi :)
[^] # Re: la vraion raison
Posté par dinomasque . Évalué à 2.
BeOS le faisait il y a 20 ans !
[^] # Re: la vraion raison
Posté par Ph Husson (site web personnel) . Évalué à 3.
[^] # Re: la vraion raison
Posté par herodiade . Évalué à 4.
> de ces perfs est due au fait que le l'amd64 a des registres en plus notamment.
Il y a aussi un avantage pratique (ou "stratégique"), non inhérent aux spécificités du x86_64, mais dû au champ d'utilisation du IA32 (et à son âge).
Dans le cas spécifique des distributions Linux (et je suppose que ça doit être aussi vrais pour certains binaires distribués pour win32), les binaires x86 sont compilés en ciblant la compatibilité avec les vieux pentiums 686 - quand ce n'est pas carrément la compatibilité avec les 486 (par ex. chez Debian). Dans tout les cas, lorsque ce n'est pas explicitement demandé (-mcpu & co), et en 32bits, GCC produit des binaires qui peuvent tourner tels quels sur un 486.
Les jeux d'instructions et fonctionnalités ultérieurs aux vieux pentiums ne sont généralement que peux exploités dans les paquets binaires pour Linux (ie. seulement si c'est suffisamment modulaire pour être activé dynamiquement, et si le développeur les a écrit explicitement à la main). Si bien que certaines distributions, qui s'efforcent de conserver la compatibilité avec les x86 pré-pentiums, distribuent deux paquets distincts pour la libc (une "libc" tout court et une libc-i686). Mais ce procédé, couteux en temps de maintenance, n'a pas été généralisé aux autres paquets.
En revanche, tout les x86_64 supportent les jeux d'instructions supportés par les pentium4, dont le compilateur peut alors tirer partis sans affecter la compatibilité. Aussi, les binaires x86_64 (qui n'existent que depuis peu) affranchissent le compilateur de ce besoin de rétro-compatibilité avec des processeurs vieux de presque 20 ans. GCC peut s'efforcer, avec plus ou moins de succès, d'exploiter les instructions et fonctionnalités des CPUs x86 modernes.
Je ne crois pas que ça fasse une très grande différence pour un navigateur comme firefox cela dit. D'après le blog d'un développeur de flash, ça ne change rien pour flash non plus, dans la mesure où les développeurs de ce logiciel écrivent eux même à ma main les parties critiques en assembleur optimisé modulairement selon les jeux d'instructions disponibles à l'exécution (ce qui fait, au passage, qu'il leur a fallu beaucoup de temps pour faire ce port x86_64 de flash).
Donc dans ce cas précis on peux supposer qu'il est peu probable qu'un flash 64 bits améliore les performances (en termes d'efficacité CPU uniquement, parce qu'être obligé d'avoir sur disque et chargé en mémoire les libs 32 bits, c'est quand même du gachis de ressources à mon gout). Mais en pratique, et dans le cas d'une distribution Linux, on ne peux pas généraliser ce constat en disant que le 64bits n'apporte aucun autre gain qu'un plus grand espace d'adressage.
Et je ne sais pas vous mais je vois malheureusement venir à grands pas le jour où firefox utilisera régulièrement plus de 3 Go de ram /o\
[^] # Re: la vraion raison
Posté par Pinaraf . Évalué à 1.
Suffit de continuer à utiliser nspluginwrapper pour isoler Flash de Firefox. J'ai diminué comme ça de 40% la mémoire utilisée par Firefox sur ma machine....
[^] # Re: la vraion raison
Posté par Gwenole Beauchesne . Évalué à 3.
[^] # Re: la vraion raison
Posté par Pinaraf . Évalué à 2.
[^] # Re: la vraion raison
Posté par thedidouille . Évalué à 2.
Surtout, ça simplifie la conception de CPU plus performant à terme.
[^] # Re: la vraion raison
Posté par pasBill pasGates . Évalué à 2.
Ok, je --> []
[^] # Re: la vraion raison
Posté par GCN (site web personnel) . Évalué à 6.
Vista aura tout bouffé avant....
~~~~> []
[^] # Re: la vraion raison
Posté par totof2000 . Évalué à 4.
Mais si tu veux, oui ça me pose problème d'utiliser un soft en mode 32 bits sur une archi 64 bits. Tout simplement parce que mon archi 64 bits je l'ai payée et que j'aimerauis en profiter ...
Avec un linux ou BSD, j'en profite sans problème.
[^] # Re: la vraion raison
Posté par TImaniac (site web personnel) . Évalué à 1.
mais le péquin moyen qui veut du convivial il en a rien à branler d'avoir un navigateur web en 64 bits. La convivialité, c'est lui proposer par défaut un navigateur qui va faire fonctionner la majorité des plugins qu'il va trouver sur le net.
[^] # Re: la vraion raison
Posté par Pinaraf . Évalué à 2.
[^] # Re: la vraion raison
Posté par TImaniac (site web personnel) . Évalué à 2.
Après tu vas me dire qu'on devrait pas avoir à cliquer, moi je te répondrais qu'il me paraît indispensable que l'utilisateur soit conscient qu'il va installer du code exécutable avec des droits potentiellement dangeureux sur ta machine. oui, sécu et convivialité font pas toujours bon ménage.
[^] # Re: la vraion raison
Posté par Pinaraf . Évalué à 1.
[^] # Re: la vraion raison
Posté par IsNotGood . Évalué à 4.
Chez Red Hat/Fedora, il y a le support 32bits pour 64bits depuis RH9 (bref, c'est très vieux).
Par contre, Fedora n'installe plus le support 32 bits depuis F9 ou F10 (depuis F10 c'est sûr). NB: il est toujours là, mais il n'est plus installé par défaut.
Enfin, depuis F8 il y a un "truc" pour utiliser des plugins 32 bits sur Firefox 64 bits.
Bref, pas de quoi se plaindre.
# et d'un !
Posté par Zorro (site web personnel) . Évalué à 4.
[^] # Re: et d'un !
Posté par ubitux . Évalué à 6.
[^] # Re: et d'un !
Posté par GnunuX (site web personnel) . Évalué à -1.
[^] # Re: et d'un !
Posté par MrLapinot (site web personnel) . Évalué à 3.
http://www.corsac.net/index.php?rub=blog&post=1404
[^] # Re: et d'un !
Posté par Zorro (site web personnel) . Évalué à 2.
IcedTea ne marche pas chez moi pour les impôts ni pour valider la signature de l'applet Java de mon disque dur distant NeufGiga.
Ce sont les 2 seuls truc Java que j'utilise, et ni l'un ni l'autre ne veut marcher avec IcedTea.
Sinon, c'est avec plaisir que je serai passé à IcedTea, évidemment.
[^] # Re: et d'un !
Posté par BAud (site web personnel) . Évalué à 3.
http://sophie.zarb.org/rpm/2009.0,x86_64/java-1.6.0-openjdk-(...)
Il faudrait que je réessaie, il marchait depuis icedtea hormis pour le webmail de LotusNotes (je soupçonne plus un souci avec une incompatibilité 1.4 et java6...).
http://cookerspot.tuxfamily.org/wikka.php?wakka=Verification(...)
[^] # Re: et d'un !
Posté par Zorro (site web personnel) . Évalué à 2.
[^] # Re: et d'un !
Posté par B16F4RV4RD1N . Évalué à 2.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: et d'un !
Posté par Gwenole Beauchesne . Évalué à 3.
Sans doute pour la 3.1 car il existe déjà des binaires x86_64 pour les nightly builds.
[^] # Re: et d'un !
Posté par Zorro (site web personnel) . Évalué à 1.
http://www.mozilla-x86-64.com/
Bon, ok, à mon avis c'est pas un projet officiel de Mozilla, mais c'est difficile à dire, vu qu'il y a pas d'informations sur leur site. Et c'est que des versions Windows, mais c'est pas grave, car les packageurs de nos belles distrib' s'occupent de nous faire des beaux paquets 64 bits tout prêts à l'emploi.
[^] # Re: et d'un !
Posté par foulmetal canette (site web personnel) . Évalué à 2.
D’autant plus que le look n’a rien à voir.
# Philosophie
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 0.
Ah ouais, quand meme !
C'est vrai que moi, sur mes autres OSs, tout marche mal car je recompile a partir de mouchoirs usagés.
Nan, mais c'est quoi cette raison de merde ? Sous Windows aussi on recompile les logiciels pour les tester ! Sous BSD aussi !
Puis s'ils avaient utilise' un vrai langage avec REPL (Scheme, CL, OCaml), ils auraient pu aller encore plus rapidement sans attendre de devoir recompiler tout le projet a chaque fois (les trois langages cités peuvent aussi au final se compiler tres efficacement, pour une aise de developpement incomparable)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.