Journal La mort de Solaris et de SPARC

Posté par  (site web personnel) . Licence CC By‑SA.
40
4
sept.
2017

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  . Évalué à 5.

    s/SOLARIS/Solaris/

  • # make it rains

    Posté par  . Évalué à 4.

    Il faut dire qu'à part Java, on se demande vraiment pourquoi Oracle a racheté SUN en 2010 ?

    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.

  • # D'un autre coté...

    Posté par  (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  (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  (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  (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  (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  (site web personnel) . Évalué à 4.

          Les sparcs se défendent très bien niveau performance en calcul.

          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

          Malheureusement je n'ai plus eu l'occasion d'en essayer personnellement depuis 2004.

          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  (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  (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  (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  (site web personnel) . Évalué à 3.

                  ça semble rester raisonnable pour une architecture vieille de six ans. Non ?

                  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 :

                  • diminution des fréquences,
                  • diminution de la consommation,
                  • maintien voire augmentation de la puissance au mm²,
                  • augmentation du nombre de cœurs bien souvent alors que certaines applications restent dépendantes d'un seul cœur car mono-processus et non multithreadé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

                  rapporté au nombre de cœur CPU c'est (c'était) plutôt pas mal

                  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  (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  (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  (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  . Évalué à 9.

        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).

        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  . Évalué à 3.

          Ou alors tu parles des workstations ?

          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  . Évalué à 1.

        en terme de fiabilité c'est le jour et la nuit

        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  (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  (site web personnel) . Évalué à 2.

        Merci bien, c'est ce genre de retour que j'apprécie vraiment.

        Les perfs étaient prévisibles : c'était lent mais puissant, fiable.

        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.

        Je l'utilisais pour lire mes mails et chauffer mon bureau.

        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 ^ !

        Pour répondre à tes questions : en 2017, ça sert plus à rien.
        

        Au moins c'est clair :-p.

  • # Même Java

    Posté par  . Évalué à 8.

    Il faut dire qu'à part Java, on se demande vraiment pourquoi Oracle a racheté SUN en 2010 ?

    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  (Mastodon) . Évalué à 9.

    Il faut dire qu'à part Java, on se demande vraiment pourquoi Oracle a racheté SUN en 2010 ?

    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  . Évalué à 4.

      Sun était abordable, avait un énorme portefeuille de brevets et tout une gamme hardware et stockage.

      Dont StorageTek que Sun avait déjà racheté 4 Milliards de $…

    • [^] # Re: Le pourquoi du comment ?

      Posté par  . Évalué à 1.

      Ils ont essayé mais leur politique tarifaire n'était pas assez agressive je pense et ont échoué là où Cisco a tendance à réussir.

      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  (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  . É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  . É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  (site web personnel) . Évalué à 3.

        Depuis 20 ans que je bosse, on prédit la disparition des mainframes, et pourtant ils sont toujours là !!!

        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  (site web personnel) . Évalué à 3.

      Donc je ne vois pas IBM abandonner AIX à court terme

      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  . É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  (site web personnel) . Évalué à 5.

          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

          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  (site web personnel) . Évalué à 2.

            Jamais vu un AIX dans le domaine de la Finance

            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  . É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  (site web personnel) . Évalué à 4. Dernière modification le 07 septembre 2017 à 15:47.

            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 ;-)

            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  . É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  . É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.

        peu d'évolutions sont à venir

        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…

        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.

        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  (site web personnel) . Évalué à 5.

          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…

          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.

          En revanche, sur les commandes de base pour l'admin, AIX est bien meilleur et productif que Linux.

          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à).

          Il y a pleins de commandes pour peupler des fichiers système style /etc/hosts. (…) Et nul besoin de sortir la grosse berta de conf management pour réinventer la roue.

          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 ».

          Sur la sécurité, va falloir développer un peu.

          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  . Évalué à 6.

            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.

            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).

            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à).

            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…

            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à).

            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.

            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 ».

            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

            IBM tarde à corriger les failles de sécurité.

            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.

            Mais un seul argument serait : personne n'utilise AIX pour des environnements connecté à Internet.

            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…

            Bref, AIX ce n'est pas nul, c'est un bon Unix, c'est puissant, c'est stable, mais c'est le passé.

            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  (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.