Rebonjour à tous,
Si, si, vous allez rire...
Après avoir posé ma question lundi "Vous pensez quoi de ce matériel" (voir
post plus bas) qui a déclenché une petite foire d'empoigne, je suis donc
allée à Confo voir ledit matériel...
Bof, pas emballée après tous vos avis, effectivement processeur de 1Go
Et dans le rayon, sur une petite étagère dans un coin, que vois-je ? Une UC
toute seule, comme abandonnée : un Pentium 4, proc 3 Mhz, 1 Go RAM, 250 GO
disque, 6 ports USB, graveur, etc,etc... le tout sous Windows XP... Et le
vendeur (qui au demeurant n'avait pas l'air d'y connaître grand chose) de me
dire : "Oh, celui là c'est le dernier sous Windows XP, alors on le brade à
500 euros, vu qu'il est pas sous Windows Vista...".
Huuuummmmmmmm.....
J'ai rien dit, forte de toutes vos remarques j'ai fait ma grande, j'ai pris
la bête, j'ai payé et je suis partie.
Bon, çà, c'est fait...
Ceci dit je fais (encore) appel à vous :
Hier soir j'ai donc branché mon nouveau PC (qu'est ce qu'il est rapide,
whaou !) fait les transferts de tous les fichiers avec un disque dur
externe, commencé à réinstaller tous mes logiciels, tout est OK
Mais BIG QUESTION : comment je fais pour le transfert de mon vieux Win98
- de mon carnet d'adresse (OE6)
- tous mes mails (reçus, envoyés, etc...) (OE6)
et la réinstallation vers le nouveau ?...
Merci encore !
Anne
François , dans le message <46bb7515$0$5066$, a écrit :
Tu fais comment, pour protéger ta bécane (et tes données) des intrusions ?
Je ne lance que des serveurs que je souhaite lancer, et je les tiens à jour.
En posant la question, tu montres que tu n'as qu'une idée très approximative du fonctionnement d'un réseau, et de l'effet d'un firewall.
Sur un réseau, un ordinateur envoie des paquets à un autre ordinateur. Le paquet arrive sur la carte réseau de la destination, où le système le lit. D'après l'entête du paquet, et en particulier des numéros appelés protocole et port, le système détermine que faire du paquet : l'ignorer, générer une réponse pour signaler une erreur, ou bien le transmettre à un programme en train de tourner, client ou serveur.
Pour qu'un paquet ou une série de paquets arrive à fournir à l'expéditeur un accès qu'il ne devrait pas avoir, il faut que l'un de ces scénarios se produise :
- Le paquet est transmis à un serveur, ce serveur est mal configuré, et au lieu de dire « désolé vous n'avez pas le droit », il répond. Un cas particulier de ce scénario, c'est quand le service est protégé par un mot de passe, mais que ce mot de passe est trop facilement devinable.
Un autre cas particulier de ce scénario, c'est le cheval de Troie : le serveur tourne à l'insu de l'utilisateur de la machine, depuis que ledit utilisateur a lancé un programme d'origine douteuse.
- Le paquet est transmis à un serveur ou à un client, il est mal formé par rapport à ce que le programme en question s'attend à recevoir, et le programme ne fait pas de vérification assez en détails. L'exemple typique est un paquet plus grand que ce que le programme est capable de gérer. Le résultat est que des bouts du paquets se retrouvent écrits n'importe où en mémoire. En calibrant bien les choses, on peut parfois arriver à faire en sorte que ces bouts viennent modifier des adresses de code à exécuter, et du coup à faire exécuter par l'ordinateur concerné un bout de code qu'on vient de lui envoyer.
- La même chose que le scénario précédent, mais le bug ne se trouve pas dans un programme, mais carrément dans la pile réseau du système d'exploitation.
Un firewall vient s'insérer au milieu de la pile réseau du système d'exploitation, avant le moment où le paquet est éventuellement transmis à un programme. Il peut alors décider de supprimer le paquet. Il intervient aussi pour les paquets que l'ordinateur ne fait que transmettre, quand il agit comme routeur entre un bout de réseau et un autre.
Supposons un administrateur compétent : il configure convenablement ses serveurs, ne lance évidemment pas de programmes d'origine douteuse, et tient à jour ses serveurs et son système par rapport aux trous de sécurité connus.
Les serveurs sont bien configurés, il n'y a pas de cheval de Troie : ça élimine le premier scénario. Les logiciels sont à jour par rapport aux trous de sécurité connus, ça élimine les deux autres.
La seule vulnérabilité qui reste, c'est ce qu'on appelle un « zero-day » : un trou de sécurité dans un logiciel qui est découvert par des personnes malintentionnés, et exploité avant que les auteurs aient eu le temps de corriger le bug et de diffuser des mises à jour.
Regardons maintenant ce qu'un firewall aurait pu faire contre un tel zero day.
Si le trou concerne un programme : par hypothèse, si le programme est là en train de tourner, c'est que l'administrateur souhaite qu'il offre un service : pas la peine de faire tourner un serveur web si c'est pour le bloquer avec un firewall, ou alors autant débrancher la prise réseau. Donc le firewall, par la force des choses, doit être configuré pour laisser passer les paquets pour ce serveur. Et en particulier les paquets mal formés permettant d'exploiter le trou.
Si le trou concerne le système : il peut se situer avant ou après le firewall. S'il se situe avant, ce qui est le plus probable puisque c'est la partie où le paquet a subi le moins d'examen de la part du système, et c'est la partie la plus complexe. Donc s'il est avant, le paquet offensif n'est pas encore passé par le firewall, le firewall n'a aucun effet. S'il est après, le firewall pourrait avoir eu un effet, c'est vrai. Mais d'un autre côté, un firewall, ça peut avoir des bugs également : ajouter le firewall dans la chaîne, ça ajoute des possibilités de trous, et ça compense largement les rares cas où il protégerait d'un zero day dans le bout de la pile réseau.
Hier, je disais :
Non, pas du tout. Un firewall sert à (1) se prémunir contre des erreurs de manipulation de l'administrateur, (2) pallier aux déficiences des mécanismes de contrôle d'accès de serveurs trop limités, et (3) limiter les utilisateurs non-administrateurs.
(1) veut dire que si l'administrateur lance des programmes d'origine douteuse se comportant comme un cheval de Troie, ou bien s'il lance par erreur un serveur avant d'avoir configuré les restrictions d'accès, ça ne donne pas accès à sa machine puisque le firewall bloque le service malencontreusement lancé.
(2) concerne le cas où on voudrait donner accès à un certain service seulement à certaines machines, par exemple toutes les machines d'un sous-réseau donné. Normalement, on configure ça au niveau du programme, mais certains programmes ne permettent pas de configurer ça. Dans ce cas, un firewall est bien pratique.
(3) concerne le cas où on a des utilisateurs sur la machine qui risquent de se faire pigeonner par des chevaux de Troie, ou qui voudraient utiliser des services auxquels ils n'ont pas droit (messagerie instantanée en milieu professionnel par exemple) : si ces utilisateurs n'ont pas le droit de configurer le firewall, le firewall les bloque, dans un sens comme dans l'autre. Ça marche également si le firewall est sur un routeur, et les utilisateurs branchent leur machine derrière ce routeur.
François , dans le message <46bb7515$0$5066$ba4acef3@news.orange.fr>, a
écrit :
Tu fais comment, pour protéger ta bécane (et tes données) des intrusions ?
Je ne lance que des serveurs que je souhaite lancer, et je les tiens à jour.
En posant la question, tu montres que tu n'as qu'une idée très approximative
du fonctionnement d'un réseau, et de l'effet d'un firewall.
Sur un réseau, un ordinateur envoie des paquets à un autre ordinateur. Le
paquet arrive sur la carte réseau de la destination, où le système le lit.
D'après l'entête du paquet, et en particulier des numéros appelés protocole
et port, le système détermine que faire du paquet : l'ignorer, générer une
réponse pour signaler une erreur, ou bien le transmettre à un programme en
train de tourner, client ou serveur.
Pour qu'un paquet ou une série de paquets arrive à fournir à l'expéditeur un
accès qu'il ne devrait pas avoir, il faut que l'un de ces scénarios se
produise :
- Le paquet est transmis à un serveur, ce serveur est mal configuré, et au
lieu de dire « désolé vous n'avez pas le droit », il répond. Un cas
particulier de ce scénario, c'est quand le service est protégé par un mot
de passe, mais que ce mot de passe est trop facilement devinable.
Un autre cas particulier de ce scénario, c'est le cheval de Troie : le
serveur tourne à l'insu de l'utilisateur de la machine, depuis que ledit
utilisateur a lancé un programme d'origine douteuse.
- Le paquet est transmis à un serveur ou à un client, il est mal formé par
rapport à ce que le programme en question s'attend à recevoir, et le
programme ne fait pas de vérification assez en détails. L'exemple typique
est un paquet plus grand que ce que le programme est capable de gérer. Le
résultat est que des bouts du paquets se retrouvent écrits n'importe où en
mémoire. En calibrant bien les choses, on peut parfois arriver à faire en
sorte que ces bouts viennent modifier des adresses de code à exécuter, et
du coup à faire exécuter par l'ordinateur concerné un bout de code qu'on
vient de lui envoyer.
- La même chose que le scénario précédent, mais le bug ne se trouve pas dans
un programme, mais carrément dans la pile réseau du système
d'exploitation.
Un firewall vient s'insérer au milieu de la pile réseau du système
d'exploitation, avant le moment où le paquet est éventuellement transmis à
un programme. Il peut alors décider de supprimer le paquet. Il intervient
aussi pour les paquets que l'ordinateur ne fait que transmettre, quand il
agit comme routeur entre un bout de réseau et un autre.
Supposons un administrateur compétent : il configure convenablement ses
serveurs, ne lance évidemment pas de programmes d'origine douteuse, et tient
à jour ses serveurs et son système par rapport aux trous de sécurité connus.
Les serveurs sont bien configurés, il n'y a pas de cheval de Troie : ça
élimine le premier scénario. Les logiciels sont à jour par rapport aux trous
de sécurité connus, ça élimine les deux autres.
La seule vulnérabilité qui reste, c'est ce qu'on appelle un « zero-day » :
un trou de sécurité dans un logiciel qui est découvert par des personnes
malintentionnés, et exploité avant que les auteurs aient eu le temps de
corriger le bug et de diffuser des mises à jour.
Regardons maintenant ce qu'un firewall aurait pu faire contre un tel zero
day.
Si le trou concerne un programme : par hypothèse, si le programme est là en
train de tourner, c'est que l'administrateur souhaite qu'il offre un
service : pas la peine de faire tourner un serveur web si c'est pour le
bloquer avec un firewall, ou alors autant débrancher la prise réseau. Donc
le firewall, par la force des choses, doit être configuré pour laisser
passer les paquets pour ce serveur. Et en particulier les paquets mal formés
permettant d'exploiter le trou.
Si le trou concerne le système : il peut se situer avant ou après le
firewall. S'il se situe avant, ce qui est le plus probable puisque c'est la
partie où le paquet a subi le moins d'examen de la part du système, et c'est
la partie la plus complexe. Donc s'il est avant, le paquet offensif n'est
pas encore passé par le firewall, le firewall n'a aucun effet. S'il est
après, le firewall pourrait avoir eu un effet, c'est vrai. Mais d'un autre
côté, un firewall, ça peut avoir des bugs également : ajouter le firewall
dans la chaîne, ça ajoute des possibilités de trous, et ça compense
largement les rares cas où il protégerait d'un zero day dans le bout de la
pile réseau.
Hier, je disais :
Non, pas du tout. Un firewall sert à (1) se prémunir contre des erreurs de
manipulation de l'administrateur, (2) pallier aux déficiences des mécanismes
de contrôle d'accès de serveurs trop limités, et (3) limiter les
utilisateurs non-administrateurs.
(1) veut dire que si l'administrateur lance des programmes d'origine
douteuse se comportant comme un cheval de Troie, ou bien s'il lance par
erreur un serveur avant d'avoir configuré les restrictions d'accès, ça ne
donne pas accès à sa machine puisque le firewall bloque le service
malencontreusement lancé.
(2) concerne le cas où on voudrait donner accès à un certain service
seulement à certaines machines, par exemple toutes les machines d'un
sous-réseau donné. Normalement, on configure ça au niveau du programme, mais
certains programmes ne permettent pas de configurer ça. Dans ce cas, un
firewall est bien pratique.
(3) concerne le cas où on a des utilisateurs sur la machine qui risquent de
se faire pigeonner par des chevaux de Troie, ou qui voudraient utiliser des
services auxquels ils n'ont pas droit (messagerie instantanée en milieu
professionnel par exemple) : si ces utilisateurs n'ont pas le droit de
configurer le firewall, le firewall les bloque, dans un sens comme dans
l'autre. Ça marche également si le firewall est sur un routeur, et les
utilisateurs branchent leur machine derrière ce routeur.
François , dans le message <46bb7515$0$5066$, a écrit :
Tu fais comment, pour protéger ta bécane (et tes données) des intrusions ?
Je ne lance que des serveurs que je souhaite lancer, et je les tiens à jour.
En posant la question, tu montres que tu n'as qu'une idée très approximative du fonctionnement d'un réseau, et de l'effet d'un firewall.
Sur un réseau, un ordinateur envoie des paquets à un autre ordinateur. Le paquet arrive sur la carte réseau de la destination, où le système le lit. D'après l'entête du paquet, et en particulier des numéros appelés protocole et port, le système détermine que faire du paquet : l'ignorer, générer une réponse pour signaler une erreur, ou bien le transmettre à un programme en train de tourner, client ou serveur.
Pour qu'un paquet ou une série de paquets arrive à fournir à l'expéditeur un accès qu'il ne devrait pas avoir, il faut que l'un de ces scénarios se produise :
- Le paquet est transmis à un serveur, ce serveur est mal configuré, et au lieu de dire « désolé vous n'avez pas le droit », il répond. Un cas particulier de ce scénario, c'est quand le service est protégé par un mot de passe, mais que ce mot de passe est trop facilement devinable.
Un autre cas particulier de ce scénario, c'est le cheval de Troie : le serveur tourne à l'insu de l'utilisateur de la machine, depuis que ledit utilisateur a lancé un programme d'origine douteuse.
- Le paquet est transmis à un serveur ou à un client, il est mal formé par rapport à ce que le programme en question s'attend à recevoir, et le programme ne fait pas de vérification assez en détails. L'exemple typique est un paquet plus grand que ce que le programme est capable de gérer. Le résultat est que des bouts du paquets se retrouvent écrits n'importe où en mémoire. En calibrant bien les choses, on peut parfois arriver à faire en sorte que ces bouts viennent modifier des adresses de code à exécuter, et du coup à faire exécuter par l'ordinateur concerné un bout de code qu'on vient de lui envoyer.
- La même chose que le scénario précédent, mais le bug ne se trouve pas dans un programme, mais carrément dans la pile réseau du système d'exploitation.
Un firewall vient s'insérer au milieu de la pile réseau du système d'exploitation, avant le moment où le paquet est éventuellement transmis à un programme. Il peut alors décider de supprimer le paquet. Il intervient aussi pour les paquets que l'ordinateur ne fait que transmettre, quand il agit comme routeur entre un bout de réseau et un autre.
Supposons un administrateur compétent : il configure convenablement ses serveurs, ne lance évidemment pas de programmes d'origine douteuse, et tient à jour ses serveurs et son système par rapport aux trous de sécurité connus.
Les serveurs sont bien configurés, il n'y a pas de cheval de Troie : ça élimine le premier scénario. Les logiciels sont à jour par rapport aux trous de sécurité connus, ça élimine les deux autres.
La seule vulnérabilité qui reste, c'est ce qu'on appelle un « zero-day » : un trou de sécurité dans un logiciel qui est découvert par des personnes malintentionnés, et exploité avant que les auteurs aient eu le temps de corriger le bug et de diffuser des mises à jour.
Regardons maintenant ce qu'un firewall aurait pu faire contre un tel zero day.
Si le trou concerne un programme : par hypothèse, si le programme est là en train de tourner, c'est que l'administrateur souhaite qu'il offre un service : pas la peine de faire tourner un serveur web si c'est pour le bloquer avec un firewall, ou alors autant débrancher la prise réseau. Donc le firewall, par la force des choses, doit être configuré pour laisser passer les paquets pour ce serveur. Et en particulier les paquets mal formés permettant d'exploiter le trou.
Si le trou concerne le système : il peut se situer avant ou après le firewall. S'il se situe avant, ce qui est le plus probable puisque c'est la partie où le paquet a subi le moins d'examen de la part du système, et c'est la partie la plus complexe. Donc s'il est avant, le paquet offensif n'est pas encore passé par le firewall, le firewall n'a aucun effet. S'il est après, le firewall pourrait avoir eu un effet, c'est vrai. Mais d'un autre côté, un firewall, ça peut avoir des bugs également : ajouter le firewall dans la chaîne, ça ajoute des possibilités de trous, et ça compense largement les rares cas où il protégerait d'un zero day dans le bout de la pile réseau.
Hier, je disais :
Non, pas du tout. Un firewall sert à (1) se prémunir contre des erreurs de manipulation de l'administrateur, (2) pallier aux déficiences des mécanismes de contrôle d'accès de serveurs trop limités, et (3) limiter les utilisateurs non-administrateurs.
(1) veut dire que si l'administrateur lance des programmes d'origine douteuse se comportant comme un cheval de Troie, ou bien s'il lance par erreur un serveur avant d'avoir configuré les restrictions d'accès, ça ne donne pas accès à sa machine puisque le firewall bloque le service malencontreusement lancé.
(2) concerne le cas où on voudrait donner accès à un certain service seulement à certaines machines, par exemple toutes les machines d'un sous-réseau donné. Normalement, on configure ça au niveau du programme, mais certains programmes ne permettent pas de configurer ça. Dans ce cas, un firewall est bien pratique.
(3) concerne le cas où on a des utilisateurs sur la machine qui risquent de se faire pigeonner par des chevaux de Troie, ou qui voudraient utiliser des services auxquels ils n'ont pas droit (messagerie instantanée en milieu professionnel par exemple) : si ces utilisateurs n'ont pas le droit de configurer le firewall, le firewall les bloque, dans un sens comme dans l'autre. Ça marche également si le firewall est sur un routeur, et les utilisateurs branchent leur machine derrière ce routeur.
Alain Naigeon
"Nicolas George" <nicolas$ a écrit dans le message de news: 46bb2b26$0$413$
"Alain Naigeon" wrote in message <46bb2a00$0$424$:
http://maxilien.com/?ajjqGOXEib
http://www.w3.org/TR/2003/REC-PNG-20031110
Tiens ils ne savent pas lire les bmp chez Linux ??! LOL
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Oberhoffen/Moder, France
"Nicolas George" <nicolas$george@salle-s.org> a écrit dans le message de
news: 46bb2b26$0$413$426a74cc@news.free.fr...
"Alain Naigeon" wrote in message
<46bb2a00$0$424$426a74cc@news.free.fr>:
http://maxilien.com/?ajjqGOXEib
http://www.w3.org/TR/2003/REC-PNG-20031110
Tiens ils ne savent pas lire les bmp chez Linux ??! LOL
--
Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - anaigeon@free.fr - Oberhoffen/Moder, France
"Nicolas George" <nicolas$ a écrit dans le message de news: 46bb2b26$0$413$
"Alain Naigeon" wrote in message <46bb2a00$0$424$:
http://maxilien.com/?ajjqGOXEib
http://www.w3.org/TR/2003/REC-PNG-20031110
Tiens ils ne savent pas lire les bmp chez Linux ??! LOL
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Oberhoffen/Moder, France
Nicolas George
"Alain Naigeon" , dans le message <46bb99a6$0$418$, a écrit :
Tiens ils ne savent pas lire les bmp chez Linux ??! LOL
Si. Mais en plus, ils savent qu'il faut vraiment être aussi con qu'un windowsien pour publier un BMP de 100 ko quand la même image en PNG en fait moins de 7.
"Alain Naigeon" , dans le message
<46bb99a6$0$418$426a74cc@news.free.fr>, a écrit :
Tiens ils ne savent pas lire les bmp chez Linux ??! LOL
Si. Mais en plus, ils savent qu'il faut vraiment être aussi con qu'un
windowsien pour publier un BMP de 100 ko quand la même image en PNG en fait
moins de 7.
"Alain Naigeon" , dans le message <46bb99a6$0$418$, a écrit :
Tiens ils ne savent pas lire les bmp chez Linux ??! LOL
Si. Mais en plus, ils savent qu'il faut vraiment être aussi con qu'un windowsien pour publier un BMP de 100 ko quand la même image en PNG en fait moins de 7.
Nina Popravka
On Thu, 9 Aug 2007 19:23:53 +0200, "speedsoft.nospam" wrote:
Alors je veux bien admettre que je n'ai pas eu de chance, que les 3 sociétés que j'ai contactées pour reinstaller l'info d'une officine étaient les 3 plus nulles du secteur
Pas nécessairement hélas. J'ai constaté également que ce genre d'officine a une fâcheuse tendance à vouloir réinventer la roue. Ca peut finir par des roues très chères. :-) -- Nina
On Thu, 9 Aug 2007 19:23:53 +0200, "speedsoft.nospam"
<speed.soft@tele2.fr> wrote:
Alors je veux bien admettre que je n'ai pas eu de chance, que les 3 sociétés
que j'ai contactées pour reinstaller l'info d'une officine étaient les 3
plus nulles du secteur
Pas nécessairement hélas.
J'ai constaté également que ce genre d'officine a une fâcheuse
tendance à vouloir réinventer la roue. Ca peut finir par des roues
très chères. :-)
--
Nina
On Thu, 9 Aug 2007 19:23:53 +0200, "speedsoft.nospam" wrote:
Alors je veux bien admettre que je n'ai pas eu de chance, que les 3 sociétés que j'ai contactées pour reinstaller l'info d'une officine étaient les 3 plus nulles du secteur
Pas nécessairement hélas. J'ai constaté également que ce genre d'officine a une fâcheuse tendance à vouloir réinventer la roue. Ca peut finir par des roues très chères. :-) -- Nina
Nicolas George
"speedsoft.nospam" wrote in message <Z4Iui.140$:
Je ne me permettrais pas de dire que Linux est un "mauvais" outil car je ne le connais pas en détail.
Si, tu t'es permis de le dire.
En revanche, je peux dire que bcp de SSII linux proposent des solutions déconnantes, tant techniquement qu'économiquement.
Enlève la précision « Linux » si tu veux être honnête.
"speedsoft.nospam" wrote in message
<Z4Iui.140$5u5.81@nntpserver.swip.net>:
Je ne me permettrais pas de dire que Linux est un "mauvais" outil car je ne
le connais pas en détail.
Si, tu t'es permis de le dire.
En revanche, je peux dire que bcp de SSII linux proposent des solutions
déconnantes, tant techniquement qu'économiquement.
Enlève la précision « Linux » si tu veux être honnête.
"speedsoft.nospam" , dans le message <46bc30b3$0$424$, a écrit :
Arol déteint ???
http://fr.wiktionary.org/wiki/boutade
speedsoft.nospam
"Nicolas George" <nicolas$ a écrit dans le message de news: 46bc2ea7$0$437$
"speedsoft.nospam" wrote in message <Z4Iui.140$:
Je ne me permettrais pas de dire que Linux est un "mauvais" outil car je ne le connais pas en détail.
Si, tu t'es permis de le dire.
Non désolé. Soyons précis :
8/8 17:41 : globalement ce post n'est pas une attaque contre Linux mais contre bcp de jeunes prosélytes que j'ai rencontré. Et je maintiens, tout en sachant pertinemment que Linux -peut- être un outil professionnel au même titre qu'Unix ! 8/8 17:54 : "Le seul but était de remettre Linux à sa place: dans la caisse à jouets... pour les neuneux comme toi qui croient y avoir redécouvert la roue ! " Remarque exclusivement destinées à Arol !!!
Pour le reste, encore une fois, je regrette sincèrement que TOUS les contacts professionnels que j'ai pu avoir avec Linux aient été déplorables ! C'est comme ça !
En revanche, je peux dire que bcp de SSII linux proposent des solutions déconnantes, tant techniquement qu'économiquement.
Enlève la précision « Linux » si tu veux être honnête.
En aucun cas, car à ce stade, je n'avais AUCUNE idée préconcue contre Linux. Je suis 100% honnête en disant : 1) que la solution implantée dans l'officine était déjà sous Linux et merdait de façon catastrophique. 2) qu'à partir de la demande d'un ami qui ne connait rien à l'info, j'ai fait 6 demandes de devis : 3 sous Linux et 3 sous Windows. 3) que sur les 3 devis Linux, 2 étaient des torchons hors de prix, établis par des Sociétés spécialisées dans la pharma et chez lesquels mes interlocuteurs techniques présentaient à 90% les caractéristiques dénoncées dans un des mes posts précédents. Un m'a même dit, alros que je lui faisais remarquer que le prix unitaire des terminaux (PC moyenne gamme) était 30% plus élevé que celui des propositions Windows (malgré un équipement inférieur et l'absence de licence Windows): "Oui mais moi je vous vends un "ensemble Hard + linux" qui sera au moins 50% plus performant que votre solution Windows"... Je lui ai demandé de le prouver.. Fin de l'épisode. Le dernier devis est celui que j'ai déjà évoqué 4) que sur les 3 devis Windows, un était clean, mais près de 2 fois plus cher que celui retenu.... 5) qu'aucune solution Windows ne me facturait du temps de développement pour des drivers de périphériques non supportés, ni d'écriture d'interface Windows / Linux, ni des temps d'insatllation et formation irréalistes dans le cadre de la gestion d'une officine.... CQFD (mais ne veut pas dire qu'il n'y a pas - quelque part- une boite qui développe tout ça sous Linux, de façon honnête compétente et compétitive !!!
"Nicolas George" <nicolas$george@salle-s.org> a écrit dans le message de
news: 46bc2ea7$0$437$426a74cc@news.free.fr...
"speedsoft.nospam" wrote in message
<Z4Iui.140$5u5.81@nntpserver.swip.net>:
Je ne me permettrais pas de dire que Linux est un "mauvais" outil car je
ne
le connais pas en détail.
Si, tu t'es permis de le dire.
Non désolé. Soyons précis :
8/8 17:41 : globalement ce post n'est pas une attaque contre Linux mais
contre bcp de jeunes prosélytes que j'ai rencontré. Et je maintiens, tout en
sachant pertinemment que Linux -peut- être un outil professionnel au même
titre qu'Unix !
8/8 17:54 : "Le seul but était de remettre Linux à sa place:
dans la caisse à jouets... pour les neuneux comme toi qui croient y avoir
redécouvert la roue ! "
Remarque exclusivement destinées à Arol !!!
Pour le reste, encore une fois, je regrette sincèrement que TOUS les
contacts professionnels que j'ai pu avoir avec Linux aient été déplorables !
C'est comme ça !
En revanche, je peux dire que bcp de SSII linux proposent des solutions
déconnantes, tant techniquement qu'économiquement.
Enlève la précision « Linux » si tu veux être honnête.
En aucun cas, car à ce stade, je n'avais AUCUNE idée préconcue contre Linux.
Je suis 100% honnête en disant :
1) que la solution implantée dans l'officine était déjà sous Linux et
merdait de façon catastrophique.
2) qu'à partir de la demande d'un ami qui ne connait rien à l'info, j'ai
fait 6 demandes de devis : 3 sous Linux et 3 sous Windows.
3) que sur les 3 devis Linux, 2 étaient des torchons hors de prix, établis
par des Sociétés spécialisées dans la pharma et chez lesquels mes
interlocuteurs techniques présentaient à 90% les caractéristiques dénoncées
dans un des mes posts précédents. Un m'a même dit, alros que je lui faisais
remarquer que le prix unitaire des terminaux (PC moyenne gamme) était 30%
plus élevé que celui des propositions Windows (malgré un équipement
inférieur et l'absence de licence Windows): "Oui mais moi je vous vends un
"ensemble Hard + linux" qui sera au moins 50% plus performant que votre
solution Windows"... Je lui ai demandé de le prouver.. Fin de l'épisode. Le
dernier devis est celui que j'ai déjà évoqué
4) que sur les 3 devis Windows, un était clean, mais près de 2 fois plus
cher que celui retenu....
5) qu'aucune solution Windows ne me facturait du temps de développement pour
des drivers de périphériques non supportés, ni d'écriture d'interface
Windows / Linux, ni des temps d'insatllation et formation irréalistes dans
le cadre de la gestion d'une officine....
CQFD (mais ne veut pas dire qu'il n'y a pas - quelque part- une boite qui
développe tout ça sous Linux, de façon honnête compétente et compétitive !!!
"Nicolas George" <nicolas$ a écrit dans le message de news: 46bc2ea7$0$437$
"speedsoft.nospam" wrote in message <Z4Iui.140$:
Je ne me permettrais pas de dire que Linux est un "mauvais" outil car je ne le connais pas en détail.
Si, tu t'es permis de le dire.
Non désolé. Soyons précis :
8/8 17:41 : globalement ce post n'est pas une attaque contre Linux mais contre bcp de jeunes prosélytes que j'ai rencontré. Et je maintiens, tout en sachant pertinemment que Linux -peut- être un outil professionnel au même titre qu'Unix ! 8/8 17:54 : "Le seul but était de remettre Linux à sa place: dans la caisse à jouets... pour les neuneux comme toi qui croient y avoir redécouvert la roue ! " Remarque exclusivement destinées à Arol !!!
Pour le reste, encore une fois, je regrette sincèrement que TOUS les contacts professionnels que j'ai pu avoir avec Linux aient été déplorables ! C'est comme ça !
En revanche, je peux dire que bcp de SSII linux proposent des solutions déconnantes, tant techniquement qu'économiquement.
Enlève la précision « Linux » si tu veux être honnête.
En aucun cas, car à ce stade, je n'avais AUCUNE idée préconcue contre Linux. Je suis 100% honnête en disant : 1) que la solution implantée dans l'officine était déjà sous Linux et merdait de façon catastrophique. 2) qu'à partir de la demande d'un ami qui ne connait rien à l'info, j'ai fait 6 demandes de devis : 3 sous Linux et 3 sous Windows. 3) que sur les 3 devis Linux, 2 étaient des torchons hors de prix, établis par des Sociétés spécialisées dans la pharma et chez lesquels mes interlocuteurs techniques présentaient à 90% les caractéristiques dénoncées dans un des mes posts précédents. Un m'a même dit, alros que je lui faisais remarquer que le prix unitaire des terminaux (PC moyenne gamme) était 30% plus élevé que celui des propositions Windows (malgré un équipement inférieur et l'absence de licence Windows): "Oui mais moi je vous vends un "ensemble Hard + linux" qui sera au moins 50% plus performant que votre solution Windows"... Je lui ai demandé de le prouver.. Fin de l'épisode. Le dernier devis est celui que j'ai déjà évoqué 4) que sur les 3 devis Windows, un était clean, mais près de 2 fois plus cher que celui retenu.... 5) qu'aucune solution Windows ne me facturait du temps de développement pour des drivers de périphériques non supportés, ni d'écriture d'interface Windows / Linux, ni des temps d'insatllation et formation irréalistes dans le cadre de la gestion d'une officine.... CQFD (mais ne veut pas dire qu'il n'y a pas - quelque part- une boite qui développe tout ça sous Linux, de façon honnête compétente et compétitive !!!
Nicolas George
"speedsoft.nospam" wrote in message <46bc3c93$0$406$:
Pour le reste, encore une fois, je regrette sincèrement que TOUS les contacts professionnels que j'ai pu avoir avec Linux aient été déplorables ! C'est comme ça !
J'en doute. Je ne sais pas si tu le crois honnêtement, et si c'est juste ta perception qui est brouillée par tes préjugés ou si tu mens délibérément, mais le fait est que ce que tu présentes ne correspond pas à la réalité.
Je suis 100% honnête en disant : <nip>
CQFD
Non, justement, pas CQFD : tu ne prouves rien avec un exemple isolé comme ça. Et la malhonnêteté de ta part est justement de présenter cet exemple comme significatif.
"speedsoft.nospam" wrote in message
<46bc3c93$0$406$426a74cc@news.free.fr>:
Pour le reste, encore une fois, je regrette sincèrement que TOUS les
contacts professionnels que j'ai pu avoir avec Linux aient été déplorables !
C'est comme ça !
J'en doute. Je ne sais pas si tu le crois honnêtement, et si c'est juste ta
perception qui est brouillée par tes préjugés ou si tu mens délibérément,
mais le fait est que ce que tu présentes ne correspond pas à la réalité.
Je suis 100% honnête en disant :
<nip>
CQFD
Non, justement, pas CQFD : tu ne prouves rien avec un exemple isolé comme
ça. Et la malhonnêteté de ta part est justement de présenter cet exemple
comme significatif.
"speedsoft.nospam" wrote in message <46bc3c93$0$406$:
Pour le reste, encore une fois, je regrette sincèrement que TOUS les contacts professionnels que j'ai pu avoir avec Linux aient été déplorables ! C'est comme ça !
J'en doute. Je ne sais pas si tu le crois honnêtement, et si c'est juste ta perception qui est brouillée par tes préjugés ou si tu mens délibérément, mais le fait est que ce que tu présentes ne correspond pas à la réalité.
Je suis 100% honnête en disant : <nip>
CQFD
Non, justement, pas CQFD : tu ne prouves rien avec un exemple isolé comme ça. Et la malhonnêteté de ta part est justement de présenter cet exemple comme significatif.
speedsoft.nospam
"Nicolas George" <nicolas$ a écrit dans le message de news: 46bc3dd4$0$437$
"speedsoft.nospam" wrote in message <46bc3c93$0$406$:
Pour le reste, encore une fois, je regrette sincèrement que TOUS les contacts professionnels que j'ai pu avoir avec Linux aient été déplorables ! C'est comme ça !
J'en doute. Je ne sais pas si tu le crois honnêtement, et si c'est juste ta perception qui est brouillée par tes préjugés ou si tu mens délibérément, mais le fait est que ce que tu présentes ne correspond pas à la réalité.
Je n'ai rien à foutre de tes procès d'intention ! C'est comme ça POINT. Je vois clair, ma vue n'est pas brouillée ... Je n'ai (n'avais serait plus exact) aucun préjugé sur Linux, bien au contraire. Ma perception est diifférente de la tienne... dont acte. Je ne vois pas pourquoi je mentirais... Ou pourquoi tu ne mentirais pas... toi ??? Tu es prosélyte et Tu concentres brièvement tout ce que bcp reprochent aux Linuxiens.... Tu considères que TA réalité est univoque et que toute autre vision d'une réalité, par essence polymorphe et variable, ne peut être que distortion ou mensonge! C'est ça, le dogme !
Je suis 100% honnête en disant : <nip>
CQFD
Non, justement, pas CQFD : tu ne prouves rien avec un exemple isolé comme ça. Et la malhonnêteté de ta part est justement de présenter cet exemple comme significatif.
Mais bien sur, 6 devis pour un projet de cette ampleur (à l'échelle d'un petit commerce, bien sur)... ça reste un ... exemple isolé. Et je persiste à dire (au moins aussi malhonnête que toi dans cette argumentation ) que - dans ce type d'application - il est extrêmement significatif, mais si, bien évidemment, il n'est pas généralisable.
"Nicolas George" <nicolas$george@salle-s.org> a écrit dans le message de
news: 46bc3dd4$0$437$426a74cc@news.free.fr...
"speedsoft.nospam" wrote in message
<46bc3c93$0$406$426a74cc@news.free.fr>:
Pour le reste, encore une fois, je regrette sincèrement que TOUS les
contacts professionnels que j'ai pu avoir avec Linux aient été
déplorables !
C'est comme ça !
J'en doute. Je ne sais pas si tu le crois honnêtement, et si c'est juste
ta
perception qui est brouillée par tes préjugés ou si tu mens délibérément,
mais le fait est que ce que tu présentes ne correspond pas à la réalité.
Je n'ai rien à foutre de tes procès d'intention ! C'est comme ça POINT. Je
vois clair, ma vue n'est pas brouillée ...
Je n'ai (n'avais serait plus exact) aucun préjugé sur Linux, bien au
contraire.
Ma perception est diifférente de la tienne... dont acte. Je ne vois pas
pourquoi je mentirais... Ou pourquoi tu ne mentirais pas... toi ??? Tu es
prosélyte et
Tu concentres brièvement tout ce que bcp reprochent aux Linuxiens....
Tu considères que TA réalité est univoque et que toute autre vision d'une
réalité, par essence polymorphe et variable, ne peut être que distortion ou
mensonge!
C'est ça, le dogme !
Je suis 100% honnête en disant :
<nip>
CQFD
Non, justement, pas CQFD : tu ne prouves rien avec un exemple isolé comme
ça. Et la malhonnêteté de ta part est justement de présenter cet exemple
comme significatif.
Mais bien sur, 6 devis pour un projet de cette ampleur (à l'échelle d'un
petit commerce, bien sur)... ça reste un ... exemple isolé.
Et je persiste à dire (au moins aussi malhonnête que toi dans cette
argumentation ) que - dans ce type d'application - il est extrêmement
significatif, mais si, bien évidemment, il n'est pas généralisable.
"Nicolas George" <nicolas$ a écrit dans le message de news: 46bc3dd4$0$437$
"speedsoft.nospam" wrote in message <46bc3c93$0$406$:
Pour le reste, encore une fois, je regrette sincèrement que TOUS les contacts professionnels que j'ai pu avoir avec Linux aient été déplorables ! C'est comme ça !
J'en doute. Je ne sais pas si tu le crois honnêtement, et si c'est juste ta perception qui est brouillée par tes préjugés ou si tu mens délibérément, mais le fait est que ce que tu présentes ne correspond pas à la réalité.
Je n'ai rien à foutre de tes procès d'intention ! C'est comme ça POINT. Je vois clair, ma vue n'est pas brouillée ... Je n'ai (n'avais serait plus exact) aucun préjugé sur Linux, bien au contraire. Ma perception est diifférente de la tienne... dont acte. Je ne vois pas pourquoi je mentirais... Ou pourquoi tu ne mentirais pas... toi ??? Tu es prosélyte et Tu concentres brièvement tout ce que bcp reprochent aux Linuxiens.... Tu considères que TA réalité est univoque et que toute autre vision d'une réalité, par essence polymorphe et variable, ne peut être que distortion ou mensonge! C'est ça, le dogme !
Je suis 100% honnête en disant : <nip>
CQFD
Non, justement, pas CQFD : tu ne prouves rien avec un exemple isolé comme ça. Et la malhonnêteté de ta part est justement de présenter cet exemple comme significatif.
Mais bien sur, 6 devis pour un projet de cette ampleur (à l'échelle d'un petit commerce, bien sur)... ça reste un ... exemple isolé. Et je persiste à dire (au moins aussi malhonnête que toi dans cette argumentation ) que - dans ce type d'application - il est extrêmement significatif, mais si, bien évidemment, il n'est pas généralisable.
