Il me semble que c'est le coté "utilisation urgente et ponctuelle" qui est tolérée de facto. Ensuite la charte informatique est la pour dicter ce qui est (ou non) toléré par l'entreprise, et celles qu'il m'a été donné de lire stipulent justement qu'elles respectent la loi et permettent les utilisations ponctuelles et urgentes.
Par exemple l'entreprise ne pourra pas te mettre a la porte si tu passe des coups de fil privés parceque ton gosse est malade, t'es à découvert et t'appelle ton banquier, ... c'est le caractère de nécéssité qui prévaut.
Si le but c'est de travailler sur des affaires personnelles depuis le boulot en se loggant sur ta machine de la maison, ... faudra prouver le "ponctuel" et "urgent" :-)
IPsec/IKE y'a pas plus pratique pour etre sur que ce soit pas interroperable, supporte mal le nat, soit mal implémenté ...
Je ne dis pas que réinventer a chaque fois c'est bien, mais ipsec ...
Posté par PLuG .
En réponse au message charge/load.
Évalué à 8.
la charge (load) est donnée souvent avec 3 chiffres:
=> moyenne sur une minute, 5 minutes et 15 minutes.
prérequis:
- le temps de chaque cpu de la machine est coupé en timeslices
(tranches de temps)
- le schéduleur attribue ces tranches aux process tour à tour (c'est son job).
la charge est calculée par le scheduleur, et représente le nombre de process éligibles lorsque le scheduleur veut distribuer une tranche de temps cpu.
On comprend aisément que sue un monoprocesseur, si cette moyenne est inférieure à 1, la machine possède des tranche de temps dont aucun process n'a besoin.
si la moyenne est supérieure à 1, c'est l'inverse, les process "attendent" que le cpu soit libre pour tourner.
en pratique, une charge > nbr-cpu n'est pas un gros problème si les applications sont de type "batch", genre routage des mails (passerelle smtp). par contre sur un serveur web ou le laptop bureautique c'est un peu gênant (manque de réactivité).
ça te plait ?
HyperThreading:
mon expérience dit que les machines hyperthreadée sont un véritable piège pour le schéduleur qui y voit 2 cpu alors que le second n'est pas très puissant ni libre quand le premier tourne à plein. l'hyperthreading sur une machine très chargée (load) semble donner des soucis de mauvaise gestion de la charge
(au moins en kernel 2.4.x, je vais tester le 2.6 sur cette machine sous peu).
MultiCore, pas testé mais ça doit se rapprocher du multiCpu.
ben la charge nominale n'est plus de "1" mais de nbr-cpu donc la machine reste réactive avec une plus grosse charge.
Moi j'ai de gros problèmes avec le chip BMC de ces Xseries recents.
le chip utilise la premiere interface réseau pour communiquer, et pour cela "forge" une adresse mac différente de l'adresse normale de la carte. (la carte a 2 mac adresse si vous voulez).
résultat: => pertes de paquets quand BMC s'active, bazar sur le réseau avec les fonctions de sécurité (controle des mac address sur le switch ...).
Le plus fort, c'est que le chip BMC continue ses merdoiement meme après l'avoir désactivé dans le Bios.
Résultat: ces xseries ont 2 interfaces ethernet mais seule la seconde se comporte correctement.
pas top d'accord avec ta méthode meme si elle peut fonctionner.
le (1) c'est une bonne idée.
le (2) c'est pas necessaire et meme dangereux, suffit de lire les logs du parefeu.
le (3) c'est pas top non plus.
il faut d'abord se renseigner sur le VPN en question. la doc ou les normes utilisées indiqueront les protocoles necessaires.
certains VPNs (IPSEC) ne sont pas nativement prévus pour supporter le NAT.
ce qui fait que le test en (1) ne prouve pas que cela va marcher deriere le parefeu.
pour que IPSEC supporte le NAT il faut que le client et le serveur supportent l'évolution IPSEC pour le NAT.
le mieux serait que tu nous dises quel serveur VPN et quel client VPN sont utilisés.
quel protocole (IPSEC ??)
as-tu le choix du protocole ? si oui je te conseille openvpn beaucoup plus simple que IPSEC.
Le problème du support "redhat only" c'est surtout que les distributeur (oracle par exemple) ne *veulent pas* avoir a qualifier leur produit sur plusieurs distributions.
Cela n'est *pas* un problème technique, et ne sera pas résolu par une normalisation a la LSB. D'ailleur le produit lui meme (oracle par exemple) fonctionne très bien sur les autres distributions ...
Bref pour moi "le monde pro" ne veut pas de plusieurs distributions, il n'en veut qu'une seule pour diminuer les cout de test/integration, la version de la librairie ou l'emplacement de l'installation c'est queudale comme problème a résoudre.
Non ce n'est pas juste le noyau qui se souvient ...
si effectivement ifconfig ne flash pas l'eeprom, la mac est bien stockée sur une ram accessible depuis la carte réseau.
En effet la carte réseau ne récupère que les trames a destination de sa mac, ce filtre est effectué par le chipset réseau de la carte.... sauf quand elle est en mode promiscuous (pour sniffer).
par contre cette mac est perdue au reboot, il faut donc reprogrammer la mac a chaque boot pour que ce soit définitif
>Sauf à prendre en compte les prix de l'assurance, de l'entretiens et de l'achat ...
sauf que le train n'est pas omnipotent.
on a *besoin* d'une voiture pour la vie courante (courses, déplacements avec les enfants, ...) donc l'achat/l'entretient/l'assurance font déjà partie du budget du ménage.
le train vient donc en suplément et est rarement rentable au niveau prix, moins pratique dans tous les cas, et la plupart du temps moins rapide.... meme sur un paris/lyon:
exemple: de chez moi (region parisienne) a chez mes parents (régions lyonnaise):
=> 30 minutes de RER pour aller a la gare de Lyon (a Paris),
=> 15 minutes d'avance pour le cas ou (difficile d'arriver juste a moins de risquer de le rater)
=> 2h15 de train (perrache)
=> 1h de bus avec changements et marche a pied, mais prenons le cas favorable, on vient me chercher en voiture (donc emmerdé quelqu'un pour qu'il perde de *son* temps a ma place: 30 minutes de voiture)
TOTAL: 4h.
ah ? ben en moins de 4h je fais le meme trajet par autoroute, j'emmerde personne et j'ai ma voiture de dispo a l'arrivée.
Je ne comprend pas le prix du train.
D'ailleur, comparez aussi le prix du transport ferroviaire et par route, et bien c'est moins cher de faire rouler des poids lourds... si vous voulez supprimer les camion, faudra faire baisser le prix de la sncf.
la detection en live c'est pour empecher de chopper le virus.
si tu fais des verifications toutes les semaines, cela n'empeche pas le virus de s'installer quand il pointe son nez, et de commencer ses actions.
imaginons qu'il reformate le disque des le deuxieme jour => tout perdu.
de plus si tu n'empeche pas l'installation du virus en verifiant a la volée, il faudra booter sur un media propre pour tester ta machine toutes les semaines. (ce qui de toutes façons est une bonne méthode).
A l'époque des réservoirs en métal il y avait des possibilités d'explosion,
A l'époque des réservoirs métaliques a l'avant, les possibilités de brulure/explosion étaient très grandes.
De nos jours, les reservoirs (essence/gazoil) sont tous EN PLASTIQUE, avec la chaleur ils fondent, répendant l'essence au sol, a l'arrière du véhicule, afin de limiter la casse.
mais dans les films, c'est moins rigolo une voiture qui prend feu doucement et les gens qui sortent.
NB1: avec la flaque d'essence en dessous, une voiture brule en environ 15 minutes quand meme ...
NB2: le GPL utilise des soupapes pour éviter l'explosion.
=> c'est le compteur de ticks d'horloge (sysUptime sous windows) qui déborde et repasse a zéro. le phénomène arrive tous les 49.7 jours.
Ce problème existe aussi sous OS/2, ou il est difficile a corriger car chaque driver vient lire la valeur a l'adresse du compteur directement (au lieu d'utiliser une fonction dans laquelle on pourait corriger une bonne fois pour toutes le problème).
Je ne sais pas pour Windows, mais OS/2, lui, ne fait que jouer a la roulette russe tous les 49.7 jours. En effet le crash n'est pas garanti, c'est juste si on a pas de chance et qu'un morceau de code a fait des lectures du compteurs au moment de l'overflow (genre un chronometrage avec soustraction de t2-t1 qui devient très grand ou négatif)
le GROS probleme c'est surtout qu'une fois compressé il est beaucoup plus difficile de restaurer une bande avec des erreurs de lecture.
un tar sur une bande deffectueuse => on recupere aisement la totalite des fichiers n'utilisant pas le morceau de bande abimé.
un tar gzippé ou bzippé => plus rien.
Sinon pour ce qui est de MS Office, c'est très logique que les utilisateurs pousse pour l'avoir: c'est ce qu'ils utilise à la maison, c'est ce qu'ils ont utilisé à l'école et c'est ce qu'ils ont utilisé dans leurs autres emplois..
De plus ils font comment pour envoyer ou recevoir des documents avec le reste du monde?
Ben justement, la STB, sous OS/2 c'est un poste de travail dédié pour prendre des commandes de clients. Les STB ne sont pas prévues pour faire autre chose que des applications métier (prise de commande, recherches de clients dans la DB, affectation de n°de téléphone ...).
La plupart des agents FT n'ont pas vraiment a "échanger avec le reste du monde", sauf de vive voix au téléphone ou de visu.
Word 2.0c c'est bien antérieur a Office97, c'est une version de word ou l'utilisateur apprend a sauvegarder toutes les 2 lignes pour ne pas trop perdre de données au prochain crash inévitable :-)
mais bon pour revenir sur le sujet, les LINEX remplaçaient les SILEX (SCO UNIX) et non pas les postes de travail sous OS/2 nommés STB (Station de Travail Banalisée).
A l'époque je n'avais pas réussi a convaincre de migrer ces stations de travail sous linux. Je ne sais pas ce que c'est devenu mais en 2000/2001 les tests les plus aboutis se faisaient sous windows ... :-(
Il faut dire que les STB OS/2 marchaient bien, et que c'est principalement les utilisateurs qui poussaient pour upgrader vers Windows et pouvoir entre autre avoir un MS Office a jour (sous OS/2 c'etait word 2.0c au lieu de word 6).
Pourtant, les applications métier de FT se passaient allègrement de la suite office et dans leur travail les agents n'étaient pas sencés utiliser un traitement de texte ...
Donc sauf avis contraire la direction prise à l'époque c'était windows.
Cool ça !
<ma vie>
A cette époque je travaillais a l'OCISI chez FT, et je faisais partie de l'equipe qui maintenait en vie SCO Unix sur les serveurs Silex. Les Silex (hardware Siemens x86) tournait en SCO pour i386 ... de plus en plus difficile a booter sur les nouveaux PCs.
Du coup j'avais convaincu ma direction de me laisser faire une maquette avec un Linux. Après avoir porté quelques applications en C et fait quelques bench montrant que samba explosait les performances de Lanman sur SCO, ils ont accepté et on a lancé un programme de migration des Silex en Linex (2500 machines sur toute la france).
</ma vie>
Je suis donc 'le père' des Linex de FT (puis j'ai démissionné début 2001 ...)
et si t'as pu trouver l'install pratique et le stage sympa c'est déjà ça :-)
je te dirai dans quelles boites je suis passé après pour répandre des Linux :-)
encore un cerveau lavé par les médias et le gouvernement.
parle nous de la cloppe ou des accidents domestiques qui font encore plus de morts que la voiture.
Les accidents domestiques touchent principalement les enfants, et tuent plus que les chauffards ... ah oui mais y'a pas de tunes a se faire alors autant pas en parler au JT.
Sauf qu'il faut compter la conso clim et electrique de tout cet ensemble,
Sauf qu'il faut compter aussi le supplement de temps pour installer la bete et la configurer, le delta d'effort pour la maintenir en vie, la documenter, ... alors que la solution Cisco est prete a l'emploi.
Sauf que pour passer de 48 a 96 ports va falloir reinvestir lourdement au lieu d'ajouter une carte a chaud dans le cassis,
Sauf que l'aggregation de lien ne sera pas possible,
De plus HSRP c'est bien mais faudrait plutot faire tourner OSPF qui va consommer aussi des ressources,
...
les exemples s'accumulent comme ça par dizaines.
Bref sur la papier c'est beau mais pas dans la vraie vie.
Je suis d'accord avec toi, mais il faut prendre garde à la lecture car Cisco propose ses inventions comme DRAFT IETF. HSRP existait bien avant VRRP, et ladifférence entre les deux est infime.
Je ne pense pas qu'ils "utilisent l'IETF comme un labo", ils font énormément d'investissement dans la recherche et sont volontaires pour que l'IETF applique leurs solutions comme norme. De plus leurs solutions sont en général assez bien décrites...
par contre ils demandent des retours sur investissement.
Les avancées sur les Vlans, le rapid spanning tree, hsrp, le multicast, les algo de QoS ... Cisco est leader sur toute la gamme réseau du fait de sa recherche.
C'est un fait.
D'un autre coté je n'arrive pas a remettre la main sur l'URL ou un developpeur kernel/linux finissait par remercier Cisco et sa documentation technique accessible en ligne.
Cisco a des défauts, mais il faut reconnaitre que la plupart des avancées réseau actuelles (toutes ?) viennent d'eux, et qu'ils ont encore la bonne conduite de les documenter et de les proposer comme draft IETF. C'est bien plus fair que l'autre monopole en place :-)
[^] # Re: "secure"
Posté par PLuG . En réponse au journal Un émulateur de terminal en AJAX.... Évalué à 2.
Par exemple l'entreprise ne pourra pas te mettre a la porte si tu passe des coups de fil privés parceque ton gosse est malade, t'es à découvert et t'appelle ton banquier, ... c'est le caractère de nécéssité qui prévaut.
Si le but c'est de travailler sur des affaires personnelles depuis le boulot en se loggant sur ta machine de la maison, ... faudra prouver le "ponctuel" et "urgent" :-)
[^] # Re: ssl
Posté par PLuG . En réponse à la dépêche Zfone : Téléphonie IP sécurisée sous Linux. Évalué à 0.
Je ne dis pas que réinventer a chaque fois c'est bien, mais ipsec ...
# definition
Posté par PLuG . En réponse au message charge/load. Évalué à 8.
=> moyenne sur une minute, 5 minutes et 15 minutes.
prérequis:
- le temps de chaque cpu de la machine est coupé en timeslices
(tranches de temps)
- le schéduleur attribue ces tranches aux process tour à tour (c'est son job).
la charge est calculée par le scheduleur, et représente le nombre de process éligibles lorsque le scheduleur veut distribuer une tranche de temps cpu.
On comprend aisément que sue un monoprocesseur, si cette moyenne est inférieure à 1, la machine possède des tranche de temps dont aucun process n'a besoin.
si la moyenne est supérieure à 1, c'est l'inverse, les process "attendent" que le cpu soit libre pour tourner.
en pratique, une charge > nbr-cpu n'est pas un gros problème si les applications sont de type "batch", genre routage des mails (passerelle smtp). par contre sur un serveur web ou le laptop bureautique c'est un peu gênant (manque de réactivité).
ça te plait ?
HyperThreading:
mon expérience dit que les machines hyperthreadée sont un véritable piège pour le schéduleur qui y voit 2 cpu alors que le second n'est pas très puissant ni libre quand le premier tourne à plein. l'hyperthreading sur une machine très chargée (load) semble donner des soucis de mauvaise gestion de la charge
(au moins en kernel 2.4.x, je vais tester le 2.6 sur cette machine sous peu).
MultiCore, pas testé mais ça doit se rapprocher du multiCpu.
ben la charge nominale n'est plus de "1" mais de nbr-cpu donc la machine reste réactive avec une plus grosse charge.
# BMC pourri
Posté par PLuG . En réponse au journal Installation de Debian sur serveur IBM eserver xseries 336. Évalué à 2.
le chip utilise la premiere interface réseau pour communiquer, et pour cela "forge" une adresse mac différente de l'adresse normale de la carte. (la carte a 2 mac adresse si vous voulez).
résultat: => pertes de paquets quand BMC s'active, bazar sur le réseau avec les fonctions de sécurité (controle des mac address sur le switch ...).
Le plus fort, c'est que le chip BMC continue ses merdoiement meme après l'avoir désactivé dans le Bios.
Résultat: ces xseries ont 2 interfaces ethernet mais seule la seconde se comporte correctement.
[^] # Re: Les jeux
Posté par PLuG . En réponse au sondage Mon OS plante. Évalué à 3.
(certainement uniquement X11 d'après ce que tu racontes)
[^] # Re: Ça existe ?
Posté par PLuG . En réponse au sondage La musique que j'écoute provient principalement. Évalué à 1.
[^] # Re: Batterie de tests destinés à identifier l'origine du problème
Posté par PLuG . En réponse au message Connexion VPN cliente au travers d'un firewall. Évalué à 0.
le (1) c'est une bonne idée.
le (2) c'est pas necessaire et meme dangereux, suffit de lire les logs du parefeu.
le (3) c'est pas top non plus.
il faut d'abord se renseigner sur le VPN en question. la doc ou les normes utilisées indiqueront les protocoles necessaires.
certains VPNs (IPSEC) ne sont pas nativement prévus pour supporter le NAT.
ce qui fait que le test en (1) ne prouve pas que cela va marcher deriere le parefeu.
pour que IPSEC supporte le NAT il faut que le client et le serveur supportent l'évolution IPSEC pour le NAT.
le mieux serait que tu nous dises quel serveur VPN et quel client VPN sont utilisés.
quel protocole (IPSEC ??)
as-tu le choix du protocole ? si oui je te conseille openvpn beaucoup plus simple que IPSEC.
[^] # Re: Bonjour la pensée unique
Posté par PLuG . En réponse à la dépêche Le Linux Standard Base devient une norme ISO. Évalué à 4.
Cela n'est *pas* un problème technique, et ne sera pas résolu par une normalisation a la LSB. D'ailleur le produit lui meme (oracle par exemple) fonctionne très bien sur les autres distributions ...
Bref pour moi "le monde pro" ne veut pas de plusieurs distributions, il n'en veut qu'une seule pour diminuer les cout de test/integration, la version de la librairie ou l'emplacement de l'installation c'est queudale comme problème a résoudre.
[^] # Re: mouchards partout, corruption aussi, F2F P2P
Posté par PLuG . En réponse au journal Quand un gouvernement s'arrange pour mettre des mouchards dans les objets courants. Évalué à 2.
si effectivement ifconfig ne flash pas l'eeprom, la mac est bien stockée sur une ram accessible depuis la carte réseau.
En effet la carte réseau ne récupère que les trames a destination de sa mac, ce filtre est effectué par le chipset réseau de la carte.... sauf quand elle est en mode promiscuous (pour sniffer).
par contre cette mac est perdue au reboot, il faut donc reprogrammer la mac a chaque boot pour que ce soit définitif
[^] # Re: moi ça ne me fait pas rire
Posté par PLuG . En réponse au journal [HS] Une vache, un chèque, un impôt.... Évalué à 3.
sauf que le train n'est pas omnipotent.
on a *besoin* d'une voiture pour la vie courante (courses, déplacements avec les enfants, ...) donc l'achat/l'entretient/l'assurance font déjà partie du budget du ménage.
le train vient donc en suplément et est rarement rentable au niveau prix, moins pratique dans tous les cas, et la plupart du temps moins rapide.... meme sur un paris/lyon:
exemple: de chez moi (region parisienne) a chez mes parents (régions lyonnaise):
=> 30 minutes de RER pour aller a la gare de Lyon (a Paris),
=> 15 minutes d'avance pour le cas ou (difficile d'arriver juste a moins de risquer de le rater)
=> 2h15 de train (perrache)
=> 1h de bus avec changements et marche a pied, mais prenons le cas favorable, on vient me chercher en voiture (donc emmerdé quelqu'un pour qu'il perde de *son* temps a ma place: 30 minutes de voiture)
TOTAL: 4h.
ah ? ben en moins de 4h je fais le meme trajet par autoroute, j'emmerde personne et j'ai ma voiture de dispo a l'arrivée.
Je ne comprend pas le prix du train.
D'ailleur, comparez aussi le prix du transport ferroviaire et par route, et bien c'est moins cher de faire rouler des poids lourds... si vous voulez supprimer les camion, faudra faire baisser le prix de la sncf.
# KernelTraffic ?
Posté par PLuG . En réponse au journal Actualité du noyau. Évalué à 2.
http://www.kerneltraffic.org/kernel-traffic/latest.html(...)
[^] # Re: detection en live pas forcement utile
Posté par PLuG . En réponse au journal Les antivirus. Évalué à 3.
si tu fais des verifications toutes les semaines, cela n'empeche pas le virus de s'installer quand il pointe son nez, et de commencer ses actions.
imaginons qu'il reformate le disque des le deuxieme jour => tout perdu.
de plus si tu n'empeche pas l'installation du virus en verifiant a la volée, il faudra booter sur un media propre pour tester ta machine toutes les semaines. (ce qui de toutes façons est une bonne méthode).
[^] # Re: Questions
Posté par PLuG . En réponse au journal Economie d'énergie. Évalué à 4.
une voiture, cela n'explose pas.
A l'époque des réservoirs en métal il y avait des possibilités d'explosion,
A l'époque des réservoirs métaliques a l'avant, les possibilités de brulure/explosion étaient très grandes.
De nos jours, les reservoirs (essence/gazoil) sont tous EN PLASTIQUE, avec la chaleur ils fondent, répendant l'essence au sol, a l'arrière du véhicule, afin de limiter la casse.
mais dans les films, c'est moins rigolo une voiture qui prend feu doucement et les gens qui sortent.
NB1: avec la flaque d'essence en dessous, une voiture brule en environ 15 minutes quand meme ...
NB2: le GPL utilise des soupapes pour éviter l'explosion.
[^] # Re: 24/24
Posté par PLuG . En réponse au journal Economie d'énergie. Évalué à 3.
=> c'est le compteur de ticks d'horloge (sysUptime sous windows) qui déborde et repasse a zéro. le phénomène arrive tous les 49.7 jours.
Ce problème existe aussi sous OS/2, ou il est difficile a corriger car chaque driver vient lire la valeur a l'adresse du compteur directement (au lieu d'utiliser une fonction dans laquelle on pourait corriger une bonne fois pour toutes le problème).
Je ne sais pas pour Windows, mais OS/2, lui, ne fait que jouer a la roulette russe tous les 49.7 jours. En effet le crash n'est pas garanti, c'est juste si on a pas de chance et qu'un morceau de code a fait des lectures du compteurs au moment de l'overflow (genre un chronometrage avec soustraction de t2-t1 qui devient très grand ou négatif)
[^] # Re: tar/zip
Posté par PLuG . En réponse au journal Sauvegarder sur DAT en activant la compression. Évalué à 5.
un tar sur une bande deffectueuse => on recupere aisement la totalite des fichiers n'utilisant pas le morceau de bande abimé.
un tar gzippé ou bzippé => plus rien.
[^] # Re: plus d'OS2
Posté par PLuG . En réponse à la dépêche IBM remplace OS/2 par Linux. Évalué à 4.
>Ouille.
désolé :-)
Sinon pour ce qui est de MS Office, c'est très logique que les utilisateurs pousse pour l'avoir: c'est ce qu'ils utilise à la maison, c'est ce qu'ils ont utilisé à l'école et c'est ce qu'ils ont utilisé dans leurs autres emplois..
De plus ils font comment pour envoyer ou recevoir des documents avec le reste du monde?
Ben justement, la STB, sous OS/2 c'est un poste de travail dédié pour prendre des commandes de clients. Les STB ne sont pas prévues pour faire autre chose que des applications métier (prise de commande, recherches de clients dans la DB, affectation de n°de téléphone ...).
La plupart des agents FT n'ont pas vraiment a "échanger avec le reste du monde", sauf de vive voix au téléphone ou de visu.
Word 2.0c c'est bien antérieur a Office97, c'est une version de word ou l'utilisateur apprend a sauvegarder toutes les 2 lignes pour ne pas trop perdre de données au prochain crash inévitable :-)
[^] # Re: Firefox pire qu'IE ??
Posté par PLuG . En réponse à la dépêche Sortie de Firefox/Thunderbird 1.0.6. Évalué à 3.
[^] # Re: plus d'OS2
Posté par PLuG . En réponse à la dépêche IBM remplace OS/2 par Linux. Évalué à 1.
A l'époque je n'avais pas réussi a convaincre de migrer ces stations de travail sous linux. Je ne sais pas ce que c'est devenu mais en 2000/2001 les tests les plus aboutis se faisaient sous windows ... :-(
Il faut dire que les STB OS/2 marchaient bien, et que c'est principalement les utilisateurs qui poussaient pour upgrader vers Windows et pouvoir entre autre avoir un MS Office a jour (sous OS/2 c'etait word 2.0c au lieu de word 6).
Pourtant, les applications métier de FT se passaient allègrement de la suite office et dans leur travail les agents n'étaient pas sencés utiliser un traitement de texte ...
Donc sauf avis contraire la direction prise à l'époque c'était windows.
[^] # Re: plus d'OS2
Posté par PLuG . En réponse à la dépêche IBM remplace OS/2 par Linux. Évalué à 6.
<ma vie>
A cette époque je travaillais a l'OCISI chez FT, et je faisais partie de l'equipe qui maintenait en vie SCO Unix sur les serveurs Silex. Les Silex (hardware Siemens x86) tournait en SCO pour i386 ... de plus en plus difficile a booter sur les nouveaux PCs.
Du coup j'avais convaincu ma direction de me laisser faire une maquette avec un Linux. Après avoir porté quelques applications en C et fait quelques bench montrant que samba explosait les performances de Lanman sur SCO, ils ont accepté et on a lancé un programme de migration des Silex en Linex (2500 machines sur toute la france).
</ma vie>
Je suis donc 'le père' des Linex de FT (puis j'ai démissionné début 2001 ...)
et si t'as pu trouver l'install pratique et le stage sympa c'est déjà ça :-)
je te dirai dans quelles boites je suis passé après pour répandre des Linux :-)
[^] # Re: Geoworks
Posté par PLuG . En réponse à la dépêche IBM remplace OS/2 par Linux. Évalué à 1.
d'un autre coté vu la qualité de la pile TCP/IP ... ils peuvent la garder :-)
[^] # Re: Autre point de vue
Posté par PLuG . En réponse à la dépêche IBM remplace OS/2 par Linux. Évalué à 3.
http://www.abandonware-magazines.org/affiche_mag.php?mag=7&page(...)
[^] # Re: Terroriste!?
Posté par PLuG . En réponse à la dépêche Comment des vendeurs essaient de breveter les solutions à des failles de sécurité qui leur sont fournies. Évalué à 1.
parle nous de la cloppe ou des accidents domestiques qui font encore plus de morts que la voiture.
Les accidents domestiques touchent principalement les enfants, et tuent plus que les chauffards ... ah oui mais y'a pas de tunes a se faire alors autant pas en parler au JT.
[^] # Re: Terroriste!?
Posté par PLuG . En réponse à la dépêche Comment des vendeurs essaient de breveter les solutions à des failles de sécurité qui leur sont fournies. Évalué à 9.
Sauf qu'il faut compter aussi le supplement de temps pour installer la bete et la configurer, le delta d'effort pour la maintenir en vie, la documenter, ... alors que la solution Cisco est prete a l'emploi.
Sauf que pour passer de 48 a 96 ports va falloir reinvestir lourdement au lieu d'ajouter une carte a chaud dans le cassis,
Sauf que l'aggregation de lien ne sera pas possible,
De plus HSRP c'est bien mais faudrait plutot faire tourner OSPF qui va consommer aussi des ressources,
...
les exemples s'accumulent comme ça par dizaines.
Bref sur la papier c'est beau mais pas dans la vraie vie.
[^] # Re: multi récidivistes
Posté par PLuG . En réponse à la dépêche Comment des vendeurs essaient de breveter les solutions à des failles de sécurité qui leur sont fournies. Évalué à 0.
Je ne pense pas qu'ils "utilisent l'IETF comme un labo", ils font énormément d'investissement dans la recherche et sont volontaires pour que l'IETF applique leurs solutions comme norme. De plus leurs solutions sont en général assez bien décrites...
par contre ils demandent des retours sur investissement.
Les avancées sur les Vlans, le rapid spanning tree, hsrp, le multicast, les algo de QoS ... Cisco est leader sur toute la gamme réseau du fait de sa recherche.
[^] # Re: Terroriste!?
Posté par PLuG . En réponse à la dépêche Comment des vendeurs essaient de breveter les solutions à des failles de sécurité qui leur sont fournies. Évalué à 2.
D'un autre coté je n'arrive pas a remettre la main sur l'URL ou un developpeur kernel/linux finissait par remercier Cisco et sa documentation technique accessible en ligne.
Cisco a des défauts, mais il faut reconnaitre que la plupart des avancées réseau actuelles (toutes ?) viennent d'eux, et qu'ils ont encore la bonne conduite de les documenter et de les proposer comme draft IETF. C'est bien plus fair que l'autre monopole en place :-)