Le 27/03/11 23:16, JKB a écrit :Le Sun, 27 Mar 2011 23:00:22 +0200,
Jerome Lambert écrivait :Le 27/03/11 22:03, Aéris a écrit :Le 27/03/2011 21:33, pehache-olino a écrit :C'est peut-être idiot, mais on a déjà des sites qui ont basculé sur ce
mode de fonctionnement (dont un depuis plusieurs années en fait, à cause
d'une spécificité locale), et le fait est que ça donne satisfaction (les
utilisateurs ne s'en plaignent pas). En réalité sur certains points
c'est même mieux qu'avant. On manipule des gros volumes de données qui
sont sur des serveurs; l'affichage de ces données avec une appli
tournant en local nécessite la lecture de ces données à travers le
réseau, ce qui le sature très vite. Ne faire passer que l'affichage
charge finalement moins le réseau et c'est plus rapide (ce n'est pas une
projection, c'est un fait).
On en arrive donc exactement à ce qu'on disait au tout début: Windows ne
sert qu'à un seul truc, servir de serveur X
Ça fait cher le serveur X et la quantité de truc inutile quand même…
Non, puisque qu'avec un "bête" terminal X, il serait limité aux
applications spécifiques. Avec la solution utilisée il y a Windows pour
les applications génériques et un accès via un serveur X pour les
applications spécifiques. Le meilleur des deux mondes, en fait.
Explique-moi sans rigoler ce qui ferait qu'il serait impossible de
faire tourner un bête traitement de texte sur un TX ?
Ça dépend ce que tu appelles "bête traitement de texte". Si c'est pour
faire tourner la suite MS-Office, c'est pas gagné.
Le 27/03/11 23:16, JKB a écrit :
Le Sun, 27 Mar 2011 23:00:22 +0200,
Jerome Lambert<jerome.lambert@swing.be> écrivait :
Le 27/03/11 22:03, Aéris a écrit :
Le 27/03/2011 21:33, pehache-olino a écrit :
C'est peut-être idiot, mais on a déjà des sites qui ont basculé sur ce
mode de fonctionnement (dont un depuis plusieurs années en fait, à cause
d'une spécificité locale), et le fait est que ça donne satisfaction (les
utilisateurs ne s'en plaignent pas). En réalité sur certains points
c'est même mieux qu'avant. On manipule des gros volumes de données qui
sont sur des serveurs; l'affichage de ces données avec une appli
tournant en local nécessite la lecture de ces données à travers le
réseau, ce qui le sature très vite. Ne faire passer que l'affichage
charge finalement moins le réseau et c'est plus rapide (ce n'est pas une
projection, c'est un fait).
On en arrive donc exactement à ce qu'on disait au tout début: Windows ne
sert qu'à un seul truc, servir de serveur X
Ça fait cher le serveur X et la quantité de truc inutile quand même…
Non, puisque qu'avec un "bête" terminal X, il serait limité aux
applications spécifiques. Avec la solution utilisée il y a Windows pour
les applications génériques et un accès via un serveur X pour les
applications spécifiques. Le meilleur des deux mondes, en fait.
Explique-moi sans rigoler ce qui ferait qu'il serait impossible de
faire tourner un bête traitement de texte sur un TX ?
Ça dépend ce que tu appelles "bête traitement de texte". Si c'est pour
faire tourner la suite MS-Office, c'est pas gagné.
Le 27/03/11 23:16, JKB a écrit :Le Sun, 27 Mar 2011 23:00:22 +0200,
Jerome Lambert écrivait :Le 27/03/11 22:03, Aéris a écrit :Le 27/03/2011 21:33, pehache-olino a écrit :C'est peut-être idiot, mais on a déjà des sites qui ont basculé sur ce
mode de fonctionnement (dont un depuis plusieurs années en fait, à cause
d'une spécificité locale), et le fait est que ça donne satisfaction (les
utilisateurs ne s'en plaignent pas). En réalité sur certains points
c'est même mieux qu'avant. On manipule des gros volumes de données qui
sont sur des serveurs; l'affichage de ces données avec une appli
tournant en local nécessite la lecture de ces données à travers le
réseau, ce qui le sature très vite. Ne faire passer que l'affichage
charge finalement moins le réseau et c'est plus rapide (ce n'est pas une
projection, c'est un fait).
On en arrive donc exactement à ce qu'on disait au tout début: Windows ne
sert qu'à un seul truc, servir de serveur X
Ça fait cher le serveur X et la quantité de truc inutile quand même…
Non, puisque qu'avec un "bête" terminal X, il serait limité aux
applications spécifiques. Avec la solution utilisée il y a Windows pour
les applications génériques et un accès via un serveur X pour les
applications spécifiques. Le meilleur des deux mondes, en fait.
Explique-moi sans rigoler ce qui ferait qu'il serait impossible de
faire tourner un bête traitement de texte sur un TX ?
Ça dépend ce que tu appelles "bête traitement de texte". Si c'est pour
faire tourner la suite MS-Office, c'est pas gagné.
Je te signale que c'est à peu près partout comme ça, de nos jours.
Et ça ne change strictement rien au fait qu'engager un
administrateur même de poste clients est moins cher et plus pérenne
pour une entreprise. Je n'ai encore jamais vu de prestataires
prétendûment là pour faire de l'administration de postes clients à
la hauteur des attentes. Et le tarif est inversement proportionnel
aux compétences des types.
C'est peut-être idiot, mais on a déjà des sites qui ont basculé sur
ce mode de fonctionnement (dont un depuis plusieurs années en fait,
à cause d'une spécificité locale), et le fait est que ça donne
satisfaction (les utilisateurs ne s'en plaignent pas).
Que les utilisateurs ne se plaignent pas n'est pas un critère. J'ai
actuellement devant moi un pool de développeurs qui utilisent Visual
Studio 2010 pour débugguer des problèmes de C++ et c'est totalement
inadapté et idiot. Ils auraient plus vite fait de recompiler leur
truc sous Linux et de passer un coup de valgrind dessus pour
dégrossir. Ils ne se plaignent pas parce qu'il ne savent pas qu'on
peut faire autrement.
En réalité sur certains points c'est
même mieux qu'avant. On manipule des gros volumes de données qui
sont sur des serveurs; l'affichage de ces données avec une appli
tournant en local nécessite la lecture de ces données à travers le
réseau, ce qui le sature très vite.
On en revient au même problème. Couche réseau moisie ou logiciel
moisi. Il y a plus de dix ans, je bossais sur des démodulateurs UMTS
et j'avais des banques de signaux à ma disposition (enfin, sur un
serveur distant). Chaque fichier représentait quelques dizaines de
Go de données et ça passait sur un réseau 10Base2 sans le saturer.
En revanche, en écrivant les outils permettant d'accéder à ces
données, on avait intégré qu'on passait au travers d'un réseau et on
n'avait pas utilisé brutalement les fonctions génériques qui font
qu'on peut attaquer un disque réseau comme s'il était physiquement
sur la machine.
Ne faire passer que l'affichage charge finalement moins le réseau
et c'est plus rapide (ce n'est pas une projection, c'est un fait).
C'est faux dans le cas général.
Je te signale que c'est à peu près partout comme ça, de nos jours.
Et ça ne change strictement rien au fait qu'engager un
administrateur même de poste clients est moins cher et plus pérenne
pour une entreprise. Je n'ai encore jamais vu de prestataires
prétendûment là pour faire de l'administration de postes clients à
la hauteur des attentes. Et le tarif est inversement proportionnel
aux compétences des types.
C'est peut-être idiot, mais on a déjà des sites qui ont basculé sur
ce mode de fonctionnement (dont un depuis plusieurs années en fait,
à cause d'une spécificité locale), et le fait est que ça donne
satisfaction (les utilisateurs ne s'en plaignent pas).
Que les utilisateurs ne se plaignent pas n'est pas un critère. J'ai
actuellement devant moi un pool de développeurs qui utilisent Visual
Studio 2010 pour débugguer des problèmes de C++ et c'est totalement
inadapté et idiot. Ils auraient plus vite fait de recompiler leur
truc sous Linux et de passer un coup de valgrind dessus pour
dégrossir. Ils ne se plaignent pas parce qu'il ne savent pas qu'on
peut faire autrement.
En réalité sur certains points c'est
même mieux qu'avant. On manipule des gros volumes de données qui
sont sur des serveurs; l'affichage de ces données avec une appli
tournant en local nécessite la lecture de ces données à travers le
réseau, ce qui le sature très vite.
On en revient au même problème. Couche réseau moisie ou logiciel
moisi. Il y a plus de dix ans, je bossais sur des démodulateurs UMTS
et j'avais des banques de signaux à ma disposition (enfin, sur un
serveur distant). Chaque fichier représentait quelques dizaines de
Go de données et ça passait sur un réseau 10Base2 sans le saturer.
En revanche, en écrivant les outils permettant d'accéder à ces
données, on avait intégré qu'on passait au travers d'un réseau et on
n'avait pas utilisé brutalement les fonctions génériques qui font
qu'on peut attaquer un disque réseau comme s'il était physiquement
sur la machine.
Ne faire passer que l'affichage charge finalement moins le réseau
et c'est plus rapide (ce n'est pas une projection, c'est un fait).
C'est faux dans le cas général.
Je te signale que c'est à peu près partout comme ça, de nos jours.
Et ça ne change strictement rien au fait qu'engager un
administrateur même de poste clients est moins cher et plus pérenne
pour une entreprise. Je n'ai encore jamais vu de prestataires
prétendûment là pour faire de l'administration de postes clients à
la hauteur des attentes. Et le tarif est inversement proportionnel
aux compétences des types.
C'est peut-être idiot, mais on a déjà des sites qui ont basculé sur
ce mode de fonctionnement (dont un depuis plusieurs années en fait,
à cause d'une spécificité locale), et le fait est que ça donne
satisfaction (les utilisateurs ne s'en plaignent pas).
Que les utilisateurs ne se plaignent pas n'est pas un critère. J'ai
actuellement devant moi un pool de développeurs qui utilisent Visual
Studio 2010 pour débugguer des problèmes de C++ et c'est totalement
inadapté et idiot. Ils auraient plus vite fait de recompiler leur
truc sous Linux et de passer un coup de valgrind dessus pour
dégrossir. Ils ne se plaignent pas parce qu'il ne savent pas qu'on
peut faire autrement.
En réalité sur certains points c'est
même mieux qu'avant. On manipule des gros volumes de données qui
sont sur des serveurs; l'affichage de ces données avec une appli
tournant en local nécessite la lecture de ces données à travers le
réseau, ce qui le sature très vite.
On en revient au même problème. Couche réseau moisie ou logiciel
moisi. Il y a plus de dix ans, je bossais sur des démodulateurs UMTS
et j'avais des banques de signaux à ma disposition (enfin, sur un
serveur distant). Chaque fichier représentait quelques dizaines de
Go de données et ça passait sur un réseau 10Base2 sans le saturer.
En revanche, en écrivant les outils permettant d'accéder à ces
données, on avait intégré qu'on passait au travers d'un réseau et on
n'avait pas utilisé brutalement les fonctions génériques qui font
qu'on peut attaquer un disque réseau comme s'il était physiquement
sur la machine.
Ne faire passer que l'affichage charge finalement moins le réseau
et c'est plus rapide (ce n'est pas une projection, c'est un fait).
C'est faux dans le cas général.
Le 27/03/2011 21:33, pehache-olino a écrit :C'est peut-être idiot, mais on a déjà des sites qui ont basculé sur
ce mode de fonctionnement (dont un depuis plusieurs années en fait,
à cause d'une spécificité locale), et le fait est que ça donne
satisfaction (les utilisateurs ne s'en plaignent pas). En réalité
sur certains points c'est même mieux qu'avant. On manipule des gros
volumes de données qui sont sur des serveurs; l'affichage de ces
données avec une appli tournant en local nécessite la lecture de ces
données à travers le réseau, ce qui le sature très vite. Ne faire
passer que l'affichage charge finalement moins le réseau et c'est
plus rapide (ce n'est pas une projection, c'est un fait).
On en arrive donc exactement à ce qu'on disait au tout début: Windows
ne sert qu'à un seul truc, servir de serveur X
Ça fait cher le serveur X et la quantité de truc inutile quand même…
On fait pareil avec un TX à 30€ sans OS hein…
Le 27/03/2011 21:33, pehache-olino a écrit :
C'est peut-être idiot, mais on a déjà des sites qui ont basculé sur
ce mode de fonctionnement (dont un depuis plusieurs années en fait,
à cause d'une spécificité locale), et le fait est que ça donne
satisfaction (les utilisateurs ne s'en plaignent pas). En réalité
sur certains points c'est même mieux qu'avant. On manipule des gros
volumes de données qui sont sur des serveurs; l'affichage de ces
données avec une appli tournant en local nécessite la lecture de ces
données à travers le réseau, ce qui le sature très vite. Ne faire
passer que l'affichage charge finalement moins le réseau et c'est
plus rapide (ce n'est pas une projection, c'est un fait).
On en arrive donc exactement à ce qu'on disait au tout début: Windows
ne sert qu'à un seul truc, servir de serveur X
Ça fait cher le serveur X et la quantité de truc inutile quand même…
On fait pareil avec un TX à 30€ sans OS hein…
Le 27/03/2011 21:33, pehache-olino a écrit :C'est peut-être idiot, mais on a déjà des sites qui ont basculé sur
ce mode de fonctionnement (dont un depuis plusieurs années en fait,
à cause d'une spécificité locale), et le fait est que ça donne
satisfaction (les utilisateurs ne s'en plaignent pas). En réalité
sur certains points c'est même mieux qu'avant. On manipule des gros
volumes de données qui sont sur des serveurs; l'affichage de ces
données avec une appli tournant en local nécessite la lecture de ces
données à travers le réseau, ce qui le sature très vite. Ne faire
passer que l'affichage charge finalement moins le réseau et c'est
plus rapide (ce n'est pas une projection, c'est un fait).
On en arrive donc exactement à ce qu'on disait au tout début: Windows
ne sert qu'à un seul truc, servir de serveur X
Ça fait cher le serveur X et la quantité de truc inutile quand même…
On fait pareil avec un TX à 30€ sans OS hein…
Excuse-moi, j'avais oublié que j'avais affaire au Turing du XXIè
siècle, à côté de qui n'importe qui parait incompétent.
Je n'ai qu'un seul mot pour un individu de ton espèce mais il serait
vulgaire.
Excuse-moi, j'avais oublié que j'avais affaire au Turing du XXIè
siècle, à côté de qui n'importe qui parait incompétent.
Je n'ai qu'un seul mot pour un individu de ton espèce mais il serait
vulgaire.
Excuse-moi, j'avais oublié que j'avais affaire au Turing du XXIè
siècle, à côté de qui n'importe qui parait incompétent.
Je n'ai qu'un seul mot pour un individu de ton espèce mais il serait
vulgaire.
Explique-moi sans rigoler ce qui ferait qu'il serait impossible de
faire tourner un bête traitement de texte sur un TX ?
Ça dépend ce que tu appelles "bête traitement de texte". Si c'est pour
faire tourner la suite MS-Office, c'est pas gagné.
Explique-moi sans rigoler ce qui ferait qu'il serait impossible de
faire tourner un bête traitement de texte sur un TX ?
Ça dépend ce que tu appelles "bête traitement de texte". Si c'est pour
faire tourner la suite MS-Office, c'est pas gagné.
Explique-moi sans rigoler ce qui ferait qu'il serait impossible de
faire tourner un bête traitement de texte sur un TX ?
Ça dépend ce que tu appelles "bête traitement de texte". Si c'est pour
faire tourner la suite MS-Office, c'est pas gagné.
"JKB" a écrit dans le message de news:
Je te signale que c'est à peu près partout comme ça, de nos jours.
Et ça ne change strictement rien au fait qu'engager un
administrateur même de poste clients est moins cher et plus pérenne
pour une entreprise. Je n'ai encore jamais vu de prestataires
prétendûment là pour faire de l'administration de postes clients à
la hauteur des attentes. Et le tarif est inversement proportionnel
aux compétences des types.
Dommage qu'il n'y ait qu'un JKB dans le monde.
C'est peut-être idiot, mais on a déjà des sites qui ont basculé sur
ce mode de fonctionnement (dont un depuis plusieurs années en fait,
à cause d'une spécificité locale), et le fait est que ça donne
satisfaction (les utilisateurs ne s'en plaignent pas).
Que les utilisateurs ne se plaignent pas n'est pas un critère. J'ai
actuellement devant moi un pool de développeurs qui utilisent Visual
Studio 2010 pour débugguer des problèmes de C++ et c'est totalement
inadapté et idiot. Ils auraient plus vite fait de recompiler leur
truc sous Linux et de passer un coup de valgrind dessus pour
dégrossir. Ils ne se plaignent pas parce qu'il ne savent pas qu'on
peut faire autrement.
Dans le cas que je décris ils savent, puisqu'ils ont connu les deux modes de
fonctionnement.
En réalité sur certains points c'est
même mieux qu'avant. On manipule des gros volumes de données qui
sont sur des serveurs; l'affichage de ces données avec une appli
tournant en local nécessite la lecture de ces données à travers le
réseau, ce qui le sature très vite.
On en revient au même problème. Couche réseau moisie ou logiciel
moisi. Il y a plus de dix ans, je bossais sur des démodulateurs UMTS
et j'avais des banques de signaux à ma disposition (enfin, sur un
serveur distant). Chaque fichier représentait quelques dizaines de
Go de données et ça passait sur un réseau 10Base2 sans le saturer.
Ce que tu racontes ne veut strictement rien dire. Il est évident que si tu
ne lis qu'un octet dans ton fichier de 10Go, ça ne sature pas le réseau.
En revanche, en écrivant les outils permettant d'accéder à ces
données, on avait intégré qu'on passait au travers d'un réseau et on
n'avait pas utilisé brutalement les fonctions génériques qui font
qu'on peut attaquer un disque réseau comme s'il était physiquement
sur la machine.
Ben finalement plutôt que de tout réécrire c'est plus simple de faire
tourner l'appli sur une machine "au plus près des données".
Ne faire passer que l'affichage charge finalement moins le réseau
et c'est plus rapide (ce n'est pas une projection, c'est un fait).
C'est faux dans le cas général.
Je ne parle pas dans le cas général
"JKB" <jkb@koenigsberg.invalid> a écrit dans le message de news:
slrniov67c.9qt.jkb@rayleigh.systella.fr
Je te signale que c'est à peu près partout comme ça, de nos jours.
Et ça ne change strictement rien au fait qu'engager un
administrateur même de poste clients est moins cher et plus pérenne
pour une entreprise. Je n'ai encore jamais vu de prestataires
prétendûment là pour faire de l'administration de postes clients à
la hauteur des attentes. Et le tarif est inversement proportionnel
aux compétences des types.
Dommage qu'il n'y ait qu'un JKB dans le monde.
C'est peut-être idiot, mais on a déjà des sites qui ont basculé sur
ce mode de fonctionnement (dont un depuis plusieurs années en fait,
à cause d'une spécificité locale), et le fait est que ça donne
satisfaction (les utilisateurs ne s'en plaignent pas).
Que les utilisateurs ne se plaignent pas n'est pas un critère. J'ai
actuellement devant moi un pool de développeurs qui utilisent Visual
Studio 2010 pour débugguer des problèmes de C++ et c'est totalement
inadapté et idiot. Ils auraient plus vite fait de recompiler leur
truc sous Linux et de passer un coup de valgrind dessus pour
dégrossir. Ils ne se plaignent pas parce qu'il ne savent pas qu'on
peut faire autrement.
Dans le cas que je décris ils savent, puisqu'ils ont connu les deux modes de
fonctionnement.
En réalité sur certains points c'est
même mieux qu'avant. On manipule des gros volumes de données qui
sont sur des serveurs; l'affichage de ces données avec une appli
tournant en local nécessite la lecture de ces données à travers le
réseau, ce qui le sature très vite.
On en revient au même problème. Couche réseau moisie ou logiciel
moisi. Il y a plus de dix ans, je bossais sur des démodulateurs UMTS
et j'avais des banques de signaux à ma disposition (enfin, sur un
serveur distant). Chaque fichier représentait quelques dizaines de
Go de données et ça passait sur un réseau 10Base2 sans le saturer.
Ce que tu racontes ne veut strictement rien dire. Il est évident que si tu
ne lis qu'un octet dans ton fichier de 10Go, ça ne sature pas le réseau.
En revanche, en écrivant les outils permettant d'accéder à ces
données, on avait intégré qu'on passait au travers d'un réseau et on
n'avait pas utilisé brutalement les fonctions génériques qui font
qu'on peut attaquer un disque réseau comme s'il était physiquement
sur la machine.
Ben finalement plutôt que de tout réécrire c'est plus simple de faire
tourner l'appli sur une machine "au plus près des données".
Ne faire passer que l'affichage charge finalement moins le réseau
et c'est plus rapide (ce n'est pas une projection, c'est un fait).
C'est faux dans le cas général.
Je ne parle pas dans le cas général
"JKB" a écrit dans le message de news:
Je te signale que c'est à peu près partout comme ça, de nos jours.
Et ça ne change strictement rien au fait qu'engager un
administrateur même de poste clients est moins cher et plus pérenne
pour une entreprise. Je n'ai encore jamais vu de prestataires
prétendûment là pour faire de l'administration de postes clients à
la hauteur des attentes. Et le tarif est inversement proportionnel
aux compétences des types.
Dommage qu'il n'y ait qu'un JKB dans le monde.
C'est peut-être idiot, mais on a déjà des sites qui ont basculé sur
ce mode de fonctionnement (dont un depuis plusieurs années en fait,
à cause d'une spécificité locale), et le fait est que ça donne
satisfaction (les utilisateurs ne s'en plaignent pas).
Que les utilisateurs ne se plaignent pas n'est pas un critère. J'ai
actuellement devant moi un pool de développeurs qui utilisent Visual
Studio 2010 pour débugguer des problèmes de C++ et c'est totalement
inadapté et idiot. Ils auraient plus vite fait de recompiler leur
truc sous Linux et de passer un coup de valgrind dessus pour
dégrossir. Ils ne se plaignent pas parce qu'il ne savent pas qu'on
peut faire autrement.
Dans le cas que je décris ils savent, puisqu'ils ont connu les deux modes de
fonctionnement.
En réalité sur certains points c'est
même mieux qu'avant. On manipule des gros volumes de données qui
sont sur des serveurs; l'affichage de ces données avec une appli
tournant en local nécessite la lecture de ces données à travers le
réseau, ce qui le sature très vite.
On en revient au même problème. Couche réseau moisie ou logiciel
moisi. Il y a plus de dix ans, je bossais sur des démodulateurs UMTS
et j'avais des banques de signaux à ma disposition (enfin, sur un
serveur distant). Chaque fichier représentait quelques dizaines de
Go de données et ça passait sur un réseau 10Base2 sans le saturer.
Ce que tu racontes ne veut strictement rien dire. Il est évident que si tu
ne lis qu'un octet dans ton fichier de 10Go, ça ne sature pas le réseau.
En revanche, en écrivant les outils permettant d'accéder à ces
données, on avait intégré qu'on passait au travers d'un réseau et on
n'avait pas utilisé brutalement les fonctions génériques qui font
qu'on peut attaquer un disque réseau comme s'il était physiquement
sur la machine.
Ben finalement plutôt que de tout réécrire c'est plus simple de faire
tourner l'appli sur une machine "au plus près des données".
Ne faire passer que l'affichage charge finalement moins le réseau
et c'est plus rapide (ce n'est pas une projection, c'est un fait).
C'est faux dans le cas général.
Je ne parle pas dans le cas général
"Aéris" a écrit dans le message de news:
4d8f980d$0$20943$Le 27/03/2011 21:33, pehache-olino a écrit :C'est peut-être idiot, mais on a déjà des sites qui ont basculé sur
ce mode de fonctionnement (dont un depuis plusieurs années en fait,
à cause d'une spécificité locale), et le fait est que ça donne
satisfaction (les utilisateurs ne s'en plaignent pas). En réalité
sur certains points c'est même mieux qu'avant. On manipule des gros
volumes de données qui sont sur des serveurs; l'affichage de ces
données avec une appli tournant en local nécessite la lecture de ces
données à travers le réseau, ce qui le sature très vite. Ne faire
passer que l'affichage charge finalement moins le réseau et c'est
plus rapide (ce n'est pas une projection, c'est un fait).
On en arrive donc exactement à ce qu'on disait au tout début: Windows
ne sert qu'à un seul truc, servir de serveur X
Ça fait cher le serveur X et la quantité de truc inutile quand même…
Serveur X pour la partie technique, et applications usuelles Windows pour
toute la bureautique.
On fait pareil avec un TX à 30€ sans OS hein…
Ben non.
Accessoirement si tu veux un TX qui ne soit pas moisi, ça coûte "un peu
plus" que 30€
"Aéris" <aeris@imirhil.fr> a écrit dans le message de news:
4d8f980d$0$20943$426a74cc@news.free.fr
Le 27/03/2011 21:33, pehache-olino a écrit :
C'est peut-être idiot, mais on a déjà des sites qui ont basculé sur
ce mode de fonctionnement (dont un depuis plusieurs années en fait,
à cause d'une spécificité locale), et le fait est que ça donne
satisfaction (les utilisateurs ne s'en plaignent pas). En réalité
sur certains points c'est même mieux qu'avant. On manipule des gros
volumes de données qui sont sur des serveurs; l'affichage de ces
données avec une appli tournant en local nécessite la lecture de ces
données à travers le réseau, ce qui le sature très vite. Ne faire
passer que l'affichage charge finalement moins le réseau et c'est
plus rapide (ce n'est pas une projection, c'est un fait).
On en arrive donc exactement à ce qu'on disait au tout début: Windows
ne sert qu'à un seul truc, servir de serveur X
Ça fait cher le serveur X et la quantité de truc inutile quand même…
Serveur X pour la partie technique, et applications usuelles Windows pour
toute la bureautique.
On fait pareil avec un TX à 30€ sans OS hein…
Ben non.
Accessoirement si tu veux un TX qui ne soit pas moisi, ça coûte "un peu
plus" que 30€
"Aéris" a écrit dans le message de news:
4d8f980d$0$20943$Le 27/03/2011 21:33, pehache-olino a écrit :C'est peut-être idiot, mais on a déjà des sites qui ont basculé sur
ce mode de fonctionnement (dont un depuis plusieurs années en fait,
à cause d'une spécificité locale), et le fait est que ça donne
satisfaction (les utilisateurs ne s'en plaignent pas). En réalité
sur certains points c'est même mieux qu'avant. On manipule des gros
volumes de données qui sont sur des serveurs; l'affichage de ces
données avec une appli tournant en local nécessite la lecture de ces
données à travers le réseau, ce qui le sature très vite. Ne faire
passer que l'affichage charge finalement moins le réseau et c'est
plus rapide (ce n'est pas une projection, c'est un fait).
On en arrive donc exactement à ce qu'on disait au tout début: Windows
ne sert qu'à un seul truc, servir de serveur X
Ça fait cher le serveur X et la quantité de truc inutile quand même…
Serveur X pour la partie technique, et applications usuelles Windows pour
toute la bureautique.
On fait pareil avec un TX à 30€ sans OS hein…
Ben non.
Accessoirement si tu veux un TX qui ne soit pas moisi, ça coûte "un peu
plus" que 30€
"JKB" a écrit dans le message de news:
Excuse-moi, j'avais oublié que j'avais affaire au Turing du XXIè
siècle, à côté de qui n'importe qui parait incompétent.
Je n'ai qu'un seul mot pour un individu de ton espèce mais il serait
vulgaire.
Bon, tu me remets quand dans ton kill-file ?
"JKB" <jkb@koenigsberg.invalid> a écrit dans le message de news:
slrniov68r.9qt.jkb@rayleigh.systella.fr
Excuse-moi, j'avais oublié que j'avais affaire au Turing du XXIè
siècle, à côté de qui n'importe qui parait incompétent.
Je n'ai qu'un seul mot pour un individu de ton espèce mais il serait
vulgaire.
Bon, tu me remets quand dans ton kill-file ?
"JKB" a écrit dans le message de news:
Excuse-moi, j'avais oublié que j'avais affaire au Turing du XXIè
siècle, à côté de qui n'importe qui parait incompétent.
Je n'ai qu'un seul mot pour un individu de ton espèce mais il serait
vulgaire.
Bon, tu me remets quand dans ton kill-file ?
Dommage qu'il n'y ait qu'un JKB dans le monde.
Connard ! (pour l'attaque ad hominem)
Le prestataire qui revient à 500 euros HT par jours pour un résultat
nul ou presque est beaucoup plus cher qu'un ingénieur maison
correctement formé. Et tu peux dire toue ce que tu veux, 500
euros/jour, ça fait 10000 euros/mois. Même avec es charges, tu as un
_bon_ ingénieur système maison. Et même pour une petit boîte, il vaut
mieux former correctement un salarié plutôt que de passer par des
prestataires. Parce qu'il y a un effet de bord : lorsque tu vires un
prestataire, celui-ci se barre généralement avec la doc et le
suivant doit se démerder avec l'existant sans savoir pourquoi telle
ou telle chose avait été faite. C'est même pour cela que des
prestataires nuls à tout point de vue sont encore sur le marché !
Dans le cas que je décris ils savent, puisqu'ils ont connu les deux
modes de fonctionnement.
Non, on ne parle pas de la même chose.
Ce que tu racontes ne veut strictement rien dire. Il est évident que
si tu ne lis qu'un octet dans ton fichier de 10Go, ça ne sature pas
le réseau.
Je n'ai jamais dit ça. J'ai simplement dit que lorsqu'on développe
une application qui utilise des données distantes, on ne fait pas
n'importe quoi. On n'attaque pas directement un disque réseau comme
s'il était local (ce que font toutes les applications windows pour
un certain nombre de raisons trop longue à expliquer ici). Et pour
ta gouverne, mes applications lisaient l'intégralité de chaque
fichier.
Ben finalement plutôt que de tout réécrire c'est plus simple de faire
tourner l'appli sur une machine "au plus près des données".
Tu as une idée de ce qu'était une banque de données de plusieurs To
de signaux il y a dix ans ?
Je ne parle pas dans le cas général
C'est dommage, c'est le seul qui permet de dimensionner les choses
et de ne pas faire n'importe quoi.
Dommage qu'il n'y ait qu'un JKB dans le monde.
Connard ! (pour l'attaque ad hominem)
Le prestataire qui revient à 500 euros HT par jours pour un résultat
nul ou presque est beaucoup plus cher qu'un ingénieur maison
correctement formé. Et tu peux dire toue ce que tu veux, 500
euros/jour, ça fait 10000 euros/mois. Même avec es charges, tu as un
_bon_ ingénieur système maison. Et même pour une petit boîte, il vaut
mieux former correctement un salarié plutôt que de passer par des
prestataires. Parce qu'il y a un effet de bord : lorsque tu vires un
prestataire, celui-ci se barre généralement avec la doc et le
suivant doit se démerder avec l'existant sans savoir pourquoi telle
ou telle chose avait été faite. C'est même pour cela que des
prestataires nuls à tout point de vue sont encore sur le marché !
Dans le cas que je décris ils savent, puisqu'ils ont connu les deux
modes de fonctionnement.
Non, on ne parle pas de la même chose.
Ce que tu racontes ne veut strictement rien dire. Il est évident que
si tu ne lis qu'un octet dans ton fichier de 10Go, ça ne sature pas
le réseau.
Je n'ai jamais dit ça. J'ai simplement dit que lorsqu'on développe
une application qui utilise des données distantes, on ne fait pas
n'importe quoi. On n'attaque pas directement un disque réseau comme
s'il était local (ce que font toutes les applications windows pour
un certain nombre de raisons trop longue à expliquer ici). Et pour
ta gouverne, mes applications lisaient l'intégralité de chaque
fichier.
Ben finalement plutôt que de tout réécrire c'est plus simple de faire
tourner l'appli sur une machine "au plus près des données".
Tu as une idée de ce qu'était une banque de données de plusieurs To
de signaux il y a dix ans ?
Je ne parle pas dans le cas général
C'est dommage, c'est le seul qui permet de dimensionner les choses
et de ne pas faire n'importe quoi.
Dommage qu'il n'y ait qu'un JKB dans le monde.
Connard ! (pour l'attaque ad hominem)
Le prestataire qui revient à 500 euros HT par jours pour un résultat
nul ou presque est beaucoup plus cher qu'un ingénieur maison
correctement formé. Et tu peux dire toue ce que tu veux, 500
euros/jour, ça fait 10000 euros/mois. Même avec es charges, tu as un
_bon_ ingénieur système maison. Et même pour une petit boîte, il vaut
mieux former correctement un salarié plutôt que de passer par des
prestataires. Parce qu'il y a un effet de bord : lorsque tu vires un
prestataire, celui-ci se barre généralement avec la doc et le
suivant doit se démerder avec l'existant sans savoir pourquoi telle
ou telle chose avait été faite. C'est même pour cela que des
prestataires nuls à tout point de vue sont encore sur le marché !
Dans le cas que je décris ils savent, puisqu'ils ont connu les deux
modes de fonctionnement.
Non, on ne parle pas de la même chose.
Ce que tu racontes ne veut strictement rien dire. Il est évident que
si tu ne lis qu'un octet dans ton fichier de 10Go, ça ne sature pas
le réseau.
Je n'ai jamais dit ça. J'ai simplement dit que lorsqu'on développe
une application qui utilise des données distantes, on ne fait pas
n'importe quoi. On n'attaque pas directement un disque réseau comme
s'il était local (ce que font toutes les applications windows pour
un certain nombre de raisons trop longue à expliquer ici). Et pour
ta gouverne, mes applications lisaient l'intégralité de chaque
fichier.
Ben finalement plutôt que de tout réécrire c'est plus simple de faire
tourner l'appli sur une machine "au plus près des données".
Tu as une idée de ce qu'était une banque de données de plusieurs To
de signaux il y a dix ans ?
Je ne parle pas dans le cas général
C'est dommage, c'est le seul qui permet de dimensionner les choses
et de ne pas faire n'importe quoi.
Bon, tu me remets quand dans ton kill-file ?
Quand tu arrêteras de changer de pseudonyme pour sortir des
boitakons de tous ceux qui t'y mettent régulièrement.
Bon, tu me remets quand dans ton kill-file ?
Quand tu arrêteras de changer de pseudonyme pour sortir des
boitakons de tous ceux qui t'y mettent régulièrement.
Bon, tu me remets quand dans ton kill-file ?
Quand tu arrêteras de changer de pseudonyme pour sortir des
boitakons de tous ceux qui t'y mettent régulièrement.