salut, c'est encore moi...
toujours avec mon pb
- DD IDE prim master: DD windows 98SE, avec boot grub en tête
- ubuntu 7.10 sur le DD primary slave
ça boote sur les 2 OS, un plaisir, sauf que mon 98SE a besoin d'une
reconstitution: j'en ai une image ghost, qui me cassera le mbr ;-)
J'ai donc tenté dans un terminal :
$dd if=/dev/hda of=MBR-backup1 bs=512 count=1
(pour une éventuelle restauration par
$dd if=MBR-backup of=/dev/hda bs=512 count=1)
cependant, j'ai lu sur un forum qu'en cas de repartitionnement entre
sauvegarde et restauration, la restauration casserait la table des
partitions, et qu'il était préférable de procéder comme suit après le
ghost (bon, le sudo est inutile, j'ai le même pb avec et sans):
marc@marc-uzinagaz:~$ sudo grub-install /dev/hda
ce qui ne modifierait qu'une partie du mbr, laissant la fin (table des
partitions) intacte.
J'ai donc fait ça avant le ghost, espérant vérifier par la même commande
$dd if=/dev/hda of=MBR-backup2 bs=512 count=1
puis
cmp MBR-backup1 MBR-backup2
que je réparais mon mbr simplement
Ok, sauf que j'obtiens ce message, que j'ai trouvé sur des tas de forums
également, mais correspondant en général à des situations bien
différentes de la mienne:
/dev/hda does not have any corresponding BIOS drive
Il semble donc que le pilote advansys ne soit pas présent en amd64, c'est rare, mais il y a des pilotes qui sont présent en i386 mais pas en adm64...
Tu as essayé un live cd en 32 bits ?
non, mais j'en ai un, gravé pour mon "autre" machine, qui n'a qu'un
Athlon xp1500 et pas de scsi
ou cela peut-il avoir été viré par une tentative d'install ratée, si installation d'applis KDE sur gnome par exemple ?
non
ou une tentative d'utilisation de "alien" ? j'en ai tentée une, qui a abouti à un message comme quoi il manquait quelque chose, et à la question "continuer ou pas" j'ai répondu que je laissais tomber (mais je ne me souviens pas de l'appli concernée)
malheureux : ne touche pas à ça !
message reçu (la raison c'était je crois justement le 64 bits)
YBM wrote:
Il semble donc que le pilote advansys ne soit pas présent en amd64,
c'est rare, mais il y a des pilotes qui sont présent en i386 mais pas
en adm64...
Tu as essayé un live cd en 32 bits ?
non, mais j'en ai un, gravé pour mon "autre" machine, qui n'a qu'un
Athlon xp1500 et pas de scsi
ou cela peut-il avoir été viré par une tentative d'install ratée, si
installation d'applis KDE sur gnome par exemple ?
non
ou une tentative d'utilisation de "alien" ? j'en ai tentée une, qui a
abouti à un message comme quoi il manquait quelque chose, et à la
question "continuer ou pas" j'ai répondu que je laissais tomber
(mais je ne me souviens pas de l'appli concernée)
malheureux : ne touche pas à ça !
message reçu (la raison c'était je crois justement le 64 bits)
Il semble donc que le pilote advansys ne soit pas présent en amd64, c'est rare, mais il y a des pilotes qui sont présent en i386 mais pas en adm64...
Tu as essayé un live cd en 32 bits ?
non, mais j'en ai un, gravé pour mon "autre" machine, qui n'a qu'un
Athlon xp1500 et pas de scsi
ou cela peut-il avoir été viré par une tentative d'install ratée, si installation d'applis KDE sur gnome par exemple ?
non
ou une tentative d'utilisation de "alien" ? j'en ai tentée une, qui a abouti à un message comme quoi il manquait quelque chose, et à la question "continuer ou pas" j'ai répondu que je laissais tomber (mais je ne me souviens pas de l'appli concernée)
malheureux : ne touche pas à ça !
message reçu (la raison c'était je crois justement le 64 bits)
YBM
YBM wrote:
Il semble donc que le pilote advansys ne soit pas présent en amd64, c'est rare, mais il y a des pilotes qui sont présent en i386 mais pas en adm64...
Tu as essayé un live cd en 32 bits ?
non, mais j'en ai un, gravé pour mon "autre" machine, qui n'a qu'un
Athlon xp1500 et pas de scsi
Essaye déjà ça... On trouve sur Google quelques trace d'une suppression du pilote advansys sous Debian à partir d'une certaine version du noyau où il a cessé de compiler.
On peut peut-être trouver un patch qui le rétablit, mais si ça marche en 32 bits, à mon avis faut pas se prendre la tête. L'intérêt d'utiliser une version 64 bits sur une 32 bits est quasi-nul (c'est même souvent plus rapide en 32 qu'en 64), sauf à avoir nettement plus de 4Go de mémoire et des applis qui ont besoin d'utiliser à elle seule plus de 4 Go de mémoire virtuelle... et c'est rare.
YBM wrote:
Il semble donc que le pilote advansys ne soit pas présent en amd64,
c'est rare, mais il y a des pilotes qui sont présent en i386 mais pas
en adm64...
Tu as essayé un live cd en 32 bits ?
non, mais j'en ai un, gravé pour mon "autre" machine, qui n'a qu'un
Athlon xp1500 et pas de scsi
Essaye déjà ça... On trouve sur Google quelques trace d'une suppression
du pilote advansys sous Debian à partir d'une certaine version du
noyau où il a cessé de compiler.
On peut peut-être trouver un patch qui le rétablit, mais si ça marche
en 32 bits, à mon avis faut pas se prendre la tête. L'intérêt d'utiliser
une version 64 bits sur une 32 bits est quasi-nul (c'est même souvent
plus rapide en 32 qu'en 64), sauf à avoir nettement plus de 4Go de
mémoire et des applis qui ont besoin d'utiliser à elle seule plus de
4 Go de mémoire virtuelle... et c'est rare.
Il semble donc que le pilote advansys ne soit pas présent en amd64, c'est rare, mais il y a des pilotes qui sont présent en i386 mais pas en adm64...
Tu as essayé un live cd en 32 bits ?
non, mais j'en ai un, gravé pour mon "autre" machine, qui n'a qu'un
Athlon xp1500 et pas de scsi
Essaye déjà ça... On trouve sur Google quelques trace d'une suppression du pilote advansys sous Debian à partir d'une certaine version du noyau où il a cessé de compiler.
On peut peut-être trouver un patch qui le rétablit, mais si ça marche en 32 bits, à mon avis faut pas se prendre la tête. L'intérêt d'utiliser une version 64 bits sur une 32 bits est quasi-nul (c'est même souvent plus rapide en 32 qu'en 64), sauf à avoir nettement plus de 4Go de mémoire et des applis qui ont besoin d'utiliser à elle seule plus de 4 Go de mémoire virtuelle... et c'est rare.
markorki
YBM wrote:
YBM wrote:
Il semble donc que le pilote advansys ne soit pas présent en amd64, c'est rare, mais il y a des pilotes qui sont présent en i386 mais pas en adm64...
Tu as essayé un live cd en 32 bits ?
non, mais j'en ai un, gravé pour mon "autre" machine, qui n'a qu'un
Athlon xp1500 et pas de scsi
Essaye déjà ça... On trouve sur Google quelques trace d'une suppression du pilote advansys sous Debian à partir d'une certaine version du noyau où il a cessé de compiler.
On peut peut-être trouver un patch qui le rétablit, mais si ça marche en 32 bits, à mon avis faut pas se prendre la tête. L'intérêt d'utiliser une version 64 bits sur une 32 bits est quasi-nul (c'est même souvent plus rapide en 32 qu'en 64), sauf à avoir nettement plus de 4Go de mémoire et des applis qui ont besoin d'utiliser à elle seule plus de 4 Go de mémoire virtuelle... et c'est rare.
J'ai essayé la version 32bits : ça boote sans pb sur SCSI, donc en solution de sauvetage en cas de pb...
Y a-t-il un inconvénient à laisser installée la version 64 bits et à n'utiliser le live-Cd 32 bits que pour des réparations du style grub/grub-install ? D'autant plus que dès que Linux boote, il est en ligne en wifi chez moi (ce que je n'ai jamais obtenu en W98 sur cette machine qui est à l'étage et à 15m de la LiveBox),
Parce qu'en traitement d'images, par exemple, avec les mêmes outils (plus récents que W98) sur mes 2 machines Windows98, tout ce qui est application de filtres (gamma, contraste, niveaux) va énormément plus vite sur le 64 bits 3Ghz que sur le 32 bits 1,5Ghz, le rapport étant à mon avis bien supérieur à 4. Le passage à 64 bits a également impliqué un changement d'architecture et l'apparition d'instructions de "parallèlisation" de traitements de données.
YBM wrote:
YBM wrote:
Il semble donc que le pilote advansys ne soit pas présent en amd64,
c'est rare, mais il y a des pilotes qui sont présent en i386 mais pas
en adm64...
Tu as essayé un live cd en 32 bits ?
non, mais j'en ai un, gravé pour mon "autre" machine, qui n'a qu'un
Athlon xp1500 et pas de scsi
Essaye déjà ça... On trouve sur Google quelques trace d'une suppression
du pilote advansys sous Debian à partir d'une certaine version du
noyau où il a cessé de compiler.
On peut peut-être trouver un patch qui le rétablit, mais si ça marche
en 32 bits, à mon avis faut pas se prendre la tête. L'intérêt d'utiliser
une version 64 bits sur une 32 bits est quasi-nul (c'est même souvent
plus rapide en 32 qu'en 64), sauf à avoir nettement plus de 4Go de
mémoire et des applis qui ont besoin d'utiliser à elle seule plus de
4 Go de mémoire virtuelle... et c'est rare.
J'ai essayé la version 32bits : ça boote sans pb sur SCSI, donc en
solution de sauvetage en cas de pb...
Y a-t-il un inconvénient à laisser installée la version 64 bits et à
n'utiliser le live-Cd 32 bits que pour des réparations du style
grub/grub-install ? D'autant plus que dès que Linux boote, il est en
ligne en wifi chez moi (ce que je n'ai jamais obtenu en W98 sur cette
machine qui est à l'étage et à 15m de la LiveBox),
Parce qu'en traitement d'images, par exemple, avec les mêmes outils
(plus récents que W98) sur mes 2 machines Windows98, tout ce qui est
application de filtres (gamma, contraste, niveaux) va énormément plus
vite sur le 64 bits 3Ghz que sur le 32 bits 1,5Ghz, le rapport étant à
mon avis bien supérieur à 4. Le passage à 64 bits a également impliqué
un changement d'architecture et l'apparition d'instructions de
"parallèlisation" de traitements de données.
Il semble donc que le pilote advansys ne soit pas présent en amd64, c'est rare, mais il y a des pilotes qui sont présent en i386 mais pas en adm64...
Tu as essayé un live cd en 32 bits ?
non, mais j'en ai un, gravé pour mon "autre" machine, qui n'a qu'un
Athlon xp1500 et pas de scsi
Essaye déjà ça... On trouve sur Google quelques trace d'une suppression du pilote advansys sous Debian à partir d'une certaine version du noyau où il a cessé de compiler.
On peut peut-être trouver un patch qui le rétablit, mais si ça marche en 32 bits, à mon avis faut pas se prendre la tête. L'intérêt d'utiliser une version 64 bits sur une 32 bits est quasi-nul (c'est même souvent plus rapide en 32 qu'en 64), sauf à avoir nettement plus de 4Go de mémoire et des applis qui ont besoin d'utiliser à elle seule plus de 4 Go de mémoire virtuelle... et c'est rare.
J'ai essayé la version 32bits : ça boote sans pb sur SCSI, donc en solution de sauvetage en cas de pb...
Y a-t-il un inconvénient à laisser installée la version 64 bits et à n'utiliser le live-Cd 32 bits que pour des réparations du style grub/grub-install ? D'autant plus que dès que Linux boote, il est en ligne en wifi chez moi (ce que je n'ai jamais obtenu en W98 sur cette machine qui est à l'étage et à 15m de la LiveBox),
Parce qu'en traitement d'images, par exemple, avec les mêmes outils (plus récents que W98) sur mes 2 machines Windows98, tout ce qui est application de filtres (gamma, contraste, niveaux) va énormément plus vite sur le 64 bits 3Ghz que sur le 32 bits 1,5Ghz, le rapport étant à mon avis bien supérieur à 4. Le passage à 64 bits a également impliqué un changement d'architecture et l'apparition d'instructions de "parallèlisation" de traitements de données.
YBM
J'ai essayé la version 32bits : ça boote sans pb sur SCSI, donc en solution de sauvetage en cas de pb...
Y a-t-il un inconvénient à laisser installée la version 64 bits et à n'utiliser le live-Cd 32 bits que pour des réparations du style grub/grub-install ? D'autant plus que dès que Linux boote, il est en ligne en wifi chez moi (ce que je n'ai jamais obtenu en W98 sur cette machine qui est à l'étage et à 15m de la LiveBox),
J'ai un gros gros doute sur la possibilité de réparer un GRUB d'une distri 64bits à partir d'un CD d'une version 32. C'est pas impossible, vu que la phase de boot pré-noyau doit être identique, mais c'est à vérifier.
Maintenant, rester en version 64 bits signifie que ton Ubuntu ne pourra jamais accéder à aucun des périphériques SCSI... à toi de voir...
Parce qu'en traitement d'images, par exemple, avec les mêmes outils (plus récents que W98) sur mes 2 machines Windows98, tout ce qui est application de filtres (gamma, contraste, niveaux) va énormément plus vite sur le 64 bits 3Ghz que sur le 32 bits 1,5Ghz, le rapport étant à mon avis bien supérieur à 4. Le passage à 64 bits a également impliqué un changement d'architecture et l'apparition d'instructions de "parallèlisation" de traitements de données.
Windows 98 n'existant pas en version 64 bits, tu tournes de A à Z en 32 bits sur ton 3Ghz, applis comprises. Tu auras le même genre d'amélioration des perfs sous Linux en étant en 32 bits.
À ta place j'installerai une version 32 bits à la place de la 64 en place (choisir un partitionnement personnalisé, associé la partoche Linux à "/" en demandant de reformater, l'autre au swap et basta).
En plus en étant en version 32 bits, tu auras pas de manip particulières à faire pour installer les quelques applis (non libres) qui n'existent qu'en version 32 bits. Faire joujou avec Wine pour faire tourner des applis Windows sera aussi plus facile.
J'ai essayé la version 32bits : ça boote sans pb sur SCSI, donc en
solution de sauvetage en cas de pb...
Y a-t-il un inconvénient à laisser installée la version 64 bits et à
n'utiliser le live-Cd 32 bits que pour des réparations du style
grub/grub-install ? D'autant plus que dès que Linux boote, il est en
ligne en wifi chez moi (ce que je n'ai jamais obtenu en W98 sur cette
machine qui est à l'étage et à 15m de la LiveBox),
J'ai un gros gros doute sur la possibilité de réparer un GRUB d'une
distri 64bits à partir d'un CD d'une version 32. C'est pas impossible,
vu que la phase de boot pré-noyau doit être identique, mais c'est
à vérifier.
Maintenant, rester en version 64 bits signifie que ton Ubuntu ne
pourra jamais accéder à aucun des périphériques SCSI... à toi de
voir...
Parce qu'en traitement d'images, par exemple, avec les mêmes outils
(plus récents que W98) sur mes 2 machines Windows98, tout ce qui est
application de filtres (gamma, contraste, niveaux) va énormément plus
vite sur le 64 bits 3Ghz que sur le 32 bits 1,5Ghz, le rapport étant à
mon avis bien supérieur à 4. Le passage à 64 bits a également impliqué
un changement d'architecture et l'apparition d'instructions de
"parallèlisation" de traitements de données.
Windows 98 n'existant pas en version 64 bits, tu tournes de A à Z en
32 bits sur ton 3Ghz, applis comprises. Tu auras le même genre
d'amélioration des perfs sous Linux en étant en 32 bits.
À ta place j'installerai une version 32 bits à la place de la 64
en place (choisir un partitionnement personnalisé, associé la partoche
Linux à "/" en demandant de reformater, l'autre au swap et basta).
En plus en étant en version 32 bits, tu auras pas de manip particulières
à faire pour installer les quelques applis (non libres) qui n'existent
qu'en version 32 bits. Faire joujou avec Wine pour faire tourner des
applis Windows sera aussi plus facile.
J'ai essayé la version 32bits : ça boote sans pb sur SCSI, donc en solution de sauvetage en cas de pb...
Y a-t-il un inconvénient à laisser installée la version 64 bits et à n'utiliser le live-Cd 32 bits que pour des réparations du style grub/grub-install ? D'autant plus que dès que Linux boote, il est en ligne en wifi chez moi (ce que je n'ai jamais obtenu en W98 sur cette machine qui est à l'étage et à 15m de la LiveBox),
J'ai un gros gros doute sur la possibilité de réparer un GRUB d'une distri 64bits à partir d'un CD d'une version 32. C'est pas impossible, vu que la phase de boot pré-noyau doit être identique, mais c'est à vérifier.
Maintenant, rester en version 64 bits signifie que ton Ubuntu ne pourra jamais accéder à aucun des périphériques SCSI... à toi de voir...
Parce qu'en traitement d'images, par exemple, avec les mêmes outils (plus récents que W98) sur mes 2 machines Windows98, tout ce qui est application de filtres (gamma, contraste, niveaux) va énormément plus vite sur le 64 bits 3Ghz que sur le 32 bits 1,5Ghz, le rapport étant à mon avis bien supérieur à 4. Le passage à 64 bits a également impliqué un changement d'architecture et l'apparition d'instructions de "parallèlisation" de traitements de données.
Windows 98 n'existant pas en version 64 bits, tu tournes de A à Z en 32 bits sur ton 3Ghz, applis comprises. Tu auras le même genre d'amélioration des perfs sous Linux en étant en 32 bits.
À ta place j'installerai une version 32 bits à la place de la 64 en place (choisir un partitionnement personnalisé, associé la partoche Linux à "/" en demandant de reformater, l'autre au swap et basta).
En plus en étant en version 32 bits, tu auras pas de manip particulières à faire pour installer les quelques applis (non libres) qui n'existent qu'en version 32 bits. Faire joujou avec Wine pour faire tourner des applis Windows sera aussi plus facile.
markorki
YBM wrote:
J'ai essayé la version 32bits : ça boote sans pb sur SCSI, donc en solution de sauvetage en cas de pb...
Y a-t-il un inconvénient à laisser installée la version 64 bits et à n'utiliser le live-Cd 32 bits que pour des réparations du style grub/grub-install ? D'autant plus que dès que Linux boote, il est en ligne en wifi chez moi (ce que je n'ai jamais obtenu en W98 sur cette machine qui est à l'étage et à 15m de la LiveBox),
J'ai un gros gros doute sur la possibilité de réparer un GRUB d'une distri 64bits à partir d'un CD d'une version 32. C'est pas impossible, vu que la phase de boot pré-noyau doit être identique, mais c'est à vérifier.
hum, grub ça écrit juste une amorce et une table des disque bootables par cette amorce... quelle raison y aurait-il que ça dépende du processeur utilisé ?
Maintenant, rester en version 64 bits signifie que ton Ubuntu ne pourra jamais accéder à aucun des périphériques SCSI... à toi de voir...
ça c'est un argument massue
Parce qu'en traitement d'images, par exemple, avec les mêmes outils (plus récents que W98) sur mes 2 machines Windows98, tout ce qui est application de filtres (gamma, contraste, niveaux) va énormément plus vite sur le 64 bits 3Ghz que sur le 32 bits 1,5Ghz, le rapport étant à mon avis bien supérieur à 4. Le passage à 64 bits a également impliqué un changement d'architecture et l'apparition d'instructions de "parallèlisation" de traitements de données.
Windows 98 n'existant pas en version 64 bits, tu tournes de A à Z en 32 bits sur ton 3Ghz, applis comprises. Tu auras le même genre d'amélioration des perfs sous Linux en étant en 32 bits.
Je ne jurerais pas qu'une appli ne puisse pas être compilée pour détecter si le processeur possède des instructions particulières, même si l'exec est conforme à Win98, système 32 bits. Une appli graphique ne travaille qu'en mémoire, quand elle calcule elle ignore l'OS, hormis juste pour **accéder** à la mémoire.
Du temps que j'étais jeune, je bossais sur une famille de minis où les "pas chers" n'avaient pas de coprocesseur, les chers en avaient. Tous les programmes de calcul étaient compilés pour utiliser le coprocesseur (enfin, les compilateurs utilisaient systématiquement les instructions du coprocesseur) parce que l'OS gérait parfaitement l'interruption "instruction non reconnue" et dans ce cas la routine d'interruption consistait en une émulation de l'instruction manquante. Tout le monde y gagnait : une seule version d'exec, compacité maxi, la séquence éventuellement longue étant "centralisée" dans l'OS, le tout étant transparent, juste plus lent sur les machines "pauvres".
Mais bon, tu as raison, rien ne garantit que XnView par exemple utilise des moteurs de calcul rusés à ce point, et le 32 bit est donc la meilleure solution.
À ta place j'installerai une version 32 bits à la place de la 64 en place (choisir un partitionnement personnalisé, associé la partoche Linux à "/" en demandant de reformater, l'autre au swap et basta).
En plus en étant en version 32 bits, tu auras pas de manip particulières à faire pour installer les quelques applis (non libres) qui n'existent qu'en version 32 bits. Faire joujou avec Wine pour faire tourner des applis Windows sera aussi plus facile.
ben voilà, si un jour je suis frustré d'avoir 2 OS 32 bits sur un PC 64 bits, j'installe un 2ème linux, en 64 bits ;-)
YBM wrote:
J'ai essayé la version 32bits : ça boote sans pb sur SCSI, donc en
solution de sauvetage en cas de pb...
Y a-t-il un inconvénient à laisser installée la version 64 bits et à
n'utiliser le live-Cd 32 bits que pour des réparations du style
grub/grub-install ? D'autant plus que dès que Linux boote, il est en
ligne en wifi chez moi (ce que je n'ai jamais obtenu en W98 sur cette
machine qui est à l'étage et à 15m de la LiveBox),
J'ai un gros gros doute sur la possibilité de réparer un GRUB d'une
distri 64bits à partir d'un CD d'une version 32. C'est pas impossible,
vu que la phase de boot pré-noyau doit être identique, mais c'est
à vérifier.
hum, grub ça écrit juste une amorce et une table des disque bootables
par cette amorce... quelle raison y aurait-il que ça dépende du
processeur utilisé ?
Maintenant, rester en version 64 bits signifie que ton Ubuntu ne
pourra jamais accéder à aucun des périphériques SCSI... à toi de
voir...
ça c'est un argument massue
Parce qu'en traitement d'images, par exemple, avec les mêmes outils
(plus récents que W98) sur mes 2 machines Windows98, tout ce qui est
application de filtres (gamma, contraste, niveaux) va énormément plus
vite sur le 64 bits 3Ghz que sur le 32 bits 1,5Ghz, le rapport étant à
mon avis bien supérieur à 4. Le passage à 64 bits a également impliqué
un changement d'architecture et l'apparition d'instructions de
"parallèlisation" de traitements de données.
Windows 98 n'existant pas en version 64 bits, tu tournes de A à Z en
32 bits sur ton 3Ghz, applis comprises. Tu auras le même genre
d'amélioration des perfs sous Linux en étant en 32 bits.
Je ne jurerais pas qu'une appli ne puisse pas être compilée pour
détecter si le processeur possède des instructions particulières, même
si l'exec est conforme à Win98, système 32 bits. Une appli graphique ne
travaille qu'en mémoire, quand elle calcule elle ignore l'OS, hormis
juste pour **accéder** à la mémoire.
Du temps que j'étais jeune, je bossais sur une famille de minis où les
"pas chers" n'avaient pas de coprocesseur, les chers en avaient. Tous
les programmes de calcul étaient compilés pour utiliser le coprocesseur
(enfin, les compilateurs utilisaient systématiquement les instructions
du coprocesseur) parce que l'OS gérait parfaitement l'interruption
"instruction non reconnue" et dans ce cas la routine d'interruption
consistait en une émulation de l'instruction manquante. Tout le monde y
gagnait : une seule version d'exec, compacité maxi, la séquence
éventuellement longue étant "centralisée" dans l'OS, le tout étant
transparent, juste plus lent sur les machines "pauvres".
Mais bon, tu as raison, rien ne garantit que XnView par exemple utilise
des moteurs de calcul rusés à ce point, et le 32 bit est donc la
meilleure solution.
À ta place j'installerai une version 32 bits à la place de la 64
en place (choisir un partitionnement personnalisé, associé la partoche
Linux à "/" en demandant de reformater, l'autre au swap et basta).
En plus en étant en version 32 bits, tu auras pas de manip particulières
à faire pour installer les quelques applis (non libres) qui n'existent
qu'en version 32 bits. Faire joujou avec Wine pour faire tourner des
applis Windows sera aussi plus facile.
ben voilà, si un jour je suis frustré d'avoir 2 OS 32 bits sur un PC 64
bits, j'installe un 2ème linux, en 64 bits ;-)
J'ai essayé la version 32bits : ça boote sans pb sur SCSI, donc en solution de sauvetage en cas de pb...
Y a-t-il un inconvénient à laisser installée la version 64 bits et à n'utiliser le live-Cd 32 bits que pour des réparations du style grub/grub-install ? D'autant plus que dès que Linux boote, il est en ligne en wifi chez moi (ce que je n'ai jamais obtenu en W98 sur cette machine qui est à l'étage et à 15m de la LiveBox),
J'ai un gros gros doute sur la possibilité de réparer un GRUB d'une distri 64bits à partir d'un CD d'une version 32. C'est pas impossible, vu que la phase de boot pré-noyau doit être identique, mais c'est à vérifier.
hum, grub ça écrit juste une amorce et une table des disque bootables par cette amorce... quelle raison y aurait-il que ça dépende du processeur utilisé ?
Maintenant, rester en version 64 bits signifie que ton Ubuntu ne pourra jamais accéder à aucun des périphériques SCSI... à toi de voir...
ça c'est un argument massue
Parce qu'en traitement d'images, par exemple, avec les mêmes outils (plus récents que W98) sur mes 2 machines Windows98, tout ce qui est application de filtres (gamma, contraste, niveaux) va énormément plus vite sur le 64 bits 3Ghz que sur le 32 bits 1,5Ghz, le rapport étant à mon avis bien supérieur à 4. Le passage à 64 bits a également impliqué un changement d'architecture et l'apparition d'instructions de "parallèlisation" de traitements de données.
Windows 98 n'existant pas en version 64 bits, tu tournes de A à Z en 32 bits sur ton 3Ghz, applis comprises. Tu auras le même genre d'amélioration des perfs sous Linux en étant en 32 bits.
Je ne jurerais pas qu'une appli ne puisse pas être compilée pour détecter si le processeur possède des instructions particulières, même si l'exec est conforme à Win98, système 32 bits. Une appli graphique ne travaille qu'en mémoire, quand elle calcule elle ignore l'OS, hormis juste pour **accéder** à la mémoire.
Du temps que j'étais jeune, je bossais sur une famille de minis où les "pas chers" n'avaient pas de coprocesseur, les chers en avaient. Tous les programmes de calcul étaient compilés pour utiliser le coprocesseur (enfin, les compilateurs utilisaient systématiquement les instructions du coprocesseur) parce que l'OS gérait parfaitement l'interruption "instruction non reconnue" et dans ce cas la routine d'interruption consistait en une émulation de l'instruction manquante. Tout le monde y gagnait : une seule version d'exec, compacité maxi, la séquence éventuellement longue étant "centralisée" dans l'OS, le tout étant transparent, juste plus lent sur les machines "pauvres".
Mais bon, tu as raison, rien ne garantit que XnView par exemple utilise des moteurs de calcul rusés à ce point, et le 32 bit est donc la meilleure solution.
À ta place j'installerai une version 32 bits à la place de la 64 en place (choisir un partitionnement personnalisé, associé la partoche Linux à "/" en demandant de reformater, l'autre au swap et basta).
En plus en étant en version 32 bits, tu auras pas de manip particulières à faire pour installer les quelques applis (non libres) qui n'existent qu'en version 32 bits. Faire joujou avec Wine pour faire tourner des applis Windows sera aussi plus facile.
ben voilà, si un jour je suis frustré d'avoir 2 OS 32 bits sur un PC 64 bits, j'installe un 2ème linux, en 64 bits ;-)
YBM
J'ai un gros gros doute sur la possibilité de réparer un GRUB d'une distri 64bits à partir d'un CD d'une version 32. C'est pas impossible, vu que la phase de boot pré-noyau doit être identique, mais c'est à vérifier.
hum, grub ça écrit juste une amorce et une table des disque bootables par cette amorce... quelle raison y aurait-il que ça dépende du processeur utilisé ?
L'amorce + le reste de GRUB c'est quand même du code machine du processeur... dans le cas du i86 et du adm64, comme il bootent tous deux en "mode réel", c'est du code 8086 donc ça pourrait bien marcher, ou non... D'autre part il y a l'outil en ligne de commande grub qui pourrait trouver bizarre qu'on lui demande d'installer une amorce pour une autre archi que celle sous laquelle elle tourne.
Je ne jurerais pas qu'une appli ne puisse pas être compilée pour détecter si le processeur possède des instructions particulières, même si l'exec est conforme à Win98, système 32 bits. Une appli graphique ne travaille qu'en mémoire, quand elle calcule elle ignore l'OS, hormis juste pour **accéder** à la mémoire.
C'est pas seulement des instructions en plus, c'est carrément un mode global de fonctionnement du processeur avec un jeu d'instructions différentes. Certes, le mode 64 permet de passer au mode 32, mais il faut que ce soit pris en compte par l'OS, qu'il existe un jeu de DLL en double compilé en 64 bits, etc.
Du temps que j'étais jeune, je bossais sur une famille de minis où les "pas chers" n'avaient pas de coprocesseur, les chers en avaient. Tous les programmes de calcul étaient compilés pour utiliser le coprocesseur (enfin, les compilateurs utilisaient systématiquement les instructions du coprocesseur) parce que l'OS gérait parfaitement l'interruption "instruction non reconnue" et dans ce cas la routine d'interruption consistait en une émulation de l'instruction manquante.
C'est justement ce qu'on faisait autrefois avec Linux quand il y avait encore des machines PC sans copro ("Emulate 80387").
Mais bon, tu as raison, rien ne garantit que XnView par exemple utilise des moteurs de calcul rusés à ce point, et le 32 bit est donc la meilleure solution.
C'est une question de recompilation surtout, et souvent d'adaptation du code pour vraiment profiter du 64 bits - sinon ça peut même être plus lent.
J'ai un gros gros doute sur la possibilité de réparer un GRUB d'une
distri 64bits à partir d'un CD d'une version 32. C'est pas impossible,
vu que la phase de boot pré-noyau doit être identique, mais c'est
à vérifier.
hum, grub ça écrit juste une amorce et une table des disque bootables
par cette amorce... quelle raison y aurait-il que ça dépende du
processeur utilisé ?
L'amorce + le reste de GRUB c'est quand même du code machine du
processeur... dans le cas du i86 et du adm64, comme il bootent
tous deux en "mode réel", c'est du code 8086 donc ça pourrait
bien marcher, ou non... D'autre part il y a l'outil en ligne
de commande grub qui pourrait trouver bizarre qu'on lui demande
d'installer une amorce pour une autre archi que celle sous laquelle
elle tourne.
Je ne jurerais pas qu'une appli ne puisse pas être compilée pour
détecter si le processeur possède des instructions particulières, même
si l'exec est conforme à Win98, système 32 bits. Une appli graphique ne
travaille qu'en mémoire, quand elle calcule elle ignore l'OS, hormis
juste pour **accéder** à la mémoire.
C'est pas seulement des instructions en plus, c'est carrément un
mode global de fonctionnement du processeur avec un jeu d'instructions
différentes. Certes, le mode 64 permet de passer au mode 32, mais
il faut que ce soit pris en compte par l'OS, qu'il existe un jeu
de DLL en double compilé en 64 bits, etc.
Du temps que j'étais jeune, je bossais sur une famille de minis où les
"pas chers" n'avaient pas de coprocesseur, les chers en avaient. Tous
les programmes de calcul étaient compilés pour utiliser le coprocesseur
(enfin, les compilateurs utilisaient systématiquement les instructions
du coprocesseur) parce que l'OS gérait parfaitement l'interruption
"instruction non reconnue" et dans ce cas la routine d'interruption
consistait en une émulation de l'instruction manquante.
C'est justement ce qu'on faisait autrefois avec Linux quand il y
avait encore des machines PC sans copro ("Emulate 80387").
Mais bon, tu as raison, rien ne garantit que XnView par exemple utilise
des moteurs de calcul rusés à ce point, et le 32 bit est donc la
meilleure solution.
C'est une question de recompilation surtout, et souvent d'adaptation
du code pour vraiment profiter du 64 bits - sinon ça peut même être
plus lent.
J'ai un gros gros doute sur la possibilité de réparer un GRUB d'une distri 64bits à partir d'un CD d'une version 32. C'est pas impossible, vu que la phase de boot pré-noyau doit être identique, mais c'est à vérifier.
hum, grub ça écrit juste une amorce et une table des disque bootables par cette amorce... quelle raison y aurait-il que ça dépende du processeur utilisé ?
L'amorce + le reste de GRUB c'est quand même du code machine du processeur... dans le cas du i86 et du adm64, comme il bootent tous deux en "mode réel", c'est du code 8086 donc ça pourrait bien marcher, ou non... D'autre part il y a l'outil en ligne de commande grub qui pourrait trouver bizarre qu'on lui demande d'installer une amorce pour une autre archi que celle sous laquelle elle tourne.
Je ne jurerais pas qu'une appli ne puisse pas être compilée pour détecter si le processeur possède des instructions particulières, même si l'exec est conforme à Win98, système 32 bits. Une appli graphique ne travaille qu'en mémoire, quand elle calcule elle ignore l'OS, hormis juste pour **accéder** à la mémoire.
C'est pas seulement des instructions en plus, c'est carrément un mode global de fonctionnement du processeur avec un jeu d'instructions différentes. Certes, le mode 64 permet de passer au mode 32, mais il faut que ce soit pris en compte par l'OS, qu'il existe un jeu de DLL en double compilé en 64 bits, etc.
Du temps que j'étais jeune, je bossais sur une famille de minis où les "pas chers" n'avaient pas de coprocesseur, les chers en avaient. Tous les programmes de calcul étaient compilés pour utiliser le coprocesseur (enfin, les compilateurs utilisaient systématiquement les instructions du coprocesseur) parce que l'OS gérait parfaitement l'interruption "instruction non reconnue" et dans ce cas la routine d'interruption consistait en une émulation de l'instruction manquante.
C'est justement ce qu'on faisait autrefois avec Linux quand il y avait encore des machines PC sans copro ("Emulate 80387").
Mais bon, tu as raison, rien ne garantit que XnView par exemple utilise des moteurs de calcul rusés à ce point, et le 32 bit est donc la meilleure solution.
C'est une question de recompilation surtout, et souvent d'adaptation du code pour vraiment profiter du 64 bits - sinon ça peut même être plus lent.
