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
Tu viens en une phrase de montrer que tu ne comprends rien à rien et que tu ne sais pas lire une spec. L'atomicité est rendue obligatoire pour certaines fonctions (au hasard pthread_mutex_* sem_*). Les fonctions sem_* sont async safe. La conséquence des deux prérequis impose qu'elles doivent être implantées en mode noyau.
Alors, au risque de me repeter, cela suppose trois possibilites :
- C'est supporte par le noyau de Windows et Cygwin l'utilise pour l'implementer. - Ce n'est pas supporte par le noyau de Windows, mais c'est implemente en userland par Cygwin. - Ce n'est pas supporte par le noyau de Windows, mais ce n'est pas implementable en userland ... donc ce n'est pas implemente dans Cygwin.
Je n'ai aucune idee de la quelle des trois suppositions est exacte, je presume que selon les fonctions, on tombe au moins une fois dans une des trois.
Mais tout ca ne fait pas de Cygwin un emulateur POSIX. Parce qu'on emule pas une norme, on l'implemente.
Et tu n'as toujours pas répondu à la question. Veux-tu que je te la repose ?
Parce que je m'en fous de ta question. Tu te trompes de debat, tu as dit une connerie en ecrivant que Cygwin est une emulation de POSIX et tu essayes de noyer le poisson.
C'est toi qui tient absolument à avoir raison.
Je m'en fous, je ne fais que suivre la definition d'un dictionnaire pour te parler. Le premier pekin qui sait lire un dico sait que tu as tord, parce que le simple fait "d'emuler une norme" ne veut strictement rien dire en soit.
D'ailleurs une norme etant un concept abstrait, on pourrait au mieux la simuler. Pour se faire, seule une autre norme pourrait faire ca, pas un programme informatique.
Je n'ai jamais pretendu une telle chose.
Si, relis-toi bien.
J'ai pas besoin, je peux pas avoir dit une telle chose pour la simple et bonne raison que je ne comprends meme pas la signification de la phrase que tu as marque.
Contrairement a toi, mon metier et mes connaissances ne portent pas sur la programmation en bas niveau, j'execre le multi-thread, que tous les developpeurs veulent placer partout et qui ne servent strictement a rien dans mon metier (sauf a certains niveau ou je n'interviens pas).
Mais tout ca ne m'empeche pas de savoir ce qu'est une norme et une emulation et dans quel contexte on peut utiliser ces deux mots.
JKB wrote:
Tu viens en une phrase de montrer que tu ne comprends rien à rien et
que tu ne sais pas lire une spec. L'atomicité est rendue obligatoire
pour certaines fonctions (au hasard pthread_mutex_* sem_*). Les
fonctions sem_* sont async safe. La conséquence des deux prérequis
impose qu'elles doivent être implantées en mode noyau.
Alors, au risque de me repeter, cela suppose trois possibilites :
- C'est supporte par le noyau de Windows et Cygwin l'utilise pour
l'implementer.
- Ce n'est pas supporte par le noyau de Windows, mais c'est implemente
en userland par Cygwin.
- Ce n'est pas supporte par le noyau de Windows, mais ce n'est pas
implementable en userland ... donc ce n'est pas implemente dans
Cygwin.
Je n'ai aucune idee de la quelle des trois suppositions est exacte, je
presume que selon les fonctions, on tombe au moins une fois dans une des
trois.
Mais tout ca ne fait pas de Cygwin un emulateur POSIX. Parce qu'on emule
pas une norme, on l'implemente.
Et tu n'as toujours pas répondu à la question. Veux-tu que je te la
repose ?
Parce que je m'en fous de ta question. Tu te trompes de debat, tu as dit
une connerie en ecrivant que Cygwin est une emulation de POSIX et tu
essayes de noyer le poisson.
C'est toi qui tient absolument à avoir raison.
Je m'en fous, je ne fais que suivre la definition d'un dictionnaire pour
te parler. Le premier pekin qui sait lire un dico sait que tu as tord,
parce que le simple fait "d'emuler une norme" ne veut strictement rien
dire en soit.
D'ailleurs une norme etant un concept abstrait, on pourrait au mieux la
simuler. Pour se faire, seule une autre norme pourrait faire ca, pas un
programme informatique.
Je n'ai jamais pretendu une telle chose.
Si, relis-toi bien.
J'ai pas besoin, je peux pas avoir dit une telle chose pour la simple et
bonne raison que je ne comprends meme pas la signification de la phrase
que tu as marque.
Contrairement a toi, mon metier et mes connaissances ne portent pas sur
la programmation en bas niveau, j'execre le multi-thread, que tous les
developpeurs veulent placer partout et qui ne servent strictement a rien
dans mon metier (sauf a certains niveau ou je n'interviens pas).
Mais tout ca ne m'empeche pas de savoir ce qu'est une norme et une
emulation et dans quel contexte on peut utiliser ces deux mots.
Tu viens en une phrase de montrer que tu ne comprends rien à rien et que tu ne sais pas lire une spec. L'atomicité est rendue obligatoire pour certaines fonctions (au hasard pthread_mutex_* sem_*). Les fonctions sem_* sont async safe. La conséquence des deux prérequis impose qu'elles doivent être implantées en mode noyau.
Alors, au risque de me repeter, cela suppose trois possibilites :
- C'est supporte par le noyau de Windows et Cygwin l'utilise pour l'implementer. - Ce n'est pas supporte par le noyau de Windows, mais c'est implemente en userland par Cygwin. - Ce n'est pas supporte par le noyau de Windows, mais ce n'est pas implementable en userland ... donc ce n'est pas implemente dans Cygwin.
Je n'ai aucune idee de la quelle des trois suppositions est exacte, je presume que selon les fonctions, on tombe au moins une fois dans une des trois.
Mais tout ca ne fait pas de Cygwin un emulateur POSIX. Parce qu'on emule pas une norme, on l'implemente.
Et tu n'as toujours pas répondu à la question. Veux-tu que je te la repose ?
Parce que je m'en fous de ta question. Tu te trompes de debat, tu as dit une connerie en ecrivant que Cygwin est une emulation de POSIX et tu essayes de noyer le poisson.
C'est toi qui tient absolument à avoir raison.
Je m'en fous, je ne fais que suivre la definition d'un dictionnaire pour te parler. Le premier pekin qui sait lire un dico sait que tu as tord, parce que le simple fait "d'emuler une norme" ne veut strictement rien dire en soit.
D'ailleurs une norme etant un concept abstrait, on pourrait au mieux la simuler. Pour se faire, seule une autre norme pourrait faire ca, pas un programme informatique.
Je n'ai jamais pretendu une telle chose.
Si, relis-toi bien.
J'ai pas besoin, je peux pas avoir dit une telle chose pour la simple et bonne raison que je ne comprends meme pas la signification de la phrase que tu as marque.
Contrairement a toi, mon metier et mes connaissances ne portent pas sur la programmation en bas niveau, j'execre le multi-thread, que tous les developpeurs veulent placer partout et qui ne servent strictement a rien dans mon metier (sauf a certains niveau ou je n'interviens pas).
Mais tout ca ne m'empeche pas de savoir ce qu'est une norme et une emulation et dans quel contexte on peut utiliser ces deux mots.
JKB
Le 24-07-2009, ? propos de Re: Windows est rapide, Microsoft est meilleure, Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :
JKB wrote:
Tu viens en une phrase de montrer que tu ne comprends rien à rien et que tu ne sais pas lire une spec. L'atomicité est rendue obligatoire pour certaines fonctions (au hasard pthread_mutex_* sem_*). Les fonctions sem_* sont async safe. La conséquence des deux prérequis impose qu'elles doivent être implantées en mode noyau.
Alors, au risque de me repeter, cela suppose trois possibilites :
- C'est supporte par le noyau de Windows et Cygwin l'utilise pour l'implementer. - Ce n'est pas supporte par le noyau de Windows, mais c'est implemente en userland par Cygwin. - Ce n'est pas supporte par le noyau de Windows, mais ce n'est pas implementable en userland ... donc ce n'est pas implemente dans Cygwin.
Je n'ai aucune idee de la quelle des trois suppositions est exacte, je presume que selon les fonctions, on tombe au moins une fois dans une des trois.
Mais tout ca ne fait pas de Cygwin un emulateur POSIX. Parce qu'on emule pas une norme, on l'implemente.
On émule des fonctionnalités qui ne sont pas présentes sur le système hôte. Je ne vois toujours pas où est le problème. D'ailleurs, 'implémenter', c'est tout sauf français.
Et tu n'as toujours pas répondu à la question. Veux-tu que je te la repose ?
Parce que je m'en fous de ta question. Tu te trompes de debat, tu as dit une connerie en ecrivant que Cygwin est une emulation de POSIX et tu essayes de noyer le poisson.
Mouarf ! C'est ce que tu fais depuis le début en évitant soigneusement de répondre à la question posée parce que tu en es parfaitement incapable.
C'est toi qui tient absolument à avoir raison.
Je m'en fous, je ne fais que suivre la definition d'un dictionnaire pour te parler. Le premier pekin qui sait lire un dico sait que tu as tord, parce que le simple fait "d'emuler une norme" ne veut strictement rien dire en soit.
D'ailleurs une norme etant un concept abstrait, on pourrait au mieux la simuler. Pour se faire, seule une autre norme pourrait faire ca, pas un programme informatique.
Tu n'as de toute façon pas répondu à la question posée, qui était une question _précise_.
Je n'ai jamais pretendu une telle chose.
Si, relis-toi bien.
J'ai pas besoin, je peux pas avoir dit une telle chose pour la simple et bonne raison que je ne comprends meme pas la signification de la phrase que tu as marque.
Contrairement a toi, mon metier et mes connaissances ne portent pas sur la programmation en bas niveau, j'execre le multi-thread, que tous les developpeurs veulent placer partout et qui ne servent strictement a rien dans mon metier (sauf a certains niveau ou je n'interviens pas).
Tu ne sais strictement rien de mon activité principale. Par contre, tu viens de montrer longuement que tu n'as aucune espèce de logique. J'espère seulement que tu ne lis pas les RFC comme tu lis les specs Posix.
Mais tout ca ne m'empeche pas de savoir ce qu'est une norme et une emulation et dans quel contexte on peut utiliser ces deux mots.
Tu ne peux pas savoir combien tu m'amuses. Tu es l'exemple du parfait imbécile qui cherche à avoir raison en mélangeant un peu tout. Continue comme ça, ça me fait des vacances.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 24-07-2009, ? propos de
Re: Windows est rapide, Microsoft est meilleure,
Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :
JKB wrote:
Tu viens en une phrase de montrer que tu ne comprends rien à rien et
que tu ne sais pas lire une spec. L'atomicité est rendue obligatoire
pour certaines fonctions (au hasard pthread_mutex_* sem_*). Les
fonctions sem_* sont async safe. La conséquence des deux prérequis
impose qu'elles doivent être implantées en mode noyau.
Alors, au risque de me repeter, cela suppose trois possibilites :
- C'est supporte par le noyau de Windows et Cygwin l'utilise pour
l'implementer.
- Ce n'est pas supporte par le noyau de Windows, mais c'est implemente
en userland par Cygwin.
- Ce n'est pas supporte par le noyau de Windows, mais ce n'est pas
implementable en userland ... donc ce n'est pas implemente dans
Cygwin.
Je n'ai aucune idee de la quelle des trois suppositions est exacte, je
presume que selon les fonctions, on tombe au moins une fois dans une des
trois.
Mais tout ca ne fait pas de Cygwin un emulateur POSIX. Parce qu'on emule
pas une norme, on l'implemente.
On émule des fonctionnalités qui ne sont pas présentes sur le
système hôte. Je ne vois toujours pas où est le problème. D'ailleurs,
'implémenter', c'est tout sauf français.
Et tu n'as toujours pas répondu à la question. Veux-tu que je te la
repose ?
Parce que je m'en fous de ta question. Tu te trompes de debat, tu as dit
une connerie en ecrivant que Cygwin est une emulation de POSIX et tu
essayes de noyer le poisson.
Mouarf ! C'est ce que tu fais depuis le début en évitant
soigneusement de répondre à la question posée parce que tu en es
parfaitement incapable.
C'est toi qui tient absolument à avoir raison.
Je m'en fous, je ne fais que suivre la definition d'un dictionnaire pour
te parler. Le premier pekin qui sait lire un dico sait que tu as tord,
parce que le simple fait "d'emuler une norme" ne veut strictement rien
dire en soit.
D'ailleurs une norme etant un concept abstrait, on pourrait au mieux la
simuler. Pour se faire, seule une autre norme pourrait faire ca, pas un
programme informatique.
Tu n'as de toute façon pas répondu à la question posée, qui était
une question _précise_.
Je n'ai jamais pretendu une telle chose.
Si, relis-toi bien.
J'ai pas besoin, je peux pas avoir dit une telle chose pour la simple et
bonne raison que je ne comprends meme pas la signification de la phrase
que tu as marque.
Contrairement a toi, mon metier et mes connaissances ne portent pas sur
la programmation en bas niveau, j'execre le multi-thread, que tous les
developpeurs veulent placer partout et qui ne servent strictement a rien
dans mon metier (sauf a certains niveau ou je n'interviens pas).
Tu ne sais strictement rien de mon activité principale. Par contre,
tu viens de montrer longuement que tu n'as aucune espèce de logique.
J'espère seulement que tu ne lis pas les RFC comme tu lis les specs
Posix.
Mais tout ca ne m'empeche pas de savoir ce qu'est une norme et une
emulation et dans quel contexte on peut utiliser ces deux mots.
Tu ne peux pas savoir combien tu m'amuses. Tu es l'exemple du
parfait imbécile qui cherche à avoir raison en mélangeant un peu tout.
Continue comme ça, ça me fait des vacances.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 24-07-2009, ? propos de Re: Windows est rapide, Microsoft est meilleure, Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :
JKB wrote:
Tu viens en une phrase de montrer que tu ne comprends rien à rien et que tu ne sais pas lire une spec. L'atomicité est rendue obligatoire pour certaines fonctions (au hasard pthread_mutex_* sem_*). Les fonctions sem_* sont async safe. La conséquence des deux prérequis impose qu'elles doivent être implantées en mode noyau.
Alors, au risque de me repeter, cela suppose trois possibilites :
- C'est supporte par le noyau de Windows et Cygwin l'utilise pour l'implementer. - Ce n'est pas supporte par le noyau de Windows, mais c'est implemente en userland par Cygwin. - Ce n'est pas supporte par le noyau de Windows, mais ce n'est pas implementable en userland ... donc ce n'est pas implemente dans Cygwin.
Je n'ai aucune idee de la quelle des trois suppositions est exacte, je presume que selon les fonctions, on tombe au moins une fois dans une des trois.
Mais tout ca ne fait pas de Cygwin un emulateur POSIX. Parce qu'on emule pas une norme, on l'implemente.
On émule des fonctionnalités qui ne sont pas présentes sur le système hôte. Je ne vois toujours pas où est le problème. D'ailleurs, 'implémenter', c'est tout sauf français.
Et tu n'as toujours pas répondu à la question. Veux-tu que je te la repose ?
Parce que je m'en fous de ta question. Tu te trompes de debat, tu as dit une connerie en ecrivant que Cygwin est une emulation de POSIX et tu essayes de noyer le poisson.
Mouarf ! C'est ce que tu fais depuis le début en évitant soigneusement de répondre à la question posée parce que tu en es parfaitement incapable.
C'est toi qui tient absolument à avoir raison.
Je m'en fous, je ne fais que suivre la definition d'un dictionnaire pour te parler. Le premier pekin qui sait lire un dico sait que tu as tord, parce que le simple fait "d'emuler une norme" ne veut strictement rien dire en soit.
D'ailleurs une norme etant un concept abstrait, on pourrait au mieux la simuler. Pour se faire, seule une autre norme pourrait faire ca, pas un programme informatique.
Tu n'as de toute façon pas répondu à la question posée, qui était une question _précise_.
Je n'ai jamais pretendu une telle chose.
Si, relis-toi bien.
J'ai pas besoin, je peux pas avoir dit une telle chose pour la simple et bonne raison que je ne comprends meme pas la signification de la phrase que tu as marque.
Contrairement a toi, mon metier et mes connaissances ne portent pas sur la programmation en bas niveau, j'execre le multi-thread, que tous les developpeurs veulent placer partout et qui ne servent strictement a rien dans mon metier (sauf a certains niveau ou je n'interviens pas).
Tu ne sais strictement rien de mon activité principale. Par contre, tu viens de montrer longuement que tu n'as aucune espèce de logique. J'espère seulement que tu ne lis pas les RFC comme tu lis les specs Posix.
Mais tout ca ne m'empeche pas de savoir ce qu'est une norme et une emulation et dans quel contexte on peut utiliser ces deux mots.
Tu ne peux pas savoir combien tu m'amuses. Tu es l'exemple du parfait imbécile qui cherche à avoir raison en mélangeant un peu tout. Continue comme ça, ça me fait des vacances.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Jerome Lambert
Nicolas George a écrit :
totof2000 , dans le message , a écrit :
Ah ? Et mis à part pour les périphériques, quel est l'intéret pour le bios de se réserver autant de mémoire ?
Les BIOS buggés, ça n'a jamais manqué.
Tu ne réponds pas à la question. Qu'il en réserve pour les périphériques est une chose, qu'il en réserve trop est une autre.
Nicolas George a écrit :
totof2000 , dans le message
<d1eb76fc-bf52-483d-9c01-5fb7f38d40ee@32g2000yqj.googlegroups.com>, a
écrit :
Ah ? Et mis à part pour les périphériques, quel est l'intéret pour le
bios de se réserver autant de mémoire ?
Les BIOS buggés, ça n'a jamais manqué.
Tu ne réponds pas à la question. Qu'il en réserve pour les périphériques
est une chose, qu'il en réserve trop est une autre.
Jerome Lambert , dans le message <4a69cc74$0$2858$, a écrit :
Tu ne réponds pas à la question.
Pas exactement, puisque j'ai montré que la question était mal posée.
Si tu veux je peux te la poser plus directement: pourquoi un BIOS réserve-t-il de la mémoire?
talon
Toxico Nimbus wrote:
Michel Talon a écrit : > JKB wrote: >> C'est toi qui a tort sur ce coup, mon grand. Tu affirmes qu'un peut >> implanter une partie élémentaire de Posix que sont les mutexes (ou les >> sémaphores, hein, je ne suis pas chien) en userland. Je te demande de le >> démontrer. Pour l'instant, tu n'as rien montré du tout (sauf ton >> incompétence crasse dès qu'on attaque un sujet vraiment pointu). >> > > Oui on le peut, par exemple pth le fait. Tout le point est que on peut > très bien avoir l'API usuelle des threads sans que plusieurs processeurs > exécutent en même temps plusieurs threads du programme.
[SNIP]
évidemment, avec un multithreading non-préhemptif, pas besoin de se soucier d'atomicité.
Ben voilà ... Le problème devient un non problème. Par contre on perd en performance car un seul processueur est utilisé, ce qui a toujours été dit.
--
Michel TALON
Toxico Nimbus <ToxN@free.fr> wrote:
Michel Talon a écrit :
> JKB <knatschke@koenigsberg.fr> wrote:
>> C'est toi qui a tort sur ce coup, mon grand. Tu affirmes qu'un peut
>> implanter une partie élémentaire de Posix que sont les mutexes (ou les
>> sémaphores, hein, je ne suis pas chien) en userland. Je te demande de le
>> démontrer. Pour l'instant, tu n'as rien montré du tout (sauf ton
>> incompétence crasse dès qu'on attaque un sujet vraiment pointu).
>>
>
> Oui on le peut, par exemple pth le fait. Tout le point est que on peut
> très bien avoir l'API usuelle des threads sans que plusieurs processeurs
> exécutent en même temps plusieurs threads du programme.
[SNIP]
évidemment, avec un multithreading non-préhemptif, pas besoin de se
soucier d'atomicité.
Ben voilà ... Le problème devient un non problème. Par contre on perd en
performance car un seul processueur est utilisé, ce qui a toujours été
dit.
Michel Talon a écrit : > JKB wrote: >> C'est toi qui a tort sur ce coup, mon grand. Tu affirmes qu'un peut >> implanter une partie élémentaire de Posix que sont les mutexes (ou les >> sémaphores, hein, je ne suis pas chien) en userland. Je te demande de le >> démontrer. Pour l'instant, tu n'as rien montré du tout (sauf ton >> incompétence crasse dès qu'on attaque un sujet vraiment pointu). >> > > Oui on le peut, par exemple pth le fait. Tout le point est que on peut > très bien avoir l'API usuelle des threads sans que plusieurs processeurs > exécutent en même temps plusieurs threads du programme.
[SNIP]
évidemment, avec un multithreading non-préhemptif, pas besoin de se soucier d'atomicité.
Ben voilà ... Le problème devient un non problème. Par contre on perd en performance car un seul processueur est utilisé, ce qui a toujours été dit.
--
Michel TALON
pehache-tolai
On 24 juil, 16:54, JKB wrote:
On émule des fonctionnalités qui ne sont pas présen tes sur le système hôte.
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 ne 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.
D'ailleurs, 'implémenter', c'est tout sauf français.
On 24 juil, 16:54, JKB <knatsc...@koenigsberg.fr> wrote:
On émule des fonctionnalités qui ne sont pas présen tes sur le
système hôte.
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 ne
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.
D'ailleurs,
'implémenter', c'est tout sauf français.
On émule des fonctionnalités qui ne sont pas présen tes sur le système hôte.
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 ne 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.
D'ailleurs, 'implémenter', c'est tout sauf français.
Le 24-07-2009, ? propos de Re: Windows est rapide, Microsoft est meilleure, pehache-tolai ?crivait dans fr.comp.os.linux.debats :
On 24 juil, 16:54, JKB wrote:
On émule des fonctionnalités qui ne sont pas présentes sur le système hôte.
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 ne 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. 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é. 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 userland (ou alors, tu touche au noyau du système, tu seras aussi en kernelland, mais il faudra que quelqu'un te fournisse ou la doc ou l'API du noyau).
Au passage, comparer l'implantation d'une FFT à celle de specifications Posix est discutable...
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 'barbarisme', que tu le veuilles ou non. En français, on dit 'implanter', comme on dit 'decryptement' et non 'décryptage' (bien que là encore, le Larousse est permissif, mais je ne vais pas dire ici ce que je pense du Larousse !).
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 24-07-2009, ? propos de
Re: Windows est rapide, Microsoft est meilleure,
pehache-tolai ?crivait dans fr.comp.os.linux.debats :
On 24 juil, 16:54, JKB <knatsc...@koenigsberg.fr> wrote:
On émule des fonctionnalités qui ne sont pas présentes sur le
système hôte.
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 ne
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. 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é. 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 userland
(ou alors, tu touche au noyau du système, tu seras aussi en kernelland,
mais il faudra que quelqu'un te fournisse ou la doc ou l'API du noyau).
Au passage, comparer l'implantation d'une FFT à celle de
specifications Posix est discutable...
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 'barbarisme',
que tu le veuilles ou non. En français, on dit 'implanter', comme on dit
'decryptement' et non 'décryptage' (bien que là encore, le Larousse est
permissif, mais je ne vais pas dire ici ce que je pense du Larousse !).
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 24-07-2009, ? propos de Re: Windows est rapide, Microsoft est meilleure, pehache-tolai ?crivait dans fr.comp.os.linux.debats :
On 24 juil, 16:54, JKB wrote:
On émule des fonctionnalités qui ne sont pas présentes sur le système hôte.
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 ne 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. 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é. 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 userland (ou alors, tu touche au noyau du système, tu seras aussi en kernelland, mais il faudra que quelqu'un te fournisse ou la doc ou l'API du noyau).
Au passage, comparer l'implantation d'une FFT à celle de specifications Posix est discutable...
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 'barbarisme', que tu le veuilles ou non. En français, on dit 'implanter', comme on dit 'decryptement' et non 'décryptage' (bien que là encore, le Larousse est permissif, mais je ne vais pas dire ici ce que je pense du Larousse !).
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Nicolas George
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. Ce qu'on sait, c'est que les BIOS buggés qui se vautrent sur la mémoire disponible, c'est fréquent.
Et toi, tu n'as toujours pas montré l'ombre d'une indication de _quel_ périphérique occuperait cette mémoire. Tant que tu ne le fais pas, tu parles dans le vide.
Jerome Lambert , dans le message
<4a69cf80$0$2858$ba620e4c@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. Ce qu'on sait, c'est que les BIOS buggés qui se vautrent
sur la mémoire disponible, c'est fréquent.
Et toi, tu n'as toujours pas montré l'ombre d'une indication de _quel_
périphérique occuperait cette mémoire. Tant que tu ne le fais pas, tu parles
dans le vide.
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. Ce qu'on sait, c'est que les BIOS buggés qui se vautrent sur la mémoire disponible, c'est fréquent.
Et toi, tu n'as toujours pas montré l'ombre d'une indication de _quel_ périphérique occuperait cette mémoire. Tant que tu ne le fais pas, tu parles dans le vide.
totof2000
On 24 juil, 17:01, Nicolas George <nicolas$ wrote:
Jerome Lambert , dans le message <4a69cc74$0$2858$, a écrit :
> Tu ne réponds pas à la question.
Pas exactement, puisque j'ai montré que la question était mal posée .
Tu n'as rien montré du tout ...
Tiens au passage tu devrais faire de la politique, je suis sur que tu aurais un certain succes ...
On 24 juil, 17:01, Nicolas George <nicolas$geo...@salle-s.org> wrote:
Jerome Lambert , dans le message
<4a69cc74$0$2858$ba620...@news.skynet.be>, a écrit :
> Tu ne réponds pas à la question.
Pas exactement, puisque j'ai montré que la question était mal posée .
Tu n'as rien montré du tout ...
Tiens au passage tu devrais faire de la politique, je suis sur que tu
aurais un certain succes ...
