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
Bruno Ducrot , dans le message <4a6dbf91$0$17762$, a écrit :
Le BIOS se contente d'enumerer les MMIO des peripheriques actives. Il faudrait vraiment que le dev soit le plus naze de tous les nazes pour se vautrer sur cette partie-la,
Et pourtant, des BIOS qui se vautrent sur la quantité de mémoire disponible, il y en a des tonnes.
Un utilisateur rajoute de la RAM, mais vois que ca ne marche pas. Je ne vois pas en quoi le vendeur est fautif s'il a prevenu que son materiel est limite.
Tant pis pour lui, s'il ne s'est pas documenté correctement.
Bruno Ducrot , dans le message
<4a6dbf91$0$17762$ba4acef3@news.orange.fr>, a écrit :
Le BIOS se contente d'enumerer les MMIO des peripheriques actives.
Il faudrait vraiment que le dev soit le plus naze de tous les nazes pour
se vautrer sur cette partie-la,
Et pourtant, des BIOS qui se vautrent sur la quantité de mémoire disponible,
il y en a des tonnes.
Un utilisateur rajoute de la RAM, mais vois que ca ne marche pas. Je
ne vois pas en quoi le vendeur est fautif s'il a prevenu que son
materiel est limite.
Tant pis pour lui, s'il ne s'est pas documenté correctement.
Bruno Ducrot , dans le message <4a6dbf91$0$17762$, a écrit :
Le BIOS se contente d'enumerer les MMIO des peripheriques actives. Il faudrait vraiment que le dev soit le plus naze de tous les nazes pour se vautrer sur cette partie-la,
Et pourtant, des BIOS qui se vautrent sur la quantité de mémoire disponible, il y en a des tonnes.
Un utilisateur rajoute de la RAM, mais vois que ca ne marche pas. Je ne vois pas en quoi le vendeur est fautif s'il a prevenu que son materiel est limite.
Tant pis pour lui, s'il ne s'est pas documenté correctement.
Bruno Ducrot
On 2009-07-27, Nicolas George wrote:
Bruno Ducrot , dans le message <4a6dbf91$0$17762$, a écrit :
Le BIOS se contente d'enumerer les MMIO des peripheriques actives. Il faudrait vraiment que le dev soit le plus naze de tous les nazes pour se vautrer sur cette partie-la,
Et pourtant, des BIOS qui se vautrent sur la quantité de mémoire disponible, il y en a des tonnes.
Ah, je vois. C'est un ancien probleme que j'avais completement oublie et qui date d'avant la generalisation de l'ACPI dans Linux.
Etes-vous au courant que meme si certains anciens BIOS n'ont pas ete corriges, les OS actuels, dont Linux, font appel a un autre appel au BIOS qui, lui, est teste par les concepteurs de BIOS puisque utilise par les OS commis par Microsoft ?
A plus,
-- 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
<4a6dbf91$0$17762$ba4acef3@news.orange.fr>, a écrit :
Le BIOS se contente d'enumerer les MMIO des peripheriques actives.
Il faudrait vraiment que le dev soit le plus naze de tous les nazes pour
se vautrer sur cette partie-la,
Et pourtant, des BIOS qui se vautrent sur la quantité de mémoire disponible,
il y en a des tonnes.
Ah, je vois. C'est un ancien probleme que j'avais completement oublie
et qui date d'avant la generalisation de l'ACPI dans Linux.
Etes-vous au courant que meme si certains anciens BIOS n'ont pas ete
corriges, les OS actuels, dont Linux, font appel a un autre appel au
BIOS qui, lui, est teste par les concepteurs de BIOS puisque utilise
par les OS commis par Microsoft ?
A plus,
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
Bruno Ducrot , dans le message <4a6dbf91$0$17762$, a écrit :
Le BIOS se contente d'enumerer les MMIO des peripheriques actives. Il faudrait vraiment que le dev soit le plus naze de tous les nazes pour se vautrer sur cette partie-la,
Et pourtant, des BIOS qui se vautrent sur la quantité de mémoire disponible, il y en a des tonnes.
Ah, je vois. C'est un ancien probleme que j'avais completement oublie et qui date d'avant la generalisation de l'ACPI dans Linux.
Etes-vous au courant que meme si certains anciens BIOS n'ont pas ete corriges, les OS actuels, dont Linux, font appel a un autre appel au BIOS qui, lui, est teste par les concepteurs de BIOS puisque utilise par les OS commis par Microsoft ?
A plus,
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Nicolas George
Bruno Ducrot , dans le message <4a6de05a$0$23462$, a écrit :
Etes-vous au courant que meme si certains anciens BIOS n'ont pas ete corriges, les OS actuels, dont Linux, font appel a un autre appel au BIOS qui, lui, est teste par les concepteurs de BIOS puisque utilise par les OS commis par Microsoft ?
Euh, allô ? Les fonctions ACPI sont encore plus souvent buggées que les fonctions BIOS historiques.
Bruno Ducrot , dans le message
<4a6de05a$0$23462$ba4acef3@news.orange.fr>, a écrit :
Etes-vous au courant que meme si certains anciens BIOS n'ont pas ete
corriges, les OS actuels, dont Linux, font appel a un autre appel au
BIOS qui, lui, est teste par les concepteurs de BIOS puisque utilise
par les OS commis par Microsoft ?
Euh, allô ? Les fonctions ACPI sont encore plus souvent buggées que les
fonctions BIOS historiques.
Bruno Ducrot , dans le message <4a6de05a$0$23462$, a écrit :
Etes-vous au courant que meme si certains anciens BIOS n'ont pas ete corriges, les OS actuels, dont Linux, font appel a un autre appel au BIOS qui, lui, est teste par les concepteurs de BIOS puisque utilise par les OS commis par Microsoft ?
Euh, allô ? Les fonctions ACPI sont encore plus souvent buggées que les fonctions BIOS historiques.
Bruno Ducrot
On 2009-07-27, Nicolas George wrote:
Bruno Ducrot , dans le message <4a6de05a$0$23462$, a écrit :
Etes-vous au courant que meme si certains anciens BIOS n'ont pas ete corriges, les OS actuels, dont Linux, font appel a un autre appel au BIOS qui, lui, est teste par les concepteurs de BIOS puisque utilise par les OS commis par Microsoft ?
Euh, allô ? Les fonctions ACPI sont encore plus souvent buggées que les fonctions BIOS historiques.
Bien essaye. Dommage que ce dont je parle ne soit pas une fonction ACPI mais qu'il s'agit bel et bien d'un appel au BIOS.
-- 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
<4a6de05a$0$23462$ba4acef3@news.orange.fr>, a écrit :
Etes-vous au courant que meme si certains anciens BIOS n'ont pas ete
corriges, les OS actuels, dont Linux, font appel a un autre appel au
BIOS qui, lui, est teste par les concepteurs de BIOS puisque utilise
par les OS commis par Microsoft ?
Euh, allô ? Les fonctions ACPI sont encore plus souvent buggées que les
fonctions BIOS historiques.
Bien essaye. Dommage que ce dont je parle ne soit pas une fonction
ACPI mais qu'il s'agit bel et bien d'un appel au BIOS.
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
Bruno Ducrot , dans le message <4a6de05a$0$23462$, a écrit :
Etes-vous au courant que meme si certains anciens BIOS n'ont pas ete corriges, les OS actuels, dont Linux, font appel a un autre appel au BIOS qui, lui, est teste par les concepteurs de BIOS puisque utilise par les OS commis par Microsoft ?
Euh, allô ? Les fonctions ACPI sont encore plus souvent buggées que les fonctions BIOS historiques.
Bien essaye. Dommage que ce dont je parle ne soit pas une fonction ACPI mais qu'il s'agit bel et bien d'un appel au BIOS.
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Patrick Lamaizière
JKB :
Je te rappelle que tu prétends pouvoir implanter les pthreads en userland sous Windows. Je te repose donc la question : comment fais-tu pour implanter un mécanisme aussi simple qu'un mutex _strictement_ en userland lorsque les mécanismes d'atomicité ne sont pas disponibles à partir d'API sur le système hôte ?
Windows c'est pourri mais y'a quand même des mutex, des threads et tout le tralala utilisable. Qu'est ce qui empêche alors ?
J'ai arrêté de contribuer à Cygwin au debut d'XP (en fait par paresse parce que j'en avais marre de me coltiner des workarounds pour Cygwin et le C/Windows). Il y avait un défaut d'atomicité qui faisait que les mutexes (et les sémaphores parce que le problème est strictement le même) fonctionnaient _presque_.
Bug dans cygwin ou bug dans l'atomicité des mutexes de Windows (ce qui m'étonnerait) ?
On parlait de la possibilité de le faire en userland sous Windows, après qu'il y ait des bugs c'est un autre débat.
En cherchant un peu je suis tombé sur une autre implémentation de pthread avec les services for Unix de MS http://technet.microsoft.com/fr-fr/library/bb463209.aspx#EEAA
Moi ça m'a l'air possible de le faire.
Il y avait un autre problème inhérent à la présence d'un fork()
Là par contre il n'y a pas d'équivalent sous Windows n'importe comment.
JKB :
Je te rappelle que tu prétends pouvoir implanter les pthreads en
userland sous Windows. Je te repose donc la question : comment fais-tu
pour implanter un mécanisme aussi simple qu'un mutex _strictement_ en
userland lorsque les mécanismes d'atomicité ne sont pas disponibles à
partir d'API sur le système hôte ?
Windows c'est pourri mais y'a quand même des mutex, des threads et tout
le tralala utilisable. Qu'est ce qui empêche alors ?
J'ai arrêté de contribuer à Cygwin au debut d'XP (en fait par
paresse parce que j'en avais marre de me coltiner des workarounds pour
Cygwin et le C/Windows). Il y avait un défaut d'atomicité qui faisait
que les mutexes (et les sémaphores parce que le problème est strictement
le même) fonctionnaient _presque_.
Bug dans cygwin ou bug dans l'atomicité des mutexes de Windows (ce qui
m'étonnerait) ?
On parlait de la possibilité de le faire en userland sous Windows, après
qu'il y ait des bugs c'est un autre débat.
En cherchant un peu je suis tombé sur une autre implémentation de
pthread avec les services for Unix de MS
http://technet.microsoft.com/fr-fr/library/bb463209.aspx#EEAA
Moi ça m'a l'air possible de le faire.
Il y avait un autre problème inhérent à la présence d'un fork()
Là par contre il n'y a pas d'équivalent sous Windows n'importe comment.
Je te rappelle que tu prétends pouvoir implanter les pthreads en userland sous Windows. Je te repose donc la question : comment fais-tu pour implanter un mécanisme aussi simple qu'un mutex _strictement_ en userland lorsque les mécanismes d'atomicité ne sont pas disponibles à partir d'API sur le système hôte ?
Windows c'est pourri mais y'a quand même des mutex, des threads et tout le tralala utilisable. Qu'est ce qui empêche alors ?
J'ai arrêté de contribuer à Cygwin au debut d'XP (en fait par paresse parce que j'en avais marre de me coltiner des workarounds pour Cygwin et le C/Windows). Il y avait un défaut d'atomicité qui faisait que les mutexes (et les sémaphores parce que le problème est strictement le même) fonctionnaient _presque_.
Bug dans cygwin ou bug dans l'atomicité des mutexes de Windows (ce qui m'étonnerait) ?
On parlait de la possibilité de le faire en userland sous Windows, après qu'il y ait des bugs c'est un autre débat.
En cherchant un peu je suis tombé sur une autre implémentation de pthread avec les services for Unix de MS http://technet.microsoft.com/fr-fr/library/bb463209.aspx#EEAA
Moi ça m'a l'air possible de le faire.
Il y avait un autre problème inhérent à la présence d'un fork()
Là par contre il n'y a pas d'équivalent sous Windows n'importe comment.
Stephane TOUGARD
JKB wrote:
Je te rappelle que tu prétends pouvoir implanter les pthreads en userland sous Windows. Je te repose donc la question : comment fais-tu pour implanter un mécanisme aussi simple qu'un mutex _strictement_ en userland lorsque les mécanismes d'atomicité ne sont pas disponibles à partir d'API sur le système hôte ?
La seule chose que je pretends est que Cygwin n'est pas un emulateur de norme POSIX (et ca, tu as clairement dis le contraire), parce que par definition, on n'emule pas une norme ... on l'implemente.
Moi, je pretends que Cygwin est une implementation (plus ou moins complete) de la norme POSIX. Pour la seule raison que la seule chose qu'on puisse faire avec une norme, c'est de l'implementer.
Le reste, c'est dans tes fantasmes (et je me contrefous de tes mutex en userland, je te parle de la langue francaise la).
Franchement, entre le JKB et le petit Nicolas, il y a vraiment des mecs qui tiennent une sacree couche ici.
JKB wrote:
Je te rappelle que tu prétends pouvoir implanter les pthreads en
userland sous Windows. Je te repose donc la question : comment fais-tu
pour implanter un mécanisme aussi simple qu'un mutex _strictement_ en
userland lorsque les mécanismes d'atomicité ne sont pas disponibles à
partir d'API sur le système hôte ?
La seule chose que je pretends est que Cygwin n'est pas un emulateur de norme
POSIX (et ca, tu as clairement dis le contraire), parce que par definition,
on n'emule pas une norme ... on l'implemente.
Moi, je pretends que Cygwin est une implementation (plus ou moins
complete) de la norme POSIX. Pour la seule raison que la seule chose
qu'on puisse faire avec une norme, c'est de l'implementer.
Le reste, c'est dans tes fantasmes (et je me contrefous de tes mutex en
userland, je te parle de la langue francaise la).
Franchement, entre le JKB et le petit Nicolas, il y a vraiment des mecs
qui tiennent une sacree couche ici.
Je te rappelle que tu prétends pouvoir implanter les pthreads en userland sous Windows. Je te repose donc la question : comment fais-tu pour implanter un mécanisme aussi simple qu'un mutex _strictement_ en userland lorsque les mécanismes d'atomicité ne sont pas disponibles à partir d'API sur le système hôte ?
La seule chose que je pretends est que Cygwin n'est pas un emulateur de norme POSIX (et ca, tu as clairement dis le contraire), parce que par definition, on n'emule pas une norme ... on l'implemente.
Moi, je pretends que Cygwin est une implementation (plus ou moins complete) de la norme POSIX. Pour la seule raison que la seule chose qu'on puisse faire avec une norme, c'est de l'implementer.
Le reste, c'est dans tes fantasmes (et je me contrefous de tes mutex en userland, je te parle de la langue francaise la).
Franchement, entre le JKB et le petit Nicolas, il y a vraiment des mecs qui tiennent une sacree couche ici.
Stephane TOUGARD
Patrick Lamaizière wrote:
Bug dans cygwin ou bug dans l'atomicité des mutexes de Windows (ce qui m'étonnerait) ?
Mais ecoute dont le grand JKB, il sait quand meme mieux que toi si Windows a un bug dans ses mutex.
En cherchant un peu je suis tombé sur une autre implémentation de pthread avec les services for Unix de MS http://technet.microsoft.com/fr-fr/library/bb463209.aspx#EEAA
Moi ça m'a l'air possible de le faire.
Bien sur que c'est possible. Windows est une merde, mais faut quand meme pas pousse non plus trop loin.
Il y avait un autre problème inhérent à la présence d'un fork()
Là par contre il n'y a pas d'équivalent sous Windows n'importe comment.
Non, mais on peut le simuler (on non l'emuler) via les threads. C'est plutot basique.
Patrick Lamaizière wrote:
Bug dans cygwin ou bug dans l'atomicité des mutexes de Windows (ce qui
m'étonnerait) ?
Mais ecoute dont le grand JKB, il sait quand meme mieux que toi si
Windows a un bug dans ses mutex.
En cherchant un peu je suis tombé sur une autre implémentation de
pthread avec les services for Unix de MS
http://technet.microsoft.com/fr-fr/library/bb463209.aspx#EEAA
Moi ça m'a l'air possible de le faire.
Bien sur que c'est possible. Windows est une merde, mais faut quand meme
pas pousse non plus trop loin.
Il y avait un autre problème inhérent à la présence d'un fork()
Là par contre il n'y a pas d'équivalent sous Windows n'importe comment.
Non, mais on peut le simuler (on non l'emuler) via les threads. C'est
plutot basique.
Bug dans cygwin ou bug dans l'atomicité des mutexes de Windows (ce qui m'étonnerait) ?
Mais ecoute dont le grand JKB, il sait quand meme mieux que toi si Windows a un bug dans ses mutex.
En cherchant un peu je suis tombé sur une autre implémentation de pthread avec les services for Unix de MS http://technet.microsoft.com/fr-fr/library/bb463209.aspx#EEAA
Moi ça m'a l'air possible de le faire.
Bien sur que c'est possible. Windows est une merde, mais faut quand meme pas pousse non plus trop loin.
Il y avait un autre problème inhérent à la présence d'un fork()
Là par contre il n'y a pas d'équivalent sous Windows n'importe comment.
Non, mais on peut le simuler (on non l'emuler) via les threads. C'est plutot basique.
Stephane TOUGARD
JKB wrote:
Si en plus tu étais bon techniquement...
T'inquiete pas pour la grand mere. Il y a pas besoin "d'emuler des normes" pour savoir gerer quelques millions d'utilisateurs sur un service informatique.
JKB wrote:
Si en plus tu étais bon techniquement...
T'inquiete pas pour la grand mere. Il y a pas besoin "d'emuler des normes"
pour savoir gerer quelques millions d'utilisateurs sur un service
informatique.
T'inquiete pas pour la grand mere. Il y a pas besoin "d'emuler des normes" pour savoir gerer quelques millions d'utilisateurs sur un service informatique.
Stephane TOUGARD
JKB wrote:
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.
Ssiiiii ! Stéphane Tougard va nous donner une explication et de sa grande hauteur, il va nous donner un exemple de code implantant la libpthread en userland ;-)
Contrairement a toi, je ne pretends pas avoir des connaissances que je n'ai pas.
JKB wrote:
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.
Ssiiiii ! Stéphane Tougard va nous donner une explication et de sa
grande hauteur, il va nous donner un exemple de code implantant la
libpthread en userland ;-)
Contrairement a toi, je ne pretends pas avoir des connaissances que je
n'ai pas.
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.
Ssiiiii ! Stéphane Tougard va nous donner une explication et de sa grande hauteur, il va nous donner un exemple de code implantant la libpthread en userland ;-)
Contrairement a toi, je ne pretends pas avoir des connaissances que je n'ai pas.
totof2000
On 28 juil, 03:41, Stephane TOUGARD wrote:
Patrick Lamaizière wrote: > Bug dans cygwin ou bug dans l'atomicité des mutexes de Windows (ce qu i > m'étonnerait) ?
Mais ecoute dont le grand JKB, il sait quand meme mieux que toi si Windows a un bug dans ses mutex.
> En cherchant un peu je suis tombé sur une autre implémentation de > pthread avec les services for Unix de MS >http://technet.microsoft.com/fr-fr/library/bb463209.aspx#EEAA
> Moi ça m'a l'air possible de le faire.
Bien sur que c'est possible. Windows est une merde, mais faut quand meme pas pousse non plus trop loin.
>> Il y avait un autre problème inhérent à la présence d'un fork( )
> Là par contre il n'y a pas d'équivalent sous Windows n'importe comm ent.
Non, mais on peut le simuler (on non l'emuler) via les threads. C'est plutot basique.
Votre prise de bec à propos des termes "émuler" et "simuler" se comprend tout à fait lorsqu'u'on a fait un peu d'électronique et informatique indiustrielle et vu (ou utilisé) des simulateurs de microcontroleurs par exemple ....
On 28 juil, 03:41, Stephane TOUGARD <steph...@unices.org> wrote:
Patrick Lamaizière wrote:
> Bug dans cygwin ou bug dans l'atomicité des mutexes de Windows (ce qu i
> m'étonnerait) ?
Mais ecoute dont le grand JKB, il sait quand meme mieux que toi si
Windows a un bug dans ses mutex.
> En cherchant un peu je suis tombé sur une autre implémentation de
> pthread avec les services for Unix de MS
>http://technet.microsoft.com/fr-fr/library/bb463209.aspx#EEAA
> Moi ça m'a l'air possible de le faire.
Bien sur que c'est possible. Windows est une merde, mais faut quand meme
pas pousse non plus trop loin.
>> Il y avait un autre problème inhérent à la présence d'un fork( )
> Là par contre il n'y a pas d'équivalent sous Windows n'importe comm ent.
Non, mais on peut le simuler (on non l'emuler) via les threads. C'est
plutot basique.
Votre prise de bec à propos des termes "émuler" et "simuler" se
comprend tout à fait lorsqu'u'on a fait un peu d'électronique et
informatique indiustrielle et vu (ou utilisé) des simulateurs de
microcontroleurs par exemple ....
Patrick Lamaizière wrote: > Bug dans cygwin ou bug dans l'atomicité des mutexes de Windows (ce qu i > m'étonnerait) ?
Mais ecoute dont le grand JKB, il sait quand meme mieux que toi si Windows a un bug dans ses mutex.
> En cherchant un peu je suis tombé sur une autre implémentation de > pthread avec les services for Unix de MS >http://technet.microsoft.com/fr-fr/library/bb463209.aspx#EEAA
> Moi ça m'a l'air possible de le faire.
Bien sur que c'est possible. Windows est une merde, mais faut quand meme pas pousse non plus trop loin.
>> Il y avait un autre problème inhérent à la présence d'un fork( )
> Là par contre il n'y a pas d'équivalent sous Windows n'importe comm ent.
Non, mais on peut le simuler (on non l'emuler) via les threads. C'est plutot basique.
Votre prise de bec à propos des termes "émuler" et "simuler" se comprend tout à fait lorsqu'u'on a fait un peu d'électronique et informatique indiustrielle et vu (ou utilisé) des simulateurs de microcontroleurs par exemple ....
