PAE: Physical Address Extension
C'est une extension du x86 permettant d'adresser plus de 4Go de mémoire (64Go)
globilux wrote:le problème (si on peut appeler un problème) c'est que j'essaie d'installer une fedora 64 bits (à ce que j'ai entendu sur ce thread, c'est tout à fait possible. je rencontre des difficultés, par exemple je me retrouve avec deux k3b au lieu d'un seul (un en i386 et l'autre en x86_64). je l'ai pas essayer mais je parie qsue le flash player est encore buggé ...
Bien sur que c'est aisé! Sans comtper qu'avec F8 il automatise automatiquement la prise en charge de flash player en 32 bits, après... faut vraiment chercher pour que cela ne fonctionne pas! k3B en i386 et x86_64? et bien en fait c'est pour garder une compatibilité, mais rien ne t'empêche de le virer et de garder que le x86_64!

C'est marrant, mais c'était le même genre de discution à l'époque du passage du 16 au 32 bits! Ou la même discution entre les différentes version de ms windows, macos, etc... vous avez peur du changement?
C'est avec ce genre de raisonnement que nous avont trainé pendant des dizaines d'années le boulet ms dos sur ms windows! le 16 bits avec des systèmes 32... Maintenant qu'ont disent que sur du 64bits le 32 fonctionne très bien en même temps vous avez encore peur, alors que la transition se fait en douceur sans être un boulet infame!

Ce n'est pas un Itanium ou un alpha64 où la compatibilité était uniquement logiciel et ramer sur des choses que même un 386 faisait mieux! là le problème est inversé! les processeurs x86_64 sont de véritable 32bits avec le 64bits dans le cpu! donc faire tourner du 32 ou du 64bits il s'en fout! sauf qu'il devient plus aisé de l'avoir de base en 64bits vu que l'ont peut mixer avec du 32! Après c'est surtout au niveau des librairies, au cas où, qu'il faut avoir les deux, mais ce n'est pas obligatoire!!

Personnellement j'enlève tout ce qui me semble pas indispensable des i386, après je réinstalle en cas de besoin, ce n'est pas plus long et aussi difficile que cela! il suffit juste de le savoir, ce qui devrait être le cas vu le nombre de question et de réponses sur le sujet depuis.... quelques années! Mais bon... certains ont peur de perdre 5 minutes sur la configuration de leur machine, surtout que comparé à une installation sous MS win cela prend 3 à 10x plus de temps de base, donc bon... Surtout pour une chose dont adobe ne veut pas bouger son Q! les plugins wma/wmv? c'est du passé, le dépôt livna/rpmfusion propose tout ce qu'il faut et compatible sans problèmes avec les applications multimédia en 64bits (là c'est préparé pour fonctionner sur n'importe quel architecture!)! Plugins JAVA? ça arrive à grand pas, si ce n'est déjà le cas! Après je ne vois aucun commentaire pour d'autres applications/logiciels! donc c'est des raisons minimes qui ont des solutions très simple (surtout avec la dernière Fedora!), il suffit de lire la documentation dans 99,99% des cas!
Pour k3b en i386 et x86_64, c'est parce qu'en l'installent, tu as fait "yum install k3b", alors que pour n'en installer qu'un seul, tu aurais du faire "yum install k3b.x86_64" ou "yum install k3b.i386" !!
C'est pas parce que yum install par défault les deux versions (pour les raisons su-citées par VINDICATORs) que tu es obligé de prendre les deux !!

Pour le flash (et le java), tout le mode dit que c'est le gros problème du 64 bits ... ca l'était p-t-e il y a qques années (personnellement, j'installais firefox.i386) mais, maintenant le plugin java gcj (qui fonctionne très bien) et nspluginwrapper, sont installés par défault sur F8 !!
Pour installer flash, il suffit de deux commands !! 
#rpm -ivh http://fpdownload.macromedia.com/get/flashplayer/current/flash-plugin-9.0.48.0-release.i386.rpm
#nspluginwrapper -i /usr/lib/mozilla/plugins/libflashplayer.so
Je ne vois pas quels problèmes ca peut poser ...
Et encore avec la F8 j'ai même pas eu besoin de le faire, dès l'installation de flashplayer il l'avait fait!
Notons que Adobe prévoit que ça prochaine version supporte les systèmes multi-cœurs nativement, ceci est en version d'essai ...
Mouhais... si c'est comme la promesse du support du 64bits... et bien on peut attendre que les poules aient des dents (zut! c'est déjà arrivés!)

Après... le multicoeur... euh ça vas servir à quoi? parce que bon... c'est pas sa qui vas saturé les cpu actuel même en un seul coeur! donc ça sert à rien (qu'ils optimise pour l'open gl là ça apportera qqchose!).
il y a 15 ans les gens pensais la même chose pour les CPLD (en électronique) evolution des PLD visant a en mettre plusieurs dans le même boitier

aujourd'hui le CPLD est 20 plus puissant que son ancètre
alexip wrote:
#rpm -ivh http://fpdownload.macromedia.com/get/flashplayer/current/flash-plugin-9.0.48.0-release.i386.rpm
#nspluginwrapper -i /usr/lib/mozilla/plugins/libflashplayer.so
j'ai fait cela sous f7 mais cela buggait je sais opas si le bug est corrigé
Chez moi, en tout cas, je ne vois pas la différence entre le plugin i386 et le plugin émulé en x86_64 !!
Depuis que je l'ai, il n'a pas planté ! et il n'est pas plus lent qu'en natif !

Sous F7, j'avais pas testé (j'l'avais fait sous fc6 en ca foirait pas mal, c'est plus le cas mnt), mais tes bugs peuvent aussi venir simplement du plugin de chez adobe ... chez moi, il plantait même en natif (quand il y avait trop d'apli flash en même temps, genre des pubs, mais tout les clients flash font ca, même le win32) !
Moi j'ai utilise F7 x86_64 et j'ai installe F8 x86_64. Pas de probleme logicielle, j'ai juste mis un peu de temps a comprendre comment nspluginwrapper est cense marcher (j'ai les codecs proprietaires aussi... enfin j'arrive a lire du real media... c'est le seul que j'ai teste puisque c'est le seul dont j'ai eu besoin).

L'OS 32 bits sur un PC 64 bits c'est de la prudence non necessaire.
@alexip: c'est normal, il n'est pas émulé, il tourne en natif, tu as un mode 32 bits dans le long mode (64bits). nspluginwrapper fait l'interface entre ton navigateur et le plugin afin qu'ils se comprennent.
@milady: ça peut toujours servir à quelqu'un.
Salut.

Je pense qu'il serait temps de préciser ce qu'est un processeur 8, 16, 32, 64 bits et l'impact sur les registres d'adresse et de données, la taille des transferts et l'espace d'adressage et le lieu avec un OS... J'ai l'impression que c'est pas clair pour tout le monde.


++
Quand je parlé d'émulation c'était avec les cpu 100% 64bits avec par exemple l'ITANIUM d'Intel! du moins dans sa première génération!
itanium n'est *pas* un x86. C'est "autre chose", une architecture completement differente, dont les performances sont tres tres dependantes du compilateur. Beaucoup plus que sur de l'x86.

Et c'est pas parce que l'x86_64 est retro-compatible x86/32bits qu'il est pas 100% 64bits.
eddy33 wrote:Salut.

Je pense qu'il serait temps de préciser ce qu'est un processeur 8, 16, 32, 64 bits et l'impact sur les registres d'adresse et de données, la taille des transferts et l'espace d'adressage et le lieu avec un OS... J'ai l'impression que c'est pas clair pour tout le monde.


++
oui c'est vrai ce serait bien

je suis maintenant sur f8 en 64 bits
par les conseil des membres de ce forum, j'y suis
j'espère ne pas être décu.
pour l'instant les yum update on l'air de bien fonctionné (c'est surtout ça qui me génait)

il ne marchait pas sous F7 (enfin pour moi)
Ne t'inquiète pas là dessus! c'était le bordel ces derniers temps!
il ne marchait pas sous F7 (enfin pour moi)
Il aurait marche pour tout le monde sauf toi ? -_-
Perso j'ai du reconstruire le cache de yum pour que ça se remette à fonctionner comme il faut!

Commande "yum makecache" et hop c'est reparti comme en l'an 40 :-P (pénible ce soulignage de fautes! je sais plus si j'en fais ou non! cela m'apporte plus de fautes que je n'en fais d'habitude! pénible! REMI!!!! les paquets pour le correcteur d'orthographe sous F8 s'en ai où?)