Sans oublier que tu tombes sur des fonctionnements aléatoires qui
sont très difficiles à diagnostiquer. Tiens, en parlant de trucs
rigolo, j'ai un SDK qui se baugeait régulièrement dans un cas bien
précis. J'ai balancé un coup de purify dessus pour voir que la
bibliothèque C++ de visual studio 2010 fait un new suivi d'un...
free() pour libérer l'objet en cas de récupération d'erreur... Et
paf, une erreur d'accès mémoire... Je comprends maintenant pourquoi
W7 est compilé avec Visual Studio 2008 !
JKB
Sans oublier que tu tombes sur des fonctionnements aléatoires qui
sont très difficiles à diagnostiquer. Tiens, en parlant de trucs
rigolo, j'ai un SDK qui se baugeait régulièrement dans un cas bien
précis. J'ai balancé un coup de purify dessus pour voir que la
bibliothèque C++ de visual studio 2010 fait un new suivi d'un...
free() pour libérer l'objet en cas de récupération d'erreur... Et
paf, une erreur d'accès mémoire... Je comprends maintenant pourquoi
W7 est compilé avec Visual Studio 2008 !
JKB
Sans oublier que tu tombes sur des fonctionnements aléatoires qui
sont très difficiles à diagnostiquer. Tiens, en parlant de trucs
rigolo, j'ai un SDK qui se baugeait régulièrement dans un cas bien
précis. J'ai balancé un coup de purify dessus pour voir que la
bibliothèque C++ de visual studio 2010 fait un new suivi d'un...
free() pour libérer l'objet en cas de récupération d'erreur... Et
paf, une erreur d'accès mémoire... Je comprends maintenant pourquoi
W7 est compilé avec Visual Studio 2008 !
JKB
Les stations seront gérées comme tout le reste du parc bureautique
actuel (poste non techniques, secrétaires, etc...), en pratique par
un prestataire.
Mon dieu...
Du tout. C'est le management technique qui a jugé que le rôle des IT
dédiés à la technique (et qui eux sont en interne) n'était pas de
passer leur temps à gérer des parcs de stations. De fait, ce n'est
que depuis qu'il y a des stations PC-linux qu'ils font : auparavant
ils ne s'occupaient que des machines et serveurs de calcul (qui
étaient accédées par des terminaux X (voire VT220 dans les temps
plus anciens)). Donc on revient finalement à l'ancien fonctionnement.
M'étonnerais, ça. Dans l'ancien temps, on avait des terminaux X en
1280x1024x24 qui tournaient sur du 10BaseT (même pas X) voire du
10Base2 ou de l'AUI. Et sur un lien 10Base2, tu pouvais coller une
dizaine de TX. Je l'ai fait et ça fonctionnait très bien tant que
personne ne prenait le bouchon pour calibrer un analyseur de réseau.
Je te mets au défi aujourd'hui de mettre dix fois plus de TX (avec
Cygwin/Xorg ou Exceed ou ce que tu veux d'autre comme serveur X) sur
un réseau 1000BaseTX tellement la couche réseau de Windows est moisie.
La bonne solution à ce problème, c'est des postes diskless avec des
procédures de boot. La mauvaise, c'est Windows + serveur X en
partant du principe que l'administration se fera toute seule et que
c'est plus simple. C'est juste idiot.
Les stations seront gérées comme tout le reste du parc bureautique
actuel (poste non techniques, secrétaires, etc...), en pratique par
un prestataire.
Mon dieu...
Du tout. C'est le management technique qui a jugé que le rôle des IT
dédiés à la technique (et qui eux sont en interne) n'était pas de
passer leur temps à gérer des parcs de stations. De fait, ce n'est
que depuis qu'il y a des stations PC-linux qu'ils font : auparavant
ils ne s'occupaient que des machines et serveurs de calcul (qui
étaient accédées par des terminaux X (voire VT220 dans les temps
plus anciens)). Donc on revient finalement à l'ancien fonctionnement.
M'étonnerais, ça. Dans l'ancien temps, on avait des terminaux X en
1280x1024x24 qui tournaient sur du 10BaseT (même pas X) voire du
10Base2 ou de l'AUI. Et sur un lien 10Base2, tu pouvais coller une
dizaine de TX. Je l'ai fait et ça fonctionnait très bien tant que
personne ne prenait le bouchon pour calibrer un analyseur de réseau.
Je te mets au défi aujourd'hui de mettre dix fois plus de TX (avec
Cygwin/Xorg ou Exceed ou ce que tu veux d'autre comme serveur X) sur
un réseau 1000BaseTX tellement la couche réseau de Windows est moisie.
La bonne solution à ce problème, c'est des postes diskless avec des
procédures de boot. La mauvaise, c'est Windows + serveur X en
partant du principe que l'administration se fera toute seule et que
c'est plus simple. C'est juste idiot.
Les stations seront gérées comme tout le reste du parc bureautique
actuel (poste non techniques, secrétaires, etc...), en pratique par
un prestataire.
Mon dieu...
Du tout. C'est le management technique qui a jugé que le rôle des IT
dédiés à la technique (et qui eux sont en interne) n'était pas de
passer leur temps à gérer des parcs de stations. De fait, ce n'est
que depuis qu'il y a des stations PC-linux qu'ils font : auparavant
ils ne s'occupaient que des machines et serveurs de calcul (qui
étaient accédées par des terminaux X (voire VT220 dans les temps
plus anciens)). Donc on revient finalement à l'ancien fonctionnement.
M'étonnerais, ça. Dans l'ancien temps, on avait des terminaux X en
1280x1024x24 qui tournaient sur du 10BaseT (même pas X) voire du
10Base2 ou de l'AUI. Et sur un lien 10Base2, tu pouvais coller une
dizaine de TX. Je l'ai fait et ça fonctionnait très bien tant que
personne ne prenait le bouchon pour calibrer un analyseur de réseau.
Je te mets au défi aujourd'hui de mettre dix fois plus de TX (avec
Cygwin/Xorg ou Exceed ou ce que tu veux d'autre comme serveur X) sur
un réseau 1000BaseTX tellement la couche réseau de Windows est moisie.
La bonne solution à ce problème, c'est des postes diskless avec des
procédures de boot. La mauvaise, c'est Windows + serveur X en
partant du principe que l'administration se fera toute seule et que
c'est plus simple. C'est juste idiot.
Pour l'entreprise, si les postes bureautiques restent sous Windows,
c'est aussi pour des questions d'incompétence du service
administration système.
Non.
Je ne connais aucun contre-exemple à l'incompétence des
administrateurs systèmes. Lorsque j'en trouverai un seul compétent,
je le ferai empailler !
D'ailleurs, heureusement qu'ils sont incompétents, ça me donne du
boulot.
Pour l'entreprise, si les postes bureautiques restent sous Windows,
c'est aussi pour des questions d'incompétence du service
administration système.
Non.
Je ne connais aucun contre-exemple à l'incompétence des
administrateurs systèmes. Lorsque j'en trouverai un seul compétent,
je le ferai empailler !
D'ailleurs, heureusement qu'ils sont incompétents, ça me donne du
boulot.
Pour l'entreprise, si les postes bureautiques restent sous Windows,
c'est aussi pour des questions d'incompétence du service
administration système.
Non.
Je ne connais aucun contre-exemple à l'incompétence des
administrateurs systèmes. Lorsque j'en trouverai un seul compétent,
je le ferai empailler !
D'ailleurs, heureusement qu'ils sont incompétents, ça me donne du
boulot.
Le 27/03/2011 21:10, JKB a écrit :Sans oublier que tu tombes sur des fonctionnements aléatoires qui
sont très difficiles à diagnostiquer. Tiens, en parlant de trucs
rigolo, j'ai un SDK qui se baugeait régulièrement dans un cas bien
précis. J'ai balancé un coup de purify dessus pour voir que la
bibliothèque C++ de visual studio 2010 fait un new suivi d'un...
free() pour libérer l'objet en cas de récupération d'erreur... Et
paf, une erreur d'accès mémoire... Je comprends maintenant pourquoi
W7 est compilé avec Visual Studio 2008 !
JKB
Et sans oublier les trucs assez funky du style « Windows Serveur 2008
RC2 a été choisi et qualifié en interne parce qu'il permet de gérer des
performances étonnantes sur une seule connexion cliente. » avec 180
lignes plus bas « Le prestataire choisit devra mettre en œuvre une
solution technique permettant de gérer 2.000 connexions simultanées. NB:
Nous attirons l'attention du prestataire sur le fait que Windows 2008
RC2 est limité au niveau hardware à 256 connexions simultanées. »
(Sisi je vous jure, je l'ai vu dans un appel d'offre…)
Le 27/03/2011 21:10, JKB a écrit :
Sans oublier que tu tombes sur des fonctionnements aléatoires qui
sont très difficiles à diagnostiquer. Tiens, en parlant de trucs
rigolo, j'ai un SDK qui se baugeait régulièrement dans un cas bien
précis. J'ai balancé un coup de purify dessus pour voir que la
bibliothèque C++ de visual studio 2010 fait un new suivi d'un...
free() pour libérer l'objet en cas de récupération d'erreur... Et
paf, une erreur d'accès mémoire... Je comprends maintenant pourquoi
W7 est compilé avec Visual Studio 2008 !
JKB
Et sans oublier les trucs assez funky du style « Windows Serveur 2008
RC2 a été choisi et qualifié en interne parce qu'il permet de gérer des
performances étonnantes sur une seule connexion cliente. » avec 180
lignes plus bas « Le prestataire choisit devra mettre en œuvre une
solution technique permettant de gérer 2.000 connexions simultanées. NB:
Nous attirons l'attention du prestataire sur le fait que Windows 2008
RC2 est limité au niveau hardware à 256 connexions simultanées. »
(Sisi je vous jure, je l'ai vu dans un appel d'offre…)
Le 27/03/2011 21:10, JKB a écrit :Sans oublier que tu tombes sur des fonctionnements aléatoires qui
sont très difficiles à diagnostiquer. Tiens, en parlant de trucs
rigolo, j'ai un SDK qui se baugeait régulièrement dans un cas bien
précis. J'ai balancé un coup de purify dessus pour voir que la
bibliothèque C++ de visual studio 2010 fait un new suivi d'un...
free() pour libérer l'objet en cas de récupération d'erreur... Et
paf, une erreur d'accès mémoire... Je comprends maintenant pourquoi
W7 est compilé avec Visual Studio 2008 !
JKB
Et sans oublier les trucs assez funky du style « Windows Serveur 2008
RC2 a été choisi et qualifié en interne parce qu'il permet de gérer des
performances étonnantes sur une seule connexion cliente. » avec 180
lignes plus bas « Le prestataire choisit devra mettre en œuvre une
solution technique permettant de gérer 2.000 connexions simultanées. NB:
Nous attirons l'attention du prestataire sur le fait que Windows 2008
RC2 est limité au niveau hardware à 256 connexions simultanées. »
(Sisi je vous jure, je l'ai vu dans un appel d'offre…)
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).
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).
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).
"JKB" a écrit dans le message de news:
Les stations seront gérées comme tout le reste du parc bureautique
actuel (poste non techniques, secrétaires, etc...), en pratique par
un prestataire.
Mon dieu...
Je te signale que c'est à peu près partout comme ça, de nos jours.
Du tout. C'est le management technique qui a jugé que le rôle des IT
dédiés à la technique (et qui eux sont en interne) n'était pas de
passer leur temps à gérer des parcs de stations. De fait, ce n'est
que depuis qu'il y a des stations PC-linux qu'ils font : auparavant
ils ne s'occupaient que des machines et serveurs de calcul (qui
étaient accédées par des terminaux X (voire VT220 dans les temps
plus anciens)). Donc on revient finalement à l'ancien fonctionnement.
M'étonnerais, ça. Dans l'ancien temps, on avait des terminaux X en
1280x1024x24 qui tournaient sur du 10BaseT (même pas X) voire du
10Base2 ou de l'AUI. Et sur un lien 10Base2, tu pouvais coller une
dizaine de TX. Je l'ai fait et ça fonctionnait très bien tant que
personne ne prenait le bouchon pour calibrer un analyseur de réseau.
Je te mets au défi aujourd'hui de mettre dix fois plus de TX (avec
Cygwin/Xorg ou Exceed ou ce que tu veux d'autre comme serveur X) sur
un réseau 1000BaseTX tellement la couche réseau de Windows est moisie.
La bonne solution à ce problème, c'est des postes diskless avec des
procédures de boot. La mauvaise, c'est Windows + serveur X en
partant du principe que l'administration se fera toute seule et que
c'est plus simple. C'est juste idiot.
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).
Accessoirement, je connais une très grosse boîte qui fonctionne comme ça
depuis toujours.
"JKB" <jkb@koenigsberg.invalid> a écrit dans le message de news:
slrniov3a3.9qt.jkb@rayleigh.systella.fr
Les stations seront gérées comme tout le reste du parc bureautique
actuel (poste non techniques, secrétaires, etc...), en pratique par
un prestataire.
Mon dieu...
Je te signale que c'est à peu près partout comme ça, de nos jours.
Du tout. C'est le management technique qui a jugé que le rôle des IT
dédiés à la technique (et qui eux sont en interne) n'était pas de
passer leur temps à gérer des parcs de stations. De fait, ce n'est
que depuis qu'il y a des stations PC-linux qu'ils font : auparavant
ils ne s'occupaient que des machines et serveurs de calcul (qui
étaient accédées par des terminaux X (voire VT220 dans les temps
plus anciens)). Donc on revient finalement à l'ancien fonctionnement.
M'étonnerais, ça. Dans l'ancien temps, on avait des terminaux X en
1280x1024x24 qui tournaient sur du 10BaseT (même pas X) voire du
10Base2 ou de l'AUI. Et sur un lien 10Base2, tu pouvais coller une
dizaine de TX. Je l'ai fait et ça fonctionnait très bien tant que
personne ne prenait le bouchon pour calibrer un analyseur de réseau.
Je te mets au défi aujourd'hui de mettre dix fois plus de TX (avec
Cygwin/Xorg ou Exceed ou ce que tu veux d'autre comme serveur X) sur
un réseau 1000BaseTX tellement la couche réseau de Windows est moisie.
La bonne solution à ce problème, c'est des postes diskless avec des
procédures de boot. La mauvaise, c'est Windows + serveur X en
partant du principe que l'administration se fera toute seule et que
c'est plus simple. C'est juste idiot.
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).
Accessoirement, je connais une très grosse boîte qui fonctionne comme ça
depuis toujours.
"JKB" a écrit dans le message de news:
Les stations seront gérées comme tout le reste du parc bureautique
actuel (poste non techniques, secrétaires, etc...), en pratique par
un prestataire.
Mon dieu...
Je te signale que c'est à peu près partout comme ça, de nos jours.
Du tout. C'est le management technique qui a jugé que le rôle des IT
dédiés à la technique (et qui eux sont en interne) n'était pas de
passer leur temps à gérer des parcs de stations. De fait, ce n'est
que depuis qu'il y a des stations PC-linux qu'ils font : auparavant
ils ne s'occupaient que des machines et serveurs de calcul (qui
étaient accédées par des terminaux X (voire VT220 dans les temps
plus anciens)). Donc on revient finalement à l'ancien fonctionnement.
M'étonnerais, ça. Dans l'ancien temps, on avait des terminaux X en
1280x1024x24 qui tournaient sur du 10BaseT (même pas X) voire du
10Base2 ou de l'AUI. Et sur un lien 10Base2, tu pouvais coller une
dizaine de TX. Je l'ai fait et ça fonctionnait très bien tant que
personne ne prenait le bouchon pour calibrer un analyseur de réseau.
Je te mets au défi aujourd'hui de mettre dix fois plus de TX (avec
Cygwin/Xorg ou Exceed ou ce que tu veux d'autre comme serveur X) sur
un réseau 1000BaseTX tellement la couche réseau de Windows est moisie.
La bonne solution à ce problème, c'est des postes diskless avec des
procédures de boot. La mauvaise, c'est Windows + serveur X en
partant du principe que l'administration se fera toute seule et que
c'est plus simple. C'est juste idiot.
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).
Accessoirement, je connais une très grosse boîte qui fonctionne comme ça
depuis toujours.
"JKB" a écrit dans le message de news:Pour l'entreprise, si les postes bureautiques restent sous Windows,
c'est aussi pour des questions d'incompétence du service
administration système.
Non.
Je ne connais aucun contre-exemple à l'incompétence des
administrateurs systèmes. Lorsque j'en trouverai un seul compétent,
je le ferai empailler !
D'ailleurs, heureusement qu'ils sont incompétents, ça me donne du
boulot.
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.
"JKB" <jkb@koenigsberg.invalid> a écrit dans le message de news:
slrniov3db.9qt.jkb@rayleigh.systella.fr
Pour l'entreprise, si les postes bureautiques restent sous Windows,
c'est aussi pour des questions d'incompétence du service
administration système.
Non.
Je ne connais aucun contre-exemple à l'incompétence des
administrateurs systèmes. Lorsque j'en trouverai un seul compétent,
je le ferai empailler !
D'ailleurs, heureusement qu'ils sont incompétents, ça me donne du
boulot.
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.
"JKB" a écrit dans le message de news:Pour l'entreprise, si les postes bureautiques restent sous Windows,
c'est aussi pour des questions d'incompétence du service
administration système.
Non.
Je ne connais aucun contre-exemple à l'incompétence des
administrateurs systèmes. Lorsque j'en trouverai un seul compétent,
je le ferai empailler !
D'ailleurs, heureusement qu'ils sont incompétents, ça me donne du
boulot.
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.
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…
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…
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…
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.
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.
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.
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 ?
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 ?
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 ?