T'es admin Windows ?
Non, et je n'ai jamais prétendu cela. J'ai juste bossé sur un projet
avec un administrateur Windows _confirmé_,
de ceux qui sont capables
d'attaquer un W2008R2 en ligne de commande et certifié Microsoft
machin-chose. Et lorsque je l'ai vu s'arracher les cheveux sur ce
truc et dire qu'il fallait installer une version complète pour faire
ce qu'on avait besoin de faire, j'ai plutôt tendance à le croire lui
que toi.
T'es admin Windows ?
Non, et je n'ai jamais prétendu cela. J'ai juste bossé sur un projet
avec un administrateur Windows _confirmé_,
de ceux qui sont capables
d'attaquer un W2008R2 en ligne de commande et certifié Microsoft
machin-chose. Et lorsque je l'ai vu s'arracher les cheveux sur ce
truc et dire qu'il fallait installer une version complète pour faire
ce qu'on avait besoin de faire, j'ai plutôt tendance à le croire lui
que toi.
T'es admin Windows ?
Non, et je n'ai jamais prétendu cela. J'ai juste bossé sur un projet
avec un administrateur Windows _confirmé_,
de ceux qui sont capables
d'attaquer un W2008R2 en ligne de commande et certifié Microsoft
machin-chose. Et lorsque je l'ai vu s'arracher les cheveux sur ce
truc et dire qu'il fallait installer une version complète pour faire
ce qu'on avait besoin de faire, j'ai plutôt tendance à le croire lui
que toi.
Écoute, mon grand. En 1995, on simulait des amplificateurs
hyperfréquence sur des SS20 qui tournaient avec deux processeurs à
75 MHz, 64 Mo, en un temps qui ferait rougir les machines actuelles.
Ah, le même algo ne pourrait pas tourner sur les machines actuelles ?
Si,
mais il faudrait juste garder les softs qui tournaient avec
Solaris 2.4 ou 2.5 et essayer de les faire tourner sous 2.10 (à
moins qu'il ne s'agisse de 5.10). Les outils en question, rigolo, ne
sont plus supportés depuis belle lurette, ce qui pose des problèmes !
La différence est toute conne. La programmation était un tout petit
peu optimisée et aujourd'hui, ce qui n'est plus le cas aujourd'hui.
En 1995, on utilisait des routeurs de type Orcad qui tournait sous
MS-DOS, sur des PC qui avaient au mieux 2 Mo de mémoire. Essaie de
prendre une carte de l'époque et de le router avec une version
moderne du même Orcad. On se contrefiche actuellement des ressources
consommées en partant du principe que l'utilisateur n'a qu'à acheter
une barrette mémoire supplémentaire voire un autre processeur ou une
autre machine. C'est idiot dans l'immense majorité des cas.
Et juste pour rire, combien coûtait une SS20 bipro en 1995 ?
Au tarif éducation ou laboratoire ? 17 000 FF de l'époque, soit une
fois et demi le prox d'un PC tout juste correct de la même époque.
Si je retrouve une facture, je te la scanne rien que pour toi.
Après tout, en
optimisant encore plus ton code il aurait pu tourner aussi vite (et
même plus vite, hein...) sur un PC bien moins cher et avc 640Ko de
RAM.
Et je t'arrête tout de suite, je n'ai pas dit que c'était mieux il y
a quinze ans ou mieux aujourd'hui. Mon discours est simplement
qu'aujourd'hui, on se contrefiche éperdument de la consommation des
ressources.
Non, on ne s'en fiche pas. Simplement, comme la RAM ou le disque
coûtent 1000 fois moins cher qu'il y a 15 ans, les contraintes ne
sont plus du tout aux mêmes endroits.
Non, on s'en _contrefiche_. On s'en contrefiche même tellement bien
qu'on écrit des bouts d'OS en Java. On utilise des langages objets
(à ramasse-miette pour couronner le tout) un peu partout. C'est
antinomique avec l'économie de ressources. Mais tu risques encore de
ne pas comprendre pourquoi.
Et excuse-moi, mais tu n'es pas ce que j'appelle un matheux (sauf si
connaître l'existence des matrices de corrélation fait le
matheux...).
Tu n'as jamais regardé de près ce que j'avais déjà pondu. De toute
façon, tu risquerais fort de ne rien comprendre.
Il y a des papiers
de mon cru dans diverses revues et conférences, je te laisse
chercher.
Ils ont une dizaine d'années, mais ne t'en fait pas, j'ai
continué mes travaux, mais pour des laboratoires de grands groupes
qui ne publient pas forcément (mais qui déposent des brevets).
Nicolas George en est un (pour ce que j'en vois), mais pas toi (ni
moi).3/ Ça fait plus de quinze ans que j'écris des specs de langages et
que j'implante les interprètes et compilateurs de ces langages.
Une de tes nombreuses activités, on sait...
Non, c'est mon activité principale ne t'en déplaise.
J'écris des
specs de langages adaptés à certains problèmes de calcul
scientifique. Et ça a un immense avantage, une fois que le langage
est spécifié, le programme de résolution du problème initiale ne
change plus et l'optimisation se fait dans le langage et plus dans
l'algorithme lui-même. Rassure-toi, je ne réinvente pas la roue à
chaque fois.
En effet. Disons que tu utilises des appels système, plutôt. Qui
sont tout sauf nécessaire en calcul scientifique. Il y a
suffisamment de bibliothèques de haut niveau qui évitent d'y avoir
recours. Entre MPI et OpenMP il y a tout ce qu'il faut pour le
parallélisme en calcul scientifique par exemple,
OpenMP est une merde dans le cas général, mais je ne vais pas passer
du temps à t'expliquer pourquoi. Au fait, ce n'est pas moi qui le
prétends, c'est expliqué sur les listes de diffusion du truc par les
concepteurs d'OpenMP.
Dit autrement pour toi, OpenMP fait que c'est
intéressant dans le cas d'un calcul parallélisable au niveau
atomique qui tourne seul sur une machine à plusieurs voies. Je te
laisse conclure.
Mais en fait je dirais même qu'il ne faut pas non d'informaticiens
contrariés, qui ont toujours la tentation d'aller optimiser ceci ou
cela en bas niveau et de réinventer l'eau tiède au lieu de se
concentrer sur le contenu algorithmique.
Ahahahahahahahahaha ! Il y a des tas de problèmes NP-complets en
analyse numérique dont les algorithmes sont parfaitement connus. On
sait même pour certains donner une borne maximale au temps de
résolution. Le problème est qu'on ne peut pas les implanter parce
qu'il n'existe pas de langage permettant de le faire correctement,
soit parce que la parallélisation est foireuse (cas MPI ou OpenMP),
soit parce que les bibliothèques de haut niveau sont trivialement
sous-optimales. Aujourd'hui, le problème n'est pas tant l'algorithmie
que la façon d'implanter ces algorithmes de façon un tant soit peu
intelligente. Séparer l'un de l'autre est juste risible. Et séparer
l'implantation des limitations du matériel est aussi risible
puisqu'il faut limiter au maximum les goulets d'étranglements, ce que
ne fera jamais un
truc comme OpenMP puisqu'il ne peut au mieux que contrôler ce qui se
passe dans son processus (pour ne pas dire son fil d'exécution).
Écoute, mon grand. En 1995, on simulait des amplificateurs
hyperfréquence sur des SS20 qui tournaient avec deux processeurs à
75 MHz, 64 Mo, en un temps qui ferait rougir les machines actuelles.
Ah, le même algo ne pourrait pas tourner sur les machines actuelles ?
Si,
mais il faudrait juste garder les softs qui tournaient avec
Solaris 2.4 ou 2.5 et essayer de les faire tourner sous 2.10 (à
moins qu'il ne s'agisse de 5.10). Les outils en question, rigolo, ne
sont plus supportés depuis belle lurette, ce qui pose des problèmes !
La différence est toute conne. La programmation était un tout petit
peu optimisée et aujourd'hui, ce qui n'est plus le cas aujourd'hui.
En 1995, on utilisait des routeurs de type Orcad qui tournait sous
MS-DOS, sur des PC qui avaient au mieux 2 Mo de mémoire. Essaie de
prendre une carte de l'époque et de le router avec une version
moderne du même Orcad. On se contrefiche actuellement des ressources
consommées en partant du principe que l'utilisateur n'a qu'à acheter
une barrette mémoire supplémentaire voire un autre processeur ou une
autre machine. C'est idiot dans l'immense majorité des cas.
Et juste pour rire, combien coûtait une SS20 bipro en 1995 ?
Au tarif éducation ou laboratoire ? 17 000 FF de l'époque, soit une
fois et demi le prox d'un PC tout juste correct de la même époque.
Si je retrouve une facture, je te la scanne rien que pour toi.
Après tout, en
optimisant encore plus ton code il aurait pu tourner aussi vite (et
même plus vite, hein...) sur un PC bien moins cher et avc 640Ko de
RAM.
Et je t'arrête tout de suite, je n'ai pas dit que c'était mieux il y
a quinze ans ou mieux aujourd'hui. Mon discours est simplement
qu'aujourd'hui, on se contrefiche éperdument de la consommation des
ressources.
Non, on ne s'en fiche pas. Simplement, comme la RAM ou le disque
coûtent 1000 fois moins cher qu'il y a 15 ans, les contraintes ne
sont plus du tout aux mêmes endroits.
Non, on s'en _contrefiche_. On s'en contrefiche même tellement bien
qu'on écrit des bouts d'OS en Java. On utilise des langages objets
(à ramasse-miette pour couronner le tout) un peu partout. C'est
antinomique avec l'économie de ressources. Mais tu risques encore de
ne pas comprendre pourquoi.
Et excuse-moi, mais tu n'es pas ce que j'appelle un matheux (sauf si
connaître l'existence des matrices de corrélation fait le
matheux...).
Tu n'as jamais regardé de près ce que j'avais déjà pondu. De toute
façon, tu risquerais fort de ne rien comprendre.
Il y a des papiers
de mon cru dans diverses revues et conférences, je te laisse
chercher.
Ils ont une dizaine d'années, mais ne t'en fait pas, j'ai
continué mes travaux, mais pour des laboratoires de grands groupes
qui ne publient pas forcément (mais qui déposent des brevets).
Nicolas George en est un (pour ce que j'en vois), mais pas toi (ni
moi).
3/ Ça fait plus de quinze ans que j'écris des specs de langages et
que j'implante les interprètes et compilateurs de ces langages.
Une de tes nombreuses activités, on sait...
Non, c'est mon activité principale ne t'en déplaise.
J'écris des
specs de langages adaptés à certains problèmes de calcul
scientifique. Et ça a un immense avantage, une fois que le langage
est spécifié, le programme de résolution du problème initiale ne
change plus et l'optimisation se fait dans le langage et plus dans
l'algorithme lui-même. Rassure-toi, je ne réinvente pas la roue à
chaque fois.
En effet. Disons que tu utilises des appels système, plutôt. Qui
sont tout sauf nécessaire en calcul scientifique. Il y a
suffisamment de bibliothèques de haut niveau qui évitent d'y avoir
recours. Entre MPI et OpenMP il y a tout ce qu'il faut pour le
parallélisme en calcul scientifique par exemple,
OpenMP est une merde dans le cas général, mais je ne vais pas passer
du temps à t'expliquer pourquoi. Au fait, ce n'est pas moi qui le
prétends, c'est expliqué sur les listes de diffusion du truc par les
concepteurs d'OpenMP.
Dit autrement pour toi, OpenMP fait que c'est
intéressant dans le cas d'un calcul parallélisable au niveau
atomique qui tourne seul sur une machine à plusieurs voies. Je te
laisse conclure.
Mais en fait je dirais même qu'il ne faut pas non d'informaticiens
contrariés, qui ont toujours la tentation d'aller optimiser ceci ou
cela en bas niveau et de réinventer l'eau tiède au lieu de se
concentrer sur le contenu algorithmique.
Ahahahahahahahahaha ! Il y a des tas de problèmes NP-complets en
analyse numérique dont les algorithmes sont parfaitement connus. On
sait même pour certains donner une borne maximale au temps de
résolution. Le problème est qu'on ne peut pas les implanter parce
qu'il n'existe pas de langage permettant de le faire correctement,
soit parce que la parallélisation est foireuse (cas MPI ou OpenMP),
soit parce que les bibliothèques de haut niveau sont trivialement
sous-optimales. Aujourd'hui, le problème n'est pas tant l'algorithmie
que la façon d'implanter ces algorithmes de façon un tant soit peu
intelligente. Séparer l'un de l'autre est juste risible. Et séparer
l'implantation des limitations du matériel est aussi risible
puisqu'il faut limiter au maximum les goulets d'étranglements, ce que
ne fera jamais un
truc comme OpenMP puisqu'il ne peut au mieux que contrôler ce qui se
passe dans son processus (pour ne pas dire son fil d'exécution).
Écoute, mon grand. En 1995, on simulait des amplificateurs
hyperfréquence sur des SS20 qui tournaient avec deux processeurs à
75 MHz, 64 Mo, en un temps qui ferait rougir les machines actuelles.
Ah, le même algo ne pourrait pas tourner sur les machines actuelles ?
Si,
mais il faudrait juste garder les softs qui tournaient avec
Solaris 2.4 ou 2.5 et essayer de les faire tourner sous 2.10 (à
moins qu'il ne s'agisse de 5.10). Les outils en question, rigolo, ne
sont plus supportés depuis belle lurette, ce qui pose des problèmes !
La différence est toute conne. La programmation était un tout petit
peu optimisée et aujourd'hui, ce qui n'est plus le cas aujourd'hui.
En 1995, on utilisait des routeurs de type Orcad qui tournait sous
MS-DOS, sur des PC qui avaient au mieux 2 Mo de mémoire. Essaie de
prendre une carte de l'époque et de le router avec une version
moderne du même Orcad. On se contrefiche actuellement des ressources
consommées en partant du principe que l'utilisateur n'a qu'à acheter
une barrette mémoire supplémentaire voire un autre processeur ou une
autre machine. C'est idiot dans l'immense majorité des cas.
Et juste pour rire, combien coûtait une SS20 bipro en 1995 ?
Au tarif éducation ou laboratoire ? 17 000 FF de l'époque, soit une
fois et demi le prox d'un PC tout juste correct de la même époque.
Si je retrouve une facture, je te la scanne rien que pour toi.
Après tout, en
optimisant encore plus ton code il aurait pu tourner aussi vite (et
même plus vite, hein...) sur un PC bien moins cher et avc 640Ko de
RAM.
Et je t'arrête tout de suite, je n'ai pas dit que c'était mieux il y
a quinze ans ou mieux aujourd'hui. Mon discours est simplement
qu'aujourd'hui, on se contrefiche éperdument de la consommation des
ressources.
Non, on ne s'en fiche pas. Simplement, comme la RAM ou le disque
coûtent 1000 fois moins cher qu'il y a 15 ans, les contraintes ne
sont plus du tout aux mêmes endroits.
Non, on s'en _contrefiche_. On s'en contrefiche même tellement bien
qu'on écrit des bouts d'OS en Java. On utilise des langages objets
(à ramasse-miette pour couronner le tout) un peu partout. C'est
antinomique avec l'économie de ressources. Mais tu risques encore de
ne pas comprendre pourquoi.
Et excuse-moi, mais tu n'es pas ce que j'appelle un matheux (sauf si
connaître l'existence des matrices de corrélation fait le
matheux...).
Tu n'as jamais regardé de près ce que j'avais déjà pondu. De toute
façon, tu risquerais fort de ne rien comprendre.
Il y a des papiers
de mon cru dans diverses revues et conférences, je te laisse
chercher.
Ils ont une dizaine d'années, mais ne t'en fait pas, j'ai
continué mes travaux, mais pour des laboratoires de grands groupes
qui ne publient pas forcément (mais qui déposent des brevets).
Nicolas George en est un (pour ce que j'en vois), mais pas toi (ni
moi).3/ Ça fait plus de quinze ans que j'écris des specs de langages et
que j'implante les interprètes et compilateurs de ces langages.
Une de tes nombreuses activités, on sait...
Non, c'est mon activité principale ne t'en déplaise.
J'écris des
specs de langages adaptés à certains problèmes de calcul
scientifique. Et ça a un immense avantage, une fois que le langage
est spécifié, le programme de résolution du problème initiale ne
change plus et l'optimisation se fait dans le langage et plus dans
l'algorithme lui-même. Rassure-toi, je ne réinvente pas la roue à
chaque fois.
En effet. Disons que tu utilises des appels système, plutôt. Qui
sont tout sauf nécessaire en calcul scientifique. Il y a
suffisamment de bibliothèques de haut niveau qui évitent d'y avoir
recours. Entre MPI et OpenMP il y a tout ce qu'il faut pour le
parallélisme en calcul scientifique par exemple,
OpenMP est une merde dans le cas général, mais je ne vais pas passer
du temps à t'expliquer pourquoi. Au fait, ce n'est pas moi qui le
prétends, c'est expliqué sur les listes de diffusion du truc par les
concepteurs d'OpenMP.
Dit autrement pour toi, OpenMP fait que c'est
intéressant dans le cas d'un calcul parallélisable au niveau
atomique qui tourne seul sur une machine à plusieurs voies. Je te
laisse conclure.
Mais en fait je dirais même qu'il ne faut pas non d'informaticiens
contrariés, qui ont toujours la tentation d'aller optimiser ceci ou
cela en bas niveau et de réinventer l'eau tiède au lieu de se
concentrer sur le contenu algorithmique.
Ahahahahahahahahaha ! Il y a des tas de problèmes NP-complets en
analyse numérique dont les algorithmes sont parfaitement connus. On
sait même pour certains donner une borne maximale au temps de
résolution. Le problème est qu'on ne peut pas les implanter parce
qu'il n'existe pas de langage permettant de le faire correctement,
soit parce que la parallélisation est foireuse (cas MPI ou OpenMP),
soit parce que les bibliothèques de haut niveau sont trivialement
sous-optimales. Aujourd'hui, le problème n'est pas tant l'algorithmie
que la façon d'implanter ces algorithmes de façon un tant soit peu
intelligente. Séparer l'un de l'autre est juste risible. Et séparer
l'implantation des limitations du matériel est aussi risible
puisqu'il faut limiter au maximum les goulets d'étranglements, ce que
ne fera jamais un
truc comme OpenMP puisqu'il ne peut au mieux que contrôler ce qui se
passe dans son processus (pour ne pas dire son fil d'exécution).
"JKB" a écrit dans le message de news:
T'es admin Windows ?
Non, et je n'ai jamais prétendu cela. J'ai juste bossé sur un projet
avec un administrateur Windows _confirmé_,
Que n'as-tu pas fait dans ta vie ?
"JKB" <jkb@koenigsberg.invalid> a écrit dans le message de news:
slrnisn5h5.5cc.jkb@rayleigh.systella.fr
T'es admin Windows ?
Non, et je n'ai jamais prétendu cela. J'ai juste bossé sur un projet
avec un administrateur Windows _confirmé_,
Que n'as-tu pas fait dans ta vie ?
"JKB" a écrit dans le message de news:
T'es admin Windows ?
Non, et je n'ai jamais prétendu cela. J'ai juste bossé sur un projet
avec un administrateur Windows _confirmé_,
Que n'as-tu pas fait dans ta vie ?
Le Thu, 12 May 2011 23:23:54 +0200,
pehache-olino écrivait :"JKB" a écrit dans le message de news:
T'es admin Windows ?
Non, et je n'ai jamais prétendu cela. J'ai juste bossé sur un projet
avec un administrateur Windows _confirmé_,
Que n'as-tu pas fait dans ta vie ?
Des tas de choses. Et lorsque je ne connais pas un sujet,
contrairement à toi, je ferme ma gueule.
JKB
Le Thu, 12 May 2011 23:23:54 +0200,
pehache-olino <pehache.7@gmail.com> écrivait :
"JKB" <jkb@koenigsberg.invalid> a écrit dans le message de news:
slrnisn5h5.5cc.jkb@rayleigh.systella.fr
T'es admin Windows ?
Non, et je n'ai jamais prétendu cela. J'ai juste bossé sur un projet
avec un administrateur Windows _confirmé_,
Que n'as-tu pas fait dans ta vie ?
Des tas de choses. Et lorsque je ne connais pas un sujet,
contrairement à toi, je ferme ma gueule.
JKB
Le Thu, 12 May 2011 23:23:54 +0200,
pehache-olino écrivait :"JKB" a écrit dans le message de news:
T'es admin Windows ?
Non, et je n'ai jamais prétendu cela. J'ai juste bossé sur un projet
avec un administrateur Windows _confirmé_,
Que n'as-tu pas fait dans ta vie ?
Des tas de choses. Et lorsque je ne connais pas un sujet,
contrairement à toi, je ferme ma gueule.
JKB
"JKB" a écrit dans le message de news:
Écoute, mon grand. En 1995, on simulait des amplificateurs
hyperfréquence sur des SS20 qui tournaient avec deux processeurs à
75 MHz, 64 Mo, en un temps qui ferait rougir les machines actuelles.
Ah, le même algo ne pourrait pas tourner sur les machines actuelles ?
Si,
Et il tournerait moins vite ?
mais il faudrait juste garder les softs qui tournaient avec
Solaris 2.4 ou 2.5 et essayer de les faire tourner sous 2.10 (à
moins qu'il ne s'agisse de 5.10). Les outils en question, rigolo, ne
sont plus supportés depuis belle lurette, ce qui pose des problèmes !
Et tu prétends que l'équivalent d'aujourd'hui tourne moins vite pour faire
la même chose, sur des machines 100 fois plus puissantes ? Tu oses tout,
toi...
La différence est toute conne. La programmation était un tout petit
peu optimisée et aujourd'hui, ce qui n'est plus le cas aujourd'hui.
En 1995, on utilisait des routeurs de type Orcad qui tournait sous
MS-DOS, sur des PC qui avaient au mieux 2 Mo de mémoire. Essaie de
prendre une carte de l'époque et de le router avec une version
moderne du même Orcad. On se contrefiche actuellement des ressources
consommées en partant du principe que l'utilisateur n'a qu'à acheter
une barrette mémoire supplémentaire voire un autre processeur ou une
autre machine. C'est idiot dans l'immense majorité des cas.
Et juste pour rire, combien coûtait une SS20 bipro en 1995 ?
Au tarif éducation ou laboratoire ? 17 000 FF de l'époque, soit une
fois et demi le prox d'un PC tout juste correct de la même époque.
Si je retrouve une facture, je te la scanne rien que pour toi.
C'est curieux, mais sur cet article de 1995, la SS20 la moins chère est
listée à 17000$ (et même pas sûr que c'est un modèle bipro, ça) :
http://www.thefreelibrary.com/Sun+announces+fastest+SPARCstation+20,+SPARCserver+20%3B+Reduces+prices...-a017545302
Faut-il en déduire que tu racontes vraiment n'importe quoi ??
Après tout, en
optimisant encore plus ton code il aurait pu tourner aussi vite (et
même plus vite, hein...) sur un PC bien moins cher et avc 640Ko de
RAM.
Pas de réponse à ça ?
Pourquoi tu n'utilisais pas un PC à 5000FF plutôt qu'une luxueuse SS20 ?
Et je t'arrête tout de suite, je n'ai pas dit que c'était mieux il y
a quinze ans ou mieux aujourd'hui. Mon discours est simplement
qu'aujourd'hui, on se contrefiche éperdument de la consommation des
ressources.
Non, on ne s'en fiche pas. Simplement, comme la RAM ou le disque
coûtent 1000 fois moins cher qu'il y a 15 ans, les contraintes ne
sont plus du tout aux mêmes endroits.
Non, on s'en _contrefiche_. On s'en contrefiche même tellement bien
qu'on écrit des bouts d'OS en Java. On utilise des langages objets
(à ramasse-miette pour couronner le tout) un peu partout. C'est
antinomique avec l'économie de ressources. Mais tu risques encore de
ne pas comprendre pourquoi.
En gros tu essaies de dire qu'il faut économiser une ressource abondante.
Et excuse-moi, mais tu n'es pas ce que j'appelle un matheux (sauf si
connaître l'existence des matrices de corrélation fait le
matheux...).
Tu n'as jamais regardé de près ce que j'avais déjà pondu. De toute
façon, tu risquerais fort de ne rien comprendre.
Ah mais si, j'ai lu. Et je n'ai pas eu de difficulté pour comprendre le
contenu mathématique (ce n'est pas de la rocket science).
Il y a des papiers
de mon cru dans diverses revues et conférences, je te laisse
chercher.
Charlot, tu as publié en tout et pour tout un article dans une revue, que tu
décliné ensuite dans une conférence. Plus une autre conférence pour ton
RPL/2. Point final.
Ils ont une dizaine d'années, mais ne t'en fait pas, j'ai
continué mes travaux, mais pour des laboratoires de grands groupes
qui ne publient pas forcément (mais qui déposent des brevets).
Ha ha , l'excuse bidon par excellence :-)
Les groupes privés ont deux politiques pour la communication de leur R&D :
il y a ceux qui brevètent et qui publient (ou du moins qui laissent leurs
chercheurs publier), et il y a ceux qui ne brevètent pas et qui ne publient
pas (pour que rien ne sorte). Tu viens d'inventer ceux qui brevètent et ne
publient pas... Toujours aussi original.
Nicolas George en est un (pour ce que j'en vois), mais pas toi (ni
moi).3/ Ça fait plus de quinze ans que j'écris des specs de langages et
que j'implante les interprètes et compilateurs de ces langages.
Une de tes nombreuses activités, on sait...
Non, c'est mon activité principale ne t'en déplaise.
C'est en contradiction complète avec ton CV.
J'écris des
specs de langages adaptés à certains problèmes de calcul
scientifique. Et ça a un immense avantage, une fois que le langage
est spécifié, le programme de résolution du problème initiale ne
change plus et l'optimisation se fait dans le langage et plus dans
l'algorithme lui-même. Rassure-toi, je ne réinvente pas la roue à
chaque fois.
Tu penses réellement que tu es crédible ??
En effet. Disons que tu utilises des appels système, plutôt. Qui
sont tout sauf nécessaire en calcul scientifique. Il y a
suffisamment de bibliothèques de haut niveau qui évitent d'y avoir
recours. Entre MPI et OpenMP il y a tout ce qu'il faut pour le
parallélisme en calcul scientifique par exemple,
OpenMP est une merde dans le cas général, mais je ne vais pas passer
du temps à t'expliquer pourquoi. Au fait, ce n'est pas moi qui le
prétends, c'est expliqué sur les listes de diffusion du truc par les
concepteurs d'OpenMP.
Un 4x4 c'est une merde dans le cas général
Une Lamborghini c'est une merde dans le cas général
Un camion c'est une merde dans le cas général
Mais si tu as besoin de parcourir une piste forestière boueuse, un 4X4 c'est
bien.
Si tu veux t'éclater sur une autoroute allemande, une Lamborghini c'est
bien. (*)
Si tu veux déménager, un camion c'est bien.
Bref, personne n'a jamais dit que OpenMP était un outil miracle, qui savait
tout faire, ou qui était adapté à tous les problèmes de parallélisation.
Mais utilisé dans son domaine d'application, OpenMP c'est bien. Et son
domaine d'application recouvre une très grosse partie du calcul scientique.
Encore une fois tu enfonces des portes ouvertes.
Dit autrement pour toi, OpenMP fait que c'est
intéressant dans le cas d'un calcul parallélisable au niveau
atomique qui tourne seul sur une machine à plusieurs voies. Je te
laisse conclure.
J'en conclus que ce que tu racontes est sans queue ni tête. Des mots
jargonnants mis les uns à la suite des autres pour impressionner le
chaland...
Juste par exemple : on fait couramment tourner plusieurs process différents,
chacun étant multithreadé par OpenMP, sur une seule machine. Donc déjà, avec
"qui tourne seul", tu es à côté de la plaque.
Mais en fait je dirais même qu'il ne faut pas non d'informaticiens
contrariés, qui ont toujours la tentation d'aller optimiser ceci ou
cela en bas niveau et de réinventer l'eau tiède au lieu de se
concentrer sur le contenu algorithmique.
Ahahahahahahahahaha ! Il y a des tas de problèmes NP-complets en
analyse numérique dont les algorithmes sont parfaitement connus. On
sait même pour certains donner une borne maximale au temps de
résolution. Le problème est qu'on ne peut pas les implanter parce
qu'il n'existe pas de langage permettant de le faire correctement,
soit parce que la parallélisation est foireuse (cas MPI ou OpenMP),
soit parce que les bibliothèques de haut niveau sont trivialement
sous-optimales. Aujourd'hui, le problème n'est pas tant l'algorithmie
que la façon d'implanter ces algorithmes de façon un tant soit peu
intelligente. Séparer l'un de l'autre est juste risible. Et séparer
l'implantation des limitations du matériel est aussi risible
puisqu'il faut limiter au maximum les goulets d'étranglements, ce que
ne fera jamais un
truc comme OpenMP puisqu'il ne peut au mieux que contrôler ce qui se
passe dans son processus (pour ne pas dire son fil d'exécution).
Bis...
Mais bon, je crois que j'avais déjà tout dit te concernant ici :
http://groups.google.com/group/fr.comp.os.linux.debats/tree/browse_frm/thread/dcbdaaab7caa50da/bba1bb3dfd9a67fd?rnum&_done=%2Fgroup%2Ffr.comp.os.linux.debats%2Fbrowse_frm%2Fthread%2Fdcbdaaab7caa50da%2F84b34d6a2c96cb00%3Fq%3Dpehache%2Bjkb%2Bfouill%25C3%25A9%2Barticles%26#doc_26c61526217498f7
"JKB" <jkb@koenigsberg.invalid> a écrit dans le message de news:
slrnisn6jr.5cc.jkb@rayleigh.systella.fr
Écoute, mon grand. En 1995, on simulait des amplificateurs
hyperfréquence sur des SS20 qui tournaient avec deux processeurs à
75 MHz, 64 Mo, en un temps qui ferait rougir les machines actuelles.
Ah, le même algo ne pourrait pas tourner sur les machines actuelles ?
Si,
Et il tournerait moins vite ?
mais il faudrait juste garder les softs qui tournaient avec
Solaris 2.4 ou 2.5 et essayer de les faire tourner sous 2.10 (à
moins qu'il ne s'agisse de 5.10). Les outils en question, rigolo, ne
sont plus supportés depuis belle lurette, ce qui pose des problèmes !
Et tu prétends que l'équivalent d'aujourd'hui tourne moins vite pour faire
la même chose, sur des machines 100 fois plus puissantes ? Tu oses tout,
toi...
La différence est toute conne. La programmation était un tout petit
peu optimisée et aujourd'hui, ce qui n'est plus le cas aujourd'hui.
En 1995, on utilisait des routeurs de type Orcad qui tournait sous
MS-DOS, sur des PC qui avaient au mieux 2 Mo de mémoire. Essaie de
prendre une carte de l'époque et de le router avec une version
moderne du même Orcad. On se contrefiche actuellement des ressources
consommées en partant du principe que l'utilisateur n'a qu'à acheter
une barrette mémoire supplémentaire voire un autre processeur ou une
autre machine. C'est idiot dans l'immense majorité des cas.
Et juste pour rire, combien coûtait une SS20 bipro en 1995 ?
Au tarif éducation ou laboratoire ? 17 000 FF de l'époque, soit une
fois et demi le prox d'un PC tout juste correct de la même époque.
Si je retrouve une facture, je te la scanne rien que pour toi.
C'est curieux, mais sur cet article de 1995, la SS20 la moins chère est
listée à 17000$ (et même pas sûr que c'est un modèle bipro, ça) :
http://www.thefreelibrary.com/Sun+announces+fastest+SPARCstation+20,+SPARCserver+20%3B+Reduces+prices...-a017545302
Faut-il en déduire que tu racontes vraiment n'importe quoi ??
Après tout, en
optimisant encore plus ton code il aurait pu tourner aussi vite (et
même plus vite, hein...) sur un PC bien moins cher et avc 640Ko de
RAM.
Pas de réponse à ça ?
Pourquoi tu n'utilisais pas un PC à 5000FF plutôt qu'une luxueuse SS20 ?
Et je t'arrête tout de suite, je n'ai pas dit que c'était mieux il y
a quinze ans ou mieux aujourd'hui. Mon discours est simplement
qu'aujourd'hui, on se contrefiche éperdument de la consommation des
ressources.
Non, on ne s'en fiche pas. Simplement, comme la RAM ou le disque
coûtent 1000 fois moins cher qu'il y a 15 ans, les contraintes ne
sont plus du tout aux mêmes endroits.
Non, on s'en _contrefiche_. On s'en contrefiche même tellement bien
qu'on écrit des bouts d'OS en Java. On utilise des langages objets
(à ramasse-miette pour couronner le tout) un peu partout. C'est
antinomique avec l'économie de ressources. Mais tu risques encore de
ne pas comprendre pourquoi.
En gros tu essaies de dire qu'il faut économiser une ressource abondante.
Et excuse-moi, mais tu n'es pas ce que j'appelle un matheux (sauf si
connaître l'existence des matrices de corrélation fait le
matheux...).
Tu n'as jamais regardé de près ce que j'avais déjà pondu. De toute
façon, tu risquerais fort de ne rien comprendre.
Ah mais si, j'ai lu. Et je n'ai pas eu de difficulté pour comprendre le
contenu mathématique (ce n'est pas de la rocket science).
Il y a des papiers
de mon cru dans diverses revues et conférences, je te laisse
chercher.
Charlot, tu as publié en tout et pour tout un article dans une revue, que tu
décliné ensuite dans une conférence. Plus une autre conférence pour ton
RPL/2. Point final.
Ils ont une dizaine d'années, mais ne t'en fait pas, j'ai
continué mes travaux, mais pour des laboratoires de grands groupes
qui ne publient pas forcément (mais qui déposent des brevets).
Ha ha , l'excuse bidon par excellence :-)
Les groupes privés ont deux politiques pour la communication de leur R&D :
il y a ceux qui brevètent et qui publient (ou du moins qui laissent leurs
chercheurs publier), et il y a ceux qui ne brevètent pas et qui ne publient
pas (pour que rien ne sorte). Tu viens d'inventer ceux qui brevètent et ne
publient pas... Toujours aussi original.
Nicolas George en est un (pour ce que j'en vois), mais pas toi (ni
moi).
3/ Ça fait plus de quinze ans que j'écris des specs de langages et
que j'implante les interprètes et compilateurs de ces langages.
Une de tes nombreuses activités, on sait...
Non, c'est mon activité principale ne t'en déplaise.
C'est en contradiction complète avec ton CV.
J'écris des
specs de langages adaptés à certains problèmes de calcul
scientifique. Et ça a un immense avantage, une fois que le langage
est spécifié, le programme de résolution du problème initiale ne
change plus et l'optimisation se fait dans le langage et plus dans
l'algorithme lui-même. Rassure-toi, je ne réinvente pas la roue à
chaque fois.
Tu penses réellement que tu es crédible ??
En effet. Disons que tu utilises des appels système, plutôt. Qui
sont tout sauf nécessaire en calcul scientifique. Il y a
suffisamment de bibliothèques de haut niveau qui évitent d'y avoir
recours. Entre MPI et OpenMP il y a tout ce qu'il faut pour le
parallélisme en calcul scientifique par exemple,
OpenMP est une merde dans le cas général, mais je ne vais pas passer
du temps à t'expliquer pourquoi. Au fait, ce n'est pas moi qui le
prétends, c'est expliqué sur les listes de diffusion du truc par les
concepteurs d'OpenMP.
Un 4x4 c'est une merde dans le cas général
Une Lamborghini c'est une merde dans le cas général
Un camion c'est une merde dans le cas général
Mais si tu as besoin de parcourir une piste forestière boueuse, un 4X4 c'est
bien.
Si tu veux t'éclater sur une autoroute allemande, une Lamborghini c'est
bien. (*)
Si tu veux déménager, un camion c'est bien.
Bref, personne n'a jamais dit que OpenMP était un outil miracle, qui savait
tout faire, ou qui était adapté à tous les problèmes de parallélisation.
Mais utilisé dans son domaine d'application, OpenMP c'est bien. Et son
domaine d'application recouvre une très grosse partie du calcul scientique.
Encore une fois tu enfonces des portes ouvertes.
Dit autrement pour toi, OpenMP fait que c'est
intéressant dans le cas d'un calcul parallélisable au niveau
atomique qui tourne seul sur une machine à plusieurs voies. Je te
laisse conclure.
J'en conclus que ce que tu racontes est sans queue ni tête. Des mots
jargonnants mis les uns à la suite des autres pour impressionner le
chaland...
Juste par exemple : on fait couramment tourner plusieurs process différents,
chacun étant multithreadé par OpenMP, sur une seule machine. Donc déjà, avec
"qui tourne seul", tu es à côté de la plaque.
Mais en fait je dirais même qu'il ne faut pas non d'informaticiens
contrariés, qui ont toujours la tentation d'aller optimiser ceci ou
cela en bas niveau et de réinventer l'eau tiède au lieu de se
concentrer sur le contenu algorithmique.
Ahahahahahahahahaha ! Il y a des tas de problèmes NP-complets en
analyse numérique dont les algorithmes sont parfaitement connus. On
sait même pour certains donner une borne maximale au temps de
résolution. Le problème est qu'on ne peut pas les implanter parce
qu'il n'existe pas de langage permettant de le faire correctement,
soit parce que la parallélisation est foireuse (cas MPI ou OpenMP),
soit parce que les bibliothèques de haut niveau sont trivialement
sous-optimales. Aujourd'hui, le problème n'est pas tant l'algorithmie
que la façon d'implanter ces algorithmes de façon un tant soit peu
intelligente. Séparer l'un de l'autre est juste risible. Et séparer
l'implantation des limitations du matériel est aussi risible
puisqu'il faut limiter au maximum les goulets d'étranglements, ce que
ne fera jamais un
truc comme OpenMP puisqu'il ne peut au mieux que contrôler ce qui se
passe dans son processus (pour ne pas dire son fil d'exécution).
Bis...
Mais bon, je crois que j'avais déjà tout dit te concernant ici :
http://groups.google.com/group/fr.comp.os.linux.debats/tree/browse_frm/thread/dcbdaaab7caa50da/bba1bb3dfd9a67fd?rnum&_done=%2Fgroup%2Ffr.comp.os.linux.debats%2Fbrowse_frm%2Fthread%2Fdcbdaaab7caa50da%2F84b34d6a2c96cb00%3Fq%3Dpehache%2Bjkb%2Bfouill%25C3%25A9%2Barticles%26#doc_26c61526217498f7
"JKB" a écrit dans le message de news:
Écoute, mon grand. En 1995, on simulait des amplificateurs
hyperfréquence sur des SS20 qui tournaient avec deux processeurs à
75 MHz, 64 Mo, en un temps qui ferait rougir les machines actuelles.
Ah, le même algo ne pourrait pas tourner sur les machines actuelles ?
Si,
Et il tournerait moins vite ?
mais il faudrait juste garder les softs qui tournaient avec
Solaris 2.4 ou 2.5 et essayer de les faire tourner sous 2.10 (à
moins qu'il ne s'agisse de 5.10). Les outils en question, rigolo, ne
sont plus supportés depuis belle lurette, ce qui pose des problèmes !
Et tu prétends que l'équivalent d'aujourd'hui tourne moins vite pour faire
la même chose, sur des machines 100 fois plus puissantes ? Tu oses tout,
toi...
La différence est toute conne. La programmation était un tout petit
peu optimisée et aujourd'hui, ce qui n'est plus le cas aujourd'hui.
En 1995, on utilisait des routeurs de type Orcad qui tournait sous
MS-DOS, sur des PC qui avaient au mieux 2 Mo de mémoire. Essaie de
prendre une carte de l'époque et de le router avec une version
moderne du même Orcad. On se contrefiche actuellement des ressources
consommées en partant du principe que l'utilisateur n'a qu'à acheter
une barrette mémoire supplémentaire voire un autre processeur ou une
autre machine. C'est idiot dans l'immense majorité des cas.
Et juste pour rire, combien coûtait une SS20 bipro en 1995 ?
Au tarif éducation ou laboratoire ? 17 000 FF de l'époque, soit une
fois et demi le prox d'un PC tout juste correct de la même époque.
Si je retrouve une facture, je te la scanne rien que pour toi.
C'est curieux, mais sur cet article de 1995, la SS20 la moins chère est
listée à 17000$ (et même pas sûr que c'est un modèle bipro, ça) :
http://www.thefreelibrary.com/Sun+announces+fastest+SPARCstation+20,+SPARCserver+20%3B+Reduces+prices...-a017545302
Faut-il en déduire que tu racontes vraiment n'importe quoi ??
Après tout, en
optimisant encore plus ton code il aurait pu tourner aussi vite (et
même plus vite, hein...) sur un PC bien moins cher et avc 640Ko de
RAM.
Pas de réponse à ça ?
Pourquoi tu n'utilisais pas un PC à 5000FF plutôt qu'une luxueuse SS20 ?
Et je t'arrête tout de suite, je n'ai pas dit que c'était mieux il y
a quinze ans ou mieux aujourd'hui. Mon discours est simplement
qu'aujourd'hui, on se contrefiche éperdument de la consommation des
ressources.
Non, on ne s'en fiche pas. Simplement, comme la RAM ou le disque
coûtent 1000 fois moins cher qu'il y a 15 ans, les contraintes ne
sont plus du tout aux mêmes endroits.
Non, on s'en _contrefiche_. On s'en contrefiche même tellement bien
qu'on écrit des bouts d'OS en Java. On utilise des langages objets
(à ramasse-miette pour couronner le tout) un peu partout. C'est
antinomique avec l'économie de ressources. Mais tu risques encore de
ne pas comprendre pourquoi.
En gros tu essaies de dire qu'il faut économiser une ressource abondante.
Et excuse-moi, mais tu n'es pas ce que j'appelle un matheux (sauf si
connaître l'existence des matrices de corrélation fait le
matheux...).
Tu n'as jamais regardé de près ce que j'avais déjà pondu. De toute
façon, tu risquerais fort de ne rien comprendre.
Ah mais si, j'ai lu. Et je n'ai pas eu de difficulté pour comprendre le
contenu mathématique (ce n'est pas de la rocket science).
Il y a des papiers
de mon cru dans diverses revues et conférences, je te laisse
chercher.
Charlot, tu as publié en tout et pour tout un article dans une revue, que tu
décliné ensuite dans une conférence. Plus une autre conférence pour ton
RPL/2. Point final.
Ils ont une dizaine d'années, mais ne t'en fait pas, j'ai
continué mes travaux, mais pour des laboratoires de grands groupes
qui ne publient pas forcément (mais qui déposent des brevets).
Ha ha , l'excuse bidon par excellence :-)
Les groupes privés ont deux politiques pour la communication de leur R&D :
il y a ceux qui brevètent et qui publient (ou du moins qui laissent leurs
chercheurs publier), et il y a ceux qui ne brevètent pas et qui ne publient
pas (pour que rien ne sorte). Tu viens d'inventer ceux qui brevètent et ne
publient pas... Toujours aussi original.
Nicolas George en est un (pour ce que j'en vois), mais pas toi (ni
moi).3/ Ça fait plus de quinze ans que j'écris des specs de langages et
que j'implante les interprètes et compilateurs de ces langages.
Une de tes nombreuses activités, on sait...
Non, c'est mon activité principale ne t'en déplaise.
C'est en contradiction complète avec ton CV.
J'écris des
specs de langages adaptés à certains problèmes de calcul
scientifique. Et ça a un immense avantage, une fois que le langage
est spécifié, le programme de résolution du problème initiale ne
change plus et l'optimisation se fait dans le langage et plus dans
l'algorithme lui-même. Rassure-toi, je ne réinvente pas la roue à
chaque fois.
Tu penses réellement que tu es crédible ??
En effet. Disons que tu utilises des appels système, plutôt. Qui
sont tout sauf nécessaire en calcul scientifique. Il y a
suffisamment de bibliothèques de haut niveau qui évitent d'y avoir
recours. Entre MPI et OpenMP il y a tout ce qu'il faut pour le
parallélisme en calcul scientifique par exemple,
OpenMP est une merde dans le cas général, mais je ne vais pas passer
du temps à t'expliquer pourquoi. Au fait, ce n'est pas moi qui le
prétends, c'est expliqué sur les listes de diffusion du truc par les
concepteurs d'OpenMP.
Un 4x4 c'est une merde dans le cas général
Une Lamborghini c'est une merde dans le cas général
Un camion c'est une merde dans le cas général
Mais si tu as besoin de parcourir une piste forestière boueuse, un 4X4 c'est
bien.
Si tu veux t'éclater sur une autoroute allemande, une Lamborghini c'est
bien. (*)
Si tu veux déménager, un camion c'est bien.
Bref, personne n'a jamais dit que OpenMP était un outil miracle, qui savait
tout faire, ou qui était adapté à tous les problèmes de parallélisation.
Mais utilisé dans son domaine d'application, OpenMP c'est bien. Et son
domaine d'application recouvre une très grosse partie du calcul scientique.
Encore une fois tu enfonces des portes ouvertes.
Dit autrement pour toi, OpenMP fait que c'est
intéressant dans le cas d'un calcul parallélisable au niveau
atomique qui tourne seul sur une machine à plusieurs voies. Je te
laisse conclure.
J'en conclus que ce que tu racontes est sans queue ni tête. Des mots
jargonnants mis les uns à la suite des autres pour impressionner le
chaland...
Juste par exemple : on fait couramment tourner plusieurs process différents,
chacun étant multithreadé par OpenMP, sur une seule machine. Donc déjà, avec
"qui tourne seul", tu es à côté de la plaque.
Mais en fait je dirais même qu'il ne faut pas non d'informaticiens
contrariés, qui ont toujours la tentation d'aller optimiser ceci ou
cela en bas niveau et de réinventer l'eau tiède au lieu de se
concentrer sur le contenu algorithmique.
Ahahahahahahahahaha ! Il y a des tas de problèmes NP-complets en
analyse numérique dont les algorithmes sont parfaitement connus. On
sait même pour certains donner une borne maximale au temps de
résolution. Le problème est qu'on ne peut pas les implanter parce
qu'il n'existe pas de langage permettant de le faire correctement,
soit parce que la parallélisation est foireuse (cas MPI ou OpenMP),
soit parce que les bibliothèques de haut niveau sont trivialement
sous-optimales. Aujourd'hui, le problème n'est pas tant l'algorithmie
que la façon d'implanter ces algorithmes de façon un tant soit peu
intelligente. Séparer l'un de l'autre est juste risible. Et séparer
l'implantation des limitations du matériel est aussi risible
puisqu'il faut limiter au maximum les goulets d'étranglements, ce que
ne fera jamais un
truc comme OpenMP puisqu'il ne peut au mieux que contrôler ce qui se
passe dans son processus (pour ne pas dire son fil d'exécution).
Bis...
Mais bon, je crois que j'avais déjà tout dit te concernant ici :
http://groups.google.com/group/fr.comp.os.linux.debats/tree/browse_frm/thread/dcbdaaab7caa50da/bba1bb3dfd9a67fd?rnum&_done=%2Fgroup%2Ffr.comp.os.linux.debats%2Fbrowse_frm%2Fthread%2Fdcbdaaab7caa50da%2F84b34d6a2c96cb00%3Fq%3Dpehache%2Bjkb%2Bfouill%25C3%25A9%2Barticles%26#doc_26c61526217498f7
lorsque je ne connais pas un sujet,
contrairement à toi, je ferme ma gueule.
mwhahahaha !!
lorsque je ne connais pas un sujet,
contrairement à toi, je ferme ma gueule.
mwhahahaha !!
lorsque je ne connais pas un sujet,
contrairement à toi, je ferme ma gueule.
mwhahahaha !!
Le Fri, 13 May 2011 09:31:58 +0200, *.-pipolin-.* a écrit :lorsque je ne connais pas un sujet,
contrairement à toi, je ferme ma gueule.mwhahahaha !!
si pipedeprodolin se tenait à cette logique, il serait muet.
Le Fri, 13 May 2011 09:31:58 +0200, *.-pipolin-.* a écrit :
lorsque je ne connais pas un sujet,
contrairement à toi, je ferme ma gueule.
mwhahahaha !!
si pipedeprodolin se tenait à cette logique, il serait muet.
Le Fri, 13 May 2011 09:31:58 +0200, *.-pipolin-.* a écrit :lorsque je ne connais pas un sujet,
contrairement à toi, je ferme ma gueule.mwhahahaha !!
si pipedeprodolin se tenait à cette logique, il serait muet.
ma logique, elle m'amène a faire partie de ce monde la:
http://envoye-special.france2.fr/les-reportages-en-video/le-cinema-de-
pendant que tu baves,
je fais...
ma logique, elle m'amène a faire partie de ce monde la:
http://envoye-special.france2.fr/les-reportages-en-video/le-cinema-de-
pendant que tu baves,
je fais...
ma logique, elle m'amène a faire partie de ce monde la:
http://envoye-special.france2.fr/les-reportages-en-video/le-cinema-de-
pendant que tu baves,
je fais...
Pourquoi tu n'utilisais pas un PC à 5000FF plutôt qu'une luxueuse SS20 ?
Parce que Libra ne tournait pas sous Dos, ça te va comme réponse ?
Je ne réponds pas à toutes tes conneries parce tes répliques sont
souvent idiotes.
Pourquoi tu n'utilisais pas un PC à 5000FF plutôt qu'une luxueuse SS20 ?
Parce que Libra ne tournait pas sous Dos, ça te va comme réponse ?
Je ne réponds pas à toutes tes conneries parce tes répliques sont
souvent idiotes.
Pourquoi tu n'utilisais pas un PC à 5000FF plutôt qu'une luxueuse SS20 ?
Parce que Libra ne tournait pas sous Dos, ça te va comme réponse ?
Je ne réponds pas à toutes tes conneries parce tes répliques sont
souvent idiotes.
Le Thu, 12 May 2011 23:23:54 +0200,
pehache-olino écrivait :"JKB" a écrit dans le message de news:
T'es admin Windows ?
Non, et je n'ai jamais prétendu cela. J'ai juste bossé sur un projet
avec un administrateur Windows _confirmé_,
Que n'as-tu pas fait dans ta vie ?
Des tas de choses. Et lorsque je ne connais pas un sujet,
contrairement à toi, je ferme ma gueule.
Le Thu, 12 May 2011 23:23:54 +0200,
pehache-olino <pehache.7@gmail.com> écrivait :
"JKB" <jkb@koenigsberg.invalid> a écrit dans le message de news:
slrnisn5h5.5cc.jkb@rayleigh.systella.fr
T'es admin Windows ?
Non, et je n'ai jamais prétendu cela. J'ai juste bossé sur un projet
avec un administrateur Windows _confirmé_,
Que n'as-tu pas fait dans ta vie ?
Des tas de choses. Et lorsque je ne connais pas un sujet,
contrairement à toi, je ferme ma gueule.
Le Thu, 12 May 2011 23:23:54 +0200,
pehache-olino écrivait :"JKB" a écrit dans le message de news:
T'es admin Windows ?
Non, et je n'ai jamais prétendu cela. J'ai juste bossé sur un projet
avec un administrateur Windows _confirmé_,
Que n'as-tu pas fait dans ta vie ?
Des tas de choses. Et lorsque je ne connais pas un sujet,
contrairement à toi, je ferme ma gueule.