SUN libère ses processeurs SPARC

Posté par (page perso) . Modéré par Amaury.
Tags :
0
13
déc.
2005
Matériel
Après avoir libéré son logiciel, SUN libère son matériel.

SUN s'oriente de plus en plus vers le service, la vente de support, autour de ses plateformes de logiciels et matériels.
Après avoir libéré Solaris (il existe même un OS GNU/Solaris, GNU avec un noyau Solaris), SUN a annoncé le 6 décembre 2005 la création de OpenSPARC, c'est à dire la mise en open-source du c½ur de leur plateforme hardware.
Chacun pourra, s'il en a les moyens, produire des processeurs "compatibles SPARC".

Étant données les performances de ce matériel, les ordinateurs "compatibles SPARC" pourraient connaître un succès comparable aux x86. Les cartes graphiques spécifiques SUN sont particulièrement remarquables. Leurs pilotes sont naturellement libres (d'autres machines SUN utilisent du nvidia).

GNU/Linux tourne déjà sur les machines SUN, que ce soit celles équipées de processeurs AMD ou de processeurs SPARC. Les machines SUN, une alternative au PC?

En fait d'après un de ses responsables, Gilles Gravier: « Sun part du principe que le logiciel peut être libre et gratuit ».
En libérant ses produits, logiciels et matériels, SUN espère augmenter le nombre de ses clients, qui pourront ainsi adapter les produits SUN à leurs besoins, et vendre plus de support sur des systèmes qu'ils connaissent bien.
SUN a aussi la capacité de résoudre plus facilement des problèmes sur leur architecture, comme de créer un module spécifique du noyau, etc.
SUN espère aussi naturellement une augmentation des contributions, rapports de bugs, etc...

C'est dans ce cadre que SUN a signé la pétition contre la loi DADVSI. Il s'agit explicitement de soutenir le libre par cet acte.

Actuellement il n'y a pas de DRM sur les machines SUN.
(J'ai posé 3 fois la question formulée différemment ! Ils sont patients...)
Il n'est pas prévu d'en mettre dans l'immédiat. Peut être seront elles utilisées un jour dans le cadre de la diffusion de documents, pour s'assurer que le destinataire est bien le bon.
Dans ce cas ces fonctions DRM seront vraisemblablement désactivables/activables selon le choix de l'utilisateur ou du propriétaire de l'ordinateur.

Solaris est sous Licence CDDL, inspirée de la licence de Mozilla. Cette licence sera étendue à d'autres logiciels SUN. Elle remplacera les autres licences libres ou apparentées pour simplifier leur gestion.

Les spécifications pour le port de systèmes libres comme GNU/Linux ou NetBSd sur Machines SUN sont naturellement disponibles.

Aller plus loin

  • # C'est bien mais..

    Posté par (page perso) . Évalué à 1.

    Moi personnellement ce que j'attend le plus c'est une carte graphique aux spécifications libre. Pour cela il y a le projet open graphics[1], donc j'attend...

    Enfin saluons tout de même cette belle action de sun. Moi j'ai juste envie de dire merci :)

    1. http://lists.duskglow.com/mailman/listinfo/open-graphics
    • [^] # Re: C'est bien mais..

      Posté par (page perso) . Évalué à 3.

      Faut-t-il créer la FHF(*) ? On y nommerait comme président Richard Halman, et on pourrait enfin faire du DRM que l'on saurait comment il fonctionne. On pourrait même l'adapter à ses propres besoins !

      Bien sûr, les grincheux vont être obligés de préciser que la jouissance d'un bien matériel est à tendance exclusive, et que les coût de reproductions ne sont pas nuls, de se lancer dans explications. Et bien, je l'ai fait exprès, voilà !

      Accessoirement, une carte 3D libre, ouais, je suis preneur, mais alors pas à 450euros, hein...

      (*) Free Hardware Fondation
  • # Quelques journaux pour commencer...

    Posté par (page perso) . Évalué à 8.

    Pour mémoire, vous pouvez utilement consulter les deux journaux :
    http://linuxfr.org/~jahrynx/20188.html (journal de deuxième page)
    https://linuxfr.org/~Jeanuel/20206.html (journal de première page)
    • [^] # Re: Quelques journaux pour commencer...

      Posté par . Évalué à -1.

      petit hs:
      Les rédacteurs pourraient revoir leur formulation toutes faites:

      Sun "libère" ses processeurs SPARC.

      Pourquoi? étaient-ils prisonniers de leur créateur.
      Je préfère plutôt la formulation:
      SUN partage, dévoile, offre...
      Je trouve que "libèrer" dans ce sens - car evidement il y a différent degré - a toujours une conotation un peu négative. Ils n'ont pas l'obligation de fournir leur travail.
      Tout comme ceux qui critiquent que Open Solaris ne soit en fait qu'une partie du Solaris commercial.
      Ils ont tout d'même offert des trucs non négligeables: OpenSolaris, ZFS, Oo, specs Java etc, etc, etc...

      C'est du marketing, oké, mais c'est déjà moins béliqueux.
      Excusez Sun d'avoir quand même jenvie de gagner un tant soit peu leur vie avec ce qu'ils créent.

      En résumé, utilisons des termes moins ambigües.
  • # Assez gros...

    Posté par . Évalué à 10.

    Étant données les performances de ce matériel, les ordinateurs "compatibles SPARC" pourraient connaître un succès comparable aux x86

    On a dit la meme chose pour les PPC... Le succès de l'architecture x86 repose essentiellement sur sa large base d'utilisateurs, et beaucoup moins sur ses qualités techniques propres. Qu'en sera t-il des SPARC ? Je pense que ca peut être une architecture exotique de plus, bien sûr le fait qu'elle soit maintenant libre est intéressant, mais est ce que ce sera suffisant pour la faire (re)vivre...

    Ce qui me gêne moi, dans l'attitude de SUN par rapport au libre, c'est qu'ils semblent ne libérer que des produits en fin de vie. Ils croient au libre comme on croit en sa roue de secours. Je prends pour exemple java, sans aucun doute LE produit de chez sun qui bénéficierait d'une libération !
    • [^] # Re: Assez gros...

      Posté par . Évalué à 2.

      Question de "newbe" : en quoi Java n'est pas libre ? On peut faire des machines virtuelles libres il me semble, gcj par exemple et tout le monde peut utiliser Java. Que faut-il pour qu'un langage de programmation, voire plus que ça dans le cas de Java avec ses jvm, soit libre ?
      • [^] # Re: Assez gros...

        Posté par . Évalué à 4.

        Eh bien, que les sources de la VM officielle soient distribuées serait déjà un bon début... non ?
        • [^] # Re: Assez gros...

          Posté par . Évalué à 2.

          Oui mais si on utilise une jvm libre type gcj, ne peut-on pas dire qu'on fait du "java libre" ?
          • [^] # Re: Assez gros...

            Posté par (page perso) . Évalué à 2.

            On ne peut pas reproduire les comportements de la JVM de Sun dans ses moindres détails si elle n'est pas ouverte. Par exemple, elle comprend des bugs bien connus des programmateurs Java qui font des "workaround" ou qui tirent parti de ces bugs (volontairement ou non) -> du coup, ces programmes ne sont pas portables sur gcj, la JVM de IBM, ou autre...

            Je ne sais pas si les specs de Java sont publiques par contre (attention, j'ai bien dit Java, pas J2EE ou autre...).
          • [^] # Re: Assez gros...

            Posté par . Évalué à 6.

            Libre, mais loin d'être à jour...
            • [^] # Re: Assez gros...

              Posté par . Évalué à 1.

              En effet, la version 1.5 de Java n'est pas encore disponible à ma connaissance sous une forme libre. Et c'est bien dommage :-(
              En plus, la blackdown Java qui un temps suivait quand même les specs d'assez près a été engloutie je ne sais comment par la version de Sun. Et depuis ma-cash, on est fortémment dépendant de la JVM officielle Sun.
              Au final, installer la dernière version de Java sur une distro libre c'est franchement galère (ubuntu, debian, gentoo, ...) si ce n'est impossible car binaire oblige la version pour des architectures alternatives genre PPC ou SPARC ne sont pas disponibles.
              • [^] # Re: Assez gros...

                Posté par (page perso) . Évalué à 2.

                La version de blackdown étant produite à partir du code de Sun, elle n'est pas plus libre que celle de Sun.

                Le support de 1.5 par GCJ et Classpath avance très bien, ceci dit.
              • [^] # Re: Assez gros...

                Posté par . Évalué à 5.

                sous debian, ya un truc qui s'appelle make-jpkg, et qui permet de faire un .deb à installer via pdkg -i très simplement...

                genre suffit de faire make-jpkg jre-machin.bin, d'appuyer une fois sur F8, et puis de taper quelques fois sur enter.
                (pour gentoo, et autres, chépo)


                concernant Java sur Sparc, il est également disponible en .bin, mais uniquement pour solaris.

                et je suppose que la version linux ne marche pas sur sparc, bien qu'aucune archi matérielle ne soit spécifée sur le site concernant la version linux
      • [^] # Re: Assez gros...

        Posté par . Évalué à 2.

        Que faut-il pour qu'un langage de programmation, voire plus que ça dans le cas de Java avec ses jvm, soit libre ?


        Que SUN fournisse le code du JRE!
        • [^] # Re: Assez gros...

          Posté par . Évalué à 2.

          La raison n'est pas là.
          Sun a d'ailleurs déjà rendu public son code source (à l'époque, c'était java 1.1.6, je crois) sans que java ne soit libre. C'était assez fouillis d'ailleurs, et les specs de la JVM (heureusement disponibles) sont bien plus utiles que le code source de Sun.
          Les raisons pour lesquelles java n'est pas libre ont été exposées dans LMF il n'y a pas longtemps.
      • [^] # Re: Assez gros...

        Posté par (page perso) . Évalué à 9.

        Si tu as le temps, tu peux lire mon "gros" article à ce sujet. Il est un peu vieux (un an), mais il reste d'actualité : http://apiacoa.org/publications/vulgarisation.html#lm-java-d(...)
      • [^] # Re: Question de "newbe"

        Posté par . Évalué à 6.

        Un article était passé dans GNU Linux Magazine France à ce sujet.

        Ce qu'il m'en reste est que Sun a posé trois conditions pour obtenir le droit de développer une machine virtuelle. Aucune n'interdit de faire une machine virtuelle libre.
        C'est par contre quasiment impossible. En effet, une de ces conditions interdit de fournir une machine virtuelle qui n'est pas 100% compatible aux normes de SUN. Il faut donc finir le produit avant de le distribuer, ce qui est très compliqué

        En espérant ne pas avoir trop déformé le fameux article.
        • [^] # Re: Question de "newbe"

          Posté par (page perso) . Évalué à 1.

          >> En espérant ne pas avoir trop déformé le fameux article.

          ben le fameux article boubou vient de poster le lien juste au dessus de ton message.
        • [^] # Re: Question de "newbe"

          Posté par (page perso) . Évalué à 2.

          C'est par contre quasiment impossible. En effet, une de ces conditions interdit de fournir une machine virtuelle qui n'est pas 100% compatible aux normes de SUN. Il faut donc finir le produit avant de le distribuer, ce qui est très compliqué

          En fait, je crois que dans la plupart des cas, ils se foutent de la condition sur les API (surtout pour une implementation libre), il veulent juste éviter qu'on leur refasse le sale coup de microsoft : Faire une API qui n'a rien a voir avec l'officiel, et s'arranger pour qu'elle devienne un standard. Ou éviter d'avoir un bordel d'APIs de base qui arrivent de partout.
    • [^] # Re: Assez gros...

      Posté par (page perso) . Évalué à 3.

      Ce qui est certain, c'est que les produits moribonds libérés font les beaux jours de la communauté et sont parfois des produits phares. Deux des meilleurs exemples sont quand même firefox/thunderbird (petit, petit, petit fils de netscape) et OOo (petit fils de star office).

      Qu'importe la raison, pourvu que l'code reste...
      • [^] # Re: Assez gros...

        Posté par . Évalué à 5.

        Deux des meilleurs exemples sont quand même firefox/thunderbird (petit, petit, petit fils de netscape)

        L'ensemble de Mozilla est une réécriture from scratch, le code libéré par Netscape ayant été considéré comme irrécupérable avec quelques mois d'essais.

        Lire les écrits passionnants de Jamie Zawinsky à ce sujet :
        http://www.jwz.org/gruntle/nomo.html
        • [^] # Re: Assez gros...

          Posté par (page perso) . Évalué à 2.

          Tout le code à été réécrit, soit. Mais il n'en reste pas moins que sans netscape, pas de mozilla. L'application à servi de cataliseur, ce qui n'est pas la moindre des choses.
          • [^] # Re: Assez gros...

            Posté par . Évalué à 7.

            Ce n'est pas l'application qui a servi de catalyseur, ce sont les ressources fournies et la communauté impulsée par Netscape. Simplement libérer du code ne sert en soi pas à grand'chose.
            Un article que j'ai écrit à ce sujet : http://www.libroscope.org/Liberer-les-logiciels
            • [^] # Re: Assez gros...

              Posté par (page perso) . Évalué à 3.

              article très intéressant, qui corrobore complètement le point de vue selon lequel, même avec une réécriture complète, mozilla est bien le descendant de feu netscape.

              Nous somme d'accord.
        • [^] # Re: Assez gros...

          Posté par . Évalué à -3.

          >L'ensemble de Mozilla est une réécriture from scratch

          Ils ont réécrit Gecko "frome scratche" ?
          Ah bin ça alors !
    • [^] # Re: Assez gros...

      Posté par . Évalué à 10.

      Ce qui me gêne moi, dans l'attitude de SUN par rapport au libre, c'est qu'ils semblent ne libérer que des produits en fin de vie.


      L'architecture liberée par sun concerne les nouveaux processeurs UltraSparc T1 : nom de code Niagara (sun4v) dont les premiers exemplaires seront disponibles début 2006 dant les modèles SunFire T1000 et T2000. Ce ne sont PAS les produits en fin de vie.

      Pour info ces modèles sont des 4/6/8 cores dont chacun des cores, comme tout processeur risc peut faire tourner 4 threads.
      Ce qui fait jusque 32 threads dans un seul processeur !
  • # confusion...

    Posté par . Évalué à 10.

    Depêche approximative et fantaisiste sur beaucoup de points.

    Chacun pourra, s'il en a les moyens, produire des processeurs "compatibles SPARC".

    Cela fait longtemps que c'est le cas. Ainsi le processeur LEON est un processeur compatible SPARC dont les sources sont livrés sous licence libre.
    cf. http://www.gaisler.com/cms4_5_3/index.php?option=com_content(...)

    Ce qui est nouveau, c'est que Sun va fournir le code source de certains de ses propres processeurs, dont le processeur Niagara qui vient juste de sortir.

    Étant données les performances de ce matériel, les ordinateurs "compatibles SPARC" pourraient connaître un succès comparable aux x86.

    Là ça devient n'importe quoi. Une telle possibilité existe depuis des années, elle ne s'est toujours pas matérialisée... La compatibilité binaire, notamment, est un point critique.

    Chacun pourra, s'il en a les moyens, produire des processeurs "compatibles SPARC".

    Oui, s'il en a les moyens... Or, produire à bon marché des processeurs performants demande de très gros investissements. Surtout s'il s'agit d'être compétitif sur le marché grand public (Intel dépense des milliards en R&D chaque année).

    Les cartes graphiques spécifiques SUN sont particulièrement remarquables.

    On ne voit pas trop le rapport avec le choix d'un processeur, puisque la connexion de la carte graphique avec le reste du système passe par des bus graphiques aujourd'hui standardisés (AGP, PCI Express).
    • [^] # Re: confusion...

      Posté par (page perso) . Évalué à 4.

      oh le lourd, juste au moment où on commence à rêver d'un monde meilleur, tu casses tous nos espoirs...
      • [^] # Re: confusion...

        Posté par . Évalué à 7.

        effectivement, il est méchant ;)

        tu noteras cependant que Intel, malgré ses milliards en R&D tous les ans, nous a pondu une grosse bouse nommée NetBurst (aka P4), au point qu'ils sont en train de faire machine arrière pour suivre les ingénieurs du petit AMD.

        si même le numéro un des processeurs arrive à cafouiller comme ca, je me dis que quelques gens bien formés et informés sont à même de faire quelque chose d'intéressant du Sparc, quitte à ne jamais faire voir le jour à leur puce, coût de fabrication oblige ;)
        • [^] # Re: confusion...

          Posté par (page perso) . Évalué à 5.

          Oui, enfin, grosse bouse, il ne faudrait tout de même pas exagérer. La grosse bouse en question propose un hyperthreadnig fort agréable en pratique. Elle a certe de nombreux défauts (consommation éléctrique délirante et ratio performances/fréquence assez faible), mais de la à dire que c'est de la merde... Par contre, c'est une voix sans issue, d'où le retour d'IBM vers l'architecture des PIII par l'intermédiaire du pentium M et de ces successeurs. Il est vrai que les PIII ressemblent aux AMD (pipeline court), mais encore une fois, dire qu'Intel suit AMD, c'est encore un peu exagéré...
          • [^] # Re: confusion...

            Posté par . Évalué à 3.

            Ca n'est pourtant pas Intel qui a introduit le 64 bits (qui ne sert à rien), ni le dual core, ni le controleur ram intégré, dans les processeurs grands publics x86 (je ne parle pas des G5 ni des Power IBM hein ;))

            M'enfin, j'avoue que j'aime bien troller hardware, et que je suis légèrement plus attiré par AMD que par Intel ;)

            Quant à l'hyperthreading, il est désactivé dans de nombreux serveurs, pour des questions de sécu (un pseudo proc peut espionner l'autre), et aussi parce que l'overhead nécessaire pour émuler les deux proc est supérieur au bénéfice qu'on peut en tirer dans de nombreux environnements...
            Mais j'avoue que sur une station de travail, ca doit etre sympa.
            J'ai jamais testé par contre :D
            • [^] # Re: confusion...

              Posté par (page perso) . Évalué à 3.

              Le 64 bits grand public a en effet été introduit par AMD, mais le 64 bits existait bien avant ça (processeurs alpha, Itanium d'Intel, etc.). Le dual core est un argument marketing (très joli, il est vrai) mais en aucun cas une véritable innovation technique. Quand le cache sera partagé entre les cores, on en reparlera, pour l'instant c'est simplement du bi-processeur un peu plus facile à mettre en oeuvre qu'avant (j'ai eu un bi-pro intel (P III) et un bi-pro AMD, j'espère qu'AMD a fait des progres depuis...). Le contrôleur RAM intégré est un vaste débat. Est-ce vraiment utile, difficile à dire puisqu'on ne peut pas comparer deux solutions strictement équivalentes exceptées le contrôleur, donc pas de conclusion.

              Dans l'autre sens, seul Intel est capable de fournir une vraie plateforme basse consommation avec son Centrino. Le Turion consomme assez peu (un peu plus que le pentium M), mais les chipsets ne suivent pas ce qui fait qu'un portable Turion a une autonomie beaucoup plus faible qu'un portable Pentium M à fonctionnalités comparables.

              Bref.
              • [^] # Re: confusion...

                Posté par . Évalué à 5.

                > mais le 64 bits existait bien avant ça

                Par exemple... SPARCv9 qui date de 1995 et qui est à l'origine des processeurs UltraSPARC de Sun (64 bits bien entendu).
                • [^] # Re: confusion...

                  Posté par . Évalué à 9.

                  Ou DEC Alpha, dès 1992 : des processeurs incroyablement innovants (64bits et RISC) dont on ne peut que regretter la disparition.
                  • [^] # Re: confusion...

                    Posté par (page perso) . Évalué à 2.

                    non, ils n'ont pas totalement disparu. J'en ai récupéré (une DEC 500 une UE2) : les 64bits font des chauffages électriques combinés avec des serveurs de pages web/mysql honorables. Le soucis c'est que c'est comme tous les gadgets qui sont sensés faire deux choses à la fois, ça en fait aucune des deux bien.

                    D'ailleurs, je sais pas si c'est debian ou les archi 64 bits, mais à fréquence égale elles se font latter par un céléron en temps de première réponse. Depuis, j'ai arrêté de fantasmer sur les vieux clous.
                    • [^] # Re: confusion...

                      Posté par . Évalué à 2.

                      D'ailleurs, je sais pas si c'est debian ou les archi 64 bits, mais à fréquence égale elles se font latter par un céléron en temps de première réponse.

                      Ca doit être gcc qui ne doit pas super optimiser le code sur ces architectures...
                      Sans compter que le code 64 bits peut être plus lent que le code 32 bits (les pointeurs étant plus gros, les structures de données augmentent en taille, et donc le cache et la mémoire sont plus sollicités).
                      • [^] # Re: confusion...

                        Posté par . Évalué à 2.

                        Ca et puis les Alpha étaient pendant une période des 'speed daemon' à la P4: ils ne faisaient pas grand chose par cycle, mais ils montaient en fréquence beaucoup plus haut que leur concurrents (qu'ils torchaient d'ailleurs surtout en FP), d'ou d'ailleurs des conso importantes (dans mon école on avait un proto d'Alpha: la pièce qui l'hébergeait était plus chaude que les autres..).

                        Donc à fréquence égale un CPU peut torcher un Alpha de cette période.

                        Et puis il faut voir le reste du systeme: Digical a essayé de pousser un AlphaPC a un moment, pour réduire les prix réduction de la taille des caches, du sous-système mémoire, etc.
                        Même un bon CPU a du mal a lutter avec une mémoire inférieure..
              • [^] # Re: confusion...

                Posté par . Évalué à 8.

                Le dual core est un argument marketing (très joli, il est vrai) mais en aucun cas une véritable innovation technique.


                Euh, là c'est idiot ce que tu dis. Le dual core a un réel avantage car il permet de mettre deux vrais processeurs dans un, ce qui permet d'avoir un coût infrastructure par processeur bien plus bas pour les workstations et pour les serveurs. Aucune comparaison possible avec des astuces de dernier espoir comme l'hyperthreading.

                C'est particulièrement intéressant dans le cas où tu bosses avec des serveurs compactes de type blade où il devient très simple d'avoir un quadri-proc sans augmenter la taille des machines.

                Je ne sais pas si tu as déjà vu beaucoup de systèmes 8 processeurs mono-core, mais crois moi sur parole que du dual core sur une carte mère 4 sockets est une solution bien plus élégante.

                Pour l'affaire du contrôleur de ram intégré, c'est vrai qu'il y a débat car celà réduit les possibilités de changer le type de ram.

                Par contre, en multi proc, le contrôleur intégré permet d'avoir une configuration mémoire NUMA avec une augmentation de la bande passante totale simultannée avec la ram proportionnelle au nombre de processeurs, ce qui est bien plus intéressant que les xeons préhistoriques qui en sont encore à partager un bus de mono-processeur entre plusieurs processeurs pour accéder à la ram.

                Quand le cache sera partagé entre les cores, on en reparlera
                Une cache unifiée entre les deux cores nécessiterait soit de mettre un contrôle transactionnel multiclient sur l'allocation, la désallocation et l'accès à la cache, soit de limiter les accès à un seul processeur à la fois. Dans le premier cas, ça coûterait plus cher, dans le second, ça réduirait sérieusement les performances.

                La solution de la cache séparée assortie d'une interconnexion directement à la sortie de la cache est en revanche une solution très efficace, et c'est ce qui est utilisé chez amd.

                Pour le reste, je te recommande vivement de lire des tests et benchmarks plutôt que de donner dans les croyances populaires.
                • [^] # Re: confusion...... disgression & précision sur le NUMA

                  Posté par . Évalué à 8.

                  Juste une petite remarque en passant par rapport au NUMA, je fait référence à ta phrase (tu vas dire que je coupe les pattes de mouche en quatre, mais bon):

                  <<Par contre, en multi proc, le contrôleur intégré permet d'avoir une configuration mémoire NUMA avec une augmentation de la bande passante totale simultannée avec la ram proportionnelle au nombre de processeurs, ce qui est bien plus intéressant que les xeons préhistoriques qui en sont encore à partager un bus de mono-processeur entre plusieurs processeurs pour accéder à la ram.>>

                  Cela fait plusieurs fois que je vois ça dans la presse et dans les têtes des gens et j'ai l'impression que tout le monde pense que le NUMA c'est le rêve absolu... etc .. etc.

                  Le NUMA (Non Uniform Memory Architecture, man wikipedia pour plus d'info) c'est un MOYEN de contournement (workaround) d'un problème industriel/physique: Effectivement,aujourd'hui, on ne sait pas fabriquer des machines avec beaucoup de processeurs et beaucoup de mémoire (et ceci de manière performante) sans casser la __magnifique__ symétrie des architectures SMP. Augmenter la performance nécessite de casser la symétrie des système. le NUMA c'est le moyen le moins pourave qu'on a trouvé pour que cela ressemble encore un peu à une machine performante.

                  Maintenant, il suffit de regarder un peu la complexité pas possible qu'induit l'architecture NUMA (hardware, mais aussi OS) pour se rendre compte que le rêve ce serait une bonne perfo sur une architecture symétrique.

                  Comme tout n'est jamais complètement négatif, je dirais pour terminer que le NUMA c'est un super moyen de sauvegarder nos emplois d'ingénieurs en info, une machine NUMA c'est toujours le bordel au niveau perf. Et dire que bientôt j'aurai (enfin je veux dire on aura tous) une machine NUMA à la maison....

                  Le plus drôle c'est que :

                  - avec l'hyperthreading c'était le bordel.
                  - Avec le NUMA c'est le MEGA bordel.

                  Alors en dessert, vous reprendrez bien les deux mélangés ? hein ? (cf Montecito sur des machines cellulaires par ex) je sais pas si il y aura 10 personnes sur la planête capables de tirer la quintessence (en perf) de l'architecture.

                  conclusion: NUMA, CACA, mais on fait pas mieux pour le moment.
                  • [^] # Re: confusion...... disgression & précision sur le NUMA

                    Posté par . Évalué à 5.

                    C'est vrai que question gestion, le Numa n'est pas des plus aisé (enfin bon, on te demande généralement pas non-plus de migrer les processus à la main)...

                    Dans le cas l'amd64, on travaille en mode hybride SUMO (sufficiently uniform memory organization), ce qui permet si l'on est avec un OS stupide (comme windows), de travailler comme si on était en bête SMP (avec tout de même un système d'interconnexion très performant comparativement à ce qu'on a chez Intel), et si l'on est avec un os plus évolué, de travailler avec un kernel optimisé capable de gérer les affinités entre les processus et les processeurs.

                    Avantage du SUMO ?
                    - La migration de processus peut se faire de manière transparente (alors que dans une config NUMA standard, la migration nécessite plus de préparation pour envoyer un processus sur un autre processeur)
                    - les échanges entre processus situés sur des processus différents se font aussi de manière transparente, le partage de mémoire peut se faire exactement comme pour du smp.

                    Donc oui, le Numa, c'est pas évident, mais dans le cas de l'amd64, c'est tout de même beaucoup plus intéressant.

                    Sinon, je vois pas ce que le pauvre hyperthreading vient faire là dedans...
                    • [^] # Re: confusion...... disgression & précision sur le NUMA

                      Posté par . Évalué à 4.

                      J'ai pas bien capté le SUMO, je vais me documenter....C'est un truc d'AMD ou d'un constructeur en particulier ?

                      Par contre, sur toutes les plateformes NUMA que je connais, on peut configurer la RAM en mode interleaved ce qui permet d'avoir un comportement uniforme et évite de créer des "points chauds" dans les crossbar. Le top c'est lorsqu'on peut configurer une partie de la RAM de manière entrelacée et l'autre partie en NUMA pure, si tu ajoutes un kernel récent là dessus tu peux avoir des comportement géniaux du genre:

                      -pagecache --> interleaved node
                      -OpenMP shared data --> interleaved node
                      -process/MPI private data --> NUMA

                      .....

                      ...
                      bref, l'extase de l'ingé, tu peux faire plein d'erreurs, tu passes plein d'heures à profiler.... .... Et l'humanité perd un temps fou.... mais nous qu'est-ce qu'on s'éclate !!!

                      J'en reviens à mes moutons: <<Quand tu dis OS stupide comme windows, je suis d'accord pour stupide en général (et hop une caresse au troll) mais il me semble qu'elle est NUMA aware(comme dirait jean-claude) c't'usine à gaz.... >>

                      <<Sinon, je vois pas ce que le pauvre hyperthreading vient faire là dedans...>>

                      moi non plus :-) Ah si ! c'était à propos de la sauvegarde de nos emplois avec des technologies qu'on pousse en avant comme étant des réelles innovations (Hyperthreading, NUMA, multicore) alors qu'en fait ça devrait plutôt être profil bas, on sait pas mieux faire..... :-)))) Du coup j'ai rajouté le multi-core dans le tas.... :-)




                      • [^] # Re: confusion...... disgression & précision sur le NUMA

                        Posté par . Évalué à 3.


                        C'est un truc d'AMD ou d'un constructeur en particulier ?

                        Je crois que c'est du pur amd, une solution indispensable pour garder une compatibilité parfaite pour les systèmes x86.

                        bref, l'extase de l'ingé, tu peux faire plein d'erreurs, tu passes plein d'heures à profiler.... .... Et l'humanité perd un temps fou.... mais nous qu'est-ce qu'on s'éclate !!!


                        Yesss... au fait, tu bosses sur quelle architecture?
                • [^] # Re: confusion...

                  Posté par (page perso) . Évalué à 3.

                  Euh, là c'est idiot ce que tu dis.

                  Si tu apprenais à lire, ça te semblerait moins idiot et ça t'éviterait de répondre à côté de la plaque.

                  Le dual core a un réel avantage car il permet de mettre deux vrais processeurs dans un, ce qui permet d'avoir un coût infrastructure par processeur bien plus bas pour les workstations et pour les serveurs.

                  Oui, c'est ce que j'ai dit, c'est un argument marketing, du multi-processeur plus facile à mettre en oeuvre.

                  Aucune comparaison possible avec des astuces de dernier espoir comme l'hyperthreading.

                  En effet et alors ? J'ai dit que ça avait un rapport ?

                  Par contre, en multi proc, le contrôleur intégré permet d'avoir une configuration mémoire NUMA avec une augmentation de la bande passante totale simultannée avec la ram proportionnelle au nombre de processeurs, ce qui est bien plus intéressant que les xeons préhistoriques qui en sont encore à partager un bus de mono-processeur entre plusieurs processeurs pour accéder à la ram.

                  Tu confonds la gestion de la communication entre les processeurs et avec le chipset (contrôleur mémoire inclus), et l'intégration de cette gestion dans le processeur. AMD a depuis des années des choses intéressantes pour la communication du processeur avec l'extérieur (hyper transport et compagnie), avant ce n'était pas intégré au processeur, c'est tout.

                  Une cache unifiée entre les deux cores nécessiterait soit de mettre un contrôle transactionnel multiclient sur l'allocation, la désallocation et l'accès à la cache, soit de limiter les accès à un seul processeur à la fois. Dans le premier cas, ça coûterait plus cher, dans le second, ça réduirait sérieusement les performances.

                  La solution de la cache séparée assortie d'une interconnexion directement à la sortie de la cache est en revanche une solution très efficace, et c'est ce qui est utilisé chez amd.


                  Il y a eu du cache partagé sur les machines SMP depuis très longtemps. Les futurs multi-core d'Intel et d'AMD prévoient d'intégrer du cache partagé. Nous verrons dans le futur si les ingénieurs des entreprises cités sont aussi nuls que tu le penses ou non.

                  Pour le reste, je te recommande vivement de lire des tests et benchmarks plutôt que de donner dans les croyances populaires.

                  De quoi parles-tu ?
                  • [^] # Re: confusion...

                    Posté par . Évalué à 5.

                    Oui, c'est ce que j'ai dit, c'est un argument marketing, du multi-processeur plus facile à mettre en oeuvre.


                    Je dirais que c'est surtout un argument technique. L'intéret n'est pas juste de mettre un bel autocollant "dual core" sur son boîtier, mais de mettre un maximum de processeurs dans un minimum de place, et si possible en évitant un maximum les complications.

                    Tu confonds la gestion de la communication entre les processeurs et avec le chipset (contrôleur mémoire inclus), et l'intégration de cette gestion dans le processeur.


                    Je pense que c'est toi qui confond...
                    L'intégration du contrôleur de mémoire dans le processeur permet d'avoir autant de fois la bande passante proc<->mémoire que de socket occupé. Dans le cas de l'AMD64, l'hypertransport est utilisé pour communiquer avec le chipset et les autres processeurs, mais chaque processeur peut dialoguer directement avec sa propre ram sans passer par le bus, d'où un gain énorme d'efficacité dans les communications (on est à presque 95% de la bande passante théorique de 6,4Gb/sec alors qu'en passant par un contrôleur externe éventuellement partagé, on tombe sous les 70%)

                    Dans le cas d'une machines bi-Xeon ou bi-athlon xp, les deux processeur passent par le même northbridge pour atteindre la ram, ce qui rajoute des problèmes de collisions et de partage.

                    Il y a eu du cache partagé sur les machines SMP depuis très longtemps.
                    Dans quel film tu as vu ça?
                    Comment veux-tu avoir de la cache vraiment partagée et accédée sans intermédiaire entre deux processeurs physiquement distincts?

                    Sur du smp classique (xeon/athlon mp) avec deux processeurs physiquement séparés, les caches ne peuvent communiquer qu'en passant par le bus, ce qui correspond presque avec la méthode d'interconnexion utilisée pour l'amd64 x2 sauf que l'amd64 x2 a l'interconnexion directement en sortie du processeur au lieu de faire un détour par le bus.

                    Les futurs multi-core d'Intel et d'AMD prévoient d'intégrer du cache partagé.

                    C'est fort possible, il ne faut jamais dire jamais, mais le problème de sécurité du P4 HT a soulevé pas mal de questions au sujet de la cache partagée, et sans réponses valable à ce sujet, il serait risqué de la part de l'un ou de l'autre de lancer un processeur multi-core à cache partagée.
                    • [^] # Re: confusion...

                      Posté par . Évalué à 4.

                      AMD lit dans le cache L2 de l'autre processeur depuis l'athlon MP. C'était plus rapide d'aller lire dans le cache que dans la rame.

                      Depuis, c'est ce qui rends les processeurs opteron multicore largement supérieur à la techno Intel. chez intel, il s'agit juste de 2 processeurs sur la même puce. Contrairement à AMD, ou les caches sont partagé.

                      "La première sécurité est la liberté"

                      • [^] # Re: confusion...

                        Posté par . Évalué à 3.

                        AMD lit dans le cache L2 de l'autre processeur depuis l'athlon MP. C'était plus rapide d'aller lire dans le cache que dans la rame.
                        ah, ça c'est sûr que lire dans la cache plutôt que dans la ram, c'est un gain (même si ça passe par le bus), mais notre ami boubou faisait le reproche suivant aux dual cores "Quand le cache sera partagé entre les cores, on en reparlera" ...

                        Hors, une vrai cache partagée (donc un bloc unique de mémoire cache accessible de manière uniforme par deux cores), ça n'existe pas dans le monde x86, c'est compliqué, et surtout ça pose des problèmes de sécurité (l'hyperthreading l'a démontré sans qu'on ait besoin d'aller jouer avec deux vrais cores).

                        Dans les amd64, les caches communiquent via le crossbar qui se situe entre les caches, les trois cannaux hypertransport et les deux cannaux de contrôleur ram.
                        En aucun cas ce ne sont des caches partagées, elles communiquent, mais ce sont bien deux blocs distincts qui ne peuvent être accédés par le processeur en face au même titre que par leur processeur.
                        • [^] # Re: confusion...

                          Posté par . Évalué à 2.

                          Cela serait super con de faire un cache partagé. Cf le cache L3 des power 5.

                          Il suffit de gérer le cache au niveau du controleur mémoire.

                          "La première sécurité est la liberté"

                          • [^] # Re: confusion...

                            Posté par . Évalué à 2.

                            tu pourrais expliquer le fonctionnement du cache L3 du G5 ?

                            tout le monde n'a pas ta connaissance des PPC ;)
                            • [^] # Re: confusion...

                              Posté par . Évalué à 3.

                              Un power 5 est bi core. Le L3 du machin est commun au 2 core.(128 Mo de eDRAM escusez du peu).

                              C'est finalement assez bète, au cas de demande pour aller lire la DRAM,il regarde d'abord le contenu du cache suplémantaire. Il n'y a pas plus de problème de cohérence que entre les L2 et la RAM.

                              "La première sécurité est la liberté"

                              • [^] # Re: confusion...

                                Posté par . Évalué à 1.

                                l'avantage étant que la cache est sur la puce (donc à 10cm de moins), et que bien qu'elle ne tourne surement pas aussi vite que le proc (faut pas déconner non plus), elle tourne cependant plus vite que la ram du système.

                                c'est donc une sorte de ram avant la ram, juste ?


                                à quand les slots sodimm sur les proco IBM ? :D
                                • [^] # Re: confusion...

                                  Posté par . Évalué à 3.

                                  C'est un cache quoi...

                                  "La première sécurité est la liberté"

                                  • [^] # Re: confusion...

                                    Posté par . Évalué à 2.

                                    Bah vi

                                    mais vu ta remarque
                                    Cela serait super con de faire un cache partagé. Cf le cache L3 des power 5.
                                    , j'avais compris qu'il était légèrement mal optimisé, mal conçu, trop petit, trop lent, ou foireux, d'où ma demande d'explication ;-)
                                    • [^] # Re: confusion...

                                      Posté par . Évalué à 2.

                                      oups, c'est vrai que la phrase est ambigue.

                                      Je dis super con à faire, dans le sens super simple, pas dans le sens "débile".

                                      "La première sécurité est la liberté"

            • [^] # Re: confusion...

              Posté par . Évalué à 1.

              un pseudo proc peut espionner l'autre

              D'après ce que j'ai lu, il semble que le problème soit surtout que les réactions d'un pseudo proc permettent de mesurer dans certains cas le comportement de l'autre pseudo-proc et du même coup de déterminer la vitesse d'exécution d'opérations crypto, ce qui permet de faire des attaques basées sur les mesures des temps d'exécution pour faire un profile du cryptage.

              Au boulot on a des serveurs de crypto à ultra basse latence, et sur ces machines, l'hyperthreading est impérativement désactivé sinon le temps de réaction du serveur devient trop instable, ce qui mène à des timeouts dans les transactions.
              • [^] # Re: confusion...

                Posté par . Évalué à 4.

                Je viens de prendre le temps de lire le rapport de Colin Percival, en fait, grâce aux attaques de timing, il est carrément possible de deviner des données de la cache avec un taux d'erreur de 25% à 400k/s sur un P4 2,8ghz... Encore un bon argument pour ne pas avoir de partage de cache dans les dual-cores.
                • [^] # Re: confusion...

                  Posté par . Évalué à 1.

                  non, c'est pas un argument. Il suffirait de rajouter un brouilleur, cela ne doit pas être bien dure à mettre en place.

                  "La première sécurité est la liberté"

                  • [^] # Re: confusion...

                    Posté par . Évalué à 2.

                    Commencer à foutre des brouilleurs dans ce qui reste quand même le centre d'un ordi, ca fait cochon.

                    enfin, c'est mon avis quoi ;)
                    • [^] # Re: confusion...

                      Posté par . Évalué à 2.

                      Cela existe déjà pour les cpu de carte à puce, donc bon.

                      "La première sécurité est la liberté"

                  • [^] # Re: confusion...

                    Posté par . Évalué à 2.

                    ben, je suis certain qu'un brouilleur, ça ferait fureur sur la cache L2 d'un processeur, l'étape suivante c'est de rajouter des sièges baquets et un frigo...

                    Sans rire, je sais pas ce que tu entend par "brouilleur", mais tout chipotage à ce niveau ne ferait que faire plonger les perfs du processeur... et ne dis pas que la carte à puce en a un, la carte à puce n'a ni la finalité ni la puissance d'un microprocesseur généraliste.
                    • [^] # Re: confusion...

                      Posté par . Évalué à 2.

                      Tu peux imaginer des tas de truc pour lisser l'execution : la désactivation du cache, un comportement aléatoire à ce niveau. Evidement tu plombes les perf du cache pour le bout code mais bon.

                      "La première sécurité est la liberté"

                      • [^] # Re: confusion...

                        Posté par . Évalué à 3.

                        Tu peux imaginer des tas de truc pour lisser l'execution


                        Si, si, je peux parfaitement m'imaginer, ça a été mon boulot pendant quelques années.

                        Par contre, ce qui m'échappe, c'est l'intéret d'une cache de second niveau partagée dans de telles conditions, et j'ai beau regarder, j'en vois pas. Une cache séparée évite bien des problèmes tout en évitant de devoir faire mumuse avec des techniques qui n'ont pas leur place dans le contexte d'une mémoire cache L2.

                        De plus, sur les amd64, il y a le protocole moesi qui permet une communication intercache directe entre les divers processeurs d'un même système, qu'ils soient en dual core, en multi proc ou en multi dual core.
                        • [^] # Re: confusion...

                          Posté par . Évalué à 2.

                          Partagé le cache de niveau 2 est simplement un moyen d'aller plus vite que d'attendre la ram. Et cela évite aussi d'avoir besoin d'un cache write "though" qui à chaque écriture devrait mettre à jour la ram au cas ou l'autre cpu veuille y accéder.

                          "La première sécurité est la liberté"

                          • [^] # Re: confusion...

                            Posté par . Évalué à 2.

                            Partagé le cache de niveau 2 est simplement un moyen d'aller plus vite que d'attendre la ram.


                            La communication intercache ne passe pas par la ram, donc c'est pas un argument.

                            Et cela évite aussi d'avoir besoin d'un cache write "though" qui à chaque écriture devrait mettre à jour la ram au cas ou l'autre cpu veuille y accéder.


                            Encore une fois, il y a déjà un protocole de communication intercache avec contrôle d'intégrité (même sur les intels), donc pas un argument non-plus.
          • [^] # Re: confusion...

            Posté par . Évalué à 7.

            La grosse bouse en question propose un hyperthreadnig fort agréable en pratique.


            Ben si je disais que l'hyperthreading dans pas mal de cas c'est une grosse bouse aussi :P

            Plus sérieusement, le P4 est un processeur qu'Intel a jeté sur le marché beaucoup trop tôt, sans laisser le temps aux ingés de le finaliser (le développement initial du P4 n'a duré que trois ans au lieu des 5 initialement prévus, ce qui en fait un grand prématuré). Dans les défauts de base du P4, on retrouve d'ailleurs un gros problème de fluidité entre les unités de décodage et les unités d'exécution, du coup, ces dernières n'étaient pas correctement alimentées en instructions.

            L'hyperthreading est venu pour masquer ce problème en créant un système de pseudos-processeurs se partageant les unités d'exécution afin de réduire l'inoccupation chronique de celles-ci. Malheureusement, il est fréquent qu'un pseudo-processeur doive exécuter du code mais ne trouve pas d'unité d'exécution libre pour le traiter, ce qui rajoute des micro latences aléatoires dans l'exécution et rend l'hyperthreading particulièrement préjudiciable aux applications temps-réel.

            D'un point de vue "processeur juste assez bon pour des trucs à haute latences ou pour le consommateur de base qui marche au marketting", le P4+HyperThreading est bon, pour le reste, c'est un processeur de merde qui a besoin de presque un ghz et pas mal de jus de plus que la concurrence pour faire la même chose.

            D'un point de vue architecturale, le P4 est mal torché, c'est tout.
            • [^] # Re: confusion...

              Posté par . Évalué à 2.

              Disons que le P4 s'est pris le mur de la chaleur dans la gueule.

              Sans les problèmes de conso statique du 90nm, les P4 tourneraient à 5 Ghz.

              Le SMT (hyperstring) permet de diminuer globalement les latences. Alors certe, c'est non prédictif mais bon, pour un serveur ou une station de travail c'est déjà ça de pris.

              Les benchs d'appli Bi-cpu montrait une augmentation de 30% des perf, ce qui n'est pas négligeable. SUN mets 4 threads sur un Proco sans doute également très pipeliné (cf l'archi du proco XBOX360 qui est aussi bi-thread/cpu).

              "La première sécurité est la liberté"

              • [^] # Re: confusion...

                Posté par . Évalué à 2.

                Sans les problèmes de conso statique du 90nm, les P4 tourneraient à 5 Ghz.

                Monter à 5ghz en P4, ça a autant de sens que de pousser un moteur de voiture à 15000 tours/minute en 3è vitesse. En plus, à 5ghz, l'électricité commence à avoir de sérieux problèmes de propagation (sur le temps d'un cycle, la lumière ne parcours que 6cm, l'électricité est beaucoup plus lente dans un processeur en surchauffe, les transistores ont eux-mêmes leurs latences, ce qui rend la propagation du signal dans le processeur beaucoup plus difficile dans une fenêtre de temps aussi réduite)

                Pour l'hyperthreading sur le P4, le constat est simple: sur les applications optimisées P4, le gain est quasi nul, pour les applications otpimisées pour le PIII le gain peut monter effectivement dans les cas les mieux adaptés à 30%, mais c'est loin d'être une généralité, et au final ça ne rivalise pas avec la puissance par cycle d'un PIII, d'un Dothan ou d'un AMD64.
                • [^] # Re: confusion...

                  Posté par . Évalué à 2.

                  sur le temps d'un cycle, la lumière ne parcours que 6cm

                  Aucun impact sur la fréquence de pointe d'un pipeline de quelques millimètres de "longueur", et partagé en plus de 10 voire 20 étages.

                  et au final ça ne rivalise pas avec la puissance par cycle d'un PIII, d'un Dothan ou d'un AMD64

                  La "puissance par cycle" n'a aucune importance, ce qui compte c'est les performances réelles.
                  • [^] # Re: confusion...

                    Posté par . Évalué à 2.

                    La "puissance par cycle" n'a aucune importance, ce qui compte c'est les performances réelles.

                    les performances réelles, la conso électrique et la chaleur émise... et étonnemment, un manque d'efficacité par cycle semble tout de même mener à un manque d'efficacité electrique et à un manque d'efficacité thermique.
                    Chaque cycle a un coût.
                    • [^] # Re: confusion...

                      Posté par . Évalué à 2.

                      Chaque cycle a un cout certe, mais le cout des cycles des différents processeurs ne sont pas comparrable.

                      "La première sécurité est la liberté"

                      • [^] # Re: confusion...

                        Posté par . Évalué à 2.

                        Dans le cas du P4, on constate en tout cas que le coût à fini par rattraper, les ambitions d'Intel...
                • [^] # Re: confusion...

                  Posté par . Évalué à 2.

                  L'analogie avec la voiture n'a pas lieu d'être.

                  A 5ghz, il serait plus rapide que la concurence. Il suffit de voir les overclocking extrème pour comprendre que le pb du P4 ce n'est pas la vitesse de propagation mais bien la chaleur (donc tes pbs lié au temps de propagation ne s'applique pas)

                  "La première sécurité est la liberté"

                  • [^] # Re: confusion...

                    Posté par . Évalué à 3.

                    A 5ghz, il serait plus rapide que la concurence.


                    et la concurrence à 4Ghz enterrerait le P4 à 5Ghz...

                    tu espères démontrer quoi?

                    La meilleure unité de mesure serait encore la consommation électrique: quel processeur fait le plus par watt, et encore une fois c'est pas le P4 qui gagnerait.

                    Le design du P4 est malheureusement trop éloigné des réalités physiques pour qu'on puisse dire qu'il est bon. Et puis, il me semble qu'intel promettait les 10Ghz lorsque le P4 est apparu... plutôt raté.

                    Au final, le coup du netburst ressemble plus à un coup de pocker manqué qu'à une architecture correctement ficelée.
                    • [^] # Re: confusion...

                      Posté par . Évalué à 2.

                      C'est clair que le marketing est passé par là.

                      Mais le pipeline extrème du P4 (40 étages !) présageait une bien plus grande monté en fréquence que la concurence (~20 étages).

                      Ensuite niveau consomation ou chaleur c'est identique puisque la chaleur c'est la conso d'un cpu.

                      "La première sécurité est la liberté"

                      • [^] # Re: confusion...

                        Posté par . Évalué à 2.

                        je me souviens avoir lu 28 pour le NorthWood, et 32 pour le Prescott
                        contre 13 pour le Pentium M premier du nom, et 16 pour un Athlon 64.

                        Ca fait pitet pas 40 et 20, mais le rapport est le bien le même ;)
                        • [^] # Re: confusion...

                          Posté par . Évalué à 3.

                          en général, on regarde la longueur du pipe entier. Le pipe FPU et celui d'acces mémoire est en général bien plus long.

                          Je ne me rappelle plus la longuer de l'athlon 64, mais le 1er athlon était à 14 niveau et battait le PIII qui était à seulement 10 niveau (un peine rallongé pour le pentium M).

                          Le P4 était pour moi à 20 avec doublement du nombre d'étage ensuite.

                          "La première sécurité est la liberté"

                          • [^] # Re: confusion...

                            Posté par . Évalué à 2.

                            L'athlon64 a 12 étages de pipeline pour les entiers et 17 pour la fpu si ma mémoire est bonne.

                            20 étages nécessitent déjà une super bonne prédiction de branchements, 40 étages, j'ose même pas imaginer la gamelle à chaque prédiction ratée...
                            • [^] # Re: confusion...

                              Posté par . Évalué à 3.

                              Ya que sun qui pourrait se permettre d'avoir un pipeline de 40 niveaux.
                              forcément, avec un nom comme madame soleil, ils devraient pas trop se gourer...



                              --------------------> [ ]
              • [^] # Re: confusion...

                Posté par . Évalué à 2.

                > Disons que le P4 s'est pris le mur de la chaleur dans la gueule.

                Il s'est surtout pris le mur des 'marketeux' dans la gueule: l'architecte principale du P4 a démissioné pour protester sur la direction que prenait le P4!

                Ca veut tout dire.. Je pense que les ingénieurs de chez Intel sont aussi bon qu'ailleurs, mais encore faut-il les laisser bosser!

                Si Intel n'a pas fait le x86-64 en premier, c'est problablement qu'ils avaient décidé de pousser l'Itanium a la place: leur design a eux (ok avec HP), plus besoin de lutter avec les clones..
            • [^] # Re: confusion...

              Posté par (page perso) . Évalué à 2.

              Les perf décevantes du P4 ne viendrait pas aussi de la nullité des compilateurs ?

              « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

              • [^] # Re: confusion...

                Posté par . Évalué à 2.

                Celà m'étonnerait, Intel est le roi de l'optimisation compilateur.

                Par contre il faut noter qu'avec le P4, le code optimisé pour les autres processeurs tourne plus mal que sur P3, Pentium M ou Athlon XP/64 ...

                En compilant les applications de manière optimale pour le P4, ce dernier reste plus lent que la concurrence (mais regagne à peu près en perfs que que l'hyperthreading peut récupérer)... En fait du code optimisé p4 ne gagne rien avec l'hyperthreading (car tout le cpu est utilisé), alors que le code optimisé PIII, PM, AMD, peut gagner avec l'hyperthreading vu que le processeur est moins bien alimenté en instructions.
                • [^] # Re: confusion...

                  Posté par (page perso) . Évalué à 2.

                  Celà m'étonnerait, Intel est le roi de l'optimisation compilateur.

                  Il ne sont tout de même pas capable d'écrire un compilateur qui remplisse le pipeline, qui sache utiliser le SIMD à fond, etc...

                  Je me pose quelques questions...

                  « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

                  • [^] # Re: confusion...

                    Posté par . Évalué à 2.

                    Quand tu vois les benchmarks des compilos intel face à gcc, tu te dis que tout de même ils s'en sortent vraiment bien question compilateur.

                    Tout n'est pas mauvais chez intel, loin de là. Le P4 est une bouse, mais le Yonah est vraiment un processeur exceptionnel si on en croit les benchs.
  • # rien ne dit que SUN ouvre toutes les specs de l'UltraSPARC

    Posté par (page perso) . Évalué à 6.

    Sun announced [...] and publish CERTAIN specifications for the UltraSPARC-based chip[...]

    Ce qui veut dire que les specs intéressantes seront peut-être squizées par SUN, comme un utilisateur l'a fait remarqué sur son journal:
    http://linuxfr.org/~jahrynx/20188.html

    Tout homme qui dirige, qui fait quelque chose, a contre lui ceux qui voudraient faire la même chose, ceux qui font précisément le contraire, et surtout la grande armée des gens d'autant plus sévères qu'ils ne font rien du tout. \n -- Jules Claretie

  • # L'avis d'OpenBSD

    Posté par . Évalué à 10.

    L'avis de theo de raadt sur la question est interessant, vu que le projet OpenBSD a longtemps tente d'obtenir de la doc pour ameliorer le support des SUNs.

    Voila sa premiere intervention sur misc@openbsd.org a ce sujet:

    > We don't need processor docs. That stuff is trivial.
    >
    > We need *chipset docs*.
    >
    > And those are still not available under Sun's new program.
    >
    > So it is STILL a complete matter of reverse engineering.
    >
    > Same as with Apple, of course: powerpc is trivial. But the chipsets
    > on every Apple machine are subtly different, full of bugs, and reading
    > Darwin is a terrific waste of time since the code is so horrid, and of
    > course, it is all just a maze of workarounds.
    >
    > Verilog for ultrasparc? Give me a break. We don't care.

    En gros, aujourd'hui la majorite de la fonctionnalite d'un systeme est compose d'un processeur et de tous les chipsets l'entourant. Par extension il semble donc plus pratique d'avoir une documentation complete des fonctionnalites d'un CPU et des chipsets qui viennent avec plutot que les 'sources' d'un CPU.

    Le mot de la fin de mr de raadt:

    >> David Weaver has posted some more stuff, which you might want
    >> to read.
    >
    > None of which matters at all. Years ago Sun refused us
    > documentation.
    > Nothing has changed.
    >
    > All Sun is trying to do is act fluffy, when they are not.

    • [^] # Re: L'avis d'OpenBSD

      Posté par . Évalué à 0.

      We don't need processor docs. That stuff is trivial.
      Il devrait en parler a l'équipe de fcpu si c'est si trivial que ca ...
      • [^] # Re: L'avis d'OpenBSD

        Posté par (page perso) . Évalué à 4.

        Je pense qu'il parle de son point de vue de développeur d'OS,et il n'a pas totalement tort, quand les T1000 et T2000 sortiront, l'équipe d'OpenBSD devra quand même aller à la pêche au information sur les chipset de ceux ci pour pouvoir implémenter OpenBSD dessus, alors que (paradoxalement?) les CPU seront Open Source.
      • [^] # Re: L'avis d'OpenBSD

        Posté par . Évalué à 3.

        Je ne vois pas le rapport, le projet F-CPU vise à créer un processeur risc aux spec libres, pas d'écrire du software qui tournera sur une architecture.

        Il y a une grosse différence entre concevoir de A à Z une architecture, et écrire du software qui tournera dessus.

        Par exemple pour écrire un driver, il n'y a pas besoin de connaître les schémas électriques de la carte : de la *bonne* doc suffit.

        Enfin je pense que Théo a suffisement contribué aux architectures sparc (que ce soit sous NetBSD à l'époque où il en faisait partie ; ou OpenBSD) pour dire qu'un processeur est trivial à comprendre comparé aux chipsets.
        • [^] # Re: L'avis d'OpenBSD

          Posté par (page perso) . Évalué à 2.

          Je ne vois pas le rapport, le projet F-CPU vise à créer un processeur risc aux spec libres, pas d'écrire du software qui tournera sur une architecture.

          Justement, je trouve que sur ce point précis, l'opinion de Theo de Raadt me rappelle un peu trop une transposition de l'argumentaire selon lequel les utilisateurs finaux n'ont que faire que le code soit libre, seules les fonctionnalités les intéressent.
          C'est sans doute vrai, mais l'initiative de libérer le code n'est pas pour autant inutile, ni sans impact.

          Dans le cas présent, je pense que l'étude du code des processeurs sera très instructive pour les gens qui développent du hardware, et en ce sens c'est une excellente chose.
          Que ça n'ait pas d'utilité directe pour les développeurs de soft (ou utilisateurs de processeurs), je veux bien le croire, mais je ne vois vraiment pas en quoi ça justifie de rejeter le geste de Sun.
        • [^] # Re: L'avis d'OpenBSD

          Posté par . Évalué à 0.

          comme il a dis que linux c'etait mal codé?
          Si tu as le code vérilog tu as TOUTE les doc que tu veux (ca peut prendre du temps certe) sur le proc ...

          Oui le code du chipset est aussi important,
          mais monsieur theo de raadt a "l'engeulade" un peu facile amha.
          Oui c'est pas parfait dans le meilleur du monde.
          Oui il y a encore beaucoup de choses a faire.
          Mais merde c'est déja un pas dans le bon sens. Et c'est pas en critiquant ce genre d'initiative que ca apporte quoi que ce soit.

          Et non faire la doc d'un process c'est pas forcement "trivial" comme il le dis.
          Quel que soit sa contribution.
          Il ne faut pas oublier que la libération ne s'adresse pas qu'a monieur theo , mais a toute la communaute, donc ca interesse AUSSI la communaute qui développe du hard libre, etc...
          Et non adapter du code pour qu'elle utilise au maximum un processeur ce n'est pas trivial si tu n'as pas la doc qu'il faut.
          • [^] # Re: L'avis d'OpenBSD

            Posté par . Évalué à 6.

            Ce n'est pas du tout le débat. Je n'ai jamais dit que l'initiative était à rejetter... justement l'attitude de Sun depuis quelques temps est excellente.
            Je ne comprend pas pourquoi tu dis que je critique...


            Et non faire la doc d'un process c'est pas forcement "trivial" comme il le dis.
            Quel que soit sa contribution.


            Il a été le responsable du port sparc à l'époque ou il était encore dans NetBSD, et ses sontributions au port OpenBSD sont très importantes (comme le fait de booter un seul même kernel pour toutes les machines sun4, sun4c, et sun4m alors que Solaris n'en est pas capable).
            Alors il me semble - sans vouloir te froisser - qu'il connaît un peu mieux le sujet que toi.


            Il ne faut pas oublier que la libération ne s'adresse pas qu'a monieur theo , mais a toute la communaute, donc ca interesse AUSSI la communaute qui développe du hard libre, etc...


            Oui, c'est justement pourquoi Théo réclame un tas de documentations aux différents constructeurs. Ce n'est pas QUE pour OpenBSD, c'est tout le monde qui bénéficie des différentes actions qu'il mène.

            Et non adapter du code pour qu'elle utilise au maximum un processeur ce n'est pas trivial si tu n'as pas la doc qu'il faut.


            C'est ce que je dis depuis le début... Il faut de la *bonne*.

            C'est dommage que chaque discussion sur OpenBSD et Théo devienne tout de suite agréssive.
            • [^] # Re: L'avis d'OpenBSD

              Posté par . Évalué à 0.

              Je n'ai jamais dit que l'initiative était à rejetter... justement l'attitude de Sun depuis quelques temps est excellente.
              Jene parlais pas de toi mais de lui : avec par exemple ce style de phrase :
              All Sun is trying to do is act fluffy, when they are not.


              Alors il me semble - sans vouloir te froisser - qu'il connaît un peu mieux le sujet que toi.
              D'un point de vue logiciel (portabilité) etc.. sans aucun doute, et je n'ai jamais dit le contraire.
              D'un point de vue matériel, besoin spécifiques, etc... peut etre pas (il ne connais pas forcément MES besoins).
              Encore une fois : ce n'est pas parce que ca n'interesse pas monsieur theo que ca n'interesse personne ! Et c'est tout ce que je voulais dire (peut etre maladroitement je le reconnais)

              Il a sans doute besoin AUSSI des docs des chipsets, mais NON -toute la- doc d'un processeur n'est pas trivial.
              Peut etre que la partie qui l'interesse l'est elle. Mais la doc dans l'ensemble n'est pas trivial. Sinon tous les constructeurs de cpu publieraient leurs verilogs car ca serait "trivial" de l'avoir...

              Oui, c'est justement pourquoi Théo réclame un tas de documentations aux différents constructeurs. Ce n'est pas QUE pour OpenBSD, c'est tout le monde qui bénéficie des différentes actions qu'il mène.
              Et je l'en suis tres reconnaissant ;)



              C'est ce que je dis depuis le début... Il faut de la *bonne*.
              Et c'est ce que j'ai dis aussi : si on a le code verilog : on les a toutes (sans doute en prenant beaucoup de temps), on a donc la bonne par extension ;)

              C'est dommage que chaque discussion sur OpenBSD et Théo devienne tout de suite agréssive.
              Bof la discussion pas encore trop je trouve ;)
          • [^] # Re: L'avis d'OpenBSD

            Posté par . Évalué à 2.

            Theo de Raad a dit que linux c'est de la merde, que Darwin c'est de la merde, c'est étonnant qu'il n'ait pas encore dit que Solaris aussi c'était de la merde. Même avec aussi peu de sens diplomatie, sans doute que Theo espère quand même avoir ses docs sur les chipsets Spac ?

            Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: L'avis d'OpenBSD

      Posté par (page perso) . Évalué à 1.

      Gilles Gravier, m'a confirmé que dans le cas de NetBSD, le port s'était fait sans problème.
      Leur politique serait plutôt de favoriser l'adaptation d'OS à leurs machines.

      Je lui soumes donc l'avis de Théo en espérant qu'un progrés en sorte
      • [^] # Re: L'avis d'OpenBSD

        Posté par (page perso) . Évalué à 5.

        Voici une réponse officielle de la part de Gilles Gravier ("Chief Technology Strategist for Security" de Sun):

        <<La citation de Theo fait reference a une situation d'il y a plus d'un
        an. Depuis (ce n'etait pas le cas a l'epoque) Solaris a ete mis en open
        source. Maintenant, mieux que la doc des chipsets, il y a un source qui
        peut etre considere comme une implementation de reference
        particulierement bien optimise. La license qui vient avec permet aux
        developeurs d'OpenBSD - ou tout autre OS libre - de re-utiliser ce code,
        et meme de le modifier, afin de l'adapter a leur OS. Il semble que la
        citation de Theo ne soit pas d'actualite... ou que quelqu'un doive lui
        expliquer que le monde a change. Contrairement a Apple, Solaris est en
        open source. Donc toute l'info necessaire pour acceder a nos
        plateformes, dans leur integralite, est disponible publiquement, ainsi
        que l'implementation de reference correspondante, avec une license tres
        permissive. Il n'est plus necessaire de faire du reverse engineering,
        comme il le pretend.>>

        Peut être que Théo tient à faire ce reverse enginering, ou mieux accéder à une documentation complète, pour être sur de ce qu'il fait. (Le coté paranoïaque de OpenBSD).
        Je comprend ce souci. Je pense aussi qu'il faut saluer des gestes positifs de libération de code ou d'architecture et encourager la suite. Cela ne doit pas empècher de demander cette suite.

        Surtout j'espère que ce débat permettra de faire avancer les choses, amener effectivement plus d'information à être publiée, sans perdre de vue que Sun doit aussi vendre quelque chose quelque part pour payer ses employés.
        • [^] # Re: L'avis d'OpenBSD

          Posté par . Évalué à 7.

          Pour la réutilisation du code source : TdR et les autres developpeurs d'OpenBSD (mais j'imagine que c'est aussi le cas sur les autres BSD) ont très clairement indiqué qu'ils considéraient la CDDL comme « encore moins libre que la GPL » (il faut comprendre ça du point de vue de leur license de choix : la BSD à deux clause et/ou la MIT/X11).
          Recherche sur la mailing-list tech@openbsd.org la réponse des devs à Jörg Schilling, qui voulait que son implem de tar (star) soit intégrée dans le système de base (pas seulement les ports) d'OpenBSD. Donc pour le kernel, où ils sont encore plus pointillieux, ce n'est meme pas la peine d'y penser.

          Là aussi, Sun a fait une grosse intox sur l' « extraordinaire permissivité » de leur licence CDDL, et de nombreux developpeurs se sont laissées intoxiquer, et croient que leurs developpement seront acceuillis à bras ouverts par les devs BSD (comme semble le croire Gilles Gravier, que tu cite, ou Schilling dans mon exemple).
          En pratique, leur code ne sera pas compatible BSD ni GPL.

          Concernant la disponibilité des sources d'OpenSolaris en lieu et place des docs, j'éspère que c'est une blague !
          L'implem d'un driver est très souvent remplie de tableaux de "valeurs magiques", d'astuces parfois indiscernables (si on n'est pas avertis) pour contourner les bugs du matériel / des firmwares, necessite de connaire l'API du noyau pour être bien lue etc.
        • [^] # Re: L'avis d'OpenBSD

          Posté par . Évalué à 6.

          Maintenant, mieux que la doc des chipsets, il y a un source


          Excellent foutage de gueule, bravo !

          La license qui vient avec permet aux developeurs d'OpenBSD - ou tout autre OS libre - de re-utiliser ce code, et meme de le modifier, afin de l'adapter a leur OS


          Balivernes.
          La licence restreint les droits par rapports à la licence BSD.
          Et elle n'est pas compatible avec la GPL (donc pas réutilisable dans le kernel linux).

          contrairement a Apple, Solaris est en open source


          Non. OpenSolaris est open source. Comme l'OpenDarwin d'Aplle quoi.
          Sinon (si l'on parle de Solaris): je veux que Gravier me maile les sources de leur driver Nvidia (entre autre), et m'autorise à redistribuer une version de leur implem java modifiée (puisque c'est aussi inclus dans Solaris) :P

          CyrrusSmith, quand arretera tu de relayer la propagande marketing de ce M. Gilles Gravier ?! Ou au moins, essaie d'interoger *plusieures sources*, pas seulement les employés de Sun ... (tip: va poser ces questions sur les mailing-lists d'OpenBSD ...).
          • [^] # Re: L'avis d'OpenBSD

            Posté par . Évalué à 2.

            Balivernes.
            La licence restreint les droits par rapports à la licence BSD.
            Et elle n'est pas compatible avec la GPL (donc pas réutilisable dans le kernel linux).

            Balivernes.
            Le CODE n'est pas réutilisable.
            Certainement pas le protocole, vu que c'est open source, le protocole de communication est libre, tu peut donc le réimplementer dans la licence de ton choix si la licence d' opensolaris ne te convient pas.
          • [^] # Re: L'avis d'OpenBSD

            Posté par (page perso) . Évalué à -1.

            Puisqu'on me repproche de n'écouter que les cadres de Sun, je me dois de montrer que je lit aussi les avis de Théo de Raadt.

            Celui ci est savoureux:
            http://www.pcinpact.com/actu/news/Le_createur_dOpenBSD_naime(...)
  • # Que lis-je??

    Posté par . Évalué à 1.


    Les cartes graphiques spécifiques SUN sont particulièrement remarquables. Leurs pilotes sont naturellement libres (d'autres machines SUN utilisent du nvidia).


    Il est possible d'utiliser une telle carte graphique sur un os libre avec un pilote libre?
    Si c'est le cas, j'm'achète fissa une station SUN.

    Cette info, si j'ai compris dans le bon sens, dépasserait de loin l'objet même de cette dépêche en terme d'intérêt.

    vite... éclairez, éclairez svp.
    • [^] # Re: Que lis-je??

      Posté par (page perso) . Évalué à 0.

      Bon, j'ai proposé un article à GNU/Linux magazine plus étendu que cette brève, avec un interview complet de Gilles Gravier et un court test de elate (GNU/Solaris). S'il sort se sera en fevrier. (Sous réserve de l'accord de la rédaction. Je viens juste de l'écrire. je ne sais pas s'il sera publié.)
      En attendant, voici quelques infos.

      Solaris est libre, avec une licence comparable à la licence mozilla.
      Donc ses sources sont libres, donc, les pilotes des cartes graphiques Sun, sont libres.
      En plus Sun vend déjà ses machines sous GNU/Linux.

      Il y a 2 sortes de cartes graphiques sur les machines Sun.
      - des cartes nvidia, dont certaines sont faites apparement spécialement pour Sun
      - des cartes Sun

      Pour les cartes nvidia, on a le choix entre des pilotes libres, avec moins de fonctionnalité, et les pilotes nvidia qui sont des binaires.

      Pour ce que j'ai pu en voir, les cartes Sun sont très performantes, mais pas données...
      Voir et fouiller un peu:
      http://fr.sun.com/
      • [^] # Re: Que lis-je??

        Posté par . Évalué à 4.

        CyrrusSmith, sauf ton respect, tu ne nous apprend rien là, j'aurais espèré que tu m'éclaires sur les chips graphique de SUN.
        Je ne veux pas entendre parler d'Nvidiarhée et ATIphilis :)

        Qu'elles ne soient pas données, ça peut s'comprendre, mais le fait que ça soit libre, full compatible OpenGL, pour moi c'est tout bon.
        Je ne joue pas avec de toute façon ce qui est inévitable, des jeux pour archi sparc, conné po.

        bye
      • [^] # Re: Que lis-je??

        Posté par . Évalué à 2.

        Bon, j'ai proposé un article à GNU/Linux magazine plus étendu que cette brève,

        J'espère que tu auras pris la peine de te renseigner un peu et d'éviter les erreurs de la brève...
        • [^] # Re: Que lis-je??

          Posté par (page perso) . Évalué à 2.

          C'est surtout un interview de Gilles Gravier de chez Sun que j'ai fait à la suite de la signature par Sun de la pétition contre la loi DADVSI de eucd.info/
          C e sont donc ses propos que je retranscri, après relecture de sa part.
          (Je part du principe que si j'interview quelqu'un, c'est qu'il connaît mieux le sujet que moi.)

          Les commentaires sur ce forum vont m'être utiles.
          J'ai pris la peine de me renseigner auprés d'un membre de l'équipe NetBSd qui a l'air plus optimiste sur l'utilisation de ce code.

          Je me dit qu'effectivement je vais creuser le sujet de cette licence CDDL.
      • [^] # Re: Que lis-je??

        Posté par . Évalué à 2.

        Faut arrêter la propagande là. Solaris n'est *pas* libre du tout.

        OpenSolaris l'est (bien que non compatible GPL ce qui est assez mesquin de la part de Sun, je trouve..), mais il n'inclus pas tout Solaris, loin de là.
  • # Ne pas se faire relai du marketing ciblé de Sun sans esprit critique !

    Posté par . Évalué à 6.

    Sun fait beaucoup de marketing autour de leur attachement à l'Open Source
    ((sic), ils parlent plus rarement de "libre"). Certes, ils sont à l'origine
    de nombreuses merveilles (Mozilla, OOo), mais il faut savoir prendre toute
    campagne de marketing (surtout si elle est ciblée à notre attention, vers
    les utilisateurs de logiciels libres) avec des pincettes.
    Le résultat est visible ici: les sites d'informations relayent sans analyser
    suffisament.

    Pour ce qui est de l'implementation de clones de machines Sun (comme il y
    a des "clones ibm/x86/pc"): la disponibilité des spécifications du processeur
    n'est qu'une goutte d'eau.
    Des machines ayant des types de processeurs identiques ne sont pas forcément
    des "clones" (c'est à dire compatibles): un powerbook est très différent
    d'une Xbox (pourtant POWER aussi), le port de Linux sur Zaurus (arm)
    ne le rend pas pour autant compatible avec les autres modèles de PDA
    ou les téléphones modernes (arm aussi, en général).

    Bref, je conteste la remarque de la dépêche « les ordinateurs "compatibles
    SPARC" pourraient connaître un succès comparable aux x86. » qui semble
    encourager l'amalgame, au profit évident des responsables marketing de Sun.
    Dans la dépêche, il y a un pernicieux glissement, passé inaperçu, entre
    "processeurs compatibles SPARC" et "ordinateurs compatibles SPARC".

    Sans l'ouverture (patent free) de l'ensemble du chipset (comment le proc est
    cablé, les divers bus sur la CM etc.) on n'obtiendra pas de "clones sun". Sans
    la disponibilité des specifications du chipset, on n'obtiendra pas de port de
    Linux (et des autres OS libres) de qualité (ou bien ce sera très long).

    Concernant le droit de réimplementer le processeur, il faudrait aussi parler
    des brevets. Il ne suffit pas que les shemas verilog du design soient
    "libres", il faut que Sun garantisse ne pas faire valoir ses brevets sur le
    Niagara contre les concurents. J'ai eu beau chercher, je n'ai trouvé aucun
    engagement de la sorte. Pour une fois, Sun est vraiment discret ...

    Je conteste aussi la dernière phrase de la dépêche, « Les spécifications
    pour le port de systèmes libres comme GNU/Linux ou NetBSd sur Machines SUN
    sont naturellement disponibles. ». Précisément, aucun *BSD n'a été porté
    sur UltraSparc III, parceque Sun a toujours refusé d'en donner les specs.

    Autres notes, en vrac:
    - "Après avoir libéré Solaris" : après avoir libéré _une partie_ de Solaris.
    - "OpenSPARC, c'est à dire la mise en open-source du c½ur de leur
    plateforme hardware" : libéré les shémas électroniques du processeur.
    - "Les cartes graphiques spécifiques SUN sont particulièrement
    remarquables.": franchement, c'est hallucinant ça ! Il parle des abominables,
    ancestrales, "Elite 3D" / "Creator 3D" et consorts ou j'ai raté un wagon ?
    - "d'autres machines SUN utilisent du nvidia" et ATI aussi
    - "Étant données les performances de ce matériel" ... que personne, à part
    les employés de Sun, n'a encore eu l'occasion d'essayer / benchmarker ...

    Désolé, mais cette article est vraiment très peu tempéré, tout aux louanges
    de Sun !
    J'aimerai savoir chez qui travaille CyrrusSmith.

    Pour la route: http://kerneltrap.org/node/568
    • [^] # Re: Ne pas se faire relai du marketing ciblé de Sun sans esprit critique

      Posté par (page perso) . Évalué à 4.

      <<J'aimerai savoir chez qui travaille CyrrusSmith.>>

      Je suis fonctionnaire de l'éducation nationnale.

      Je n'ai aucune action Sun, D'ailleur je n'ai aucune action de quelque entreprise que ce soit.

      J'admet avoir un expérience très limité des machines Sun (quelques courts essais), mais les machines récentes m'ont paru effectivement dotés de performances graphiques interessantes.

      Donc merci de ta contribution technique au débat. J'ai surtout voulu par cette annonce montrer une ouverture possible pour sortir des machines x86 ou autres qui seront bientôt dotées de fonctions DRM qu'il sera interdit de contourner.

      Si des documentations manquent, peut être qu'à à l'avenir les choses vont changer.

      Beaucoup de choses qui n'étaient pas libres il y a peu le sont devenues.
      Maintenant, les chipset des PC sont ils tous identiques, libres, et documentés?
      (C'est une vraie question. je ne connais pas la réponse).

      En attendant le système Solaris qui fonctionne sur ce architecture est libre, dont au au moins son noyau. Son code peut donc être repris, utilisé, modifié et adapté et servir à des ports d'autres OS.
      Par contre je ne sais pas s'il est bien documenté.


      Il est vrai que je suis souvent bon public et facile à enthousiasmer.
      L'interet d'un tel forum est justement de confronter les informations, et d'augmenter la connaissance de tous par le débat.
      • [^] # Re: Ne pas se faire relai du marketing ciblé de Sun sans esprit critique

        Posté par . Évalué à 2.

        Je suis fonctionnaire de l'éducation nationnale.

        Ok, au temps pour moi.
        Celà dit je maitient qu'il faut être prudent avec les annonces venant des employés d'entreprises privées (surtout des grosses boites comme Sun, IBM, Apple etc., qui savent ce qu'attend un geek Linuxien).

        Maintenant, les chipset des PC sont ils tous identiques, libres, et documentés?

        Pour l'essentiel, oui. (enfin par "identiques" bien sûr): "cablage" du proc à la mémoire, principaux buses, etc.
        Celà dit les fabriquants de carte mères utilisent de plus en plus de composants opaques et non documentés (par ex. certains chipsets SATA), donc tout n'est pas rose non plus de ce coté :(


        Son code peut donc être repris, utilisé, modifié et adapté et servir à des ports d'autres OS.


        Malheureusement non, du fait d'incompatibilité des licences.
        Par exemple le code CDDL ne peut être réutilisé dans une appli GPL, comme le kernel Linux.

        Il est vrai que je suis souvent bon public et facile à enthousiasmer.

        Bah, tu a bien fait de proposer une dépêche sur ce proc, car c'est un sujet interessant.
        Seulement la campagne de com de Sun est tellement bien orchestrée (ça va même jusqu'à faire bloguer les employés de Sun) qu'on a du mal à ne pas relayer leur marketing, alors je profite de l'occasion pour demystifier un peu (et je ferai pareil à la prochaine occas, sur IBM et Apple ;).
    • [^] # Re: Ne pas se faire relai du marketing ciblé de Sun sans esprit critique

      Posté par . Évalué à 2.

      juste comme ca :

      un powerbook est très différent
      d'une Xbox (pourtant POWER aussi),

      Oui mais ca n'as rien a voir
      C'est pas le même processeur (mais vraiment pas le même)
      c'est comme si je disais qu'une majorette c'est comme une maseratti parce qu'il y a ma dedans ...

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.