j'aimerais avoir des avis (plus ou moins) objectifs concernant Linux et
les machines 64 bits, et, d'une manière général, sur les machines 64 bits.
Tout d'abord, si j'ai bien compris l'avantage du 64 bit, c'est de faire
passer les registres du prcesseur de 32 à 64 bits. Ca peut sembler être
une Lapalissade, mais c'est bon de le préciser. Donc, le (seul ?)
avantage du 64 bits pour les application ne demandant pas de calculs
avec des chiffres (relativement) enorme, c'est l'augmentation de
l'espace d'addressage ? Le terme "64 bits" ne serait donc qu'une astuce
marketing ?
De plus, il faut en toute logique que les applications soit compilées
par un gcc en "mode 64bits" (?): ce mode "est il au point" ? Ne
change-t-il vraiment rien d'autre que quelques broutilles concernant
l'addressage ?
Si le prémice du paragraphe précédent est correct, existe-t-il beaucoup
d'applications Linux compatible 64bits ? Une liste existe-t-elle ?
Enfin, est-il possible d'émuler des applications 32 bits sur un kernel
"compilé en mode 64 bits", et cela ralentit-il l'application ? Notez que
je préferrerais utiliser Debian (ma station de travail actuelle en 32
bits), mais qu'en est-il de l'avancement des distributions Linux par
rapport "au 64 bit" ?
Vous l'aurez compris,si je post ici et maintenant ce message, c'est pour
me décider à l'achat d'un futur et hypothètique ordinateur portable. Je
pensais me porter vers un Intel Core 2 Duo. Quelques remarques par
rapport à ce type de processeur ?
Pour finir, je tiens à préciser que je n'ai trouvé que des sujets (pas
tellement réjouissant) datant de 2004/2005/2006 sur internet, très peu
de (fin) 2007.
"Nicolas George" <nicolas$ a écrit dans le message de news: fedv1o$129u$
"pehache-tolai" , dans le message
Ah, maintenant c'est "Certains". Dans le post d'avant, c'était "*LES* bouzins propriétaires, c'est une autre histoire".
Oui, « c'est une autre histoire », pas « aucun ne fonctionne ». Mais je comprends que la nuance soit un peu difficile à appréhender pour toi.
Elle est d'autant plus difficile à appréhender que ta formulation reste volontairement dans le vague, mais en suggérant que d'une manière générale *LES* (et non pas *des*) "bouzins propriétaires" (déjà, "bouzin", c'est pas connoté, hein...) fonctionnent mal en 64 bits, sauf éventuellement une ou deux exceptions.
Alors, ces bouzins propriétaires qui fonctionnent mal en 64 bits, c'est lesquels ?
-- pehache http://pehache.free.fr/public.html
"Nicolas George" <nicolas$george@salle-s.org> a écrit dans le message
de news: fedv1o$129u$1@nef.ens.fr
"pehache-tolai" , dans le message
Ah, maintenant c'est "Certains". Dans le post d'avant, c'était "*LES*
bouzins propriétaires, c'est une autre histoire".
Oui, « c'est une autre histoire », pas « aucun ne fonctionne ». Mais
je comprends que la nuance soit un peu difficile à appréhender pour
toi.
Elle est d'autant plus difficile à appréhender que ta formulation reste
volontairement dans le vague, mais en suggérant que d'une manière générale
*LES* (et non pas *des*) "bouzins propriétaires" (déjà, "bouzin", c'est pas
connoté, hein...) fonctionnent mal en 64 bits, sauf éventuellement une ou
deux exceptions.
Alors, ces bouzins propriétaires qui fonctionnent mal en 64 bits, c'est
lesquels ?
"Nicolas George" <nicolas$ a écrit dans le message de news: fedv1o$129u$
"pehache-tolai" , dans le message
Ah, maintenant c'est "Certains". Dans le post d'avant, c'était "*LES* bouzins propriétaires, c'est une autre histoire".
Oui, « c'est une autre histoire », pas « aucun ne fonctionne ». Mais je comprends que la nuance soit un peu difficile à appréhender pour toi.
Elle est d'autant plus difficile à appréhender que ta formulation reste volontairement dans le vague, mais en suggérant que d'une manière générale *LES* (et non pas *des*) "bouzins propriétaires" (déjà, "bouzin", c'est pas connoté, hein...) fonctionnent mal en 64 bits, sauf éventuellement une ou deux exceptions.
Alors, ces bouzins propriétaires qui fonctionnent mal en 64 bits, c'est lesquels ?
-- pehache http://pehache.free.fr/public.html
Jerome Lambert
Jerome Lambert wrote:
(...)
Suite aux quelques idées avancés dans le sujet, je me demande bien: est-il possible d'avoir une machine plus ou moins protable d'un autre type que x86 ou PowerPC
Il existe des portables SPARC, p.ex. chez tadpole.
Hum, aucun constructeur plus abordable ? 10 000$ la machine, non merci.
En "non-x86", le seul abordable fut Apple avec les PowerPC, mais même cette lignée est finie. Tout fout l'camp, mon bon monsieur...
Jerome Lambert wrote:
(...)
Suite aux quelques idées avancés dans le sujet, je me demande bien:
est-il possible d'avoir une machine plus ou moins protable d'un autre
type que x86 ou PowerPC
Il existe des portables SPARC, p.ex. chez tadpole.
Hum, aucun constructeur plus abordable ? 10 000$ la machine, non merci.
En "non-x86", le seul abordable fut Apple avec les PowerPC, mais même
cette lignée est finie. Tout fout l'camp, mon bon monsieur...
Suite aux quelques idées avancés dans le sujet, je me demande bien: est-il possible d'avoir une machine plus ou moins protable d'un autre type que x86 ou PowerPC
Il existe des portables SPARC, p.ex. chez tadpole.
Hum, aucun constructeur plus abordable ? 10 000$ la machine, non merci.
En "non-x86", le seul abordable fut Apple avec les PowerPC, mais même cette lignée est finie. Tout fout l'camp, mon bon monsieur...
Jerome Lambert
On 2007-10-08, pehache-tolai wrote:
On 8 oct, 11:59, Nicolas George <nicolas$ wrote:
À peu près toutes. Il y a deux ans, on tombait assez souvent sur des bugs à ce niveau (j'en ai trouvé un dans Transcode et un dans Speex la même semaine), mais ça devient de plus en plus rare (j'en ai quand même trouvé un dans le noyau cet été), et dans l'ensemble, tout fonctionne parfaitement.
... Dans le monde libre. Les bouzins propriétaires, c'est une autre histoire. Il y a bien longtemps que les "bouzins propriétaires" tournent (ou
tournaient) sans problème en 64 bits...
Rien de précis, aucun argument, aucun exemple. Bravo, c'est du bon troll.
Facile, il suffit de connaître la chronologie de l'informatique, les machines 64 bits à OS proprios étant apparues et ayant été exploitées bien avant que les OS libres ne sortent de l'informatique alternative.
On 2007-10-08, pehache-tolai <pehache.7@gmail.com> wrote:
On 8 oct, 11:59, Nicolas George <nicolas$geo...@salle-s.org> wrote:
À peu près toutes. Il y a deux ans, on tombait assez souvent sur des bugs à
ce niveau (j'en ai trouvé un dans Transcode et un dans Speex la même
semaine), mais ça devient de plus en plus rare (j'en ai quand même trouvé un
dans le noyau cet été), et dans l'ensemble, tout fonctionne parfaitement.
... Dans le monde libre. Les bouzins propriétaires, c'est une autre
histoire.
Il y a bien longtemps que les "bouzins propriétaires" tournent (ou
tournaient) sans problème en 64 bits...
Rien de précis, aucun argument, aucun exemple. Bravo, c'est du bon troll.
Facile, il suffit de connaître la chronologie de l'informatique, les
machines 64 bits à OS proprios étant apparues et ayant été exploitées
bien avant que les OS libres ne sortent de l'informatique alternative.
À peu près toutes. Il y a deux ans, on tombait assez souvent sur des bugs à ce niveau (j'en ai trouvé un dans Transcode et un dans Speex la même semaine), mais ça devient de plus en plus rare (j'en ai quand même trouvé un dans le noyau cet été), et dans l'ensemble, tout fonctionne parfaitement.
... Dans le monde libre. Les bouzins propriétaires, c'est une autre histoire. Il y a bien longtemps que les "bouzins propriétaires" tournent (ou
tournaient) sans problème en 64 bits...
Rien de précis, aucun argument, aucun exemple. Bravo, c'est du bon troll.
Facile, il suffit de connaître la chronologie de l'informatique, les machines 64 bits à OS proprios étant apparues et ayant été exploitées bien avant que les OS libres ne sortent de l'informatique alternative.
Thierry B.
--{ Nicolas George a plopé ceci: }--
sans compter les problèmes d'alignement qui grèvent les performances
Je te l'ai déjà dit à l'époque, je te le redis maintenant : les opcodes pas alignés, c'est le mode de fonctionnement _normal_ d'un x86, et ça ne grève absolument pas les performances.
Il n'y a pas que le processeur d'important dans ces histoires d'alignement d'opcodes. Je pense que la plomberie alentour a aussi son mot à dire sur les performances: cache, bus, ram...
sans compter les
problèmes d'alignement qui grèvent les performances
Je te l'ai déjà dit à l'époque, je te le redis maintenant : les opcodes pas
alignés, c'est le mode de fonctionnement _normal_ d'un x86, et ça ne grève
absolument pas les performances.
Il n'y a pas que le processeur d'important dans ces histoires
d'alignement d'opcodes. Je pense que la plomberie alentour a
aussi son mot à dire sur les performances: cache, bus, ram...
sans compter les problèmes d'alignement qui grèvent les performances
Je te l'ai déjà dit à l'époque, je te le redis maintenant : les opcodes pas alignés, c'est le mode de fonctionnement _normal_ d'un x86, et ça ne grève absolument pas les performances.
Il n'y a pas que le processeur d'important dans ces histoires d'alignement d'opcodes. Je pense que la plomberie alentour a aussi son mot à dire sur les performances: cache, bus, ram...
Rien de précis, aucun argument, aucun exemple. Bravo, c'est du bon troll.
Ben si tu veux du défonçage de portes ouvertes, 1994, OS/400 V3R6M0, bascule du cisc 48 bits au Power (pseudo risc) 64 bits. La seule pénalité était à la première exécution sur la nouvelle plateforme, le système devait regénérer le code natif à partir du code MI stocké dans les objets programme, à part ça c'était transparent, pas de recompilation pour tirer profit des nouvelles possibilités, pas d'adaptation au niveau source. (Le plus beau est que le 400/iSeries/son prochain nom pourra rejouer le même scénario lors du passage aux processeurs 128 bits, du fait de son architecture, pensée au début des années 70 par un véritable visionnaire, Frank Soltis).
Tu peux aussi jeter un oeil du coté des mainframes ibm, hitachi ou encore amdahl qui ont passé cette barrière depuis un certain temps.
En bref, les "bouzins" propriétaires ont effectivement une sacrée longueur d'avance dans le domaine.
-- Un inconnu du nom de Mailer-Daemon reçoit mes mails. Comment cela est possible ? Comment l'eviter. Répondre très rapidement, car mon mois d'essai se termine ce soir, et je suis très inquiete de ce piratage ? -+- Exorcisme dans le GNU - Satan l'habite, son bit l'attend -+-
nicolas vigier <boklm@mars-attacks.org> writes:
'Lut,
Rien de précis, aucun argument, aucun exemple. Bravo, c'est du bon
troll.
Ben si tu veux du défonçage de portes ouvertes, 1994, OS/400 V3R6M0,
bascule du cisc 48 bits au Power (pseudo risc) 64 bits. La seule
pénalité était à la première exécution sur la nouvelle plateforme, le
système devait regénérer le code natif à partir du code MI stocké dans
les objets programme, à part ça c'était transparent, pas de
recompilation pour tirer profit des nouvelles possibilités, pas
d'adaptation au niveau source. (Le plus beau est que le 400/iSeries/son
prochain nom pourra rejouer le même scénario lors du passage aux
processeurs 128 bits, du fait de son architecture, pensée au début des
années 70 par un véritable visionnaire, Frank Soltis).
Tu peux aussi jeter un oeil du coté des mainframes ibm, hitachi ou
encore amdahl qui ont passé cette barrière depuis un certain temps.
En bref, les "bouzins" propriétaires ont effectivement une sacrée
longueur d'avance dans le domaine.
--
Un inconnu du nom de Mailer-Daemon reçoit mes mails. Comment cela est
possible ? Comment l'eviter. Répondre très rapidement, car mon mois
d'essai se termine ce soir, et je suis très inquiete de ce piratage ?
-+- Exorcisme dans le GNU - Satan l'habite, son bit l'attend -+-
Rien de précis, aucun argument, aucun exemple. Bravo, c'est du bon troll.
Ben si tu veux du défonçage de portes ouvertes, 1994, OS/400 V3R6M0, bascule du cisc 48 bits au Power (pseudo risc) 64 bits. La seule pénalité était à la première exécution sur la nouvelle plateforme, le système devait regénérer le code natif à partir du code MI stocké dans les objets programme, à part ça c'était transparent, pas de recompilation pour tirer profit des nouvelles possibilités, pas d'adaptation au niveau source. (Le plus beau est que le 400/iSeries/son prochain nom pourra rejouer le même scénario lors du passage aux processeurs 128 bits, du fait de son architecture, pensée au début des années 70 par un véritable visionnaire, Frank Soltis).
Tu peux aussi jeter un oeil du coté des mainframes ibm, hitachi ou encore amdahl qui ont passé cette barrière depuis un certain temps.
En bref, les "bouzins" propriétaires ont effectivement une sacrée longueur d'avance dans le domaine.
-- Un inconnu du nom de Mailer-Daemon reçoit mes mails. Comment cela est possible ? Comment l'eviter. Répondre très rapidement, car mon mois d'essai se termine ce soir, et je suis très inquiete de ce piratage ? -+- Exorcisme dans le GNU - Satan l'habite, son bit l'attend -+-
Nicolas George
"pehache-tolai" , dans le message , a écrit :
mais en suggérant que d'une manière générale *LES* (et non pas *des*) "bouzins propriétaires" (déjà, "bouzin", c'est pas connoté, hein...) fonctionnent mal en 64 bits,
Oui, ça je le dis. Et bouzin est très connoté. Mais il y a encore une subtilité de la langue qui t'échappe.
"pehache-tolai" , dans le message <5mvdvvFf9tvuU1@mid.individual.net>, a
écrit :
mais en suggérant que d'une manière générale
*LES* (et non pas *des*) "bouzins propriétaires" (déjà, "bouzin", c'est pas
connoté, hein...) fonctionnent mal en 64 bits,
Oui, ça je le dis. Et bouzin est très connoté. Mais il y a encore une
subtilité de la langue qui t'échappe.
mais en suggérant que d'une manière générale *LES* (et non pas *des*) "bouzins propriétaires" (déjà, "bouzin", c'est pas connoté, hein...) fonctionnent mal en 64 bits,
Oui, ça je le dis. Et bouzin est très connoté. Mais il y a encore une subtilité de la langue qui t'échappe.
pehache-tolai
"Nicolas George" <nicolas$ a écrit dans le message de news: fee2dk$1skq$
"pehache-tolai" , dans le message
mais en suggérant que d'une manière générale *LES* (et non pas *des*) "bouzins propriétaires" (déjà, "bouzin", c'est pas connoté, hein...) fonctionnent mal en 64 bits,
Oui, ça je le dis. Et bouzin est très connoté. Mais il y a encore une subtilité de la langue qui t'échappe.
C'est comme Bigard, il est trop subtil pour moi.
Mais à part ça, cette liste de bouzins propriétaires qui fonctionnent mal en 64 bits, on peut la connaître ? Parce qu'à un moment c'est bien de sortir du vague, aussi...
-- pehache http://pehache.free.fr/public.html
"Nicolas George" <nicolas$george@salle-s.org> a écrit dans le message
de news: fee2dk$1skq$1@nef.ens.fr
"pehache-tolai" , dans le message
mais en suggérant que d'une manière générale
*LES* (et non pas *des*) "bouzins propriétaires" (déjà, "bouzin",
c'est pas connoté, hein...) fonctionnent mal en 64 bits,
Oui, ça je le dis. Et bouzin est très connoté. Mais il y a encore une
subtilité de la langue qui t'échappe.
C'est comme Bigard, il est trop subtil pour moi.
Mais à part ça, cette liste de bouzins propriétaires qui fonctionnent mal en
64 bits, on peut la connaître ? Parce qu'à un moment c'est bien de sortir du
vague, aussi...
"Nicolas George" <nicolas$ a écrit dans le message de news: fee2dk$1skq$
"pehache-tolai" , dans le message
mais en suggérant que d'une manière générale *LES* (et non pas *des*) "bouzins propriétaires" (déjà, "bouzin", c'est pas connoté, hein...) fonctionnent mal en 64 bits,
Oui, ça je le dis. Et bouzin est très connoté. Mais il y a encore une subtilité de la langue qui t'échappe.
C'est comme Bigard, il est trop subtil pour moi.
Mais à part ça, cette liste de bouzins propriétaires qui fonctionnent mal en 64 bits, on peut la connaître ? Parce qu'à un moment c'est bien de sortir du vague, aussi...
-- pehache http://pehache.free.fr/public.html
Nicolas S.
remy a écrit:
Dans ce cas, on suppose que l'horloge CMOS de la machine est configurée sur le temps local, et que l'on doit l'augmenter de cette valeur pour obtenir le temps UTC
Mais quel rapport peux-tu bien voir entre ça et la discussion en cours?
-- Nicolas S.
remy <remy@fctpas.fr> a écrit:
Dans ce cas, on suppose que l'horloge CMOS de la machine est
configurée sur le temps local, et que l'on doit l'augmenter de cette
valeur pour obtenir
le temps UTC
Mais quel rapport peux-tu bien voir entre ça et la discussion en cours?
Dans ce cas, on suppose que l'horloge CMOS de la machine est configurée sur le temps local, et que l'on doit l'augmenter de cette valeur pour obtenir le temps UTC
Mais quel rapport peux-tu bien voir entre ça et la discussion en cours?
-- Nicolas S.
Emmanuel Florac
Le Mon, 08 Oct 2007 07:48:17 +0000, JKB a écrit :
Question connexe... Sur sparc64/linux, le userland est 32 bits et le noyau 64 bits. Quelle est la taille maximale de mémoire utilisable par un processus ?
4 Go, je pense.
-- Ne pas savoir de quoi on parle est un avantage dont il ne faut pas abuser. R.Debray
Le Mon, 08 Oct 2007 07:48:17 +0000, JKB a écrit :
Question connexe... Sur sparc64/linux, le userland est 32 bits et le
noyau 64 bits. Quelle est la taille maximale de mémoire utilisable par
un processus ?
4 Go, je pense.
--
Ne pas savoir de quoi on parle est un avantage dont il ne faut pas
abuser.
R.Debray
Question connexe... Sur sparc64/linux, le userland est 32 bits et le noyau 64 bits. Quelle est la taille maximale de mémoire utilisable par un processus ?
4 Go, je pense.
-- Ne pas savoir de quoi on parle est un avantage dont il ne faut pas abuser. R.Debray
Nicolas George
"pehache-tolai" , dans le message , a écrit :
C'est comme Bigard, il est trop subtil pour moi.
Allez, je t'aide : bouzin et logiciel sont deux mots différents, demande-toi pourquoi.
Mais à part ça, cette liste de bouzins propriétaires qui fonctionnent mal en 64 bits, on peut la connaître ?
Oh oui, on peut la connaître, il suffit de la faire. Mais personnellement, j'évite de perdre mon temps avec les conneries.
"pehache-tolai" , dans le message <5mvjalFfke2uU1@mid.individual.net>, a
écrit :
C'est comme Bigard, il est trop subtil pour moi.
Allez, je t'aide : bouzin et logiciel sont deux mots différents, demande-toi
pourquoi.
Mais à part ça, cette liste de bouzins propriétaires qui fonctionnent mal en
64 bits, on peut la connaître ?
Oh oui, on peut la connaître, il suffit de la faire. Mais personnellement,
j'évite de perdre mon temps avec les conneries.
