Reprise du message précédent :

Il s'agit d'une société "centrale d'achat" qui a été rachetée par une société de finance... Donc dépenser 1 euro dans un truc superflu comme l'informatique, c'est hors de question. Tant qu'ils n'auront pas eu un réel problème, je ne vois pas comment leur faire comprendre l'intérêt d'investir davantage dans ce domaine. Pour ce qui est de l'applicatif et de son utilisation, c'est par contre loin d'être de l'amateurisme. Si t'as du coca dans tous les distributeurs de boissons en europe, sans jamais qu'il y ait de rupture de stock, c'est notamment grace à cet applicatif. C'est pas une macro Excel qui tourne sur le PC du comptable
 

Non, mise à part l'interface légèrement différente, c'est rigoureusement pareil. Y'a un soft qui permet d'arrêter/démarrer chaque module de l'ERP, ou tout à la fois... Et une fois terminé, c'est reboot classique de Windows. Faut juste penser à redémarrer les services (toujours via cette interface) après. Pour le coup, n'importe qui peut faire la manip, a partir du moment où on l'a montré une fois.
 

A ce niveau là, aucun problème. Déjà, aucun patch n'est livré sans ouverture de cas auprès du support. En aucun cas un patch n'est livré "pour le fun". Si ça marche sans le patch, tu continues à bosser avec ta version sans patch. La plupart des patchs correspondent à des spécifiques demandés par des clients, et ils sont plus que rares. Deplus, quand on demande une nouvelle version pour un EXE, il est compilé à la demande, avec les parties du source modifiée uniquement en rapport avec la demande de ticket. Donc de ce côté, aucune différence d'une plateforme à l'autre.

T'as l'air à fond dans ton trip Windows, bah fonce alors
 
Tu reçois la revue Oracle ? Celle qui parait tous les 2 mois ?
Si oui, j'imagine que tu as pu voir la grande importance accordée à Windows... (c'est ironique).

 
pour ce point, c'est loin d'être crutial dans notre cas.
 
ici, la charge du serveur actuel (un Piv 2GHz avec 2 Go). actuellement utilisé par les US, et certains batchs "de nuit" sont déjà en train de tourner (y'a pas grand monde aux US)
la charge reste très faible, alors que le serveur fait tout tourner (applicatif, oracle et éditique), et en plus c'est Win2K, qui est plus gourmand, et monte moins bien la charge que 2K3.
avec la migration, il y aura au minimum 2 serveurs récent (un pour oracle et un pour applicatif/editique) plus certainement le serveur utilisé pour l'appli web que je leur ai fait pour la couche e-commerce, ce qui induit une charge très largement inférieure sur le serveur. s'ils mettent en plus l'éditique sur un serveur dédié, comme préconisé par l'éditeur, mise à part le serveur oracle, ils vont tous se tourner les pouces.
d'où mes arguments originaux à propos de la différence de montée en charge : actuellement, le serveur n'est quasiment jamais à 100%, et ça ne dure jamais plus de quelques secondes. avec la nouvelle architcture, ils sont tranquilles pour quelques années encore. donc l'aspet montée en charge reste un facteur peu déterminant.
 

J'aurais juste une question toute bête (enfin peut être deux) :
- Combien de clients déployés sous Linux et sous Windows. Leur profil avec, bien entendu, pour avoir une idée de l'activité gérée par ce système à chaque fois
 
- Combien de migrations, de Unix vers l'un de ces environnements.  
 
Si possible, à chaque fois essaies d'avoir de quoi pouvoir les contacter, histoire d'essayer d'avoir des retours "clients" (et pas seulement du type qui a un jour entendu parler de l'appli en question mais qui sait pas trop ce que c'est en fait, car non utilisateur ou non mainteneur/ production). A toi de voir les bonnes questions à poser pour avoir des retours significatifs.
 
Ca vaut mieux que 2 000 pages de trolls stériles  (les pages, ).

.
Je rejoins l'avis de ceux qui te disent de poursuivre avec Windows, si tu n'as pas les compétences-moyens inter/intra projet pour mettre un linux (qui reste le meilleur choix intrinsèquement, mais, il faut, comme toujours des personnes compétentes).
 
Aussi, je ne commente pas tes a priori sur Linux, ça reste ton avis d'utilisateur de Windows au long court et sur une situation précise (tu ne sembles pas avoir les moyens de changer cet état de fait sur ce projet, donc voilà rien à dire de plus).
 
C'est juste mon avis de non informaticien, mais je suis dans les télécoms (donc un carton rouge on va dire pour ceux qui regardent M6 à l'instant ).
 
edit : beurk, la prise d'écran, c'est affreux .

je bosse pas chez l'éditeur, ça va être dur d'obtenir ces chiffres.
 
de ce que j'ai vu, chez GE, ils ont environ 400 postes clients (tous sous Windows, principalement en mode TELNET, avec une 50aine en mode client/serveur). Un seul serveur Unix (SunOS, j'ai pas de détails sur la config) fait tourner cette instance, plus une seconde (de recette), base et éditique comprises.
a priori, aux dernière nouvelles, ils optent pour la migration sous Windows. je n'ai pas d'autre expériences de migration (d'autant plus que la nouvelle version ne date que de quelques mois).
lors de ma formation, je n'ai eu que des généralités : ceux qui étaient déjà sous Windows migrent principalement sous Windows. ceux qui étaient sous Unix, migrent principalement sous Linux. Et les nouveaux clients prennent principalement Linux (l'offre Windows était originalement présente pour compenser le coût d'un serveur Unix... quand tu t'adresses pour moitié de ton budget à des PME c'est con de leur imposer un serveur dont le coût dépasse leur CA annuel)
Après, il y a des exceptions. Mais je doute de pouvoir en savoir plus.
On a débauché un gars de chez l'éditeur, il pourra peut-être nous donner plus d'infos, mais d'ici qu'il arrive la migration sera finie

moi j'ai pas de problème avec Linux hein. c'est plus que rare que je doive intervenir sur le serveur, et la procédure de redémarrage de l'appli/serveur est la même sous Linux que sous Windows. ma société a en interne les compétences nécessaires pour faire l'install et le support, sans parler que l'éditeur partipera au déploiment. mon job consiste ensuite à faire du paramétrage fonctionnel pour que la nouvelle instance se comporte comme l'ancienne, pour ça le serveur pourrait tourner sur une architecture extra-terrestre, ça changerait rien à mon boulot.
je pense surtout aux gens en interne "au jour le jour", mais faut pas se focaliser là dessus les gars. ça va faire une ligne dans mon compte rendu "utilisateur lambda peut faire une maintenance basique sur le serveur : win=oui / linux=non" y'aura pas une ligne de plus sur le sujet...
 
par contre, on me dit depuis plusieurs posts "que linux est un meilleur choix intrinsèquement", mais pour ça, j'ai pas lu un argument "valable" (en plus de la charge, qui n'impactera pas la décision, ou la stabilité et la sécurité, qui restent des points mineurs vu l'architecture/utilisation de la chose)

C'est déjà qqchose dont je tiendrais compte ...

Autre chose : quel est l'historique de cet éditeur sous les divers environnements ?

Heu, si tu veux vraiment te convaincre des performances d'un système sur un autre, pour ton application, il n'y a pas 36 méthodes : il faut tester sur des machines cibles pour les mêmes tâches, enfin, je ne sais pas si c'est faisable ce genre de manip quand on bosse en régie .
 
Sinon, le reste, c'est de la littérature que tu peux croire ou non (protocole de mise en oeuvre, cible visée etc ...).
 
Bref, donc, pas la peine de discuter 10 ans là-dessus .

Y'en a eu aucun pour l'archi basée sur windows.
Niveau simplicité j'ai déjà mis en place du full linux, voire une intégration Linux/Unix/Win complètement transparente pour l'utilisateur lambda car le client pouvait pas se permettre de décliner ses compétences en interne pour chacun des environnements. Ca se travaille (et c'est pas si compliqué que ça de cacher l'apparente complexité de "linux", niveau amdin  applicative au quotidien).

j'en reviens à ce que je te disais et je complète en reprenant ce qui t'as été dit ici et là  :
Se baser sur un maximum de retours concrets et significatifs et/ou compléter par ses propres tests.
 
Maintenant si t'as pas le temps, tu ne pourras te baser que sur des conjectures plus ou moins vraies, ce que d'autres appellent de la "littérature"  

Bon, j'ai pondu ça, et je crois que je vais en rester là.
Pas le courage de censurer le doc, comme ça vous savez quel ERP c'est (de toute façon, personne le connait )
 
http://www.bci-logs.fr/medias/Etud [...] 0Linux.pdf
 
Voilà, j'espère que c'est assez objectif, dites-moi si y'a vraiment des âneries. N'oubliez pas de lire les annotations en pieds de page.

 
J'ai lu ton plaidoyer pro Windows. N'importe qui adopte Windows dans ce cas. Rien que la lecture de la première ligne

une fois (ya longtemps) j'ai fait un reboot en me disant ça ira mieux après.
pb!! les scripts /etc/rc.d (demarrage des services) étaient défaillants
donc pas de reboot du tout.
depuis j'evite de rebooter sans avoir analyser le pb.
 
une autre fois, j'ai passé une apm (en RTT) a debogguer un blocage serveur SQL, alors
qu'un reboot total de toutes les machines à résolu le pb.
 
alors dire que n'importe qui peut rebooter n'importe quoi, c'est n'importe quoi.
 
alors effectivement, sous win on reboot plus souvent et très facilement ne serais ce que pour liberer
la ram et le cache (les pointeurs des applis "degueux" ) ==> 9099% d'être de nouveau op après.
 
ensuite pourquoi sur ton serveur, si tu choisi linux, tu ne mettrais pas d'interface graphique, puisque sous win
y en a une par défaut et faire ressembler l'IHM linux (cliquodrome) a celle de win comme ça n'importe quel "gogo"
pourra faire un reboot si besoin (d'ailleurs ctrl+alt+del aussi reboot propre sous linux).
 
pour le reste, je sais pas.

memaster62 > comme tu le dis, on a plus souvent des problèmes au reboot avec Linux/Unix que Windows. De ma vie, j'ai jamais vu un serveur Windows poser de problème après un redémarrage -au pire, un service pourri qui démarre pas, qu'on identifie immédiatement et qui ne pose pas de problème à démarrer manuellement-, alors qu'il suffit souvent de pas grand chose pour qu'un x-like ne redémarre pas. Après, c'est généralement un problème d'administration (scripts de démarrage corrompus et mal testés), chose qui n'existe pas (ou presque) sous Windows. Idem, sous Linux, un reboot est généralement inutile, et ne résoud pas grand chose. Au contraire, sous Windows, avant de chercher plus loin, dans 99% des cas, le reboot suffit à résoudre n'importe quel problème. Après, il est possible que 99% de ces cas ne se produisent jamais sous Linux, j'en doute un peu, mais c'est possible.
Ensuite, ne pas mettre d'IHM sur un Linux, c'est peut-être mon côté puriste. Mettre un KDE qui bouffe plus que l'IHM de Windows, je trouve pas ça très opportun sur un serveur, alors que souvent l'avantage majeur de Linux retenu c'est qu'il consomme moins. Après, je suis d'accord, si c'est le seul moyen de permettre aux utilisateurs de faire de la maintenance "classique" au jour le jour (changer le schedule du backup ou reboot de la machine) pourquoi pas. Mais disons que je suis d'avis que c'est bien la dernière solution à adopter pour un serveur. D'un autre côté, seule une personne qualifiée devrait pouvoir accéder aux serveurs...

reply du nuxien de ma boîte (genre y recompile un kernel sunos à chaud en production pour pouvoir imprimer en couleur sur une imprimante, c't'un malade )
 

 
Pour le 18) je lui ai répondu : j'entends par "intégration dans le réseau" le support du domaine NT du client, avec gestions des ACL, patages de disques et mappage des comptes du domaine en local. Même si maintenant il y a des outils, c'est pas vraiment préconisé "en standard", et ça relève plus de la bidouille ou de l'exploit qu'autrechose pour réussir à faire marcher la chose. Mais aucun des produits utilisés n'en a besoin, donc c'est as vraiment important.

Quelques remarques sur le document :
perso, je suis à moins de 50Mo d'occupation mémoire avec une GUI (fluxbox pour le gestionnaire de fenêtre mais il y a encore moins lourd) mais c'est pas une utilisation serveur
 
pour les mises à jour, si tu mets à jour le noyau, il faudra rebooter, mais c'est un des seuls cas pour linux, donc ce n'est pas intégralement sans reboot.
 
pour le coût des licences, les versions que tu proposes dans ton premier post sont pas gratuites du tout donc je sais pas si tu peux mettre 0 à 1000€
 
tu peux t'intégrer à un réseau AD avec samba.  
 
Enfin, pour le matériel, windows n'est pas compatible avec tout, tu ne peux pas l'installer sur un PPC et plus généralement, c'est problématique sur du non x86.

Salut,
 
Ce qui me parait bizarre c'est que normalement une fois un serveur configuré il n'y a plus besoin de faire de manoeuvre dessus (en tout cas pour linux). De plus on peut tout programmer (backups, maj, etc...) avec cron ou scripts. Après en fait ca dépend de la qualité de la personne qui installe et valide le serveur. Il existe des distrib avec une interface graphique permettant une configuration avancée des services réseau (suse par ex. ,redhat levez la main...). On peut prendre le controle d'un pc linux avec vnc et le rebooter. On peut faire des scripts pour que quand on double clike de windows ca redemarre tous les serveurs (avec ssh). De plus, laisser l'administration de serveurs aussi cruciaux à des débutants c'est du suicide pur et simple. En plus, je te dis pas la responsabilité du blaireau qui va niquer la BD de la boite. En gros : 1) ca a l'air d'être des guignols 2) tu n'a pas les qualifications suffisantes pour installer le serveur nux et donc ton propos est biaisé car tu ne connais que winmerde.
pour la montée en charge et les performances serveur samba (partage windows)
http://www.webperformanceinc.com/l [...] index.html
http://solutions.journaldunet.com/ [...] rypt.shtml
http://www.kegel.com/nt-linux-benchmarks.html
etc...
 
Bref dès le départ la question était biaisée donc la réponse déjà connue (analyse non objective : en prenant les faits que l'on connait ou qui nous arrangent on peut prouver nawak). Je ne comprend donc pas trop la démarche de comparaison alors qu'il n'y en a pas besoin (c'est comme poser un arrosoir à coté d'une passoire et dire 'pour arroser je vais choisir l'arrosoir, car la passoire, elle, ne permet pas d'arroser'    )
 
j'ai regardé ton doc :
intégration au réseau incomplet et samba alors il gere les domaines nt les acl etc... des grosses boites l'utilisent... allez cadeau www.samba.org ???
présence d'un gui : non. La c carrément retour vers le futur, la console unix en 80 colonnes vert et noir LOL (KDE et xorg : en idle 3% cpu sur un XP-M 2800+)
PS : sous linux on utilise toujours ces bonnes vieilles cartes perforées, c'est plus fiable.
de plus : l'installation de suse ou redhat est plus simple que celle de windows car il n'y a pas une floppée de merde à installer après l'install de l'os. et puis bon laisser un neuneu configurer/installer oracle LOL
sinon tes critères ne sont pas quantifiés.
 
Sans volonté de troll aucune

trop fort ce arjuna ...trolle a bloc en ecrivant des pages et des pages de "conneries" ...repond de travers a tous les arguments meme les + evidents (s'apelle un troll).
trop fort mais je vois pas ton interet ..... ou tu es un adulte et tu es disons "bizarre" (pour pas t'insulter ...), ou tu es un adulte et ton histoire est vraie..c'est vrai que ds l'info y a des barjots de temps en temps ... ou t'es un gamin qui se marre mais alors ds ce cas la va plutot faire su skate avec tes collegues ou va rendre visite a ta copine ...
 
sans rancune

Merci pour les liens .

 
De rien    
 
Au passage j'apprécie beaucoup la cordialité grandissante de ce forum.
 
A+

T'en environ à combien d'occupation mémoire ? Si c'est dans les 40 Mo, y'a le mot "environ" dans ma phrase. Windows 2K3 ça bouffe 76 Mo après une install "à vide" et pourtant je mets 150 Mo dans mon doc. On n'est pas à 1 Mo près.
 
Je suis OK pour la mise à jour du Kernel, c'est pareil si on dois changer du matos dans la machine (ils vont pas s'amuser à prendre une machine full hotplug juste pour pouvoir changer 1 fois dans la vie du serveur un composant). Deplus, une version du kernel est certifié pour l'ERP, je doute très fortement qu'on le remette à jour par la suite. Après tout, quand ça marche, je ne vois pas l'intérêt de patcher... Se palucher des jeux d'essai de 500 pages, moi ça me fait pas tripper. Donc en gros, Windows a besoin de rebooter tous les 3/4 patchs critiques, Linux, ça devrait arriver 2 fois dans la vie du serveur (c'est pas tous les jours qu'une faille critique est trouvée dans le kernel Linux, surtout quand il s'agit d'une version validée).
 
Pour ce qui est des coûts, je sais. Mais je ne pense pas que Red Hat AS coûte plus cher que Windows. Donc 0 à 1000 € donne une fourchette raisonnable. Dans tous les cas, il sera très certainement livré pré-installé avec le serveur, donc le prix de la licence, on s'en contre-balance pus ou moins, sauf si ça dépasse le prix du serveur...
 
Pour ce qui est de l'intégration AD, oui, je sais, Samba évolue. Sauf que l'intégration "complète" n'est qu'en version Alpha, et dans tous les cas, Samba reste un facteur "à risque" rarement installé dans la config de base d'un Linux. A partir de là, non, je ne risque pas de mettre "complète" et encore moins "native".
 
On va rester sur des serveur standard. Oui, on pourrait aussi imaginer un cluster de CPC6128+ mais c'est pas à l'ordre du jour
De plus, on n'a pas les sources de l'ERP je te le rappelle. Donc on est de toute façon limité aux x86 et AMD64/EM64T qui sont aussi bien supportés par Windows que par Linux (rappel de mon premier poste)

ça m'a pas l'air grace à toi en tout cas.

 
=> j'essaie d'aider les autres comme je peux, maintenant, si tu a des critiques constructives à formuler sur mon post je les attend avec plaisir. Mais évite les betises quand a samba stp, ne dis pas que ce n'est pas un produit fini. Puis j'en profite pour rajouter un bémol à ton "étude linux vs windows" (sic) : pour un serveur, linux supporte plus de matériels différents que windows, ici on ne parle plus de webcams pourries ou de keyboards exotiques avec les touches qui clignotent mais de lecteurs de bande, périphériques réseau haut débit et autres, sous-système de monitoring matériel... Tu sais de quoi je parle de toute facon. Par exemple http://solutions.journaldunet.com/ [...] scsi.shtml "les drivers windows sont arrivés en 2003 et ont permis de réduire la conso en ressources" (tain y sont trop forts chez crosoft ils font de l'optimisation de drivers tout pourraves et à la bourre)
 
au passage je peux pas m'empecher de te donner ce lien http://www.winsupersite.com/review [...] 308_05.asp
et paul t. n'est pas connu pour son hostilité face à windows (mais la on déborde )
 
a+

Dans ton poste, mise à part son caractère insultat, je n'ai à noter que des points "vides d'arguments". C'est tout ce que j'ai à reprocher à ton poste.
 
J'ai déjà dit "je ne sais combien de fois" que :
1) C'est pas moi qui décide
2) Si la gestion de la boîte de mon client est merdique, j'y peux rien
3) Que ce soit sous Windows ou Linux, ce ne sera pas moi qui effecturai la migration
4) Mon métier, c'est "Chef de projets d'intégration GénériX", GénériX étant l'applicatif d'entreprise sur lequel je travail. Je ne suis aucunement ingénieur système, et le fonctionnement de cette application n'est nullement impacté par la plateforme sur laquelle il tourne.
 
Ensuite, quand tu me mets en lien un truc sur Vista, désolé, mais je ne vois pas le rapport. Et quand tu me parles de super matos à 10M€ l'unité, je ne vois pas non plus le rapport avec la config qui sera retenue... Lis un peu le topic, et trouve l'endroit où j'indique la config actuellement, qui est suffisante... Les serveurs retenus seront vraissemblement des serveurs d'entrée de gamme de Dell, HP ou IBM, qui sont tous livrées soit avec Windows 2003 Server, soit une distribution "AS" de Linux, avec dans les deux cas, 100% du matériel certifié pour chacun des deux OS. Je vois pas l'intérêt d'acheter une carte RAID à 16 canaux qui fait du 200 To/s quand le volume des données à gérer dépasse pas les 20 Go... Et encore moi l'intéret de mettre ce type de matériel sur un serveur d'entrée de gamme. Bref, t'es totalement hors sujet, tu me prends pour un con, et je pense être en droit de ne pas aimer ça
 
Pour ce qui est de Samba :

 
Voilà, ça c'est la réponse de mon collègue qui, sans connaître tes compétences Linux, et sans trop me mouiller, doit au minimum avoir les mêmes que toi dans le domaine, et j'accorde donc 100% de crédit à sa réponse. Après, il peut se tromper...
Dans tous les cas, y'a pas une seule version béta ou alpha du moindre produit qui tournera sur un serveur avec lequel je dois travailler, quand bien même elle serait réputée plus stable que la version "stable".

Tiens... Un truc "qu'à rien à voir"...
 
Depuis le temps qu'on me dit "Java c'est cool, maintenant c'est super rapide sur Win32 tout comme Linux", qu'en est-il réellement ?
Parceque là, va y avoir un sérieux problème de perfs avec une partie du nouvel applicatif (version intranet, en Java) :
 

 
Du coup, si Linux est substanciellement plus rapide, je pense qu'il s'impose au moins pour faire tourner cette partie du soft... Parceque là, à 25 user par proc, c'est total n'importe quoi

?? Il me dit aussi qu'Oracle nécessite un serveur X pour s'installer ??? Ils ont pas osé quand même

Par contre, je viens de m'appercevoir qu'il y a une chiée de trucs à réécrire si ils passent sous Linux... Y'a des chances pour qu'ils ne veuillent pas de Linux juste pour cette raison, ça représente "à la louche" un bon mois de boulot... (le soft d'édique a des grosses différences entre sa version win et x)

Install windows et barre toi d'osa

Je ne voulais en aucun cas t'insulter. Ce que je réfute, c'est ta comparaison qui n'est pas objective pour les raisons que tu a cité précedemment. Pour ces raisons aussi, le passage à linux semble difficile si toute l'infrastructure est windows-dépendante.
 
Je reste sur ma position : le support matériel de linux est identique voire meilleur que celui de windows sur les serveurs. Donc tu devrais rectifier ton tableau (sur l'entrée de gamme, c'est pareil). Pour les perfs, linux est meilleur aussi dans la plupart des cas, ce qui est comphréensible par l'évolution plus rapide du noyau et par la somme de moyens de développement mis en jeu de manière totalement collaborative. Par exemple voir le 2e lien posté par Dark Schneider sur ce post http://forum.hardware.fr/hardwaref [...] 0887-1.htm
Les interfaces réseau sont tout simplement mieux gérées.
Et sur les serveurs d'entrée de gamme soit interface 1gbit le goulet d'étranglement est déjà fort : http://forum.hardware.fr/hardwaref [...] 9928-1.htm
 
Si j'ai inclus le lien vers l'article sur vista, c'est pour illustrer le fait que 1) la méthodologie de développement de windows est foireuse 2) Ceci met en jeu la pérennité critère important lors d'une migration : la plateforme va-t-elle rester stable ? Mon oracle version x machin sortira quand optimisé pour vista ? Es ce que mon appli tournera bien ? Parce que microsoft va arreter la maintenance de zindozs server 2003 assez vite et vista sera ressourcivore. Debian est maintenu pendant très longtemps en ce qui concerne la sécurité par exemple. Et les updates sont toujours gratuites. L'uptime est aussi un facteur important dans la mise en place d'une infrastructure d'importance critique pour la société que tu cite.
Sur samba tu a sans doute raison. <EDIT: c'est samba 4 qui est en beta et samba 3 permet la gestion de domaines et des acl, ce qui est amplement suffisant pour des postes client xp : http://www.linagora.com/IMG/pdf/Pres-Samba3-SL2005.pdf http://linuxfr.org/2005/02/06/18251.html >
 
Du point de vue de l'interface en permettant à un utilisateur de faire de manière simple des actions prédéfinies :
- déclencher des scripts d'extinction et de redémarrage propres sur tous les serveurs
- redémarrer tel ou tel service (ce qui n'est pas du niveau d'un noob sous windows)
- etc... à distance ou sur un poste maitre unique. On peut penser à webmin si tu es sur un projet web.
 
ca suffit amplement si on définit bien les besoins de l'utilisateur, et évite les manips foireuses du style shutdowns à la sauvage. De toute facon un techos sera toujours nécessaire pour les interventions de maintenance. Pour l'utilisateur le serveur doit rester une boite noire qui lui fournit un service, il ne doit pas bidouiller dedans c'est trop dangereux !! C'est comme aller bidouiller un as400 sans savoir trop ce qu'on fait...
 
Un mois de portage c'est peu si ca peut leur permettre d'accéder à un nouveau marché et plus tard ils le feront et plus ce sera difficile. Ont-ils pensé à ca ?
 
a+

 
Sur tous les serveurs pas trop cheap y'a une interface d'admin accéssible en SSH sur une autre IP. C'est bien souvent un OS séparé qui réside sur une ROM qui te permet de tout faire à distance (ce qui inclut rebooter, booter , éteindre, aller dans le bios, etc etc) via ssh.  
Après tu va me dire : oui mais si mon réseau plante et le réseau d'admin aussi ? Là il faut pas avoir de bol qd mm =)

C'est un installeur graphique en Java  
 
Mais y a aussi moyen de faire une installation "unattended" sans X il me semble

Je plussoie largement l'avis qu' à fourni Mjules à ce sujet : tes chiffres sont faux il n'y a pas à discuter là-dessus, et il ne s'agit pas d'un arrondi à 1 ou 2 Mo près mais beaucoup plus.  
 
Une Debian à "vide" (sans GUI, services par défaut donc) ne consomme guère plus de 24 Mo, avec le serveur X de démarré + Enlightenment (DR16), l'explorateur de fichier (Rox-Filer) et un Eterm en transparence je suis à 46 Mo. Avec une consommation de 74 à 82 Mo j'ai en plus Firefox de démarré.
 
Ca fait une nette différence avec les chiffres que tu as avancé non ?  

 
une debian quasi toute fraiche, ça me pompe 12mo avec un kernel compilé moi meme (pas celui de base quoi)  
 
edit : pour ceux se posent la question, j'ai viré tout ce qui ne me sert pas, donc pas mal de trucs...

Ce qui fera environ 12Mo avec un kernel debian

Pas forcement, ptet que dans son kernel compilé à la mano, il n'a inclus le support d'aucun périphérique
 
PS: sinon, je suis entierement d'accord avec l'idée de ta remarque ...

Bon, on va se calmer, les enfants.

J'ai du mal quand même à comprendre certains arguments, en particulier ceux sur la montée en charge.
 
D'un, je vois pas en quoi l'occupation mémoire est synonyme de performance, ou pas. Vérifier une tenue en charge ca ne se fait pas à coup de moniteur d'évènement à la windows ou à coup de free -m sous linux.
 
Dans les quelques posts que j'ai pu lire, il y a beaucoup d'a priori que je ne vais pas aborder; en particulier sur la robustesse technique proposée par l'OS: les propos sont tenus pour la plupart par des non professionnels desdits systèmes, sans argumentation autre que "j'ai constaté". Ce qui justifie la demande d'objectivité, et je vais bien me garder d'argumenter la dessus.
 
Maintenant, je n'ai jamais manipulé de base oracle, uniquement postgre et mysql, au travers d'études de JE de mon école. Pour oracle, j'ai pas grand chose comme source, à part un bon ami qui travaille régulièrement sur la db d'Amadeus, qui tourne sous oracle. Je peux lui demander si besoin pour la charge.
 
 
Je pense que plutot t'orienter sur un argumentaire technique, plein d'écueils de par son caractère complexe (argumenter sur la tenue en charge de x ou de y, faut arrêter un brin quand même: configurer des politiques d'accès aux ressources est quelque chose que n'importe quel admin/développeur sait faire), il vaut mieux se concentrer sur les caractères fonctionnels: les coûts.
 
- ce que ca va couter en migration d'archi, d'un unix vers un linux ou un windows.
- le support et le service qu'il y aura derrière.
 
Je vais pas lancer mon troll ici, mais je souhaite tout de même faire remarquer aux gens que le modèle de développement vers lequel on s'oriente aujourd'hui est un modèle de service, l'OS est presque secondaire dans la démarche.
 
Tu demandes à une secrétaire de pouvoir redémarrer le serveur simplement, je vais répondre:
- je vois pas en quoi une secrétaire devrait avoir un accès physique à ces machines. En plus d'être un non sens, c'est dangereux: un employé qui veut emmerder la boîte ou fait une fausse manip, tu te bouffes les doigts après. Ca, c'est vécu.
- configurer des accès et des limitations aux ressources est quand même un prérequis, si lancer des impressions a la possibilité de faire du thrash sur la base, je ne pense pas qu'un windows ou un linux changera la donne.
 
Amha, c'est kiff kiff. Tu devrais plutot orienter ton argumentation vers le système avec lequel tu seras le plus à l'aise, et pour lequel il y a le plus de maitrise d'oeuvre; si personne ne sait se servir d'un unix-like, et si personne n'a les moyens de l'apprendre en un temps raisonnable, oriente toi vers du windows.
 
Mais intervenir techniquement suite à une panne sur des windows, d'expérience perso (win2k3 sur des serveurs de fichiers de centre de recherche CNRS) c'est pas une sinécure, et bien pire que sur des unix. Tu n'as aucune information, t'es face à écran noir au démarrage avec rien dessus, et le mode sans échec, j'en ai vu ses limites.
 
Pour ma part, la robustesse d'un système d'exploitation c'est celui qui l'installe et l'administre qui en fait la force ou la faiblesse, et tu seras pas à l'abris nulle part d'une panne sévère. Mais quand elle survient, c'est la ou tu vois si le système est bien foutu, ou pas. J'aurais bien aimé qu'un simple reboot résolve mes précédents problèmes, malheureusement, ca n'a pas été tout le temps le cas.
 
Sinon les sauvegardes sur bande, je vois pas en quoi il faut les faire faire par un chien, pour moi, cron script + rsync/bacula, ca marche très bien, ca se fait aussi bien sous windows que sous linux, sans demander au chien

Je sens que ce topic ne va pas tarder à partir aux oubliettes des topics ...
 
Parce que vu ce qu'il apporte d'intéressant ...

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.