OVH Cloud OVH Cloud

linux et athlon 64

29 réponses
Avatar
BrunoL
Joyeux Noël,

Dés que pixmania m'aura livré (4jours annoncés 10 jours aprés j'attends
toujours - site à éviter !-) je disposerai d'un portable avec ce processeur.

Aprés un tour sur le net j'ai trouvé tant d'info que je suis paumé.

Connaitriez-vous un site dédié qui explique les étapes à respecter en
particulier pour une slackware (distrib que j'ai retenu)et pour le
partage de connexion internet en wifi.

Merci.

--
-- pour me contacter oter le deuxième point de l'adresse.

9 réponses

1 2 3
Avatar
Basile Starynkevitch [news]
On 2004-12-27, Jérémy JUST wrote:
On Sat, 25 Dec 2004 14:44:00 +0100
"Rakotomandimby (R12y) Mihamina" wrote:

Tu prends un "portable" pour partager le connexion internet?


Bah, un portable en 64 bits, c'est déjà un drôle de choix...


Pas forcément. Bien sûr, les portables AMD64 ont peu d'autonomie
(moins qu'un powerbook), mais ils sont puissants et peuvent tourner un
linux 64 bits.


PS: quelqu'un sait en quoi consiste la technique « Enhanced Virus »
bidule dont parlent ces pubs?


Je crois que en langage linuxien, il s'agit d'offrir la possibilité
de mmap-er un morceau de mémoire en gérant effectivement la permission
d'execution. Si j'ai bien compris, l'AMD64 a un bit non-execute dans
son gestionnaire de mémoire, et peut donc gérer des projections
mémoire en lecture/écriture, mais sans droit d'execution. Si Windows
exploite cette possibilité (je ne connais pas Windows!) il pourrait
rendre la vie plus difficile aux virus.

Cordialement

--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net
aliases: basile<at>tunes<dot>org = bstarynk<at>nerim<dot>net
8, rue de la Faïencerie, 92340 Bourg La Reine, France


Avatar
Jerome Lambert
Rakotomandimby (R12y) Mihamina wrote:
( Sun, 26 Dec 2004 13:50:25 +0100 ) BrunoL :

J'ai un trés mauvais souvenir des MdK


Ta derniere version de mandrake c'etait quoi?


la 9.x j'ai oublié le détail



Essaie la 10.1.
Je pense qu'il ne faut pas s'attendre a des miracles, mais ils ont _un
peu_ amelioré les choses entre temps :-)


Personnellement, j'aurais tendance à diriger les déçus de Mandrake vers
Fedora, mais ça va finir par se terminer en débat... ;-)




Avatar
no_spam
On Mon, 27 Dec 2004 19:28:44 +0000, Basile Starynkevitch [news] wrote:

On 2004-12-27, Jérémy JUST wrote:
On Sat, 25 Dec 2004 14:44:00 +0100
"Rakotomandimby (R12y) Mihamina" wrote:

Tu prends un "portable" pour partager le connexion internet?


Bah, un portable en 64 bits, c'est déjà un drôle de choix...


Pas forcément. Bien sûr, les portables AMD64 ont peu d'autonomie
(moins qu'un powerbook), mais ils sont puissants et peuvent tourner un
linux 64 bits.


C'est logique qu'ils aient une autonomie plus courte: ils consoment
_beaucoup_ plus qu'un powerpc. Et c'est rassurant qu'en contrepartie ils
soient plus puissant ;-)
C'est bien pour un développeur en balade, par exemple...

PS: quelqu'un sait en quoi consiste la technique « Enhanced Virus »
bidule dont parlent ces pubs?


Je crois que en langage linuxien, il s'agit d'offrir la possibilité
de mmap-er un morceau de mémoire en gérant effectivement la permission
d'execution. Si j'ai bien compris, l'AMD64 a un bit non-execute dans
son gestionnaire de mémoire, et peut donc gérer des projections
mémoire en lecture/écriture, mais sans droit d'execution. Si Windows
exploite cette possibilité (je ne connais pas Windows!) il pourrait
rendre la vie plus difficile aux virus.


Pour compléter, ça permet surtout d'avoir une pile non executable sur PC
ce qui permet d'éviter les classiques attaques par buffer overflow sur
cette même pile... Pas toutes quand même, il ne faut pas exagérer ;-)
Ca a un inconvénient: il a fallu modifier les ABI: traditionnellement les
retours de handler de signaux se faisaient en executant du code que le
noyau générait sur la pile. Avec une pile protégée, ça crashe
l'application instantanément et c'est dur à comprendre: l'appli crashe
de façon alléatoire, du moins vu de l'utilisateur, puisque les signaux
peuvent arriver à n'importe quel moment. Joie et allégresse garantie
pour le développeur: j'ai testé pour vous ;-)
Je rassure les âmes sensibles: le patch est à faire dans la libc et la
glibc (si elle est assez récente) fait ce qu'il faut.



Avatar
no_spam
On Mon, 27 Dec 2004 14:01:07 +0100, Jerome Lambert wrote:

françois wrote:
Jerome Lambert wrote:

Bonjour,

Quelques remarques:

- il n'existe pas de plug-in flash pour Amd64, donc il est impossible
d'accéder aux sites 100% flash avec les distributions Amd64



à moins de me tromper, je crois que l'amd64 est pleinement
compatible avec le mode 32 bits, les distributions 64 bits
ne peuvent-il pas gérer le 32 bits en même temps que le 64 bits en
attendant que petit à petit l'offre de logiciels 64 s'enrichissent ?



Si, bien sur. Sinon, l'amd64 n'aurait pas plus d'intérêt que l'Itanium
(c'est dire !).

Ça peut fonctionner pour les programmes *open-source* qu'il suffit de
recompiler, par contre ça ne marche pas pour les programmes binaires qui
vérifient l'architecture avant de se lancer, comme p.ex. le plug-in
flash :-(


Non, ça fonctionne avec tous les programmes, sans les recompiler, à
condition de les lancer dans un environnement totalement en 32 bits, donc
dans un chroot.
Je le fait tout les jours !
Je n'ai pas choisi la méthode la plus simple, mais j'ai une Gentoo 32
bits (entièrement 32 bits) dans un chroot sur mon amd64. Le noyau et
l'environnement principals sont en 64 bits mais je peux lancer sans
problème toutes les applis 32 bits _sans recompilation_ sans aucun
problème.
L'architecture x86_64 a été explicitement designée pour le permettre,
ce serait un comble que ça ne marche pas !



Avatar
Jerome Lambert
no_spam wrote:
On Mon, 27 Dec 2004 14:01:07 +0100, Jerome Lambert wrote:
(...)

Ça peut fonctionner pour les programmes *open-source* qu'il suffit de
recompiler, par contre ça ne marche pas pour les programmes binaires qui
vérifient l'architecture avant de se lancer, comme p.ex. le plug-in
flash :-(



Non, ça fonctionne avec tous les programmes, sans les recompiler, à
condition de les lancer dans un environnement totalement en 32 bits, donc
dans un chroot.
Je le fait tout les jours !
Je n'ai pas choisi la méthode la plus simple, mais j'ai une Gentoo 32
bits (entièrement 32 bits) dans un chroot sur mon amd64. Le noyau et
l'environnement principals sont en 64 bits mais je peux lancer sans
problème toutes les applis 32 bits _sans recompilation_ sans aucun
problème.
L'architecture x86_64 a été explicitement designée pour le permettre,
ce serait un comble que ça ne marche pas !


Ah mais le problème n'est pas là, les distributions Amd64 incluent
d'office la couche "chroot 32 bits" pour faire tourner les programmes
non portés, OpenOffice étant l'exemple type pour Gentoo...

Simplement, certains programmes refusent catégoriquement de se lancer,
voir crashent...

Pour le plug-in flash qui nous occupe, j'avais (à la bourrin) modifié le
script d'installation afin que celui-ci ne vérifie pas l'architecture de
la machine, et du coup il s'installait, mais alors Mozilla ne démarrait
plus :-(

*LA* solution serait alors de créer un système complet 32 bits chrooté
et de démarrer Mozilla, mais c'est un peu lourd pour un simple plug-in
largement dispensable, du moins pour moi ;-)


Avatar
françois
Jerome Lambert wrote:
françois wrote:


[...]

Si, cela fonctionne si le binaire n'est pas trop "regardant" sur
l'architecture. Par exemple on ne sait pas compiler OpenOffice en
version Amd64, mais la version i386 fonctionne très bien sur mon Amd64,
que ce soit sous Fedora 3 Amd64 ou sous Gentoo Amd64...



ah je suis soulagé, merci pour l'info.



Ainsi, ma Gentoo dispose d'un répertoire /emul/linux/x86/ qui contient
toute une série de bibliothèque permttant de faire fonctionner les
applications 32 bits sur ma machine.

Par contre, les programmes qui font la vérification (comme le player
flash) refusent de s'installer, encore que je reste persuadé qu'en
bidouillant un peu, il y aurait moyen de le faire fonctionner...


oh, tant que l'on a pas les sources je ne pense pas, à moins d'agir
directement sur ce que renvoi la commande interrogant l'architecture
de la distrib (peut-être que c'est uname qui est utilisé, ou alors un
accès direct à /proc (??) ), ou encore comme le fait nospam, chrooter.

@+

Avatar
françois
no_spam wrote:
On Mon, 27 Dec 2004 14:01:07 +0100, Jerome Lambert wrote:


françois wrote:

à moins de me tromper, je crois que l'amd64 est pleinement
compatible avec le mode 32 bits, les distributions 64 bits
ne peuvent-il pas gérer le 32 bits en même temps que le 64 bits en
attendant que petit à petit l'offre de logiciels 64 s'enrichissent ?




Si, bien sur. Sinon, l'amd64 n'aurait pas plus d'intérêt que l'Itanium
(c'est dire !).




Je me disait bien

Ça peut fonctionner pour les programmes *open-source* qu'il suffit de
recompiler, par contre ça ne marche pas pour les programmes binaires qui
vérifient l'architecture avant de se lancer, comme p.ex. le plug-in
flash :-(



Non, ça fonctionne avec tous les programmes, sans les recompiler, à
condition de les lancer dans un environnement totalement en 32 bits, donc
dans un chroot.
Je le fait tout les jours !
Je n'ai pas choisi la méthode la plus simple, mais j'ai une Gentoo 32
bits (entièrement 32 bits) dans un chroot sur mon amd64. Le noyau et
l'environnement principals sont en 64 bits mais je peux lancer sans
problème toutes les applis 32 bits _sans recompilation_ sans aucun
problème.


C'est assez lourd comme solution non ?
n'y aurait-il pas moyen de ruser un peu (quoique un chroot je n'y avais
pas penser) ?

L'architecture x86_64 a été explicitement designée pour le permettre,
ce serait un comble que ça ne marche pas !



ouf!



Avatar
Jerome Lambert
françois wrote:
Jerome Lambert wrote:

françois wrote:



[...]

Si, cela fonctionne si le binaire n'est pas trop "regardant" sur
l'architecture. Par exemple on ne sait pas compiler OpenOffice en
version Amd64, mais la version i386 fonctionne très bien sur mon
Amd64, que ce soit sous Fedora 3 Amd64 ou sous Gentoo Amd64...



ah je suis soulagé, merci pour l'info.


De toutes façons, les programmes posant problèmes sont rares, mais le
plug-in flash en fait partie.

J'écris en ce moment depuis une Fedora Core 3 Amd64, et rien ne manque à
mon confort ;-) . Concernant la Fedora (que je connais bien), la seule
différence avec la version i386 est que les mises-à-jour ont 24 à 48
heures de retard sur leurs homologues i386. Pour le reste, c'est
exactement pareil...


Avatar
no_spam
On Tue, 28 Dec 2004 00:43:17 +0100, Jerome Lambert wrote:

no_spam wrote:
On Mon, 27 Dec 2004 14:01:07 +0100, Jerome Lambert wrote:
(...)

Ça peut fonctionner pour les programmes *open-source* qu'il suffit de
recompiler, par contre ça ne marche pas pour les programmes binaires qui
vérifient l'architecture avant de se lancer, comme p.ex. le plug-in
flash :-(



Non, ça fonctionne avec tous les programmes, sans les recompiler, à
condition de les lancer dans un environnement totalement en 32 bits, donc
dans un chroot.
Je le fait tout les jours !
Je n'ai pas choisi la méthode la plus simple, mais j'ai une Gentoo 32
bits (entièrement 32 bits) dans un chroot sur mon amd64. Le noyau et
l'environnement principals sont en 64 bits mais je peux lancer sans
problème toutes les applis 32 bits _sans recompilation_ sans aucun
problème.
L'architecture x86_64 a été explicitement designée pour le permettre,
ce serait un comble que ça ne marche pas !


Ah mais le problème n'est pas là, les distributions Amd64 incluent
d'office la couche "chroot 32 bits" pour faire tourner les programmes
non portés, OpenOffice étant l'exemple type pour Gentoo...

Simplement, certains programmes refusent catégoriquement de se lancer,
voir crashent...


Dans la Gentoo, pour lancer un programme 32 bits sans chroot, il faut
utiliser l'utilitaire linux32. Celui ci signale au noyau que l'executable
doit tourner en mode 32 bits (Linux a un concept de "personalité" des
programmes qui leur permet d'utiliser une table de syscall différente de
celle utilisée pour les programmes standards) et signale au linker
dynamique de chercher les libraires dans /lib32 au lieu de /lib64.
Si on ne se sert pas de linux32, ça ne marche que si les headers du
fichier ELF ont été généré de façon spéciale pour indiquer que le
linker dynamique est dans /lib32 et non pas dans /lib (qui est un lien
vers /lib64). Donc, les programmes 32 bits compilés avec gcc 64 bits (ld
en fait, mais bref...) marcheront mais les programmes compilés sur un PC
standard crasheront (sauf cas très particulier: programmes statiques ne
faisant aucun syscall ayant une sémantique différente en 32 et en 64
bits...).

Pour le plug-in flash qui nous occupe, j'avais (à la bourrin) modifié le
script d'installation afin que celui-ci ne vérifie pas l'architecture de
la machine, et du coup il s'installait, mais alors Mozilla ne démarrait
plus :-(


Il est impossible de faire tourner un plugin 32 bits dans un programme 64
bits, à moins que le programme en question soit explicitement prévu
pour: les ABI 32 et 64 bits sont différentes, c'est à dire que les
passages de paramêtres entre fonctions ne se font pas de la même façon.
En 32 bits, tous les paramêtres de fonction sont mis sur la pile. C'est
très couteux (puisque ça demande des accès mémoires) et dangereux
puisqu'on peut eventuellement déclencher des exceptions lors des accès
mémoire. L'amd64 ayant plus de registres qu'un x86 normal, les premiers
paramêtres des fonctions sont passés dans les registres supplémentaires
(ce qui ressemble aux ABI RISC...). Si un plugin 32 bits appelle une
fonction 64 bits ou l'inverse, ça ne peut pas bien se passer...

*LA* solution serait alors de créer un système complet 32 bits chrooté
et de démarrer Mozilla, mais c'est un peu lourd pour un simple plug-in
largement dispensable, du moins pour moi ;-)


Une autre solution consistant à utiliser un mozilla 32 bits compilé en
statique et lancé avec l'utilitaire linux32 ou un équivalent.



1 2 3