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
- Opensparc (34 clics)
- Solaris et la CDDL (13 clics)
- GNUsolaris (16 clics)
- Libérations de brevets par SUN (18 clics)
- Le weblog de Gilles Gravier (12 clics)
# C'est bien mais..
Posté par psychoslave__ (site web personnel) . Évalué à 1.
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 ナイコ (site web personnel) . Évalué à 3.
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 Jeanuel (site web personnel) . Évalué à 8.
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 GhZaaark3 . Évalué à -1.
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 Cali_Mero . Évalué à 10.
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 Zanton . Évalué à 2.
[^] # Re: Assez gros...
Posté par Cali_Mero . Évalué à 4.
[^] # Re: Assez gros...
Posté par Zanton . Évalué à 2.
[^] # Re: Assez gros...
Posté par yoho (site web personnel) . Évalué à 2.
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 Sylvain Sauvage . Évalué à 7.
http://java.sun.com/docs/books/vmspec/
http://java.sun.com/docs/books/jls/index.html
Disponibles depuis le début (= très, très longtemps).
[^] # Re: Assez gros...
Posté par yoho (site web personnel) . Évalué à 2.
[^] # Re: Assez gros...
Posté par Mark Havel . Évalué à 6.
[^] # Re: Assez gros...
Posté par pvincent . Évalué à 1.
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 boubou (site web personnel) . Évalué à 2.
Le support de 1.5 par GCJ et Classpath avance très bien, ceci dit.
[^] # Re: Assez gros...
Posté par nicodache . Évalué à 5.
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 FredCL . Évalué à 2.
Que SUN fournisse le code du JRE!
[^] # Re: Assez gros...
Posté par stef . Évalué à 2.
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 boubou (site web personnel) . Évalué à 9.
[^] # Re: Question de "newbe"
Posté par Julien . Évalué à 6.
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 patrick_g (site web personnel) . Évalué à 1.
ben le fameux article boubou vient de poster le lien juste au dessus de ton message.
[^] # Re: Question de "newbe"
Posté par Yannick (site web personnel) . Évalué à 2.
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 Jeanuel (site web personnel) . Évalué à 3.
Qu'importe la raison, pourvu que l'code reste...
[^] # Re: Assez gros...
Posté par Antoine . Évalué à 5.
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 Jeanuel (site web personnel) . Évalué à 2.
[^] # Re: Assez gros...
Posté par Antoine . Évalué à 7.
Un article que j'ai écrit à ce sujet : http://www.libroscope.org/Liberer-les-logiciels
[^] # Re: Assez gros...
Posté par Jeanuel (site web personnel) . Évalué à 3.
Nous somme d'accord.
[^] # Re: Assez gros...
Posté par grmbl . Évalué à -3.
Ils ont réécrit Gecko "frome scratche" ?
Ah bin ça alors !
[^] # Re: Assez gros...
Posté par vosgien_ . Évalué à 10.
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 Antoine . Évalué à 10.
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 ccomb (site web personnel) . Évalué à 4.
[^] # Re: confusion...
Posté par nicodache . Évalué à 7.
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 boubou (site web personnel) . Évalué à 5.
[^] # Re: confusion...
Posté par nicodache . Évalué à 3.
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 boubou (site web personnel) . Évalué à 3.
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 Vincent Pelletier . Évalué à 5.
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 Serge Julien . Évalué à 9.
[^] # Re: confusion...
Posté par Jul (site web personnel) . É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. Depuis, j'ai arrêté de fantasmer sur les vieux clous.
[^] # Re: confusion...
Posté par Antoine . Évalué à 2.
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 reno . Évalué à 2.
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 ragoutoutou . Évalué à 8.
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.
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 EraZerg . Évalué à 8.
<<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 ragoutoutou . Évalué à 5.
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 EraZerg . Évalué à 4.
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 ragoutoutou . Évalué à 3.
Je crois que c'est du pur amd, une solution indispensable pour garder une compatibilité parfaite pour les systèmes x86.
Yesss... au fait, tu bosses sur quelle architecture?
[^] # Re: confusion...
Posté par boubou (site web personnel) . Évalué à 3.
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 ragoutoutou . Évalué à 5.
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.
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.
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.
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 Nicolas Boulay (site web personnel) . Évalué à 4.
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 ragoutoutou . Évalué à 3.
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 Nicolas Boulay (site web personnel) . Évalué à 2.
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 nicodache . Évalué à 2.
tout le monde n'a pas ta connaissance des PPC ;)
[^] # Re: confusion...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
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 nicodache . Évalué à 1.
c'est donc une sorte de ram avant la ram, juste ?
à quand les slots sodimm sur les proco IBM ? :D
[^] # Re: confusion...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: confusion...
Posté par nicodache . Évalué à 2.
mais vu ta remarque , 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 Nicolas Boulay (site web personnel) . Évalué à 2.
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 ragoutoutou . Évalué à 1.
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 ragoutoutou . Évalué à 4.
[^] # Re: confusion...
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: confusion...
Posté par nicodache . Évalué à 2.
enfin, c'est mon avis quoi ;)
[^] # Re: confusion...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: confusion...
Posté par ragoutoutou . Évalué à 2.
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 Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: confusion...
Posté par ragoutoutou . Évalué à 3.
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 Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: confusion...
Posté par ragoutoutou . Évalué à 2.
La communication intercache ne passe pas par la ram, donc c'est pas un argument.
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 ragoutoutou . Évalué à 7.
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 Nicolas Boulay (site web personnel) . Évalué à 2.
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 ragoutoutou . Évalué à 2.
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 Antoine . Évalué à 2.
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 ragoutoutou . Évalué à 2.
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 Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: confusion...
Posté par ragoutoutou . Évalué à 2.
[^] # Re: confusion...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
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 ragoutoutou . Évalué à 3.
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 Nicolas Boulay (site web personnel) . Évalué à 2.
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 nicodache . Évalué à 2.
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 Nicolas Boulay (site web personnel) . Évalué à 3.
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 ragoutoutou . Évalué à 2.
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 nicodache . Évalué à 3.
forcément, avec un nom comme madame soleil, ils devraient pas trop se gourer...
--------------------> [ ]
[^] # Re: confusion...
Posté par reno . Évalué à 2.
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 Ontologia (site web personnel) . Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: confusion...
Posté par ragoutoutou . Évalué à 2.
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 Ontologia (site web personnel) . Évalué à 2.
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 ragoutoutou . Évalué à 2.
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 Ben (site web personnel) . Évalué à 6.
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. -- Jules Claretie
# L'avis d'OpenBSD
Posté par panda panda . Évalué à 10.
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 briaeros007 . Évalué à 0.
Il devrait en parler a l'équipe de fcpu si c'est si trivial que ca ...
[^] # Re: L'avis d'OpenBSD
Posté par neriki (site web personnel) . Évalué à 4.
[^] # Re: L'avis d'OpenBSD
Posté par vosgien_ . Évalué à 3.
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 Yann Hodique (site web personnel) . Évalué à 2.
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 briaeros007 . Évalué à 0.
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 vosgien_ . Évalué à 6.
Je ne comprend pas pourquoi tu dis que je critique...
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.
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.
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 briaeros007 . Évalué à 0.
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 B16F4RV4RD1N . Évalué à 2.
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 CyrrusSmith (site web personnel) . Évalué à 1.
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 CyrrusSmith (site web personnel) . Évalué à 5.
<<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 herodiade . Évalué à 7.
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 herodiade . Évalué à 6.
Excellent foutage de gueule, bravo !
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).
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 briaeros007 . Évalué à 2.
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 CyrrusSmith (site web personnel) . Évalué à -1.
Celui ci est savoureux:
http://www.pcinpact.com/actu/news/Le_createur_dOpenBSD_naime(...)
# Que lis-je??
Posté par GhZaaark3 . Évalué à 1.
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 CyrrusSmith (site web personnel) . Évalué à 0.
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 GhZaaark3 . Évalué à 4.
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 Antoine . Évalué à 2.
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 CyrrusSmith (site web personnel) . Évalué à 2.
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 matlj . Évalué à 2.
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 herodiade . Évalué à 6.
((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 CyrrusSmith (site web personnel) . Évalué à 4.
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 herodiade . Évalué à 2.
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 briaeros007 . Évalué à 2.
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 ...
[^] # Re: Ne pas se faire relai du marketing ciblé de Sun sans esprit critique
Posté par nicodache . Évalué à 2.
plutot un truc du genre qu'une ferrari ou une maserati c'est pareil parce que la peinture est rouge ;)
dans ce cas-ci, c'est tout les deux des power
yen a un qui est mono-core, l'autre qui est tri-core, l'un qui est concu pour etre un proc généraliste, l'autre est un proc conçu pour une console de jeu (je suis loin de croire que le proco de la XBOX est constitué de 3 G5 ou Power (970/980/5))
[^] # Re: Ne pas se faire relai du marketing ciblé de Sun sans esprit critique
Posté par briaeros007 . Évalué à 3.
rien a voir avec un ppc "classique" (en tout cas pas grand chose).
Effectivement la comparaison avec la ferrari est meilleur ;)
[^] # Re: Ne pas se faire relai du marketing ciblé de Sun sans esprit critique
Posté par herodiade . Évalué à 3.
Je pensait 'playstation', et puis je sait pas ce qui m'a pris, j'ai parlé de xbox.
ça doit être le marketing, là encore (avant noël, c'est fatal) ;).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.