debug this fifo a formulé la demande :
> Jérémie Bottone wrote:
>
>> - Lent
>
> windows aussi est lent.
Faut, il n'y a qu'à voir le temps pour ouvrir OpenOffice ou Mozilla
sous Windows ou Linux, et on jette Linux
Dans l'ensemble, n'importe quellles t'aches faites sous Windows, par un
utilisateur expérimenté ou pas, sont faites beaucoup plus rapidment,
qu'elles soient locales ou distantes
Pourquoi ? Car Linux est un système bricolé par des bricoleurs, basé
sur du code UNIX datant de 30 ans
Les programmeurs LINUX sont incapable de faire des logiciels terminés
qui fonctionnement bien, d'où e pourquoi du larmoyement et du
pleurnichage perpetuel, de la victimisation même
Alors ils disent: Bouhhhhhh, tous les codes sources doivent être
ouverts !
(Ceci pour éviter de se donner de la peine de développer, et de pouvoir
"pomper" allieurs ce qu'ils sont incapanle de réaliser)
Je hais LINUX et cette mentalité
Microsoft, est une usine de développement, dont il sort des milliers de
logiciels de qualité, s'attirant la jalousie de tous les pingouins du
monde
Et voila, il y a rien a faire. De la, ton ego prend encore une fois le dessus.
Sans blaguer, t'as pense a consulter ?
Bruno Ducrot
On 2009-07-24, totof2000 wrote:
On 24 juil, 20:11, Nicolas George <nicolas$ wrote:
Jerome Lambert , dans le message <4a69cf80$0$2858$, a écrit :
> Si tu veux je peux te la poser plus directement: pourquoi un BIOS > réserve-t-il de la mémoire?
On n'en sait rien.
Trop drole ...
Ce qu'on sait, c'est que les BIOS buggés qui se vautrent sur la mémoire disponible, c'est fréquent.
Personne n'a dit le contraire ...
Je pretends le contraire. Je pense que Nicolas n'a absolument aucune connnaissance sur les chipsets mobiles, surtout ceux de marque Intel. Sinon il n'aurait jamais ecrit une telle annerie.
Il suffit de dire un truc du genre "Tu n'as qu'a regarder n'importe quel spec sur les northbridges mobiles publie par Intel." C'est a peu pres le seul genre de reponse que l'on peut donner qui soit a peu de chose pres comprehensible par Nicolas.
A plus,
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
On 2009-07-24, totof2000 wrote:
On 24 juil, 20:11, Nicolas George <nicolas$geo...@salle-s.org> wrote:
Jerome Lambert , dans le message
<4a69cf80$0$2858$ba620...@news.skynet.be>, a écrit :
> Si tu veux je peux te la poser plus directement: pourquoi un BIOS
> réserve-t-il de la mémoire?
On n'en sait rien.
Trop drole ...
Ce qu'on sait, c'est que les BIOS buggés qui se vautrent
sur la mémoire disponible, c'est fréquent.
Personne n'a dit le contraire ...
Je pretends le contraire. Je pense que Nicolas n'a absolument aucune
connnaissance sur les chipsets mobiles, surtout ceux de marque Intel.
Sinon il n'aurait jamais ecrit une telle annerie.
Il suffit de dire un truc du genre "Tu n'as qu'a regarder n'importe
quel spec sur les northbridges mobiles publie par Intel."
C'est a peu pres le seul genre de reponse que l'on peut donner qui soit
a peu de chose pres comprehensible par Nicolas.
A plus,
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
On 24 juil, 20:11, Nicolas George <nicolas$ wrote:
Jerome Lambert , dans le message <4a69cf80$0$2858$, a écrit :
> Si tu veux je peux te la poser plus directement: pourquoi un BIOS > réserve-t-il de la mémoire?
On n'en sait rien.
Trop drole ...
Ce qu'on sait, c'est que les BIOS buggés qui se vautrent sur la mémoire disponible, c'est fréquent.
Personne n'a dit le contraire ...
Je pretends le contraire. Je pense que Nicolas n'a absolument aucune connnaissance sur les chipsets mobiles, surtout ceux de marque Intel. Sinon il n'aurait jamais ecrit une telle annerie.
Il suffit de dire un truc du genre "Tu n'as qu'a regarder n'importe quel spec sur les northbridges mobiles publie par Intel." C'est a peu pres le seul genre de reponse que l'on peut donner qui soit a peu de chose pres comprehensible par Nicolas.
A plus,
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Nicolas George
Bruno Ducrot , dans le message <4a6d78e8$0$23449$, a écrit :
Il suffit de dire un truc du genre "Tu n'as qu'a regarder n'importe quel spec sur les northbridges mobiles publie par Intel."
Les specs donnent des bornes supérieures. Si ces bornes supérieures étaient effectivement atteintes ou même approchées sur les constructions courantes, Intel perdrait toutes ses parts de marché, car personne ne voudrait d'un chipset qui boufferait une telle quantité de RAM.
Bruno Ducrot , dans le message
<4a6d78e8$0$23449$ba4acef3@news.orange.fr>, a écrit :
Il suffit de dire un truc du genre "Tu n'as qu'a regarder n'importe
quel spec sur les northbridges mobiles publie par Intel."
Les specs donnent des bornes supérieures. Si ces bornes supérieures étaient
effectivement atteintes ou même approchées sur les constructions courantes,
Intel perdrait toutes ses parts de marché, car personne ne voudrait d'un
chipset qui boufferait une telle quantité de RAM.
Bruno Ducrot , dans le message <4a6d78e8$0$23449$, a écrit :
Il suffit de dire un truc du genre "Tu n'as qu'a regarder n'importe quel spec sur les northbridges mobiles publie par Intel."
Les specs donnent des bornes supérieures. Si ces bornes supérieures étaient effectivement atteintes ou même approchées sur les constructions courantes, Intel perdrait toutes ses parts de marché, car personne ne voudrait d'un chipset qui boufferait une telle quantité de RAM.
Bruno Ducrot
On 2009-07-27, Nicolas George wrote:
Bruno Ducrot , dans le message <4a6d78e8$0$23449$, a écrit :
Il suffit de dire un truc du genre "Tu n'as qu'a regarder n'importe quel spec sur les northbridges mobiles publie par Intel."
Les specs donnent des bornes supérieures. Si ces bornes supérieures étaient effectivement atteintes ou même approchées sur les constructions courantes, Intel perdrait toutes ses parts de marché, car personne ne voudrait d'un chipset qui boufferait une telle quantité de RAM.
(en passant, un periph ne bouffe pas de RAM : tout au plus il la "camoufle", si vous voulez bien me pardonner ce terme tout aussi inapproprie, mais l'on ne va pas trop chipoter sur les mots)
Si je comprends bien, pour vous, et malgre le fait que ce soit documente par Intel, vous deduisez que les configurations courantes n'ont pas de problemes, car sinon ca se verrait et ca ne se vendrait pas ?
Cependant, il suffit de tapper, par exemple, "BIOS memory remapping" sur un moteur de recherche pour verifier que ce genre de configuration est plus courante que vous ne semblez le croire. Meme si la plupart du temps l'on ne perd typiquement que 756Mo, la perte de 1Go est tout de meme assez courante.
Enfin, dans le cas des version mobile des northbridges vendu par Intel, puisque ceux-ci ne sont pas capable d'adresser plus de 4Go (contrairement aux versions Desktop qui vont jusqu'a 8Go), la bidouille un peu crade pour recuperer une partie de la ram ne fonctionnera pas.
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
On 2009-07-27, Nicolas George wrote:
Bruno Ducrot , dans le message
<4a6d78e8$0$23449$ba4acef3@news.orange.fr>, a écrit :
Il suffit de dire un truc du genre "Tu n'as qu'a regarder n'importe
quel spec sur les northbridges mobiles publie par Intel."
Les specs donnent des bornes supérieures. Si ces bornes supérieures étaient
effectivement atteintes ou même approchées sur les constructions courantes,
Intel perdrait toutes ses parts de marché, car personne ne voudrait d'un
chipset qui boufferait une telle quantité de RAM.
(en passant, un periph ne bouffe pas de RAM : tout au plus il la "camoufle",
si vous voulez bien me pardonner ce terme tout aussi inapproprie, mais
l'on ne va pas trop chipoter sur les mots)
Si je comprends bien, pour vous, et malgre le fait que ce soit documente
par Intel, vous deduisez que les configurations courantes n'ont pas
de problemes, car sinon ca se verrait et ca ne se vendrait pas ?
Cependant, il suffit de tapper, par exemple, "BIOS memory remapping" sur
un moteur de recherche pour verifier que ce genre de configuration est
plus courante que vous ne semblez le croire. Meme si la plupart du
temps l'on ne perd typiquement que 756Mo, la perte de 1Go est tout de
meme assez courante.
Enfin, dans le cas des version mobile des northbridges vendu par Intel,
puisque ceux-ci ne sont pas capable d'adresser plus de 4Go (contrairement
aux versions Desktop qui vont jusqu'a 8Go), la bidouille un peu crade pour
recuperer une partie de la ram ne fonctionnera pas.
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
Bruno Ducrot , dans le message <4a6d78e8$0$23449$, a écrit :
Il suffit de dire un truc du genre "Tu n'as qu'a regarder n'importe quel spec sur les northbridges mobiles publie par Intel."
Les specs donnent des bornes supérieures. Si ces bornes supérieures étaient effectivement atteintes ou même approchées sur les constructions courantes, Intel perdrait toutes ses parts de marché, car personne ne voudrait d'un chipset qui boufferait une telle quantité de RAM.
(en passant, un periph ne bouffe pas de RAM : tout au plus il la "camoufle", si vous voulez bien me pardonner ce terme tout aussi inapproprie, mais l'on ne va pas trop chipoter sur les mots)
Si je comprends bien, pour vous, et malgre le fait que ce soit documente par Intel, vous deduisez que les configurations courantes n'ont pas de problemes, car sinon ca se verrait et ca ne se vendrait pas ?
Cependant, il suffit de tapper, par exemple, "BIOS memory remapping" sur un moteur de recherche pour verifier que ce genre de configuration est plus courante que vous ne semblez le croire. Meme si la plupart du temps l'on ne perd typiquement que 756Mo, la perte de 1Go est tout de meme assez courante.
Enfin, dans le cas des version mobile des northbridges vendu par Intel, puisque ceux-ci ne sont pas capable d'adresser plus de 4Go (contrairement aux versions Desktop qui vont jusqu'a 8Go), la bidouille un peu crade pour recuperer une partie de la ram ne fonctionnera pas.
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Nicolas George
Bruno Ducrot , dans le message <4a6d99a0$0$17770$, a écrit :
(en passant, un periph ne bouffe pas de RAM : tout au plus il la "camoufle", si vous voulez bien me pardonner ce terme tout aussi inapproprie, mais l'on ne va pas trop chipoter sur les mots)
Si c'est l'espace d'adressage qui est occupé, et pas la mémoire (comme c'est le cas avec un contrôleur vidéo en mémoire partagée), alors il est possible pour le système d'exploitation d'utiliser cette RAM, donc on revient à une lacune logicielle.
Si je comprends bien, pour vous, et malgre le fait que ce soit documente par Intel, vous deduisez que les configurations courantes n'ont pas de problemes, car sinon ca se verrait et ca ne se vendrait pas ?
Exactement.
Cependant, il suffit de tapper, par exemple, "BIOS memory remapping" sur un moteur de recherche pour verifier que ce genre de configuration est plus courante que vous ne semblez le croire.
Les moteurs de recherche ne filtrent pas encore les rumeurs qui se propagent sans fondement réel.
Enfin, dans le cas des version mobile des northbridges vendu par Intel, puisque ceux-ci ne sont pas capable d'adresser plus de 4Go (contrairement aux versions Desktop qui vont jusqu'a 8Go), la bidouille un peu crade pour recuperer une partie de la ram ne fonctionnera pas.
C'est une autre problématique.
Bruno Ducrot , dans le message
<4a6d99a0$0$17770$ba4acef3@news.orange.fr>, a écrit :
(en passant, un periph ne bouffe pas de RAM : tout au plus il la "camoufle",
si vous voulez bien me pardonner ce terme tout aussi inapproprie, mais
l'on ne va pas trop chipoter sur les mots)
Si c'est l'espace d'adressage qui est occupé, et pas la mémoire (comme c'est
le cas avec un contrôleur vidéo en mémoire partagée), alors il est possible
pour le système d'exploitation d'utiliser cette RAM, donc on revient à une
lacune logicielle.
Si je comprends bien, pour vous, et malgre le fait que ce soit documente
par Intel, vous deduisez que les configurations courantes n'ont pas
de problemes, car sinon ca se verrait et ca ne se vendrait pas ?
Exactement.
Cependant, il suffit de tapper, par exemple, "BIOS memory remapping" sur
un moteur de recherche pour verifier que ce genre de configuration est
plus courante que vous ne semblez le croire.
Les moteurs de recherche ne filtrent pas encore les rumeurs qui se propagent
sans fondement réel.
Enfin, dans le cas des version mobile des northbridges vendu par Intel,
puisque ceux-ci ne sont pas capable d'adresser plus de 4Go (contrairement
aux versions Desktop qui vont jusqu'a 8Go), la bidouille un peu crade pour
recuperer une partie de la ram ne fonctionnera pas.
Bruno Ducrot , dans le message <4a6d99a0$0$17770$, a écrit :
(en passant, un periph ne bouffe pas de RAM : tout au plus il la "camoufle", si vous voulez bien me pardonner ce terme tout aussi inapproprie, mais l'on ne va pas trop chipoter sur les mots)
Si c'est l'espace d'adressage qui est occupé, et pas la mémoire (comme c'est le cas avec un contrôleur vidéo en mémoire partagée), alors il est possible pour le système d'exploitation d'utiliser cette RAM, donc on revient à une lacune logicielle.
Si je comprends bien, pour vous, et malgre le fait que ce soit documente par Intel, vous deduisez que les configurations courantes n'ont pas de problemes, car sinon ca se verrait et ca ne se vendrait pas ?
Exactement.
Cependant, il suffit de tapper, par exemple, "BIOS memory remapping" sur un moteur de recherche pour verifier que ce genre de configuration est plus courante que vous ne semblez le croire.
Les moteurs de recherche ne filtrent pas encore les rumeurs qui se propagent sans fondement réel.
Enfin, dans le cas des version mobile des northbridges vendu par Intel, puisque ceux-ci ne sont pas capable d'adresser plus de 4Go (contrairement aux versions Desktop qui vont jusqu'a 8Go), la bidouille un peu crade pour recuperer une partie de la ram ne fonctionnera pas.
C'est une autre problématique.
pehache-tolai
On 24 juil, 19:31, JKB wrote:
> Déjà, pas forcément : elles peuvent être présentes, mais avec une API > différente.
> Et si elles ne sont pas présente et bien on les implémente. Elles n e > sont alors pas plus émulées que si elles étaient dans le kernel.
> Et avec ta conception, tout devient émulation : si j'installe sous > Windows ou n'importe quel OS une librairie de FFT par exemple, est-ce > que tu vas dire qu'on émule une fonctionnalité (les FFT) qui n'est pas > présente sur le système hôte ?? Idiot, n'est-ce pas ? Et pourtant ce > qu'il faudrait dire suivant ta logique.
Que je sache, une FFT est un truc qui est implantable en userland, et strictement en userland.
Et alors ? Je ne sais bien que ça n'aurait que peu d'intérêt de l'implémenter dans un kernel, mais rien n'empêche de le faire non plus. Ce ne serait pas la première fois qu'on verrait dans un kernel un truc dont on se demande ce qu'il fout là.
Bref, ma comparaison est valide.
C'est donc une bibliothèque totalement indépendante de l'OS (si on l'écrit bien, mais c'est un autre débat ). En écrivant une FFT, on n'a absolument pas besoin de gérer des trucs aussi abscons que l'atomicité.
Je ne vois pas ce que l'atomicité a d'abscons, mais passons.
Et en toute rigueur, et comme ça a été dit dans d'autres réponses d e ce fil, on n'a pas absolument besoin non plus de gérer l'atomicité pour implémenter une API de threads.
Si le système hôte ne fournit rien pour gérer une API de thread Posix, tu ne peux qu'essayer de l'émuler en u serland
Non : de l'implémenter.
>> D'ailleurs, >> 'implémenter', c'est tout sauf français.
Et bien regarde dans petit bob. Dans le seul dictionnaire que j'ai sous la main et qui comporte ce mot, j'ai en GROS 'anglicisme' et 'barbar isme', que tu le veuilles ou non. En français, on dit 'implanter', comme on di t 'decryptement' et non 'décryptage' (bien que là encore, le Larousse e st permissif, mais je ne vais pas dire ici ce que je pense du Larousse !).
Même si c'est anglicisme à la base, implémenter est maintenant largement passé dans la langue française et il est totalement vain de battre contre.
-- pehache
On 24 juil, 19:31, JKB <knatsc...@koenigsberg.fr> wrote:
> Déjà, pas forcément : elles peuvent être présentes, mais avec une API
> différente.
> Et si elles ne sont pas présente et bien on les implémente. Elles n e
> sont alors pas plus émulées que si elles étaient dans le kernel.
> Et avec ta conception, tout devient émulation : si j'installe sous
> Windows ou n'importe quel OS une librairie de FFT par exemple, est-ce
> que tu vas dire qu'on émule une fonctionnalité (les FFT) qui n'est pas
> présente sur le système hôte ?? Idiot, n'est-ce pas ? Et pourtant ce
> qu'il faudrait dire suivant ta logique.
Que je sache, une FFT est un truc qui est implantable en userland,
et strictement en userland.
Et alors ? Je ne sais bien que ça n'aurait que peu d'intérêt de
l'implémenter dans un kernel, mais rien n'empêche de le faire non
plus. Ce ne serait pas la première fois qu'on verrait dans un kernel
un truc dont on se demande ce qu'il fout là.
Bref, ma comparaison est valide.
C'est donc une bibliothèque totalement
indépendante de l'OS (si on l'écrit bien, mais c'est un autre débat ).
En écrivant une FFT, on n'a absolument pas besoin de gérer des trucs
aussi abscons que l'atomicité.
Je ne vois pas ce que l'atomicité a d'abscons, mais passons.
Et en toute rigueur, et comme ça a été dit dans d'autres réponses d e
ce fil, on n'a pas absolument besoin non plus de gérer l'atomicité
pour implémenter une API de threads.
Si le système hôte ne fournit rien pour
gérer une API de thread Posix, tu ne peux qu'essayer de l'émuler en u serland
Non : de l'implémenter.
>> D'ailleurs,
>> 'implémenter', c'est tout sauf français.
Et bien regarde dans petit bob. Dans le seul dictionnaire que j'ai
sous la main et qui comporte ce mot, j'ai en GROS 'anglicisme' et 'barbar isme',
que tu le veuilles ou non. En français, on dit 'implanter', comme on di t
'decryptement' et non 'décryptage' (bien que là encore, le Larousse e st
permissif, mais je ne vais pas dire ici ce que je pense du Larousse !).
Même si c'est anglicisme à la base, implémenter est maintenant
largement passé dans la langue française et il est totalement vain de
battre contre.
> Déjà, pas forcément : elles peuvent être présentes, mais avec une API > différente.
> Et si elles ne sont pas présente et bien on les implémente. Elles n e > sont alors pas plus émulées que si elles étaient dans le kernel.
> Et avec ta conception, tout devient émulation : si j'installe sous > Windows ou n'importe quel OS une librairie de FFT par exemple, est-ce > que tu vas dire qu'on émule une fonctionnalité (les FFT) qui n'est pas > présente sur le système hôte ?? Idiot, n'est-ce pas ? Et pourtant ce > qu'il faudrait dire suivant ta logique.
Que je sache, une FFT est un truc qui est implantable en userland, et strictement en userland.
Et alors ? Je ne sais bien que ça n'aurait que peu d'intérêt de l'implémenter dans un kernel, mais rien n'empêche de le faire non plus. Ce ne serait pas la première fois qu'on verrait dans un kernel un truc dont on se demande ce qu'il fout là.
Bref, ma comparaison est valide.
C'est donc une bibliothèque totalement indépendante de l'OS (si on l'écrit bien, mais c'est un autre débat ). En écrivant une FFT, on n'a absolument pas besoin de gérer des trucs aussi abscons que l'atomicité.
Je ne vois pas ce que l'atomicité a d'abscons, mais passons.
Et en toute rigueur, et comme ça a été dit dans d'autres réponses d e ce fil, on n'a pas absolument besoin non plus de gérer l'atomicité pour implémenter une API de threads.
Si le système hôte ne fournit rien pour gérer une API de thread Posix, tu ne peux qu'essayer de l'émuler en u serland
Non : de l'implémenter.
>> D'ailleurs, >> 'implémenter', c'est tout sauf français.
Et bien regarde dans petit bob. Dans le seul dictionnaire que j'ai sous la main et qui comporte ce mot, j'ai en GROS 'anglicisme' et 'barbar isme', que tu le veuilles ou non. En français, on dit 'implanter', comme on di t 'decryptement' et non 'décryptage' (bien que là encore, le Larousse e st permissif, mais je ne vais pas dire ici ce que je pense du Larousse !).
Même si c'est anglicisme à la base, implémenter est maintenant largement passé dans la langue française et il est totalement vain de battre contre.
-- pehache
Bruno Ducrot
On 2009-07-27, Nicolas George wrote:
Bruno Ducrot , dans le message <4a6d99a0$0$17770$, a écrit :
(en passant, un periph ne bouffe pas de RAM : tout au plus il la "camoufle", si vous voulez bien me pardonner ce terme tout aussi inapproprie, mais l'on ne va pas trop chipoter sur les mots)
Si c'est l'espace d'adressage qui est occupé, et pas la mémoire (comme c'est le cas avec un contrôleur vidéo en mémoire partagée), alors il est possible pour le système d'exploitation d'utiliser cette RAM, donc on revient à une lacune logicielle.
Justement, lisez plus attentivement ma reponse sur le probleme des northbrides version mobile de chez Intel.
Si je comprends bien, pour vous, et malgre le fait que ce soit documente par Intel, vous deduisez que les configurations courantes n'ont pas de problemes, car sinon ca se verrait et ca ne se vendrait pas ?
Exactement.
Il s'agit d'un raisonnement certes tout-a-fait logique, mais qui manque cruellement de donnees concretes pour que je puisse l'accepter sans me poser de questions.
Cependant, il suffit de tapper, par exemple, "BIOS memory remapping" sur un moteur de recherche pour verifier que ce genre de configuration est plus courante que vous ne semblez le croire.
Les moteurs de recherche ne filtrent pas encore les rumeurs qui se propagent sans fondement réel.
Il n'y a pas de fumees sans feu (j'avoue que mon argument est completement foireux, mais le votre l'est tout autant).
Enfin, dans le cas des version mobile des northbridges vendu par Intel, puisque ceux-ci ne sont pas capable d'adresser plus de 4Go (contrairement aux versions Desktop qui vont jusqu'a 8Go), la bidouille un peu crade pour recuperer une partie de la ram ne fonctionnera pas.
C'est une autre problématique.
Pardon ? Cela montre surtout que certains ordinateurs portables, a base de chipset Intel, sont souvent limites a 3 Go, voire 3,2 Go en raison de cette limitation, et que dans ce cas precis, ce ne peut etre un probleme d'OS, ni de BIOS buggue.
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
On 2009-07-27, Nicolas George wrote:
Bruno Ducrot , dans le message
<4a6d99a0$0$17770$ba4acef3@news.orange.fr>, a écrit :
(en passant, un periph ne bouffe pas de RAM : tout au plus il la "camoufle",
si vous voulez bien me pardonner ce terme tout aussi inapproprie, mais
l'on ne va pas trop chipoter sur les mots)
Si c'est l'espace d'adressage qui est occupé, et pas la mémoire (comme c'est
le cas avec un contrôleur vidéo en mémoire partagée), alors il est possible
pour le système d'exploitation d'utiliser cette RAM, donc on revient à une
lacune logicielle.
Justement, lisez plus attentivement ma reponse sur le probleme des
northbrides version mobile de chez Intel.
Si je comprends bien, pour vous, et malgre le fait que ce soit documente
par Intel, vous deduisez que les configurations courantes n'ont pas
de problemes, car sinon ca se verrait et ca ne se vendrait pas ?
Exactement.
Il s'agit d'un raisonnement certes tout-a-fait logique, mais qui
manque cruellement de donnees concretes pour que je puisse l'accepter
sans me poser de questions.
Cependant, il suffit de tapper, par exemple, "BIOS memory remapping" sur
un moteur de recherche pour verifier que ce genre de configuration est
plus courante que vous ne semblez le croire.
Les moteurs de recherche ne filtrent pas encore les rumeurs qui se propagent
sans fondement réel.
Il n'y a pas de fumees sans feu (j'avoue que mon argument est completement
foireux, mais le votre l'est tout autant).
Enfin, dans le cas des version mobile des northbridges vendu par Intel,
puisque ceux-ci ne sont pas capable d'adresser plus de 4Go (contrairement
aux versions Desktop qui vont jusqu'a 8Go), la bidouille un peu crade pour
recuperer une partie de la ram ne fonctionnera pas.
C'est une autre problématique.
Pardon ? Cela montre surtout que certains ordinateurs portables, a base
de chipset Intel, sont souvent limites a 3 Go, voire 3,2 Go en raison de
cette limitation, et que dans ce cas precis, ce ne peut etre un probleme
d'OS, ni de BIOS buggue.
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
Bruno Ducrot , dans le message <4a6d99a0$0$17770$, a écrit :
(en passant, un periph ne bouffe pas de RAM : tout au plus il la "camoufle", si vous voulez bien me pardonner ce terme tout aussi inapproprie, mais l'on ne va pas trop chipoter sur les mots)
Si c'est l'espace d'adressage qui est occupé, et pas la mémoire (comme c'est le cas avec un contrôleur vidéo en mémoire partagée), alors il est possible pour le système d'exploitation d'utiliser cette RAM, donc on revient à une lacune logicielle.
Justement, lisez plus attentivement ma reponse sur le probleme des northbrides version mobile de chez Intel.
Si je comprends bien, pour vous, et malgre le fait que ce soit documente par Intel, vous deduisez que les configurations courantes n'ont pas de problemes, car sinon ca se verrait et ca ne se vendrait pas ?
Exactement.
Il s'agit d'un raisonnement certes tout-a-fait logique, mais qui manque cruellement de donnees concretes pour que je puisse l'accepter sans me poser de questions.
Cependant, il suffit de tapper, par exemple, "BIOS memory remapping" sur un moteur de recherche pour verifier que ce genre de configuration est plus courante que vous ne semblez le croire.
Les moteurs de recherche ne filtrent pas encore les rumeurs qui se propagent sans fondement réel.
Il n'y a pas de fumees sans feu (j'avoue que mon argument est completement foireux, mais le votre l'est tout autant).
Enfin, dans le cas des version mobile des northbridges vendu par Intel, puisque ceux-ci ne sont pas capable d'adresser plus de 4Go (contrairement aux versions Desktop qui vont jusqu'a 8Go), la bidouille un peu crade pour recuperer une partie de la ram ne fonctionnera pas.
C'est une autre problématique.
Pardon ? Cela montre surtout que certains ordinateurs portables, a base de chipset Intel, sont souvent limites a 3 Go, voire 3,2 Go en raison de cette limitation, et que dans ce cas precis, ce ne peut etre un probleme d'OS, ni de BIOS buggue.
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Nicolas George
Bruno Ducrot , dans le message <4a6dabf4$0$17783$, a écrit :
Justement, lisez plus attentivement ma reponse sur le probleme des northbrides version mobile de chez Intel.
Je ne vois pas ce que je suis censé avoir manqué.
Il n'y a pas de fumees sans feu (j'avoue que mon argument est completement foireux, mais le votre l'est tout autant).
Le fait que certains voient de la RAM manquante indique que quelque chose fait manquer la RAM, mais pas que ce quelque chose est matériel, ça peut très bien être un BIOS buggé ou mal configuré.
Pardon ?
Une limite absolue d'un matériel, c'est quelque chose de différent. C'est comme pour les barrettes mémoire double face : les vieux chipsets n'en voyaient qu'une face.
Si quelqu'un met 4 Go dans un matériel qui est limité à 3 Go, et le vend comme 4 Go, c'est un escroc, c'est tout.
Bruno Ducrot , dans le message
<4a6dabf4$0$17783$ba4acef3@news.orange.fr>, a écrit :
Justement, lisez plus attentivement ma reponse sur le probleme des
northbrides version mobile de chez Intel.
Je ne vois pas ce que je suis censé avoir manqué.
Il n'y a pas de fumees sans feu (j'avoue que mon argument est completement
foireux, mais le votre l'est tout autant).
Le fait que certains voient de la RAM manquante indique que quelque chose
fait manquer la RAM, mais pas que ce quelque chose est matériel, ça peut
très bien être un BIOS buggé ou mal configuré.
Pardon ?
Une limite absolue d'un matériel, c'est quelque chose de différent. C'est
comme pour les barrettes mémoire double face : les vieux chipsets n'en
voyaient qu'une face.
Si quelqu'un met 4 Go dans un matériel qui est limité à 3 Go, et le vend
comme 4 Go, c'est un escroc, c'est tout.
Bruno Ducrot , dans le message <4a6dabf4$0$17783$, a écrit :
Justement, lisez plus attentivement ma reponse sur le probleme des northbrides version mobile de chez Intel.
Je ne vois pas ce que je suis censé avoir manqué.
Il n'y a pas de fumees sans feu (j'avoue que mon argument est completement foireux, mais le votre l'est tout autant).
Le fait que certains voient de la RAM manquante indique que quelque chose fait manquer la RAM, mais pas que ce quelque chose est matériel, ça peut très bien être un BIOS buggé ou mal configuré.
Pardon ?
Une limite absolue d'un matériel, c'est quelque chose de différent. C'est comme pour les barrettes mémoire double face : les vieux chipsets n'en voyaient qu'une face.
Si quelqu'un met 4 Go dans un matériel qui est limité à 3 Go, et le vend comme 4 Go, c'est un escroc, c'est tout.
Toxico Nimbus
Le 27/07/2009 14:32, pehache-tolai a écrit :
Que je sache, une FFT est un truc qui est implantable en userland, et strictement en userland.
Et alors ? Je ne sais bien que ça n'aurait que peu d'intérêt de l'implémenter dans un kernel, mais rien n'empêche de le faire non plus. Ce ne serait pas la première fois qu'on verrait dans un kernel un truc dont on se demande ce qu'il fout là.
Bref, ma comparaison est valide.
Surement pas, une lib de FFT n'a aucun besoin d'être en kernelland alors qu'une gestion correcte de threading - j'entends par là des threads préemptifs et gérant le multiprocesseur - ne peut exister entièrement en userland, justement parce que l'on ne peut se permettre d'ignorer les problèmes d'atomicité.
C'est donc une bibliothèque totalement indépendante de l'OS (si on l'écrit bien, mais c'est un autre débat). En écrivant une FFT, on n'a absolument pas besoin de gérer des trucs aussi abscons que l'atomicité.
Je ne vois pas ce que l'atomicité a d'abscons, mais passons.
Et en toute rigueur, et comme ça a été dit dans d'autres réponses de ce fil, on n'a pas absolument besoin non plus de gérer l'atomicité pour implémenter une API de threads.
L'atomicité est inhérente au parallélisme. Dans un environnement parallèle, le développeur doit forcément pouvoir s'assurer l'atomicité des ses sections critiques. Or Il ne peut pas le faire sans avoir à recourir au noyau.
-- Toxico Nimbus
Le 27/07/2009 14:32, pehache-tolai a écrit :
Que je sache, une FFT est un truc qui est implantable en userland,
et strictement en userland.
Et alors ? Je ne sais bien que ça n'aurait que peu d'intérêt de
l'implémenter dans un kernel, mais rien n'empêche de le faire non
plus. Ce ne serait pas la première fois qu'on verrait dans un kernel
un truc dont on se demande ce qu'il fout là.
Bref, ma comparaison est valide.
Surement pas, une lib de FFT n'a aucun besoin d'être en kernelland alors
qu'une gestion correcte de threading - j'entends par là des threads
préemptifs et gérant le multiprocesseur - ne peut exister entièrement en
userland, justement parce que l'on ne peut se permettre d'ignorer les
problèmes d'atomicité.
C'est donc une bibliothèque totalement
indépendante de l'OS (si on l'écrit bien, mais c'est un autre débat).
En écrivant une FFT, on n'a absolument pas besoin de gérer des trucs
aussi abscons que l'atomicité.
Je ne vois pas ce que l'atomicité a d'abscons, mais passons.
Et en toute rigueur, et comme ça a été dit dans d'autres réponses de
ce fil, on n'a pas absolument besoin non plus de gérer l'atomicité
pour implémenter une API de threads.
L'atomicité est inhérente au parallélisme. Dans un environnement
parallèle, le développeur doit forcément pouvoir s'assurer l'atomicité
des ses sections critiques. Or Il ne peut pas le faire sans avoir à
recourir au noyau.
Que je sache, une FFT est un truc qui est implantable en userland, et strictement en userland.
Et alors ? Je ne sais bien que ça n'aurait que peu d'intérêt de l'implémenter dans un kernel, mais rien n'empêche de le faire non plus. Ce ne serait pas la première fois qu'on verrait dans un kernel un truc dont on se demande ce qu'il fout là.
Bref, ma comparaison est valide.
Surement pas, une lib de FFT n'a aucun besoin d'être en kernelland alors qu'une gestion correcte de threading - j'entends par là des threads préemptifs et gérant le multiprocesseur - ne peut exister entièrement en userland, justement parce que l'on ne peut se permettre d'ignorer les problèmes d'atomicité.
C'est donc une bibliothèque totalement indépendante de l'OS (si on l'écrit bien, mais c'est un autre débat). En écrivant une FFT, on n'a absolument pas besoin de gérer des trucs aussi abscons que l'atomicité.
Je ne vois pas ce que l'atomicité a d'abscons, mais passons.
Et en toute rigueur, et comme ça a été dit dans d'autres réponses de ce fil, on n'a pas absolument besoin non plus de gérer l'atomicité pour implémenter une API de threads.
L'atomicité est inhérente au parallélisme. Dans un environnement parallèle, le développeur doit forcément pouvoir s'assurer l'atomicité des ses sections critiques. Or Il ne peut pas le faire sans avoir à recourir au noyau.
-- Toxico Nimbus
pehache-tolai
On 27 juil, 16:31, Toxico Nimbus wrote:
Le 27/07/2009 14:32, pehache-tolai a écrit :
>> Que je sache, une FFT est un truc qui est implantab le en userland, >> et strictement en userland.
> Et alors ? Je ne sais bien que ça n'aurait que peu d'intérêt de > l'implémenter dans un kernel, mais rien n'empêche de le faire non > plus. Ce ne serait pas la première fois qu'on verrait dans un kernel > un truc dont on se demande ce qu'il fout là.
> Bref, ma comparaison est valide.
Surement pas, une lib de FFT n'a aucun besoin d'être en kernelland alor s qu'une gestion correcte de threading - j'entends par là des threads préemptifs et gérant le multiprocesseur - ne peut exister entièreme nt en userland, justement parce que l'on ne peut se permettre d'ignorer les problèmes d'atomicité.
La spécification POSIX dit-elle que les threads doivent obligatoirement tourner sur plusieurs proc ? Si la réponse est non, une implémentation en userland qui du coup est restreinte à un processeur unique est valide. Sans grand intérêt certes (sinon de permettre une portabilité directe d'un code Posix), mais valide.
-- pehache
On 27 juil, 16:31, Toxico Nimbus <T...@free.fr> wrote:
Le 27/07/2009 14:32, pehache-tolai a écrit :
>> Que je sache, une FFT est un truc qui est implantab le en userland,
>> et strictement en userland.
> Et alors ? Je ne sais bien que ça n'aurait que peu d'intérêt de
> l'implémenter dans un kernel, mais rien n'empêche de le faire non
> plus. Ce ne serait pas la première fois qu'on verrait dans un kernel
> un truc dont on se demande ce qu'il fout là.
> Bref, ma comparaison est valide.
Surement pas, une lib de FFT n'a aucun besoin d'être en kernelland alor s
qu'une gestion correcte de threading - j'entends par là des threads
préemptifs et gérant le multiprocesseur - ne peut exister entièreme nt en
userland, justement parce que l'on ne peut se permettre d'ignorer les
problèmes d'atomicité.
La spécification POSIX dit-elle que les threads doivent
obligatoirement tourner sur plusieurs proc ? Si la réponse est non,
une implémentation en userland qui du coup est restreinte à un
processeur unique est valide. Sans grand intérêt certes (sinon de
permettre une portabilité directe d'un code Posix), mais valide.
>> Que je sache, une FFT est un truc qui est implantab le en userland, >> et strictement en userland.
> Et alors ? Je ne sais bien que ça n'aurait que peu d'intérêt de > l'implémenter dans un kernel, mais rien n'empêche de le faire non > plus. Ce ne serait pas la première fois qu'on verrait dans un kernel > un truc dont on se demande ce qu'il fout là.
> Bref, ma comparaison est valide.
Surement pas, une lib de FFT n'a aucun besoin d'être en kernelland alor s qu'une gestion correcte de threading - j'entends par là des threads préemptifs et gérant le multiprocesseur - ne peut exister entièreme nt en userland, justement parce que l'on ne peut se permettre d'ignorer les problèmes d'atomicité.
La spécification POSIX dit-elle que les threads doivent obligatoirement tourner sur plusieurs proc ? Si la réponse est non, une implémentation en userland qui du coup est restreinte à un processeur unique est valide. Sans grand intérêt certes (sinon de permettre une portabilité directe d'un code Posix), mais valide.
