Le Wed, 14 Dec 2011 17:48:02 +0100
Ascadix a écrit :Yliur avait prétendu :Le Wed, 14 Dec 2011 01:36:39 +0100
Ascadix a écrit :Il se trouve que Yliur a formulé :Le Wed, 14 Dec 2011 00:37:46 +0100
Ascadix a écrit :
[la fragmentation]Moins sensible en mono-tache, plus en multi-tache ou usage genre
BDD.
Pourquoi moins sensible en mono-tâche ?
Parceque en multi-tache, les têtes du DD doivent déjà sauter d'un
bout à l'autre du DD en raison des accés simultanés à de nombreux
fichiers, à multiplier par la fragmentation des fichiers.
En monotache, t'as globalement moins d'accés fichiers simultanés
donc à niveau defragmentaiton équivalent, les têtes doivent se
déplacer 1* nb de fragments alors qu'en multi-tache c'est X*nb de
frag ( et X et +/- plus grand que 1)
Tu veux dire que faire plusieurs accès disques simultanés c'est plus
lent qu'en faire un seul, en fait. Mais ça n'a rien à voir avec la
fragmentation.
ça n'a rien à voir comme cause ... mais l'effet des 2 sur les perfs
est cumulatif.
Ma question c'est pourquoi tu considères que c'est plus sensible en
multi-tâches.Tout ça reste vrai si les fichiers ne sont pas du tout
fragmentés.
Oui ...
J'ai écrit + ou - sensible, j'ai jamais écrit inexistant.Et en multi-tâches avec un peu de chances certains
processus ont autre chose à faire que lire sur le disque pendant
qu'un autre est bloqué dessus, ce qui limite les pertes de temps
dues aux accès disques.
Il y a encore plus de "temps mort" en mono-tâche ...
?
Là je ne comprends pas. Qu'appelles-tu "temps mort" ? Quand un
processus est bloqué en attente d'un retour du disque, il ne peut rien
faire d'autre, ce qui rend ce blocage plus pénalisant s'il n'y a pas
d'autre processus en cours d'exécution parce que le processeur n'a
rien à faire.
Pour reprendre l'analogie de l'armoire à dossier chère à certains
, tu va aller plus vite si je te demande de me récupérer un
dossier éparpillé dans 5 tiroirs que si tu doit récupérer les
morceaux de 10 dossiers éparpillé dans 5*10 = 50 tirroirs
Justement, dans cet exemple comme lorsque tu parles plus haut de
sauter d'un bout à l'autre du disque, le fait de passer d'un
fichier à l'autre est confondu avec le fait de passer d'une
fragment à l'autre. Pour prendre une image illustrant simplement
mon propos : une tâche avec des accès disque un peu partout : la
tête doit parcourir tout l'espace entre deux fragments extrêmes
pour passer de l'un à l'autre. Deux tâches simultanées, avec des
fragments de fichiers entrecroisés : la tête doit faire à peu près
le même chemin, avec plus d'arrêts, ce qui ne prend pas plus de
temps (temps de parcours cumulé). Au contraire, si les deux tâches
étaient accomplies de manière séquentielle, le trajet total de la
tête aurait été plus important. Tout ça si le système est capable
de réorganiser les accès aux disques pour simplifier le parcours de
la tête, bien sûr (pour faire simple, imaginons qu'il utilise
quelque chose du genre de l'algorithme de l'ascenseur : le temps de
déplacement cumulé ne dépend pas du nombre d'arrêts
intermédiaires). Et si on ne considère pas cette optimisation, le
côté multi-tâches reste neutre du point de vue de la fragmentation
(à vue de nez).
Que la tête saute d'une piste du début à une piste de fin, ou
s'arréte par une piste intermédiaire pour lire qq secteurs, c'est pas
la même vitesse.
Des références ? Ce n'est pas un moteur précis, du genre pas-à-pas ?
As-tu des chiffres à citer pour comparer ou est-ce une supposition ?
Et ça n'explique pour pourquoi la fragmentation est plus sensible en
multi-tâches qu'en mono-tâches, parce que le trajet total sera
peut-être plus court en multi-tâches (que si elles avaient été
exécutées successivement par exemple).en comparaison, une fois positioné sur une piste,
lire 1 ou 50 secteurs ça provoque un cout en temps bien moindre que
le positionnement sur une piste intermédiaire.
Alors bien sur, si elle les softs demandent dans l'ordre :
piste 1 ... piste 100 + piste 50 ... piste 200 + piste 30
... -> requetes multiples
+ -> fragmentation
et que le DD lit physiquement dans cet ordre c'est pas bon.
La réorganisation des I/O par l'OS, éventuellement épaulé par des
technos plus proches du matos comme le NCQ va permetre d'optimiser ça
en réalisant mécaniquement une lecteur dans l'ordre :
p1 - p30 - p50 - p100 - p200
Mais ça restera quand même plus lent que si il avait seulemernt eu
besoin de faire
p1 - p30 - 200 (si ça avait été défragmenté)
ou simplement
p 100 + p 50 si seul soft avait été en cours et que personne ne
demande à lire p1 / p200 / p30
Les 2 causes se combinent et donnent toujours un résultat plus lent,
même si c'est + /- notable suivant le détail, c'est toujorus + lent.
Le Wed, 14 Dec 2011 17:48:02 +0100
Ascadix <ascadix.ng@free.fr> a écrit :
Yliur avait prétendu :
Le Wed, 14 Dec 2011 01:36:39 +0100
Ascadix <ascadix.ng@free.fr> a écrit :
Il se trouve que Yliur a formulé :
Le Wed, 14 Dec 2011 00:37:46 +0100
Ascadix <ascadix.ng@free.fr> a écrit :
[la fragmentation]
Moins sensible en mono-tache, plus en multi-tache ou usage genre
BDD.
Pourquoi moins sensible en mono-tâche ?
Parceque en multi-tache, les têtes du DD doivent déjà sauter d'un
bout à l'autre du DD en raison des accés simultanés à de nombreux
fichiers, à multiplier par la fragmentation des fichiers.
En monotache, t'as globalement moins d'accés fichiers simultanés
donc à niveau defragmentaiton équivalent, les têtes doivent se
déplacer 1* nb de fragments alors qu'en multi-tache c'est X*nb de
frag ( et X et +/- plus grand que 1)
Tu veux dire que faire plusieurs accès disques simultanés c'est plus
lent qu'en faire un seul, en fait. Mais ça n'a rien à voir avec la
fragmentation.
ça n'a rien à voir comme cause ... mais l'effet des 2 sur les perfs
est cumulatif.
Ma question c'est pourquoi tu considères que c'est plus sensible en
multi-tâches.
Tout ça reste vrai si les fichiers ne sont pas du tout
fragmentés.
Oui ...
J'ai écrit + ou - sensible, j'ai jamais écrit inexistant.
Et en multi-tâches avec un peu de chances certains
processus ont autre chose à faire que lire sur le disque pendant
qu'un autre est bloqué dessus, ce qui limite les pertes de temps
dues aux accès disques.
Il y a encore plus de "temps mort" en mono-tâche ...
?
Là je ne comprends pas. Qu'appelles-tu "temps mort" ? Quand un
processus est bloqué en attente d'un retour du disque, il ne peut rien
faire d'autre, ce qui rend ce blocage plus pénalisant s'il n'y a pas
d'autre processus en cours d'exécution parce que le processeur n'a
rien à faire.
Pour reprendre l'analogie de l'armoire à dossier chère à certains
, tu va aller plus vite si je te demande de me récupérer un
dossier éparpillé dans 5 tiroirs que si tu doit récupérer les
morceaux de 10 dossiers éparpillé dans 5*10 = 50 tirroirs
Justement, dans cet exemple comme lorsque tu parles plus haut de
sauter d'un bout à l'autre du disque, le fait de passer d'un
fichier à l'autre est confondu avec le fait de passer d'une
fragment à l'autre. Pour prendre une image illustrant simplement
mon propos : une tâche avec des accès disque un peu partout : la
tête doit parcourir tout l'espace entre deux fragments extrêmes
pour passer de l'un à l'autre. Deux tâches simultanées, avec des
fragments de fichiers entrecroisés : la tête doit faire à peu près
le même chemin, avec plus d'arrêts, ce qui ne prend pas plus de
temps (temps de parcours cumulé). Au contraire, si les deux tâches
étaient accomplies de manière séquentielle, le trajet total de la
tête aurait été plus important. Tout ça si le système est capable
de réorganiser les accès aux disques pour simplifier le parcours de
la tête, bien sûr (pour faire simple, imaginons qu'il utilise
quelque chose du genre de l'algorithme de l'ascenseur : le temps de
déplacement cumulé ne dépend pas du nombre d'arrêts
intermédiaires). Et si on ne considère pas cette optimisation, le
côté multi-tâches reste neutre du point de vue de la fragmentation
(à vue de nez).
Que la tête saute d'une piste du début à une piste de fin, ou
s'arréte par une piste intermédiaire pour lire qq secteurs, c'est pas
la même vitesse.
Des références ? Ce n'est pas un moteur précis, du genre pas-à-pas ?
As-tu des chiffres à citer pour comparer ou est-ce une supposition ?
Et ça n'explique pour pourquoi la fragmentation est plus sensible en
multi-tâches qu'en mono-tâches, parce que le trajet total sera
peut-être plus court en multi-tâches (que si elles avaient été
exécutées successivement par exemple).
en comparaison, une fois positioné sur une piste,
lire 1 ou 50 secteurs ça provoque un cout en temps bien moindre que
le positionnement sur une piste intermédiaire.
Alors bien sur, si elle les softs demandent dans l'ordre :
piste 1 ... piste 100 + piste 50 ... piste 200 + piste 30
... -> requetes multiples
+ -> fragmentation
et que le DD lit physiquement dans cet ordre c'est pas bon.
La réorganisation des I/O par l'OS, éventuellement épaulé par des
technos plus proches du matos comme le NCQ va permetre d'optimiser ça
en réalisant mécaniquement une lecteur dans l'ordre :
p1 - p30 - p50 - p100 - p200
Mais ça restera quand même plus lent que si il avait seulemernt eu
besoin de faire
p1 - p30 - 200 (si ça avait été défragmenté)
ou simplement
p 100 + p 50 si seul soft avait été en cours et que personne ne
demande à lire p1 / p200 / p30
Les 2 causes se combinent et donnent toujours un résultat plus lent,
même si c'est + /- notable suivant le détail, c'est toujorus + lent.
Le Wed, 14 Dec 2011 17:48:02 +0100
Ascadix a écrit :Yliur avait prétendu :Le Wed, 14 Dec 2011 01:36:39 +0100
Ascadix a écrit :Il se trouve que Yliur a formulé :Le Wed, 14 Dec 2011 00:37:46 +0100
Ascadix a écrit :
[la fragmentation]Moins sensible en mono-tache, plus en multi-tache ou usage genre
BDD.
Pourquoi moins sensible en mono-tâche ?
Parceque en multi-tache, les têtes du DD doivent déjà sauter d'un
bout à l'autre du DD en raison des accés simultanés à de nombreux
fichiers, à multiplier par la fragmentation des fichiers.
En monotache, t'as globalement moins d'accés fichiers simultanés
donc à niveau defragmentaiton équivalent, les têtes doivent se
déplacer 1* nb de fragments alors qu'en multi-tache c'est X*nb de
frag ( et X et +/- plus grand que 1)
Tu veux dire que faire plusieurs accès disques simultanés c'est plus
lent qu'en faire un seul, en fait. Mais ça n'a rien à voir avec la
fragmentation.
ça n'a rien à voir comme cause ... mais l'effet des 2 sur les perfs
est cumulatif.
Ma question c'est pourquoi tu considères que c'est plus sensible en
multi-tâches.Tout ça reste vrai si les fichiers ne sont pas du tout
fragmentés.
Oui ...
J'ai écrit + ou - sensible, j'ai jamais écrit inexistant.Et en multi-tâches avec un peu de chances certains
processus ont autre chose à faire que lire sur le disque pendant
qu'un autre est bloqué dessus, ce qui limite les pertes de temps
dues aux accès disques.
Il y a encore plus de "temps mort" en mono-tâche ...
?
Là je ne comprends pas. Qu'appelles-tu "temps mort" ? Quand un
processus est bloqué en attente d'un retour du disque, il ne peut rien
faire d'autre, ce qui rend ce blocage plus pénalisant s'il n'y a pas
d'autre processus en cours d'exécution parce que le processeur n'a
rien à faire.
Pour reprendre l'analogie de l'armoire à dossier chère à certains
, tu va aller plus vite si je te demande de me récupérer un
dossier éparpillé dans 5 tiroirs que si tu doit récupérer les
morceaux de 10 dossiers éparpillé dans 5*10 = 50 tirroirs
Justement, dans cet exemple comme lorsque tu parles plus haut de
sauter d'un bout à l'autre du disque, le fait de passer d'un
fichier à l'autre est confondu avec le fait de passer d'une
fragment à l'autre. Pour prendre une image illustrant simplement
mon propos : une tâche avec des accès disque un peu partout : la
tête doit parcourir tout l'espace entre deux fragments extrêmes
pour passer de l'un à l'autre. Deux tâches simultanées, avec des
fragments de fichiers entrecroisés : la tête doit faire à peu près
le même chemin, avec plus d'arrêts, ce qui ne prend pas plus de
temps (temps de parcours cumulé). Au contraire, si les deux tâches
étaient accomplies de manière séquentielle, le trajet total de la
tête aurait été plus important. Tout ça si le système est capable
de réorganiser les accès aux disques pour simplifier le parcours de
la tête, bien sûr (pour faire simple, imaginons qu'il utilise
quelque chose du genre de l'algorithme de l'ascenseur : le temps de
déplacement cumulé ne dépend pas du nombre d'arrêts
intermédiaires). Et si on ne considère pas cette optimisation, le
côté multi-tâches reste neutre du point de vue de la fragmentation
(à vue de nez).
Que la tête saute d'une piste du début à une piste de fin, ou
s'arréte par une piste intermédiaire pour lire qq secteurs, c'est pas
la même vitesse.
Des références ? Ce n'est pas un moteur précis, du genre pas-à-pas ?
As-tu des chiffres à citer pour comparer ou est-ce une supposition ?
Et ça n'explique pour pourquoi la fragmentation est plus sensible en
multi-tâches qu'en mono-tâches, parce que le trajet total sera
peut-être plus court en multi-tâches (que si elles avaient été
exécutées successivement par exemple).en comparaison, une fois positioné sur une piste,
lire 1 ou 50 secteurs ça provoque un cout en temps bien moindre que
le positionnement sur une piste intermédiaire.
Alors bien sur, si elle les softs demandent dans l'ordre :
piste 1 ... piste 100 + piste 50 ... piste 200 + piste 30
... -> requetes multiples
+ -> fragmentation
et que le DD lit physiquement dans cet ordre c'est pas bon.
La réorganisation des I/O par l'OS, éventuellement épaulé par des
technos plus proches du matos comme le NCQ va permetre d'optimiser ça
en réalisant mécaniquement une lecteur dans l'ordre :
p1 - p30 - p50 - p100 - p200
Mais ça restera quand même plus lent que si il avait seulemernt eu
besoin de faire
p1 - p30 - 200 (si ça avait été défragmenté)
ou simplement
p 100 + p 50 si seul soft avait été en cours et que personne ne
demande à lire p1 / p200 / p30
Les 2 causes se combinent et donnent toujours un résultat plus lent,
même si c'est + /- notable suivant le détail, c'est toujorus + lent.
Le 14/12/2011 19:13, Ascadix a écrit :"Le site WinRumors vient en effet de publier ..."
Tu peux y cliquer sur le mot "WinRumors" qui est un lien vers l'article
d'origine:
http://www.winrumors.com/windows-phone-sms-attack-discovered-reboots-device-and-disables-messaging-hub/
Je repose donc ma question que tu semble vouloir esquiver ... peut-tu
indiquer *où* dans l'article d'origine ils parlent de réinstaller l'OS
du WindowsPhone ?
Faut quand même pas que je t'explique comment suivre un lien dans une
page web ?
Je cite plus précisément le site bussinessmobile.fr:
Le problème semble définitif puisque selon nos confrères, seul un reset
intégral du smartphone et une réinstallation du système permet d'y échapper.
WinRumors souligne également que....
C'est bien précisé "SELON NOS CONFRERES",reste a savoir si les confrères
c'est winrumors ou d'autres spécialistes.
Le 14/12/2011 19:13, Ascadix a écrit :
"Le site WinRumors vient en effet de publier ..."
Tu peux y cliquer sur le mot "WinRumors" qui est un lien vers l'article
d'origine:
http://www.winrumors.com/windows-phone-sms-attack-discovered-reboots-device-and-disables-messaging-hub/
Je repose donc ma question que tu semble vouloir esquiver ... peut-tu
indiquer *où* dans l'article d'origine ils parlent de réinstaller l'OS
du WindowsPhone ?
Faut quand même pas que je t'explique comment suivre un lien dans une
page web ?
Je cite plus précisément le site bussinessmobile.fr:
Le problème semble définitif puisque selon nos confrères, seul un reset
intégral du smartphone et une réinstallation du système permet d'y échapper.
WinRumors souligne également que....
C'est bien précisé "SELON NOS CONFRERES",reste a savoir si les confrères
c'est winrumors ou d'autres spécialistes.
Le 14/12/2011 19:13, Ascadix a écrit :"Le site WinRumors vient en effet de publier ..."
Tu peux y cliquer sur le mot "WinRumors" qui est un lien vers l'article
d'origine:
http://www.winrumors.com/windows-phone-sms-attack-discovered-reboots-device-and-disables-messaging-hub/
Je repose donc ma question que tu semble vouloir esquiver ... peut-tu
indiquer *où* dans l'article d'origine ils parlent de réinstaller l'OS
du WindowsPhone ?
Faut quand même pas que je t'explique comment suivre un lien dans une
page web ?
Je cite plus précisément le site bussinessmobile.fr:
Le problème semble définitif puisque selon nos confrères, seul un reset
intégral du smartphone et une réinstallation du système permet d'y échapper.
WinRumors souligne également que....
C'est bien précisé "SELON NOS CONFRERES",reste a savoir si les confrères
c'est winrumors ou d'autres spécialistes.
Merci du conseil. Je vais peut-être paraître naïf mais je crois que les
gens peuvent changer, rien n'est inéluctable.
Merci du conseil. Je vais peut-être paraître naïf mais je crois que les
gens peuvent changer, rien n'est inéluctable.
Merci du conseil. Je vais peut-être paraître naïf mais je crois que les
gens peuvent changer, rien n'est inéluctable.
Le 14/12/2011 18:45, Ascadix a écrit :Je ne crois pas avoir vu, depuis que je lis ce newsgroup, quelqu'un
insulter un utilisateur de windows.
Par contre, les kroteux qui viennent ici chier sur linux du haut de leur
'con-pétance' de windozien, ceux là, oui, se font recevoir.
Faut oser mettre ces 2 phrases là bout-à-bout :-)
Sauf quand on comprend ce qu'on lit. Mais ce n'est pas le fort du
kroteux que de comprendre.
Le 14/12/2011 18:45, Ascadix a écrit :
Je ne crois pas avoir vu, depuis que je lis ce newsgroup, quelqu'un
insulter un utilisateur de windows.
Par contre, les kroteux qui viennent ici chier sur linux du haut de leur
'con-pétance' de windozien, ceux là, oui, se font recevoir.
Faut oser mettre ces 2 phrases là bout-à-bout :-)
Sauf quand on comprend ce qu'on lit. Mais ce n'est pas le fort du
kroteux que de comprendre.
Le 14/12/2011 18:45, Ascadix a écrit :Je ne crois pas avoir vu, depuis que je lis ce newsgroup, quelqu'un
insulter un utilisateur de windows.
Par contre, les kroteux qui viennent ici chier sur linux du haut de leur
'con-pétance' de windozien, ceux là, oui, se font recevoir.
Faut oser mettre ces 2 phrases là bout-à-bout :-)
Sauf quand on comprend ce qu'on lit. Mais ce n'est pas le fort du
kroteux que de comprendre.
tu peux regarder du coté de
fr.comp.os.linux.conf, il y à là-bas des contributeurs qui jouent le jeu
et causent technique sans ressentir le besoin d'insulter les nouveaux ou
les personnes utilisants aussi du Windows.
tu peux regarder du coté de
fr.comp.os.linux.conf, il y à là-bas des contributeurs qui jouent le jeu
et causent technique sans ressentir le besoin d'insulter les nouveaux ou
les personnes utilisants aussi du Windows.
tu peux regarder du coté de
fr.comp.os.linux.conf, il y à là-bas des contributeurs qui jouent le jeu
et causent technique sans ressentir le besoin d'insulter les nouveaux ou
les personnes utilisants aussi du Windows.
Il se trouve que Hugolino a formulé :
> Le 14-12-2011, Yliur a écrit :
>> Ascadix a écrit :
>>
>>> Parceque en multi-tache, les têtes du DD doivent déjà sauter d'un
>>> bout à l'autre du DD en raison des accés simultanés à de nombreux
>>> fichiers, à multiplier par la fragmentation des fichiers.
>
>> Deux tâches simultanées, avec des fragments de fichiers entrecroisés
>> : la tête doit faire à peu près le même chemin, avec plus d'arrêts,
>> ce qui ne prend pas plus de temps (temps de parcours cumulé).
>> Au contraire, si les deux tâches étaient accomplies de manière
>> séquentielle, le trajet total de la tête aurait été plus important.
>
> T'es un vrai méchant, toi !! Pourquoi mettre ainsi le nez dans son caca
> à cet imbécile ?
> N'aurais-tu donc aucune compassion pour les kroteux qui démontrent
> eux-mêmes par A + B qu'ils sont incapables de penser correctement.
>
> Allez Ascadix, retourne jouer avec tes copains...
Y a pas à dire, les courges dans ton genre, ça fait une bonne pub pour
"l'ouverture d'esprit" des Linuxiens ...
Si au moins tu tentais d'expliquer ce que t'as pas compris ou ce qui
te semble pas correct ?
Mais bon, vraisemblablement il pleuvra des lingots le jour ou tu sera
capable d'aligner une seule ligne d'infos ...
Et encore une fois, un xpost + fu2 sournois de la part du minable de
service.
Il se trouve que Hugolino a formulé :
> Le 14-12-2011, Yliur <yliur@free.fr> a écrit :
>> Ascadix <ascadix.ng@free.fr> a écrit :
>>
>>> Parceque en multi-tache, les têtes du DD doivent déjà sauter d'un
>>> bout à l'autre du DD en raison des accés simultanés à de nombreux
>>> fichiers, à multiplier par la fragmentation des fichiers.
>
>> Deux tâches simultanées, avec des fragments de fichiers entrecroisés
>> : la tête doit faire à peu près le même chemin, avec plus d'arrêts,
>> ce qui ne prend pas plus de temps (temps de parcours cumulé).
>> Au contraire, si les deux tâches étaient accomplies de manière
>> séquentielle, le trajet total de la tête aurait été plus important.
>
> T'es un vrai méchant, toi !! Pourquoi mettre ainsi le nez dans son caca
> à cet imbécile ?
> N'aurais-tu donc aucune compassion pour les kroteux qui démontrent
> eux-mêmes par A + B qu'ils sont incapables de penser correctement.
>
> Allez Ascadix, retourne jouer avec tes copains...
Y a pas à dire, les courges dans ton genre, ça fait une bonne pub pour
"l'ouverture d'esprit" des Linuxiens ...
Si au moins tu tentais d'expliquer ce que t'as pas compris ou ce qui
te semble pas correct ?
Mais bon, vraisemblablement il pleuvra des lingots le jour ou tu sera
capable d'aligner une seule ligne d'infos ...
Et encore une fois, un xpost + fu2 sournois de la part du minable de
service.
Il se trouve que Hugolino a formulé :
> Le 14-12-2011, Yliur a écrit :
>> Ascadix a écrit :
>>
>>> Parceque en multi-tache, les têtes du DD doivent déjà sauter d'un
>>> bout à l'autre du DD en raison des accés simultanés à de nombreux
>>> fichiers, à multiplier par la fragmentation des fichiers.
>
>> Deux tâches simultanées, avec des fragments de fichiers entrecroisés
>> : la tête doit faire à peu près le même chemin, avec plus d'arrêts,
>> ce qui ne prend pas plus de temps (temps de parcours cumulé).
>> Au contraire, si les deux tâches étaient accomplies de manière
>> séquentielle, le trajet total de la tête aurait été plus important.
>
> T'es un vrai méchant, toi !! Pourquoi mettre ainsi le nez dans son caca
> à cet imbécile ?
> N'aurais-tu donc aucune compassion pour les kroteux qui démontrent
> eux-mêmes par A + B qu'ils sont incapables de penser correctement.
>
> Allez Ascadix, retourne jouer avec tes copains...
Y a pas à dire, les courges dans ton genre, ça fait une bonne pub pour
"l'ouverture d'esprit" des Linuxiens ...
Si au moins tu tentais d'expliquer ce que t'as pas compris ou ce qui
te semble pas correct ?
Mais bon, vraisemblablement il pleuvra des lingots le jour ou tu sera
capable d'aligner une seule ligne d'infos ...
Et encore une fois, un xpost + fu2 sournois de la part du minable de
service.
Le Wed, 14 Dec 2011 18:04:33 +0100, Ascadix a écrit :tu peux regarder du coté de
fr.comp.os.linux.conf, il y à là-bas des contributeurs qui jouent le jeu
et causent technique sans ressentir le besoin d'insulter les nouveaux ou
les personnes utilisants aussi du Windows.
sauf que souvent, on trouve les mêmes contributeurs qu'ici...
Le Wed, 14 Dec 2011 18:04:33 +0100, Ascadix a écrit :
tu peux regarder du coté de
fr.comp.os.linux.conf, il y à là-bas des contributeurs qui jouent le jeu
et causent technique sans ressentir le besoin d'insulter les nouveaux ou
les personnes utilisants aussi du Windows.
sauf que souvent, on trouve les mêmes contributeurs qu'ici...
Le Wed, 14 Dec 2011 18:04:33 +0100, Ascadix a écrit :tu peux regarder du coté de
fr.comp.os.linux.conf, il y à là-bas des contributeurs qui jouent le jeu
et causent technique sans ressentir le besoin d'insulter les nouveaux ou
les personnes utilisants aussi du Windows.
sauf que souvent, on trouve les mêmes contributeurs qu'ici...
Le Wed, 14 Dec 2011 10:01:07 +0000, Kevin Denis a écrit :
> Plier le noyau? Un concept intéressant assurément.
encore un modèle en couches, probablement.
Le Wed, 14 Dec 2011 10:01:07 +0000, Kevin Denis a écrit :
> Plier le noyau? Un concept intéressant assurément.
encore un modèle en couches, probablement.
Le Wed, 14 Dec 2011 10:01:07 +0000, Kevin Denis a écrit :
> Plier le noyau? Un concept intéressant assurément.
encore un modèle en couches, probablement.
Frederic Bezies a exprimé avec précision :
> Le Tue, 13 Dec 2011 22:01:06 +0100, P4nd1-P4nd4 a écrit :
>
>> ... Et cracher les morceaux !
>>
>> Cette opération indispensable pour l'utilisateur avertis (Enfin,
>> celui qui veut que son ordinateur fonctionne plus vite sans
>> défragmenter vu qu'il n'y pas de défragmenteur sous Linux...) qui
>> souhaite "optimiser"
>
> Ah ? Tu m'expliqueras la différence entre un noyau et un système de
> fichiers. Tu te dis informaticien, non ?
Ah
mon avis, il veut simplement dire que quand on commence à penser
"optimisation", on doit avoir une vue d'ensemble, et la logique est
plutot de commencer par chasser le gaspi sur les points les +
pénalisants avant de passer au fignolage sur les points ou le gain
est infinitésimal.
Frederic Bezies a exprimé avec précision :
> Le Tue, 13 Dec 2011 22:01:06 +0100, P4nd1-P4nd4 a écrit :
>
>> ... Et cracher les morceaux !
>>
>> Cette opération indispensable pour l'utilisateur avertis (Enfin,
>> celui qui veut que son ordinateur fonctionne plus vite sans
>> défragmenter vu qu'il n'y pas de défragmenteur sous Linux...) qui
>> souhaite "optimiser"
>
> Ah ? Tu m'expliqueras la différence entre un noyau et un système de
> fichiers. Tu te dis informaticien, non ?
Ah
mon avis, il veut simplement dire que quand on commence à penser
"optimisation", on doit avoir une vue d'ensemble, et la logique est
plutot de commencer par chasser le gaspi sur les points les +
pénalisants avant de passer au fignolage sur les points ou le gain
est infinitésimal.
Frederic Bezies a exprimé avec précision :
> Le Tue, 13 Dec 2011 22:01:06 +0100, P4nd1-P4nd4 a écrit :
>
>> ... Et cracher les morceaux !
>>
>> Cette opération indispensable pour l'utilisateur avertis (Enfin,
>> celui qui veut que son ordinateur fonctionne plus vite sans
>> défragmenter vu qu'il n'y pas de défragmenteur sous Linux...) qui
>> souhaite "optimiser"
>
> Ah ? Tu m'expliqueras la différence entre un noyau et un système de
> fichiers. Tu te dis informaticien, non ?
Ah
mon avis, il veut simplement dire que quand on commence à penser
"optimisation", on doit avoir une vue d'ensemble, et la logique est
plutot de commencer par chasser le gaspi sur les points les +
pénalisants avant de passer au fignolage sur les points ou le gain
est infinitésimal.
Le 14/12/2011 19:04, NiKo a écrit :Le 14/12/2011 18:45, Ascadix a écrit :Je ne crois pas avoir vu, depuis que je lis ce newsgroup, quelqu'un
insulter un utilisateur de windows.
Par contre, les kroteux qui viennent ici chier sur linux du haut de
leur
'con-pétance' de windozien, ceux là, oui, se font recevoir.
Faut oser mettre ces 2 phrases là bout-à-bout :-)
Sauf quand on comprend ce qu'on lit. Mais ce n'est pas le fort du
kroteux que de comprendre.
Comment disiez-vous déjà ?
<<Je ne crois pas avoir vu, depuis que je lis ce newsgroup, quelqu'un
insulter un utilisateur de windows.>>
Le brainwashing de la petite secte des intolérants est redoutable ! :-)
Le 14/12/2011 19:04, NiKo a écrit :
Le 14/12/2011 18:45, Ascadix a écrit :
Je ne crois pas avoir vu, depuis que je lis ce newsgroup, quelqu'un
insulter un utilisateur de windows.
Par contre, les kroteux qui viennent ici chier sur linux du haut de
leur
'con-pétance' de windozien, ceux là, oui, se font recevoir.
Faut oser mettre ces 2 phrases là bout-à-bout :-)
Sauf quand on comprend ce qu'on lit. Mais ce n'est pas le fort du
kroteux que de comprendre.
Comment disiez-vous déjà ?
<<Je ne crois pas avoir vu, depuis que je lis ce newsgroup, quelqu'un
insulter un utilisateur de windows.>>
Le brainwashing de la petite secte des intolérants est redoutable ! :-)
Le 14/12/2011 19:04, NiKo a écrit :Le 14/12/2011 18:45, Ascadix a écrit :Je ne crois pas avoir vu, depuis que je lis ce newsgroup, quelqu'un
insulter un utilisateur de windows.
Par contre, les kroteux qui viennent ici chier sur linux du haut de
leur
'con-pétance' de windozien, ceux là, oui, se font recevoir.
Faut oser mettre ces 2 phrases là bout-à-bout :-)
Sauf quand on comprend ce qu'on lit. Mais ce n'est pas le fort du
kroteux que de comprendre.
Comment disiez-vous déjà ?
<<Je ne crois pas avoir vu, depuis que je lis ce newsgroup, quelqu'un
insulter un utilisateur de windows.>>
Le brainwashing de la petite secte des intolérants est redoutable ! :-)