Architecture de processeur adéquate au fichier image Wheezy

Bonjour,
Je suis en ce moment sur la page “Installer Debian par Internet”.Je souhaite installer par le réseau.
Mon processeur est un Intel® Core™ i5-2500K CPU @ 3.30GHz × 4 .
Les fichiers image suivants, qui font jusqu’à 180 Mo, peuvent être gravés sur de petits CD-R(W), de 80 mm de diamètre. Veuillez choisir ci-dessous l’architecture de processeur adéquate.

amd64
armel
armhf
i386
ia64
kfreebsd-i386
kfreebsd-amd64
mips
mipsel
powerpc
sparc
s390x

Je me demande quel fichier image choisir.
Merci

Le Core i5 est un processeur de la famille x86 32 bits (i386) et 64 bits (amd64).
Les architectures suivantes sont supportées :

  • amd64 pour un système 64 bits avec un noyau Linux
  • i386 pour un système 32 bits avec un noyau Linux
  • kfreebsd-i386 pour un système 32 bits avec un noyau FreeBSD
  • kfreebsd-amd64 pour un système 64 bits avec un noyau FreeBSD

Pour plus de détails, voir http://www.debian.org/ports/

Merci pour l’info!Je la télécharge.
Manas

[quote=“PascalHambourg”]Le Core i5 est un processeur de la famille x86 32 bits (i386) et 64 bits (amd64).
Les architectures suivantes sont supportées :

  • amd64 pour un système 64 bits avec un noyau Linux
  • i386 pour un système 32 bits avec un noyau Linux
  • kfreebsd-i386 pour un système 32 bits avec un noyau FreeBSD
  • kfreebsd-amd64 pour un système 64 bits avec un noyau FreeBSD

Pour plus de détails, voir http://www.debian.org/ports/[/quote]

j’ai un Barbone Nuvo-1005B avec Intel Core Mobile i5 520M (mémoire 2Go DDR3 1333Mhz et un SSD "SATA InnoLite II 64Gb)

quelle est l’image la plus appropriée? Si j’ai bien compris toutes ces architectures sont compatible pour ce processeur?
64 bits a t’il un avantage avec cette configuration?

j’ai actuellement le choix depuis
debian.org/releases/stable/ … ex.fr.html

entre ces 4 versions.

cdimage.debian.org/debian-cd/7.6 … etinst.iso
cdimage.debian.org/debian-cd/7.6 … etinst.iso
cdimage.debian.org/debian-cd/7.6 … etinst.iso
cdimage.debian.org/debian-cd/7.6 … etinst.iso

quelle différence majeure y a t’il entre le kfreebsd et linux pour le noyau?

@ JEAN THEVENET : un Core i5 est nécessairement un 64 bits si je ne m’abuse. Donc il te faudra télécharger l’iso “amd64”. Avant on pouvait aisément faire tourner la version 32 bits (= i386) sur un processeur 64 bits, mais depuis que Debian a intégré le multiarch (c’est-à-dire depuis Wheezy), on observe des bugs lors de l’installation si on essaye d’installer la version 32 bits sur un processeur 64 bits. C’est tout l’intérêt du multiarch : pouvoir utiliser une autre architecture sans avoir à changer son processeur (ce qui serait loin d’être pratique, faut bien avouer ^^ ). Mais cela implique d’utiliser obligatoirement la version avec l’architecture exacte qui correspond à ton processeur. Il se peut que la version 32 bits fonctionne sur ton Core i5, mais je te le déconseille très fortement.

Donc suite à ce que je viens de dire : théoriquement oui, mais en fait non.

Oui, ça permet de mieux exploiter les capacités du processeur, même si tu ne verras pas vraiment de différence en pratique. Ca peut permettre de gagner quelques dizaines de secondes, voire quelques minutes, lors d’une grosse compilation. Mais surtout, ça permet d’exploiter plus de 3 Go de RAM sans avoir à faire intervenir un hack au niveau de la gestion de la mémoire.

kFreeBSD est un noyau UNIX.
Linux est un noyau… Linux.

Pour te la faire courte : UNIX = le système d’exploitation utilisé depuis des lustres sur les grosses machines genre AS400, superordinateurs, etc. Comme UNIX n’existait pas à l’époque pour les PC compatibles IBM x86, Linus Torvald a décidé de porter un clone d’UNIX pour son PC. Mais les systèmes UNIX sont soumis à des redevances très importantes si on veut réutiliser le code, donc il a décidé de réécrire tout un système d’exploitation de zéro, sans reprendre la moindre ligne de code d’UNIX, mais en étant au maximum compatible et en ayant au maximum les mêmes fichiers de configuration (norme POSIX). De plus, il a décidé de mettre son système sous licence libre. Depuis, FreeBSD a également été mis sous licence libre.

Donc en somme, si on caricature : Linux = UNIX libre pour PC. Donc ce n’est pas étonnant qu’on puisse installer un noyau Linux ou FreeBSD sans qu’il n’y ait énormément de différences, puisque Linux est un peu ce qu’aurait été FreeBSD s’il n’y avait pas eu de problèmes de licences à l’époque (car FreeBSD a entre temps été porté pour les architectures PC compatibles IBM, soit les processeurs x86).
Mais ceux qui s’y connaissent un peu te diront que Linux est loin d’être aussi fiable qu’UNIX car UNIX suit des procédure de développement particulièrement rigoureuses. Donc les puristes n’utiliseront pas Linux mais UNIX.

Pour la culture : MacOS utilise un noyau UNIX. Voilà pourquoi il est souvent plus facile de porter un logiciel de Linux vers MacOS et vice versa, que vers ou depuis Windows.

Je viens d’installer Jessie sur mon architecture. Cette petite Jessie ne me pose pas de problème et est déjà très stable.
J’ai installé Jessie parce que PC Linux France me propose un portable avec Jessie pré-installé. Il m’a été précisé qu’il n’installait pas Wheezy sur le portable en question parce que ce n’était pas possible ( ref: PClF W550SU1 15.6" LED Intel HD 4600 Haswell ).
Je crois bien que je vais être obligé d’abandonner à regret mon Toshiba Satellite P100 473 acheté en 2007 à cause de l’image ( couleurs zébrées ) . J’ai essayé tous les pilotes mais aucun ne corrige le problème . :114

Ah ? Jamais observé, lu ni entendu parler. Des sources ou une expérience ?

Et même plusieurs. Tu fais allusion à PAE qui ajoute une couche supplémentaire pour permettre d’adresser physiquement plus de 4 Gio (auxquels il faut retrancher l’espace d’adressage en mémoire correspondant aux périphériques comme la carte graphique, d’où les 3 et quelque Gio de RAM). Mais il y avait déjà un hack pour gérer plus de 1 Gio. En effet à l’origine le noyau allouait un espace d’adressage virtuel de 3 Gio à chaque processus et l’intégralité de la RAM physique était “mappée” en permanence dans l’espace d’adressage restant jusqu’à concurrence de 1 Gio, ce qui permettait au noyau de gérer la mémoire de façon efficace. Pour gérer plus de 1 Gio de RAM, il a fallu mettre en place un premier hack (HIGHMEM4G), toute la RAM ne pouvant plus être mappée en permanence. C’est ce qu’on peut voir sous forme de HighMemory et LowMemory dans le contenu de /proc/meminfo. L’accès à la HighMemory est un peu moins rapide puisqu’il faut d’abord la mapper. Un hack alternatif (VMSPLIT) consistait à augmenter la mémoire du noyau à 2 ou 3 Gio au détriment de la mémoire virtuelle des programmes utilisateur qui diminuait d’autant à 2 ou 1 Gio.

Avec un noyau 64 bits dont l’espace d’adressage virtuel est énorme en comparaison de la taille de la RAM physique, on peut revenir au modèle d’origine efficace où non seulement toute la RAM est mappée en permanence, mais aussi les processus utilisateurs ont accès à l’intégralité de celle-ci et ne sont pas limités par l’espace d’adressage de la mémoire virtuelle.

Ah ? Jamais observé, lu ni entendu parler. Des sources ou une expérience ?[/quote][/quote]
Oui, mon expérience perso.

Je pouvais installer Debian Squeeze en 32 bits sans aucun problème.
En revanche, lorsque j’ai tenté la même chose avec Debian Wheezy, l’installateur plantait en beauté au lancement. J’ai alors testé la version 64 bits et là plus aucun problème.

Je précise qu’il s’agit d’un Lenovo ThinkPad T400, donc il s’agit d’une machine très bien supportée par Linux depuis Debian Lenny.

Il se peut que ç’ait été résolu depuis, mais je ne suis pas choqué outre mesure que cela ne fonctionne pas car si on compile pour une architecture 32 ou 64 bits, autant en tirer partie au maximum, même si cela casse la compatibilité avec le 32 bits puisque de toute façon le multiarch permet d’exploiter proprement le mode 32 bits toute en bénéficiant du 64 bits original. Ca reste curieux dans le sens où les architectures “amd64” sont censées être pleinement compatibles avec le 32 bits (me semble-t-il, mais c’est peut-être là que ça coince), donc je suppose qu’il s’agit d’un bug dans l’installateur de Debian. Je n’ai pas réessayé depuis la v7.0.