Reprise du message précédent :
Bon, quelques points :
1) J'ai déjà modifié y'a 10 plombes au niveau du support matériel. "Si matériel certifié" pour les deux OS, ça vous convient ?
2) Bon, vous allez arrêter de dire que c'est moi qui décide de la politique informatique ou de sécurité ? Ca fait X fois que je dis que je ne suis en rien décideur, va falloir se calmer maintenant
3) Pour ce qui est de la charge mémoire, ouais, un Debian compilé à la main avec juste deux touches du clavier reconnues, ça fait 12 Mo. OK. Maintenant, de toute façon, d'après la doc technique de l'applicatif, le choix sera RedHat 4.0 AS, qui est de toute façon le plus répendu chez les constructeurs de serveurs d'entrée de gamme (Dell, HP, etc.) Avec Oracle qui nous emmerde à faire une install en graphique, on ne risque pas de se retrouver avec un Linux qui bouffe 12 Mo. J'ai mis depuis le début 50 Mo, va falloir se calmer. Quand bien même ça serait 35 Mo, "35" ça fait un peu ridicule. J'ajoute un service ou j'en enlève un, j'ai tout de suite plusieurs Mo de différence, alors vous allez pas me pomper avec "j'ai la plus grosse". MS Dos ça tiens en moins de 300 Ko, donc linux c'est de la pure daube. Voilà le niveau de l'argumentaire.
4) Arrêtez de m'emmerder avec vos jugements sur mes compétences ou celle des autres employés de ma société, non seulement on n'a rien à voir avec la plateforme du client, mais surtout certains de mes collègues sont très compétents dans le domaine, alors vous serez gentil de pas les insulter sans savoir.
5) Pour la gouverne de tous, parceque j'ai l'impression que 90% des gens ici maîtrisent encore plus mal Windows que moi je ne maîtrise Linux... On peut parfaitement arrêter et démarrer un service par script sous Windows, y compris à distance, sans parler du schedule, et ce, sans passer par le moindre outils externe ni la GUI. Donc je vous retourne vos commentaires : quand on sait pas, on arrête de dire des âneries.
 
Je suis venu ici pour avoir des infos et de l'aide, j'ai eu droit à la parade des trolls en rut, et quelques éléments constructifs noyés dedans. Ceci dit, merci beaucoup à ceux qui m'ont répondu, j'ai pu ajouter pas mal de points dans mon document et en améliorer certains.

Perso, le truc qui me tracasse le plus dans ton cas, et qui je pense est le réel "point de   complexité" (ou "nid à problèmes" potentiel si tu préfères, c'est pas tant d'un point de vue technique (Linux, win2k3  kif-kif pour moi dans cette affaire là, à qq petits points de détails près, mais pas envie de les exposer ...), c'est que l'éditeur migre sa solution d'un environnement *Nix vers un environnement Linux et Windows.
 
Si j'étais à ta place, j'aimerai être sur que :
 
1/ ils ont bien toutes les ressources nécessaires pour assurer le support client, et le support que j'appellerai "Professional Services" (qui te concerne directement puisque tu es dans ce cas là et tu interviens pour le compte d'un client qui utilise les produits de cet éditeur), après cette migration. Que ce soit d'un point de vue système, mais aussi développement (j'ai vu des boites se bouffer les doigts après une migration de produit d'un environnement vers un autre, car les développeurs qui ont assuré la migration vers le nouvel environnement/techno n'avait pas le même niveau de compétence, et c'est à priori normal sauf à restaffer sur la nouvelle techno mais bon ..., sur le nouvel OS/environnement).
 
2/ Qu'ils ne sont pas allé trop vite en besogne lors de cette migration (l'histoire des 25 users/processeur m'inquiète un peu et ça me donne la désagréable sensation que les patches vont se succéder à un certain  rythme dans les mois qui viennent, et que ce qu'ils livrent à leurs clients en ce moment, c'est pas la version finale, ni même des Release Candidate, niveau qualité/bugs/etc ...) ...
 
3/ Que d'autres avant toi (et si possible avec un profil similaire, périmètre de projet similaire) ont effectué cette migration, l'ont réussi, avec un retour d'XP intéressant, notamment pour l'éditeur, à la clef. Parce que si tu fais partie des "pionniers", tu imagines très bien ce que ça veut dire, les platres que tu risques de te taper (et là on rejoint le 1/, sur la qualité de l'éditeur à pouvoir te fournir un support "Professional services" digne de ce nom, en cas de situation merdique, non rencontrée encore ). Surtout que ta boite, et toi, vous êtes pris entre le client "final" et l'éditeur ... pas la position la plus confortable, AMHA.
 
Après, vue la "légèreté" du client derrière, à ne pas avoir ne serait ce qu'un interlocuteur, en interne, un peu compétent/formé (pas forcément besoin que ce soit une embauche non plus et pas besoin de le transformer en informaticien non plus) pour assurer ne serait ce que le premier niveau de support et être l'interlocuteur unique vis à vis de vous et faciliter la remontée d'infos/problèmes, si tu me dis dans les mois qui viennent qu'ils ont galéré suite à cette migration, tu ne m'étonneras pas.
 
  Mais bon, tu as précisé une chose qui résume bien pourquoi cette situation existe : C'est une boite qui a été reprise par une boite financière et pour eux, très très souvent informatique rime avec "Centre de coûts" ...
 
Bon courage

Merci
 
Quelques petites précisions quand même, j'ai pas dû très bien m'expliquer
 
Au départ (il y a "très" longtemps) cet ERP ne fonctionnait que sous Unix.
Après le démodage de telnet, et les demandes croissantes d'une interface graphique, avant que Java n'existe, ils ont développé une version client/server "surcouche" de telnet, qui tourne sous Windows (le client).
Forts de cette expérience, et voyant qu'avec une version graphique, ils pouvaient séduire les PME, ils ont décidé de porter leur application serveur sur Windows aussi. Ceci remonte à l'époque de NT4. La plateforme Windows est donc réellement éprouvée, ce n'est pas un revers du jour au lendemain.
 
Par contre, la migration de Unix vers Linux est bien plus récente, et date des trois dernières versions, avec notamment l'apparition d'un client alternatif, sous forme d'intranet.
Passer d'Unix à Linux, quand en plus on a l'expérience PC avec Windows, je ne pense pas que ce soit du suicide. Niveau techno de développement, on retrouve pour ainsi dire la même chose entre Unix et Linux, et d'un point de vue contraintes matérielles, on a largement eu le temps de se faire les dents avec Windows.
En bref, je suis plutôt confiant pour ce qui est de l'avenir du produit. De toute façons, après ces dernières années particulièrement difficiles, la plupart des créateurs de l'appli sont partis, et la relève semble tenir la route. On peut même dire que ça s'est amélioré, puisque nombre de clients ont imposé des certifications diverses et variées, ce qui garanti aujourd'hui un minimum un contrôle qualité sans faille.
 
Actuellement, le client chez qui je suis est en version 4.4 Elle ne sera plus supporté d'ici fin juin. Il est donc impératif de migrer. La dernière version en date étant la 5.2, il est tout naturel de passer à celle-ci. Mais la véritable raison qui pousse à passer à cette version et pas une autre, c'est que la 5.2 est la toute dernière version à fonctionner avec le client "lourd" (l'appli windows). Ensuite, ce sera full intranet, hors vu les perfs du module actuels, vous aurez compris l'urgence de passer à la 5.2 et éviter de désastre avec une 5.3. Cependant, la 5.2 dispose déjà de l'architecture décidée pour les versions à venir, donc lorsque la version intranet sera réellement utilisable, ils pourront sans problème migrer cette partie de l'application, sans devoir refaire un setup complet.
 
Pour ce qui est des retours clients, même si j'en ai pas vraiment directement, c'est actuellement une véritable ruée vers cette version, pour les mêmes raisons. Le mieux, ça va être chez GE (le pire c'est que je risque d'enchaîner chez eux après ) qui ont toute une partie de l'application en 3.8, et quelques brides de 4.2... C'est à dire qu'ils doivent payer chaque mois à peu près le prix de leurs licences, afin de conserver chez l'éditeur une équipe de développeurs sur cette version, et garantir le support et les évolutions, puisque ces versions ne sont plus supportées (c'est donc un support spécifique et dédié). Le plus marrant, c'est que dans ce cas, les spécifiques ne sont pas portés sur les nouvelles versions. Du coup, quand ils vont migrer, non seulement y'a rien qui va marcher, mais ça va leur coûter bonbon pour redévelopper tous les spécifiques... Ca promet d'être un projet particulièrement chiant à gérer
 
Enfin bref, tout ça pour dire que la migration, c'est pas la grande inconnue, d'autant plus que la version 4.4 est la dernière version 4.x, et que les versions 5.x portent principalement sur un réagencement de l'architecture du programme, avec notamment une couche Java qui vient progressivement remplacer les EXE en C (actuellement, tout est en doublon encore). Du coup, on s'attend à très peut de changement entre la 4.4 et la 5.2 niveau fonctionnalités, à condition de ne pas utiliser les nouvelles (pour le moment, on va se contenter d'une migration ISOfonctionnelle, on verra après, j'y suis tout l'été pour ça )

trop bon le troll qui sert a rien ......heuresement que ca reste electronique car sinon on boufferait la foret ...
 
moi ce qui m'eclate le plus, a part le blabla d'age mental 3ans, c'est une base oracle avec degun ds la boite .....

ca : "Passer d'Unix à Linux, quand en plus on a l'expérience PC avec Windows, je ne pense pas que ce soit du suicide" ... c'est une phrase de competition ...

j'ai dit "je pense", et en l'absence d'arguments contraires, je ne vois pas ce qu'il y a de choquant là dedans.
Ma référence pour ce jugement, c'est Oracle.
La version 8i était disponible pour RedHat, mais non certifiée (et gratuite, même pour de l'exploitation, sans aucun support). il s'agissait des sources de la version unix recompilées sous Linux, avec très peux de changement.
en une version, ils on pérénisé l'offre, rendue payante, et assuré le support. maintenant, Oracle sous Linux ne pose aucun problème de performances, alors que le passage sous Windows a nécessité une réécriture quasi complète du moteur avant d'être performante.
 
Donc oui, je conclu que passer d'Unix à Linux, avec cet exemple, n'est pas du suicide, surtout lorsqu'on a déjà une expérience PC avec une offre pérène sous Windows. Architecuralement parlant, Linux et Unix y'a très peu de différences. La seule véritable différence, c'est l'absence d'un processeur RISC au profit d'un MISC, et un matériel bien moins performant, qu'une simple habitude sous Windows permet de mieux prendre en compte.
Je ne vois pas ce qu'il y a de choquant là dedans...
 
Je développe des applis pour PalmOS, et pour PocketPC, deux OS et architectures différentes. Je connais le C# sous Windows, les limitations des matériels handled avec PalmOS, je n'ai eu aucun problème pour écrire ma première application PocketPC

Bon, on va arrêter les frais ici.

nyme> tu avais été prevenu ...