Cela n’étonnera personne mais, désormais, cela semble inévitable, Solaris et SPARC sont sur la voie de garage menant à la décharge…
https://scalability.org/2017/09/oracle-finally-kills-off-solaris-and-sparc/
Il faut dire qu’à part Java, on se demande vraiment pourquoi Oracle a racheté Sun en 2010 ?
Le passage en logiciel libre de ce qu’il reste pourrait être intéressant, dont mettre le code source de la dernière version de Solaris dans une licence 100 % compatible avec le noyau Linux ? Cependant, je n’y crois guère, sauf qu’à la différence d’OpenOffice où IBM jouait en sous main, ici il ne me semble pas qu’il y ait un autre géant dans le jeu. Mais, Oracle mise tout de même sur GNU/Linux pour son propre cloud…
Feuilleton à suivre !
# Majuscules ?
Posté par shbrol . Évalué à 5.
s/SOLARIS/Solaris/
[^] # Re: Majuscules ?
Posté par ymorin . Évalué à 4.
s/Solaris/Slowaris/ ;-)
[^] # Re: Majuscules ?
Posté par YBoy360 (site web personnel) . Évalué à 4.
s/Slowaris/Slowlaris/
# make it rains
Posté par Le Gab . Évalué à 4.
Parce que 2 milliards même en 2010, c'est keu dalle pour une boîte comme Oracle qui pensait pouvoir faire la nique à IBM chez les grands comptes.
Bref, je ne pense pas que cette acquisition a réellement posé problème à Oracle, il pouvait se le permettre, c'est tout.
[^] # Re: make it rains
Posté par refreketu . Évalué à 5.
C'était 7,4 milliards de dollars.
[^] # Re: make it rains
Posté par gUI (Mastodon) . Évalué à 6.
Ça fait combien en transfert de Mbappé ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: make it rains
Posté par Sacha Trémoureux (site web personnel) . Évalué à 10.
Un bras.
# D'un autre coté...
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 6.
Pour ceux qui veulent continuer avec du
sparc64, il y a d'autres sources que le cadavre de Sun : Fujitsu ne semble pas disposé à jeter l'éponge. Je ne sais pas ce que ça vaut, mais il semble qu'il y a encore des gens qui utilisent ce genre de machine pour faire du serious business.[^] # Re: D'un autre coté...
Posté par Psychofox (Mastodon) . Évalué à 4.
À vrai dire c'était Fujitsu qui fabriquait les machines sparc Sun puis Oracle, donc ça vaut la même chose.
# Performances SPARC ?
Posté par Tarnyko (site web personnel) . Évalué à 10.
Quel est l'intérêt d'une machine SPARC en 2017 ? Comment ses performances brutes se comparent-elles, par exemple, aux architectures Intel x86-64 et POWER récentes ?
(c'est une vraie question. Je pourrais chercher des benchs moi-même, mais aurais sans doute un meilleur retour sur ce fil)
[^] # Re: Performances SPARC ?
Posté par Psychofox (Mastodon) . Évalué à 8.
En terme de performances brutes je ne sais pas car je n'ai jamais fais de comparaison, mais en terme de fiabilité c'est le jour et la nuit d'après mon expérience à la fois sur du sparc64 (plus depuis 2014 comme du Power (jusqu'en 2016).
Statistiquement les sortes de PC bricolés que nous vendent hp, cisco, dell, hitachi sont vraiment pas folichons en terme de fiabilité. Mais bon comme ils ne coûtent rien et qu'on vit dans un monde de virtualisation et de haute dispo tout le monde s'en branle. Même quand un hyperviseur tombe et descend avec lui 20 à 40 VMs d'un coup, plus personne ne s'en émeut.
[^] # Re: Performances SPARC ?
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 4.
Les sparcs se défendent très bien niveau performance en calcul. Conférer à ce sujet le top500 permet de s'en convaincre facilement. Malheureusement je n'ai plus eu l'occasion d'en essayer personnellement depuis 2004.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Performances SPARC ?
Posté par BAud (site web personnel) . Évalué à 4.
sources ?
en 2011 le T4 cédait le pas au Power7 et au Xeon lorsque le benchmark est rapporté au cœur…
http://www.myra.com/blog/benchmarking-sparc-t4-intel-xeon-business-case-dead
Je te note le début de la conclusion :
« Well, in absence of a decent CPU-only benchmark, we can only speak broadly about the SPARC T4's per-core performance. SPECjEnterprise2010 definitely suggests the T4 is still getting outperformed by Xeon. Oracle has increased their per-core licensing factor for the T4 compared to the T3, with Xeon and T4 both at 0.5. Poor POWER7, heavyweight champion, is dinged by Oracle at double the licensing cost per-core - else it might be the winner. »
Sur des tests applicatifs (serveur d'appli + base de données), les sparc n'obtiennent de bonnes notes qu'au prix d'une débauche en nombre de cœurs :
http://www.spec.org/jEnterprise2010/results/jEnterprise2010.html
ah… des SunFire 280 ?
Il y a ensuite eu : SF15K (~2006-2009), M9000 (2008-2014), UCS de chez Cisco… pour le haut de gamme. J'essaie d'oublier les T2000 / T4000 / T5000 qui avaient peut-être de bonnes capacités en multi-threading mais une puissance de calcul minimaliste par cœur.
[^] # Re: Performances SPARC ?
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 4.
Il me semble que la lignée de Sparc que vous évoquez soit celle éteinte par oracle. Quant à mon message, il mentionnait plutôt — assez implicitement certes — celle présente dans le top500 et développée par fujitsu.
Le K computer occupait la 1er place en 2011 et pointait encore à la 8ème en juin dernier. Ce qui paraît tout à fait remarquable pour un ordinateur n'utilisant pas de GPU comme co-processeur.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Performances SPARC ?
Posté par BAud (site web personnel) . Évalué à 4.
Le K computer est 277è au classement green500 et le 1er SPARC est 111è au green500. Pas très efficace rapporté au kW consommé…
[^] # Re: Performances SPARC ?
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2.
Certes. Par contre rapporté au nombre de cœur CPU c'est (c'était) plutôt pas mal ; considérant notamment la polyvalence de ce type d'architecture nettement supérieure à des CP/GPU ou des bluegene. Par ailleurs — sauf rénovation — ça semble rester raisonnable pour une architecture vieille de six ans. Non ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Performances SPARC ?
Posté par BAud (site web personnel) . Évalué à 3.
Au début 2000 la course à la puissance était encore le seul^principal critère ; depuis ~2010, c'est l'efficience énergétique qui est plutôt visée :
mais bon, le PUE (Power Usage effectiveness) n'est qu'une première étape. Ne lancer des traitements que lorsque nécessaire éviterait de cramer de la puissance pour rien déjà… (ah ces milliers d'heures passées à sauvegarder des données
Donc, non : l'architecture SPARC a montré ses limites (explosion des cœurs et de la consommation pour une course vaine à la puissance). Ceci explique sans doute son abandon, même par Oracle, sujet de ce journal. À un moment, c'est le principe de réalité qui nous rattrape tous ;-) Pas étonnant d'ailleurs que le 1er commentaire de ce nourjal soit une allusion à Slowlaris : cela aurait pu te donner une indication :D
[^] # Re: Performances SPARC ?
Posté par François Trahay (site web personnel) . Évalué à 6.
Le K computer est 277eme au green500, mais:
- lors de son installation (en 2011), il était beaucoup plus efficace (824.6 GFlop/kWatt) que les autres machines du top 500 ( 463.7 GFlop/kW en moyenne pour les machines du top10)
- la plupart des machines qui sont + efficaces utilisent des accélérateurs (GPU, Xeon phi, etc.) qui ont l'avantage de faire beaucoup de GFlop pour peu de Watt et qui sont très efficaces sur certains types d'appli (comme LINPACK, le benchmark utilisé pour faire le classement du top500/green500)
Donc, pour un processeur "généraliste", le SPARC64 VIIIfx était quand même vachement efficace !
[^] # Re: Performances SPARC ?
Posté par Renault (site web personnel) . Évalué à 5.
C'était efficace au passé, oui.
Mais faire une architecture de processeur, ce n'est pas gratuit, améliorer le SPARC tout en gardant la compatibilité ascendante du jeu d'instructions et de certains mécanismes n'est pas une mince affaire.
Et ce n'est pas parce qu'hier le SPARC était bon qu'une mise à jour avec les nouveautés techniques et les nouvelles contraintes qu'ils seraient meilleurs que les x86 d'aujourd'hui sur le sujet.
C'est dommage qu'Oracle abandonne peu à peu l'ensemble des bonnes technologies que Sun avait, mais s'ils ne le font pas c'est aussi probablement parce que ce n'est pas assez rentable comme activité pour eux. Peut être aussi qu'ils ont saboté par inadvertance certains sujets (comme OpenOffice.org) mais bon, c'est ainsi.
[^] # Re: Performances SPARC ?
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 9.
Encore une fois, on ne semble pas s'entendre. Oracle abandonne l'architecture Sparc Niagara de Sun, une architecture Sparc optimisée pour la gestion d'un maximum de filaments et de calculs en entiers. L'architecture de Fujitsu est différente (plutôt tournée vers l'efficacité des calculs flottants si j'ai bien suivi), gérée par une autre entreprise, avec des objectifs distincts. Jusqu'à aujourd'hui — sauf dans le titre réducteur ou trompeur de l'article — il n'a jamais été question de la fin de cette dernière architecture. Seulement de la branche possédée par Oracle. Ou bien aurai-je mal compris ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Performances SPARC ?
Posté par lasher . Évalué à 3.
Non non, tu as bien compris. :-)
[^] # Re: Performances SPARC ?
Posté par MTux . Évalué à 9.
Heu… quel genre de soucis recontres-tu sur des serveurs x86_64 exactement ? Perso j'ai pas à m'en plaindre. Ou alors tu parles des workstations ?
[^] # Re: Performances SPARC ?
Posté par Kerro . Évalué à 3.
Même au niveau des postes de travail, je trouve la fiabilité tout à fait excellente. Je parle du matériel, pas des OS.
Et encore une fois, on élimine les bouses, il ne faut pas non plus prétendre que les plus infâmes cartes-mères sont fiables, ni les alimentations en carton, etc.
[^] # Re: Performances SPARC ?
Posté par Kerro . Évalué à 1.
Je n'ai pas le souvenir d'avoir eu de problème de fiabilité avec du PC, à part des bouzes pour lesquelles s'était prévisible (Dell bien entendu, ou des « serveurs » de chez ACER ou ASUS).
Les serveurs qui tombent à cause de problèmes matériels (carte-mère, mémoire, processeur) je crois en avoir rencontré zéro jusqu'à présent (je ne compte pas les truc qu'on trouve chez 1and1 ou Amen, je parle de machines un minimum sérieuses locales ou hébergées).
Avec du Sparc ou n'importe quoi d'autre je ne suis pas sûr qu'il soit possible d'obtenir significativement mieux. Le taux de panne de la micro-électronique est relativement constant à technologie donnée (toujours en mettant de côté les grosses bouses évidentes).
[^] # Re: Performances SPARC ?
Posté par YBoy360 (site web personnel) . Évalué à 10.
Pour avoir fait beaucoup d'optimisation CPU sur Sparc (uniquement desktop), pendant longtemps, il y a longtemps, ce que l'on pouvait conclure de ces CPU par rapport aux CPU de l'époque (Intel, Power) : ils étaient totalement largué question FPU, arrivaient à surnager question ALU, avaient un controller mémoire pas trop mal (pour du desktop), et une unité prefetch dédiée, qui, quand on était comme moi, était sympa à utiliser (je crois que j'ai été le seul au monde à l'utiliser, à mon époque, et a y voir un intérêt…).
Les perfs étaient prévisibles : c'était lent mais puissant, fiable. La différence avec le PC, c'est que tu avais des machines très grosse (genre 140 CPU), qui utilisaient exactement le même OS… Par exemple dans mon bureau j'avais un V880, avec 8 CPUs, et 2 cartes graphiques de 12 kilos chacune (un putain de desktop). ça gérait l'overlay, jusqu'a 4 (ou plus) écrans en vision stéréo (via des lunettes à christoliquide, qui occultaient les verres en synchronisation avec les écrans). Je l'utilisais pour lire mes mails et chauffer mon bureau.
Pour répondre à tes questions : en 2017, ça sert plus à rien.
Le concepteur en chef de la divion CPU de Sun (je l'ai rencontré, mais j'arrive plus à retrouver son nom) s'est barré chez MS pour travailler sur des CPU sans MMU (la mémoire est gérée directement par une machine virtuelle, un truc dans le genre)).
[^] # Re: Performances SPARC ?
Posté par Tarnyko (site web personnel) . Évalué à 2.
Merci bien, c'est ce genre de retour que j'apprécie vraiment.
La fiabilité (que souligne aussi PsychoFox) est appréciable, mais attendue pour des machines de cette trempe -et cette "facture" ;-). Effectivement les benchs pointés ne soulignent pas des performances ahurissantes, mais juste capables de titiller le tiers supérieur pour les modèles les plus chers. J'ai le sentiment que ça ne justifie pas les embêtements d'archi, à moins d'avoir de l'héritage logiciel (legacy) ou des besoin spécifiques couverts par l'OS.
Et aussi impressionner le touriste ; attends, vu l'installation et les lunettes ça devait être énorme la tête du visiteur tombé dessus par hasard ^ !
Au moins c'est clair :-p.
# Même Java
Posté par claudex . Évalué à 8.
Même pour Java, ils commencent à se séparer de certains bouts. https://www.infoq.com/news/2017/08/oracle-open-sourcing-javaee
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Le pourquoi du comment ?
Posté par Psychofox (Mastodon) . Évalué à 9.
Sun était abordable, avait un énorme portefeuille de brevets et tout une gamme hardware et stockage. Oracle voulait tenir la chaîne de bout en bout avec des systèmes comme les Exadata, des baies de stockages, etc. Ils ont essayé mais leur politique tarifaire n'était pas assez agressive je pense et ont échoué là où Cisco a tendance à réussir.
[^] # Re: Le pourquoi du comment ?
Posté par Prosper . Évalué à 4.
Dont StorageTek que Sun avait déjà racheté 4 Milliards de $…
[^] # Re: Le pourquoi du comment ?
Posté par Dabowl_75 . Évalué à 1.
Oracle a fait de grosses réduction sur le prix des licences si tu achetais un exadata.
Le seul problème de l'exadata, c'est que ce n'est pas fait pour héberger plusieurs bases, en gros pour faire de la consolidation.
Et le ticket d'entrée d'un exadata n'est pas donné.
Mais comme les commerciaux d'oracle sont bons, j'ai vu quelques dsi acheter des exadata et dire à leur équipe de les peupler (mais ils ne savaient pas avec quoi…)
[^] # Re: Le pourquoi du comment ?
Posté par YBoy360 (site web personnel) . Évalué à 10.
Puis Sun avait un super logo, et ça, ça n'a pas de prix!
# La fin programmée des Unix proprio
Posté par Dabowl_75 . Évalué à 2.
Oracle ne fait que mettre des clous sur un cercueil déjà peuplé depuis longtemps.
Les autres cercueils à venir sont HPUX et AIX.
Il y a encore une grosse base AIX implantée sur le marché français et le couplage hardware permet pas mal d'avantages.
Donc je ne vois pas IBM abandonner AIX à court terme, mais les délais de support et maintenance ont été rallongés…
Mais hélas, quand je vois que sous Linux le seul volume manager un peu sérieux est proprio (veritas)…on perd du proprio pour retrouver du proprio
A la fin on n'a rien gagné en liberté
[^] # Re: La fin programmée des Unix proprio
Posté par georgeswwbush . Évalué à 3.
Pas totalement d'accord…. Pour certain besoins précis - grosse DB centralisée, grand nombre de CPU, intégration / support par un vendeur - les machines Unix auront toujours un créneau, de niche certes.
Depuis 20 ans que je bosse, on prédit la disparition des mainframes, et pourtant ils sont toujours là !!!
Tant qu'ils font le job….
Par contre, pour Sparc / Solaris, c'est clair que ça sent le sapin. La faute à l'attitude déplorable d'Oracle (et surtout les commerciaux): arrogance, suffisance, agressivité…
Ça rappelle les machines DEC (et la puce Alpha) rachetées par HP.
[^] # Re: La fin programmée des Unix proprio
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Pour avoir regarder le hardware des BULL genre DPS7000, j'ai l'impression que leur vitesse vient surtout de leur contrôleur disque qui faisait en gros les requêtes de base de donnée en hardware.
Donc, si un construction lance un contrôleur disque spécialisé, on peut imaginer que les mainframes perdent tout intérêts. La plus part des DB utilisent des "moteurs" qu'il peut être possible de porter en HW et de gérer des grappes de SSD ou de HD.
"La première sécurité est la liberté"
[^] # Re: La fin programmée des Unix proprio
Posté par Jiel (site web personnel) . Évalué à 3.
Mais AIX est à la traîne pour à peu près tout (commandes de base, outils, sécurité) et peu d'évolutions sont à venir. AIX, c'est très stable, ça marche pour faire de l'informatique « à la papa » pour la finance voire pour l'industrie, mais pour le reste… Ce sera maintenu tant que cela rapporte plus de sous que cela coûte et heureusement, c'est souvent vendu avecd es serveurs qui coûtent très cher.
[^] # Re: La fin programmée des Unix proprio
Posté par zen . Évalué à 1.
Jamais vu un AIX dans le domaine de la Finance. La banque de détail ou l'assurance oui. La finance est un très gros consommateur de calcul flottant. On trouve des grilles de calcul à plusieurs millier de CPU avec du proc Intel et du window ou linux.
Les sparc en Finance j'en ai vu pour les serveurs de base de données ( oracle ou sybase ). Mais remplacé maintenant pour de l'intel sous linux pour des problèmes coût.
[^] # Re: La fin programmée des Unix proprio
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
Ils ne calculent pas en entier ou en réel en virgule fixe ? Sachant que 0.1 + 0.2 - 0.3 ne fait pas 0 dans quasiment tous les langages, j'aurais du mal à faire de la finance en calcul flottant. A vrai dire, j'aurais du mal à faire de la finance tout court ;-)
[^] # Re: La fin programmée des Unix proprio
Posté par Jiel (site web personnel) . Évalué à 2.
Je me méprends sur le terme de "finance". J'en ai vu dans des assurances et des services liés au banque (pour faire tourner du Websphere notamment).
[^] # Re: La fin programmée des Unix proprio
Posté par zen . Évalué à 3.
La finance consomme énormément de CPU pour les analyses de risques sur tous les produits financier derivé de taux ou dérivé action. Des traitements réglementaire comme la VaR ( Value At Risk ) consomme pas mal de calul. En fait coté finance il y a énormement de calculs statisques et simulations d'évolutions de cours de taux, ou valeur des produits.
Toutes les grosses institutions financières se posent la question de l'utilisation des GPU.
[^] # Re: La fin programmée des Unix proprio
Posté par Michaël (site web personnel) . Évalué à 4. Dernière modification le 07 septembre 2017 à 15:47.
Ce que tu dis est exact en ce qui concerne la comptabilité mais en gestion de risque on utilise beaucoup de modèles mathématiques plus ou moins complexes – qui impliquent du calcul scientifique et donc du calcul en virgule flottante.
Même si les outils sont arbitrairement complexes le problème de base n'est pas difficile à saisir. Un des produits financiers les plus communs est le crédit, et la banque qui émet un crédit a dans ses actifs un contrat qui engage l'autre partie prenante à rembourser sa dette. Quelle est la valeur de cet actif? Quel est le prix juste pour un tel actif? Quel est le prix juste pour une police d'assurance qui protège la banque d'un défaut de paiement? Ce sont les questions de base qui ouvrent sur la finance mathématique.
Un des textes de base de référence sur le sujet est le livre de John Hull “Options, Futures and Other Derivatives” dont les tout premiers chapitres sont abordables sans gros bagage mathématique et qui peut donner une idée plus précise sur le genre de méthodes utilisées. Dans les textes d'introduction il y aussi le livre de Joshi “The Concepts and Practice of Mathematical Finance” qui est moins populaire mais très sympa et on trouve plein de cours en ligne en fac. À un niveau plus avancé un texte classique est le livre de Brigo et Mercurio “Interest rate models, theory and practice” ou (enfin quelque chose en français) le cours de Nicole el-Karoui. Sur arXiv il y a une section q-fin dédiée à la finance mathématique.
[^] # Re: La fin programmée des Unix proprio
Posté par Dabowl_75 . Évalué à 2.
ne pas occulter les "habitudes" qu'il peut y avoir dans un domaine, et les partenariats des éditeurs de gros progiciels avec les constructeurs (coucou murex).
Parfois l'absence d'une techno dans un domaine se résume à ça.
[^] # Re: La fin programmée des Unix proprio
Posté par Dabowl_75 . Évalué à 5.
AIX à la traîne sur les commandes de base ?
Je crois que tu connais mal AIX.
Si tu veux parler d'un tar ou d'un sed, oui. Par rapport aux commandes de la GNU, c'est clair qu'il est à la ramasse.
Mais on peut installer les outils de la GNU sous AIX depuis 2003 au moins, depuis AIX5L…
En revanche, sur les commandes de base pour l'admin, AIX est bien meilleur et productif que Linux.
Je te renvoie aux commandes d'admin pour gérer les users/group (lsuser, etc..).
Il y a pleins de commandes pour peupler des fichiers système style /etc/hosts.
Cela évite les conneries faites à la mano ou par des scripts foireux.
Et nul besoin de sortir la grosse berta de conf management pour réinventer la roue.
Sur la sécurité, va falloir développer un peu.
AIX dispose aussi de la Stack Execution Disable protection.
Il y a aussi AIX Security Expert, pour gérer des profils de tuning server compatible SOX par exemple :
https://www.ibm.com/developerworks/aix/library/au-aixsecurity/index.html
Voilà deux exemples rapides qui me viennent à l'esprit.
Les délais de maintenance/support/release ont été rallongés, certes.
Pour les évolutions à venir, il faudrait déjà que tu voies le chemin parcouru.
Les évolutions récentes comme le live kernel update sont tout de même assez importantes pour être signalées.
Et j'en passe, mais clairement l'avenir n'est pas du côté des unix proprios, en fait la bataille n'a même plus lieux sur les OS…
Le coût d'acquisition a bien baissé mais cela reste élevé.
Mais ce n'est qu'une composante de l'infra, on n'a pas parlé des coûts de licences logiciels.
Or avec ce type de machine, on peut faire des choses qui permettent de réduire la voilure sur le nb de sockets, et donc réduire les coûts (coucou oracle).
Et c'est bien pour ça que le parc AIX continue de grossir, car on arrive à des TCO moins élevés au final qu'avec l'équivalent en x86 sur certains projets.
[^] # Re: La fin programmée des Unix proprio
Posté par Jiel (site web personnel) . Évalué à 5.
Par défaut, pas de commandes GNU, le shell par défaut est ksh, vim n'est pas disponible, ssh pas installé. En 2017, sur un Unix. Oui, on est clairement à la ramasse.
Je ne trouve pas. Rien que la base de registre ODM est un fouilli incroyable. C'est vrai, la gestion des LVM est très simple, mais Linux a rattrapé son retard sur ce point (il y a 10 ans déjà).
Rien que le fait qu'AIX ne privilégie pas les outils de configuration management en dit long sur le fait qu'il soit sur le déclin. Aujourd'hui, on utilise puppet/ansible/terraform en production, pas des commandes « à la papa ».
Par exemple, telnet était encore activé par défaut il y a quelques années (je ne sais pas si c'est toujours le cas), le login en root à distance est activé par défaut. Je ne me rappelle pas d'un équivalent à SELinux sous AIX. IBM tarde à corriger les failles de sécurité. Mais un seul argument serait : personne n'utilise AIX pour des environnements connecté à Internet.
Bref, AIX ce n'est pas nul, c'est un bon Unix, c'est puissant, c'est stable, mais c'est le passé.
[^] # Re: La fin programmée des Unix proprio
Posté par Dabowl_75 . Évalué à 6.
si si SSH est installé, par contre ibm a un mis un temps infini à l'inclure dans l'install de base (il est depuis très longtemps dans les extras).
L'ODM, y a du pour et du contre.
Niveau gestion du matériel, AIX a une bien meilleure gestion que Linux car les périphériques sont déclarés de manière dynamique et persistente, stabilité garantie au reboot suivant. Pas de loterie comme il arrive parfois avec Linux où une NIC est découverte avant une autre selon la découverte du matériel…même si ça va mieux avec de bonnes règles udev etc etc…
Je n'ai jamais vraiment aimé le LVM Linux mais c'est peut-être un biais cognitif dû à ma longue expérience AIX.
Dans des projets de migrations de baie SAN par exemple, avec le LVM d'AIX, je suis davantage rassuré qu'avec celui de Linux.
Que ce soit avec un migratepv ou un mklvcopy, je n'ai jamais de surprise.
Avec Linux, on va parler ici de redhat, si t'es pas au dernier niveau de patch de la rhel6, tu as parfois des surprises…
Mais bon, c'était il y a bien deux ou trois ans et je n'ai pas fait de telles opérations en rhel7, alors on va accorder le bénéfice du doute.
Tu es mal renseigné. Sur l'install de base, tu as raison, il n'y a ni python ni ruby.
Mais sinon sur AIX on fait aussi du bien du Ansible que du chef. IBM avait choisi d'ailleurs chef, bien mal lui en a pris, on a tous fait du Ansible (pour des raisons internes…). Bref, il y a une communauté d'AIXiens qui fait du bon boulot.
https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Power%20Systems/page/Automating%20AIX%20Patching%20with%20Chef
Lesquelles ? Si tu parles des failles d'OpenSSL c'est faux. Il y a régulièrement des bulletins de sécurité et on a les patchs dans les temps.
Et c'est pas pour rien que IBM a racheté BigFix pour se concentrer sur ses sujets.
Ca c'est vrai, je ne vois pas d'intérêt à raccorder un AIX à internet (si ce n'est pour récupérer des patchs systèmes).
En revanche, il y a encore pas mal d'AIX raccordés au réseau swift…
C'est tellement le passé que c'est un des rares à encore permettre un shrink à chaud du filesystem, alors que tout le monde s'en fout maintenant que redhat a choisi xfs par défaut
[^] # Re: La fin programmée des Unix proprio
Posté par Psychofox (Mastodon) . Évalué à 5.
Pour ce que ça vaut chez mon employeur précédent on gérait des machines AIX via puppet.
Ce qui m'embêtait surtout c'était la gestion des logs. Par exemple pour récupérer les errpt dans splunk faut soit dumper le report de façon régulière, soit créer un odm qui va appeler logger à chaque nouvelle erreur pour avoir un logging standard dans /var/log…
Bref on finit toujours par y arriver mais ça nécessite un peu de travail supplémentaire sans grosse valeur ajoutée.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.