Dans la même enquête, AMR Research montre les avantages du passage d'un système d'informations sous Linux, générant notamment des économies de 30% et une meilleure stabilité du système (avec des audits de code réguliers).
Aller plus loin
- l'article sur vnunet.fr (2 clics)
- l'article sur vnunet.com (1 clic)
- le site d'amrresearch (1 clic)
# Euh ...
Posté par Maillequeule . Évalué à 10.
[^] # Re: Euh ...
Posté par Tutur . Évalué à 7.
Vivement le retour du [-1] .....
[^] # Re: Euh ...
Posté par Gilles . Évalué à 1.
Avant de dire des bétises ce serait vaudrait vraiment s'informer !
Par exemple TOUTES les appliances de Symantec tournent sous Linux.
Pour Sun la bécane LX50 est sous Linux, et est destinée à recevoir un Chekpoint NG.
[^] # Re: Euh ...
Posté par Tutur . Évalué à 1.
Desole
# Re: Aux Etats-Unis, on se méfie de Linux
Posté par XHTML/CSS inside (site web personnel) . Évalué à 4.
("business humanum est" et "in gold we trust").
Quoi que, vu que ça ne leur rapporte pas directement un max de pognon, on peut comprendre leur réticence (dites moivoir, M$ c'est bien américain, non ?).
Encore un rapport qui ne va pas être lu...
[^] # Re: Aux Etats-Unis, on se méfie de Linux
Posté par grmbl . Évalué à 4.
Beh oui mais "American product, the best" aussi. Et on peur pas dire que GNU/Linux soit americain pur jus.
# Re: Aux Etats-Unis, on se méfie de Linux
Posté par notrya2 . Évalué à 1.
[^] # Re: Aux Etats-Unis, on se méfie de Linux
Posté par Benjamin . Évalué à -2.
(-1)
[^] # Re: Aux Etats-Unis, on se méfie de Linux
Posté par notrya2 . Évalué à 10.
Si l'europe utilisait nettement plus GNU/Linux que les USA, Mandrake et Suse serait beaucoup mieux positionné. Or c'est RedHat qui "rafle" la mise malgrés la bonne implentation de Mdk aux USA.
Je ne nie pas qu'il y a des pays qui ont plus confiance en Linux que les USA. Mais globalement je pense que les USA sont au-dessus de la moyenne. De plus, les principaux "partenaires" commerciaux de GNU/Linux sont américain (IBM, SUN, etc...).
J'ai aussi lu que linux était moins utilisé en France qu'aux USA. Par contre, les allemands utilisent plus Linux que les USA (rapporté à la population bien sure).
[^] # Re: Aux Etats-Unis, on se méfie de Linux
Posté par notrya2 . Évalué à 5.
http://counter.li.org/reports/arearank.php?orderby=users#table(...)
[^] # Re: Aux Etats-Unis, on se méfie de Linux
Posté par gbouba . Évalué à 1.
bouba.
# Re: Aux Etats-Unis, on se méfie de Linux
Posté par kardiac . Évalué à 10.
L'autre point est la détection d'erreur hardware fournis par les unix professionels (je parlerais seulement d'AIX que je connais bien). Et bien c'est vrai !!! Dans l'architecture hardware RS/6000 de tout les serveurs relativement récent un "service processor" est intégré pour vérifier le hardware et prévenir l'OS en cas d'erreur hardware. Le "service processor" fonctionnant même lorsque le serveur est arrété et étant particuliérement pertinent(très rare qu'il indique une erreur sur la mauvaise pièce hardware et si c'est le cas c'est dans 90% des cas la pièce en amont qui est coupable). C'est quand même d'un grand confort pour un serveur supportant des applications critiques.
Mais tout ceci est un bonus hardware : linux ne peut pas rivaliser en se basant sur un système de détection uniquement logiciel et aucun autre OS ne pourrait d'ailleurs.
Donc pour conclure c'est un article plutot positif et j'espère qu'IBM intégrera bientot un support pour le "service processor" à linux ce qui enlévera les quelques doutes qui restent aux grandes entreprises.
Kardiac qui aime bien le Power 4 aussi =)
[^] # Re: Aux Etats-Unis, on se méfie de Linux
Posté par Delahaye Matthieu . Évalué à 5.
C'est vrai qu'ils sont un peu en retard la dessus. Moi sur mes Itanium I et II d'HP j'ai deja le support ;-)
[^] # service processor dans les arch itanium?
Posté par kardiac . Évalué à 1.
Quand je parle de service processor, c'est bien un processeur distinct des power 4, dédié à la détection d'erreur. Il peut par exemple désactivé un power 4 en fonctionnement s'il est sur le point de griller (tout est évidemment paramètrable ;-) l'OS(prévenu par le service processor) se chargeant de répartir la charge du proc sur les autres. Il a aussi 2-3 autres fonctionnalités sympas (gestion des slots memoire, des proc, historique des erreurs hardwares (pouvant ne pas être même détecté par AIX, etc...)
Sinon IBM supporte linux sur l'ensemble de sa gamme pseries et ce jusqu'au regatta( peut-être pas le p690 actuellement mais c'est en cours). Tu as donc le choix entre AIX et linux lorsque tu achète un serveur IBM. Plutot sympa non ? ;-)
IBM considérant même linux comme le remplacant d'AIX d'ici quelques années. Et pour l'instant ils sont plutot pas mal sur le respect de la philosophie du libre et coté contribution . Pourvu que ca dure.
Kardiac
[^] # Re: service processor dans les arch itanium?
Posté par Delahaye Matthieu . Évalué à 1.
J'ai pas teste des archis Itanium autre que HP donc je sais pas si c'est generalise chez tout les constructeurs. De plus, c'est plus ou moins le meme service que sur les archis pa-risc (toujours chez HP). Donc je ne m'avancerai pas pour faire un lien fort Itanium/service processor
Par contre j'ai jamais vu de liens Linux/service processor sur pa-risc alors que le kernel est capable de dialoguer avec lui sous ia64 via SAL/PAL, un truc specifique Itanium (qui doit surement exister sous d'autres noms avec d'autres architectures).
Y a un projet en cours sur sf:
http://mca-recovery.sourceforge.net/(...)
[^] # Re: service processor dans les arch itanium?
Posté par kardiac . Évalué à 1.
Le projet avait l'air intéressant mais ils ont du se décourager devant le manque de documentation :-( Un développeur freebsd (s'occupant apparament du portage de freebsd sous ia64) a posé la question si le projet était encore actif le 12 décembre sur le forum de sourceforge et a pas eu de réponse re :-(
C'est malheureusement le genre de projet qui sans le minimum d'aide et de support du constructeur a très peu de chance d'aboutir. dernier :-(((
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.