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
Il serait peut-être bon que tu mettes ton argumentaire anti-windows un peu à jour : un BSOD ça fait une paye que je n'en ai pas vu un.
Tu n'as donc pas regardé la cérémonie d'ouverture des jeux de Pékin l'an dernier. Belle publicité !
-- Stéphan Peccini Les photos : <URL:http://photonature.fr> Les Pyrénées : <URL:http://photonature.fr/pyrenees> Le blog : <URL:http://pyrenees.peccini.fr>
pehache-tolai a écrit :
Il serait peut-être bon que tu mettes ton argumentaire anti-windows un peu
à jour : un BSOD ça fait une paye que je n'en ai pas vu un.
Tu n'as donc pas regardé la cérémonie d'ouverture des jeux de Pékin l'an
dernier. Belle publicité !
--
Stéphan Peccini
Les photos : <URL:http://photonature.fr>
Les Pyrénées : <URL:http://photonature.fr/pyrenees>
Le blog : <URL:http://pyrenees.peccini.fr>
Il serait peut-être bon que tu mettes ton argumentaire anti-windows un peu à jour : un BSOD ça fait une paye que je n'en ai pas vu un.
Tu n'as donc pas regardé la cérémonie d'ouverture des jeux de Pékin l'an dernier. Belle publicité !
-- Stéphan Peccini Les photos : <URL:http://photonature.fr> Les Pyrénées : <URL:http://photonature.fr/pyrenees> Le blog : <URL:http://pyrenees.peccini.fr>
Jerome Lambert
pehache-tolai a écrit :
"NiKo" a écrit dans le message de news: 4a746735$0$437$
Ce que tu comprend pas, c'est que sous Linux, on ouvre l'application dont on a besoin et on s'en sert. On aura pas d'écran bleu
Il serait peut-être bon que tu mettes ton argumentaire anti-windows un peu à jour : un BSOD ça fait une paye que je n'en ai pas vu un.
J'avoue que ces dernières années, j'ai vu plus de kernel panic que de BSOD. Comme quoi...
pehache-tolai a écrit :
"NiKo" <NiKo@nomail.svp> a écrit dans le message de news:
4a746735$0$437$426a34cc@news.free.fr
Ce que tu comprend pas, c'est que sous Linux, on ouvre l'application
dont on a besoin et on s'en sert. On aura pas d'écran bleu
Il serait peut-être bon que tu mettes ton argumentaire anti-windows un
peu à jour : un BSOD ça fait une paye que je n'en ai pas vu un.
J'avoue que ces dernières années, j'ai vu plus de kernel panic que de
BSOD. Comme quoi...
"NiKo" a écrit dans le message de news: 4a746735$0$437$
Ce que tu comprend pas, c'est que sous Linux, on ouvre l'application dont on a besoin et on s'en sert. On aura pas d'écran bleu
Il serait peut-être bon que tu mettes ton argumentaire anti-windows un peu à jour : un BSOD ça fait une paye que je n'en ai pas vu un.
J'avoue que ces dernières années, j'ai vu plus de kernel panic que de BSOD. Comme quoi...
Richard Delorme
Le 01/08/2009 15:36, JKB a écrit :
Tu prends tes petits doigts, tu codes, tu essaies de trouver des workarounds pour régler des problèmes d'atomicité à la turc et tu t'aperçois que ce n'est pas possible en userland strict sans s'appuyer sur des primitives du noyau qui manque de bol ne sont pas disponibles...
Je suis cette discussion d'un peu loin, mais j'ai du mal à comprendre le rapport entre kerneland, userland, disneyland et atomicité. Sur les processeurs x86, à ma connaissance, seule une poignée d'instructions est atomique (xchg, les opérations sur entiers préfixés par lock, etc.). A partir de ces fonctions, il est assez facile de construire, en assembleur, des verrous, genre /spinlock/, autour des zones de code critique. Ce n'est pas nécessairement l'équivalent d'un mutex, par les fonctionnalités, mais c'est un début, qui permet de contrôler l'atomicité de n'importe quelle zone de code.
-- Richard
Le 01/08/2009 15:36, JKB a écrit :
Tu prends tes petits doigts, tu codes, tu essaies de trouver des
workarounds pour régler des problèmes d'atomicité à la turc et tu
t'aperçois que ce n'est pas possible en userland strict sans s'appuyer
sur des primitives du noyau qui manque de bol ne sont pas disponibles...
Je suis cette discussion d'un peu loin, mais j'ai du mal à comprendre
le rapport entre kerneland, userland, disneyland et atomicité. Sur les
processeurs x86, à ma connaissance, seule une poignée d'instructions est
atomique (xchg, les opérations sur entiers préfixés par lock, etc.). A
partir de ces fonctions, il est assez facile de construire, en
assembleur, des verrous, genre /spinlock/, autour des zones de code
critique. Ce n'est pas nécessairement l'équivalent d'un mutex, par les
fonctionnalités, mais c'est un début, qui permet de contrôler
l'atomicité de n'importe quelle zone de code.
Tu prends tes petits doigts, tu codes, tu essaies de trouver des workarounds pour régler des problèmes d'atomicité à la turc et tu t'aperçois que ce n'est pas possible en userland strict sans s'appuyer sur des primitives du noyau qui manque de bol ne sont pas disponibles...
Je suis cette discussion d'un peu loin, mais j'ai du mal à comprendre le rapport entre kerneland, userland, disneyland et atomicité. Sur les processeurs x86, à ma connaissance, seule une poignée d'instructions est atomique (xchg, les opérations sur entiers préfixés par lock, etc.). A partir de ces fonctions, il est assez facile de construire, en assembleur, des verrous, genre /spinlock/, autour des zones de code critique. Ce n'est pas nécessairement l'équivalent d'un mutex, par les fonctionnalités, mais c'est un début, qui permet de contrôler l'atomicité de n'importe quelle zone de code.
-- Richard
JKB
Le 02-08-2009, ? propos de Re: Windows est rapide, Microsoft est meilleure, Jerome Lambert ?crivait dans fr.comp.os.linux.debats :
pehache-tolai a écrit :
"NiKo" a écrit dans le message de news: 4a746735$0$437$
Ce que tu comprend pas, c'est que sous Linux, on ouvre l'application dont on a besoin et on s'en sert. On aura pas d'écran bleu
Il serait peut-être bon que tu mettes ton argumentaire anti-windows un peu à jour : un BSOD ça fait une paye que je n'en ai pas vu un.
J'avoue que ces dernières années, j'ai vu plus de kernel panic que de BSOD. Comme quoi...
Moi aussi... Faut dire que ce n'est pas dur, je développe un peu pour le noyau Linux (sparc) et je n'ai plus de PC sous Windows...
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 02-08-2009, ? propos de
Re: Windows est rapide, Microsoft est meilleure,
Jerome Lambert ?crivait dans fr.comp.os.linux.debats :
pehache-tolai a écrit :
"NiKo" <NiKo@nomail.svp> a écrit dans le message de news:
4a746735$0$437$426a34cc@news.free.fr
Ce que tu comprend pas, c'est que sous Linux, on ouvre l'application
dont on a besoin et on s'en sert. On aura pas d'écran bleu
Il serait peut-être bon que tu mettes ton argumentaire anti-windows un
peu à jour : un BSOD ça fait une paye que je n'en ai pas vu un.
J'avoue que ces dernières années, j'ai vu plus de kernel panic que de
BSOD. Comme quoi...
Moi aussi... Faut dire que ce n'est pas dur, je développe un peu
pour le noyau Linux (sparc) et je n'ai plus de PC sous Windows...
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 02-08-2009, ? propos de Re: Windows est rapide, Microsoft est meilleure, Jerome Lambert ?crivait dans fr.comp.os.linux.debats :
pehache-tolai a écrit :
"NiKo" a écrit dans le message de news: 4a746735$0$437$
Ce que tu comprend pas, c'est que sous Linux, on ouvre l'application dont on a besoin et on s'en sert. On aura pas d'écran bleu
Il serait peut-être bon que tu mettes ton argumentaire anti-windows un peu à jour : un BSOD ça fait une paye que je n'en ai pas vu un.
J'avoue que ces dernières années, j'ai vu plus de kernel panic que de BSOD. Comme quoi...
Moi aussi... Faut dire que ce n'est pas dur, je développe un peu pour le noyau Linux (sparc) et je n'ai plus de PC sous Windows...
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.
JKB
Le 02-08-2009, ? propos de Re: Windows est rapide, Microsoft est meilleure, Richard Delorme ?crivait dans fr.comp.os.linux.debats :
Le 01/08/2009 15:36, JKB a écrit :
Tu prends tes petits doigts, tu codes, tu essaies de trouver des workarounds pour régler des problèmes d'atomicité à la turc et tu t'aperçois que ce n'est pas possible en userland strict sans s'appuyer sur des primitives du noyau qui manque de bol ne sont pas disponibles...
Je suis cette discussion d'un peu loin, mais j'ai du mal à comprendre le rapport entre kerneland, userland, disneyland et atomicité. Sur les processeurs x86, à ma connaissance, seule une poignée d'instructions est atomique (xchg, les opérations sur entiers préfixés par lock, etc.). A partir de ces fonctions, il est assez facile de construire, en assembleur, des verrous, genre /spinlock/, autour des zones de code critique. Ce n'est pas nécessairement l'équivalent d'un mutex, par les fonctionnalités, mais c'est un début, qui permet de contrôler l'atomicité de n'importe quelle zone de code.
On est bien d'accord sur ce point. Le point faible de l'utilisation de ces instructions assembleur, c'est que tu te retrouves dans la situation d'avoir un sem_wait() qui sera atomique et un sem_post() qui lui, ne le sera plus (sur i386, mais pourra l'être sur amd64, ce qui fout un boxon inimaginable dans tout les codes qui doivent être portables. Au passage, les sémaphores étant les seuls verrous async safe, c'est un peu gênant...). C'est à cause de ce genre de trucs foireux que l'implantation des threads a été reprise trois fois sous Linux.
Cordialement,
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 02-08-2009, ? propos de
Re: Windows est rapide, Microsoft est meilleure,
Richard Delorme ?crivait dans fr.comp.os.linux.debats :
Le 01/08/2009 15:36, JKB a écrit :
Tu prends tes petits doigts, tu codes, tu essaies de trouver des
workarounds pour régler des problèmes d'atomicité à la turc et tu
t'aperçois que ce n'est pas possible en userland strict sans s'appuyer
sur des primitives du noyau qui manque de bol ne sont pas disponibles...
Je suis cette discussion d'un peu loin, mais j'ai du mal à comprendre
le rapport entre kerneland, userland, disneyland et atomicité. Sur les
processeurs x86, à ma connaissance, seule une poignée d'instructions est
atomique (xchg, les opérations sur entiers préfixés par lock, etc.). A
partir de ces fonctions, il est assez facile de construire, en
assembleur, des verrous, genre /spinlock/, autour des zones de code
critique. Ce n'est pas nécessairement l'équivalent d'un mutex, par les
fonctionnalités, mais c'est un début, qui permet de contrôler
l'atomicité de n'importe quelle zone de code.
On est bien d'accord sur ce point. Le point faible de l'utilisation
de ces instructions assembleur, c'est que tu te retrouves dans la
situation d'avoir un sem_wait() qui sera atomique et un sem_post() qui
lui, ne le sera plus (sur i386, mais pourra l'être sur amd64, ce qui
fout un boxon inimaginable dans tout les codes qui doivent être
portables. Au passage, les sémaphores étant les seuls verrous async
safe, c'est un peu gênant...). C'est à cause de ce genre de trucs foireux que
l'implantation des threads a été reprise trois fois sous Linux.
Cordialement,
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 02-08-2009, ? propos de Re: Windows est rapide, Microsoft est meilleure, Richard Delorme ?crivait dans fr.comp.os.linux.debats :
Le 01/08/2009 15:36, JKB a écrit :
Tu prends tes petits doigts, tu codes, tu essaies de trouver des workarounds pour régler des problèmes d'atomicité à la turc et tu t'aperçois que ce n'est pas possible en userland strict sans s'appuyer sur des primitives du noyau qui manque de bol ne sont pas disponibles...
Je suis cette discussion d'un peu loin, mais j'ai du mal à comprendre le rapport entre kerneland, userland, disneyland et atomicité. Sur les processeurs x86, à ma connaissance, seule une poignée d'instructions est atomique (xchg, les opérations sur entiers préfixés par lock, etc.). A partir de ces fonctions, il est assez facile de construire, en assembleur, des verrous, genre /spinlock/, autour des zones de code critique. Ce n'est pas nécessairement l'équivalent d'un mutex, par les fonctionnalités, mais c'est un début, qui permet de contrôler l'atomicité de n'importe quelle zone de code.
On est bien d'accord sur ce point. Le point faible de l'utilisation de ces instructions assembleur, c'est que tu te retrouves dans la situation d'avoir un sem_wait() qui sera atomique et un sem_post() qui lui, ne le sera plus (sur i386, mais pourra l'être sur amd64, ce qui fout un boxon inimaginable dans tout les codes qui doivent être portables. Au passage, les sémaphores étant les seuls verrous async safe, c'est un peu gênant...). C'est à cause de ce genre de trucs foireux que l'implantation des threads a été reprise trois fois sous Linux.
Cordialement,
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.
rg
pehache-tolai a écrit :
"NiKo" a écrit dans le message de news: 4a746735$0$437$
Ce que tu comprend pas, c'est que sous Linux, on ouvre l'application dont on a besoin et on s'en sert. On aura pas d'écran bleu
Il serait peut-être bon que tu mettes ton argumentaire anti-windows un peu à jour : un BSOD ça fait une paye que je n'en ai pas vu un.
2 jours après avoir réinstallé mon PC sous windows XP (avec MAJ).
Kernel panic par contre, depuis que je bidouille plus les pilotes parce que ça marche, j'en ai pas revu.
-- Régis (rg)
pehache-tolai a écrit :
"NiKo" <NiKo@nomail.svp> a écrit dans le message de news:
4a746735$0$437$426a34cc@news.free.fr
Ce que tu comprend pas, c'est que sous Linux, on ouvre l'application
dont on a besoin et on s'en sert. On aura pas d'écran bleu
Il serait peut-être bon que tu mettes ton argumentaire anti-windows un peu à
jour : un BSOD ça fait une paye que je n'en ai pas vu un.
2 jours après avoir réinstallé mon PC sous windows XP (avec MAJ).
Kernel panic par contre, depuis que je bidouille plus les pilotes parce
que ça marche, j'en ai pas revu.
"NiKo" a écrit dans le message de news: 4a746735$0$437$
Ce que tu comprend pas, c'est que sous Linux, on ouvre l'application dont on a besoin et on s'en sert. On aura pas d'écran bleu
Il serait peut-être bon que tu mettes ton argumentaire anti-windows un peu à jour : un BSOD ça fait une paye que je n'en ai pas vu un.
2 jours après avoir réinstallé mon PC sous windows XP (avec MAJ).
Kernel panic par contre, depuis que je bidouille plus les pilotes parce que ça marche, j'en ai pas revu.
-- Régis (rg)
David Marec
pehache-tolai:
"NiKo" a écrit dans le message de news: 4a746735$0$437$
Ce que tu comprend pas, c'est que sous Linux, on ouvre l'application dont on a besoin et on s'en sert. On aura pas d'écran bleu
Il serait peut-être bon que tu mettes ton argumentaire anti-windows un peu à jour : un BSOD ça fait une paye que je n'en ai pas vu un.
Des BSOD, assez peu depuis quelques années, oui.
Mais un MS-Windows-XP qui se fige, l'explosion en vol de explorer.exe ou la demande expresse de fermeture de programmes pour cause de mémoire , c'est devenu un classique, moins que sous MS-Windows 98, mais tout de même trop fréquent...
David Marec, -- http://user.lamaiziere.net/david/Site/ http://www.freebsd.org/fr/ http://www.diablotins.org/
pehache-tolai:
"NiKo" <NiKo@nomail.svp> a écrit dans le message de news:
4a746735$0$437$426a34cc@news.free.fr
Ce que tu comprend pas, c'est que sous Linux, on ouvre l'application
dont on a besoin et on s'en sert. On aura pas d'écran bleu
Il serait peut-être bon que tu mettes ton argumentaire anti-windows un peu
à jour : un BSOD ça fait une paye que je n'en ai pas vu un.
Des BSOD, assez peu depuis quelques années, oui.
Mais un MS-Windows-XP qui se fige, l'explosion en vol de explorer.exe ou la
demande expresse de fermeture de programmes pour cause de mémoire , c'est
devenu un classique, moins que sous MS-Windows 98, mais tout de même trop
fréquent...
David Marec,
--
http://user.lamaiziere.net/david/Site/
http://www.freebsd.org/fr/ http://www.diablotins.org/
"NiKo" a écrit dans le message de news: 4a746735$0$437$
Ce que tu comprend pas, c'est que sous Linux, on ouvre l'application dont on a besoin et on s'en sert. On aura pas d'écran bleu
Il serait peut-être bon que tu mettes ton argumentaire anti-windows un peu à jour : un BSOD ça fait une paye que je n'en ai pas vu un.
Des BSOD, assez peu depuis quelques années, oui.
Mais un MS-Windows-XP qui se fige, l'explosion en vol de explorer.exe ou la demande expresse de fermeture de programmes pour cause de mémoire , c'est devenu un classique, moins que sous MS-Windows 98, mais tout de même trop fréquent...
David Marec, -- http://user.lamaiziere.net/david/Site/ http://www.freebsd.org/fr/ http://www.diablotins.org/
Thierry B
On 2009-08-01, Stephane TOUGARD wrote:
On emule un systeme d'exploitation et on implemente l'API systeme d'une norme.
Il y a donc consensus, passons rapidement au vote.
-- t> Et après Nautilus, il faut t'attaquer à la face nord de t> l'Everest: la débloatisation de Gnus. Ah non, ça fait partie du cahier des charges. Si Gnus n'est plus bloaté, moi je lirait les news avec netcat.
On 2009-08-01, Stephane TOUGARD <stephane@unices.org> wrote:
On emule un systeme d'exploitation et on implemente l'API systeme d'une
norme.
Il y a donc consensus, passons rapidement au vote.
--
t> Et après Nautilus, il faut t'attaquer à la face nord de
t> l'Everest: la débloatisation de Gnus.
Ah non, ça fait partie du cahier des charges. Si Gnus n'est plus bloaté,
moi je lirait les news avec netcat.
On emule un systeme d'exploitation et on implemente l'API systeme d'une norme.
Il y a donc consensus, passons rapidement au vote.
-- t> Et après Nautilus, il faut t'attaquer à la face nord de t> l'Everest: la débloatisation de Gnus. Ah non, ça fait partie du cahier des charges. Si Gnus n'est plus bloaté, moi je lirait les news avec netcat.
