En perte de vitesse sur le marché des CPU après le début fracassant de l'architecture X86-64 et la très bonne résistance des Power d'IBM, Sun vient de prendre une décision radicale en décidant de publier la description de ses processeurs sous la licence libre la plus célèbre et la plus reconnue.
Après la bascule vers la GPL, n'importe quel fabricant pourra utiliser le design librement, le modifier et produire des microprocesseurs qui resteront eux-mêmes libres.
Richard stallman a salué cette initiative : "The free world welcomes Sun's decision to use the Free Software Foundation's GPL" et tous les libristes peuvent en faire autant.
NdM Il s'agit de la suite de l'article de décembre dernier donné en lien Selon Jonathan Schwartz "Open source is not just about software. Freedom is not just about software. It's going to come to hardware, and we're going to drive that".
C'est évidemment un coup de poker dans l'espoir de regagner des parts de marché qui se sont évaporées au profit de ses concurrents, mais c'est aussi un gain net pour l'ensemble de la communauté du libre.
Celle-ci avait senti depuis longtemps que la prochaine bataille se jouerait sur le hardware et que si les utilisateurs voulaient préserver leurs libertés il serait nécessaire d'avoir des machines libres en plus des logiciels. Les menaces du Trusted computing se précisent, les pressions des majors pour imposer une "chaîne de confiance hardware" augmentent. C'est ce qui explique la naissance de projets comme F-CPU (une tentative de design d'un processeur moderne libre) et de nombreux autres essais. Le succès n'est pas vraiment au rendez-vous du fait de la puissance très réduite des puces ou de la focalisation sur un marché de niche (comme le LEON de l'agence spatiale européenne qui est un processeur compatible Sparc v8 sous LGPL).
Bien entendu, le fait que la conception d'un processeur moderne et puissant soit une tache épouvantablement complexe n'aide pas au décollage de telles tentatives et c'est pourquoi l'annonce de SUN est si importante.
La première spécification disponible est celle de l'UltraSPARC T1 , une puce ultra innovante puisqu'elle propose 8 coeurs simples (in-order) avec 4 threads dans chaque coeur. On obtient ainsi une puce à 1.2 GHz faisant tourner 32 threads simultanément en ne consommant que 72 watts !
Aller plus loin
- L'annonce : (38 clics)
- OpenSparc : (14 clics)
- DLFP: SUN libère ses processeurs SPARC (10 clics)
# C'est bien mais
Posté par salvaire . Évalué à 8.
[^] # Re: C'est bien mais
Posté par dilbert . Évalué à 10.
[^] # Re: C'est bien mais
Posté par reno . Évalué à 9.
[^] # Re: C'est bien mais
Posté par libresurf (site web personnel, Mastodon) . Évalué à 3.
[^] # Re: C'est bien mais
Posté par Anonyme . Évalué à 10.
alors qu'avant tu payais des ingenieur pendant 3 ans, tu achetais des logiciel a 100KE, tu serais les fesses pour ne pas avoir de bug. Tu pleurais a droite et a gauche pour avoir des financement, et tu essayer de trouver un fondeur pour faire une petite serie pour faire des proto.
Si l'europe et les industriel europeens ne sont pas trop nul, il y a quelque choses a faire. cf les universitées, les chercheurs qui pleurent 'yapasdemoyen' etc...
[^] # Re: C'est bien mais
Posté par Jakie Kasperwsky . Évalué à 8.
Qui peut construire de telle puce ? Tout le monde et c'est ça qui peut faire des progrès énormes en terme de coût et de recherche en R&D. Si SUN donnait aussi une archi de carte graphique sous licence libre, on peut envisager d'avoir des ordis standards fabriqués par milion et ne coûtant presque rien.
[^] # Re: C'est bien mais
Posté par patrick_g (site web personnel) . Évalué à 10.
ahem....je me suis laissé dire qu'une usine de production de puces gravées en 90 nanomètres se chiffre en milliards de dollars.
Faudra bien les amortir et donc facturer les puces en monnaie sonnante et trébuchante. Faut pas croire que l'effet d'échelle va être gigantesque car la compétion sera avec les x86 qui sont déja produits par centaines de millions d'exemplaires et ou il existe une conccurence (Itel,AMD,Via) pour faire baisser les prix.
Sun fait juste ça pour sauver son architecture CPU propriétaire et il ne faut pas s'attendre à une invasion de PC UltraSparc sous Linux à Carrouf !
Les vrais bénéfices c'est :
1) la description libre d'un processeur puissant et moderne pour les étudiants.
2) la possibilité pour des fondeurs alternatifs d'entrer sur le marché.
3) la possibilité pour des pays souverains de se baser sur une informatique non dépendante de firmes étrangères.
4) Une issue de secours en cas de Trusted Computing généralisé.
[^] # Re: C'est bien mais
Posté par Nico C. . Évalué à 6.
peut etre pourrions nous assister a une invasion d'appareils mobiles UltraSparc sous Linux a Carrouf... car dans ce secteur il y a encore une assez grande variete de processeurs...
[^] # Re: C'est bien mais
Posté par djano . Évalué à 2.
Je me suis laisse dire que sa consommation, meme si elle semble faible pour un CPU de serveur reste assez enorme pour un appareil mobile: 70 Watts
premiere sources avec Google + ultrasparc t1 consommation :
http://www.silicon.fr/getarticle.asp?ID=12400
http://www.presence-pc.com/actualite/ultrasparc-t1-12947/
[^] # Re: C'est bien mais
Posté par patrick_g (site web personnel) . Évalué à 9.
* 17.6 W (max) at 650 MHz, 1.7 V
* Energy star support: 1/2x, 1/6x, reduced clocking
* 2.5 W max in sleep mode
[^] # Re: C'est bien mais
Posté par Jimmy . Évalué à 5.
Par exemple, des DSP Texas Instruments C5xxx, utilisés dans des téléphones portables, consomment environ 0.33mA/MHz, soit 80mW à 200MHz sous une tension de coeur de 1.2V.
http://focus.ti.com/dsp/docs/dspplatformscontenttp.tsp?secti(...)
Un DSP C6416 à 1GHz consomme moins d'1W, et il a aussi 8 unités de calcul en parallèle (ca compte quand même pour un seul coeur)
http://focus.ti.com/docs/prod/folders/print/tms320c6416t.htm(...)
Un ARM926 consomme environ 0.45 mW/MHz, soit 120mW à 266 MHz. Sans compter les modes d'économie d'énergie.
http://arm.com/products/CPUs/ARM926EJ-S.html
Cela dit, la libération du Sparc (même si c'était déjà un design assez ouvert, cf. LEON) est une excellente nouvelle, car on pourrait voir apparaître des fondeurs-intégrateurs comme il y a des assembleurs de PC taiwanais, produisant à bas coût le design développé par la communauté des électroniciens-libres. Ca pourrait se concerner surtout des mini-PC, du style MacMini ou Mini-ITX, très prisés des geeks que nous sommes ! http://damnsmalllinux.org/store/
De son côté, IBM et Freescale ont également ouvert le design du PowerPC 405 pour les universités, mais apparemment n'importe qui peut devenir membre du consortium de spécification du standard PowerPC. La licence n'a quand même pas l'air libre ... http://www.power.org/home
[^] # Re: C'est bien mais
Posté par gpe . Évalué à 3.
[^] # Re: C'est bien mais
Posté par ZeAuReLiEn . Évalué à 10.
Le rapport puissance/consommation apparait donc très bon
[^] # Re: C'est bien mais
Posté par ZeAuReLiEn . Évalué à 5.
[^] # Re: C'est bien mais
Posté par cortex62 . Évalué à 4.
Question : la gestion du cache mémoire ça ce passe comment ? Parce que la il y a du monde quand même.
[^] # Re: C'est bien mais
Posté par bertrand . Évalué à 10.
Il execute 32 threads sur 8 cores, donc 4 thread par core.
Les 4 threads d'un core sont exécuté successivement.
Les instructions de chaque thread sont exécutés après les rapatriements de données dans le cache. Les accès mémoires ne pénalisent donc pas le core car, pendant ce temps il exécute une instruction des chacun des 3 autres threads.
C'est du moins le principe. Cela nécessite donc un cache moins grand qu'un processeur monothread.
Si une instruction a besoin d'accèder à 2 adresses mémoires, et qu'il y en a déja une en cache il n'y a pas d'attente par exemple.
Par ailleurs le fait que l'entrelacement des threads soit systématique pemet de l'implémenter très simplement dans le processeur. Il suffit (en très très gros) de basculer a un jeu de registre parmi quatre à chaque période d'horloge.
La contrepartie des 8 cores, c'est qu'ils sont très simple (comparé à un x86-64 ou équivalent).
La performance n'est donc pas identique à un monocore ultra rapide avec un cache monstrueux.
C'est très adapté à des serveurs gérant des processus simple (et si possible identique car besoin de moins de cache d'instruction) en grand nombre, genre serveur web ( Sun n'a pas fait ça par hasard), peut être moins à un desktop quoi que le nombre de processus activé sur un desktop linux classique est non négligeable. Sur des programmes effectuant du calcul intensif et non programmé en multithread la puissance disponible est de 1/32 de la puissance total du processeur.
[^] # Re: C'est bien mais
Posté par Matthieu Moy (site web personnel) . Évalué à 6.
Dans l'embarqué, un truc qui compte, c'est déjà que le proc ne consomme pas quand il ne travaille pas. Genre ton téléphone portable alumé pendant que tu ne téléphone pas. Les designers ont des techniques assez évoluées pour activer et désactiver l'alimentation d'une partie de la puce selon si elle est en utilisation ou pas.
Ça ne fait pas de l'ultra-sparc un mauvais processeur, mais pour de l'embarqué, j'ai des doutes.
[^] # Re: C'est bien mais
Posté par Cali_Mero . Évalué à 3.
[^] # Re: C'est bien mais
Posté par imalip . Évalué à 10.
[^] # Re: C'est bien mais
Posté par Cali_Mero . Évalué à 5.
Dans le monde du logiciel, il est facile pour un vendeur peu regardant de "s'inspirer" de code GPL pour améliorer son propre produit non-GPL. Or là on parle de spécifications matérielles, et je n'ai pas souvenir de précédent de la GPL appliquée à ce genre de choses, alors je me demande ce qui les empêcherait de le faire...
[^] # Re: C'est bien mais
Posté par herodiade . Évalué à 5.
Le design est GPL.
Je crois qu'il set un peu abusif de parler de "Hardware Libre" en fait, parce que je doute que le fait que les schémas soient sous GPL change quoi que ce soit au droit de redistribution du hardware.
Bref, je ne suis pas sur que dans ce cas, Intel ou AMD soient contraints de reverser leurs propres designs.
Quelqu'un à les idées plus clair que nous sur cette question ?
[^] # Re: C'est bien mais
Posté par herodiade . Évalué à 7.
En effet:
- Si dans ce contexte la GPL n'est pas contraingnante sur le matériel produit (distribuer un processeur basé sur un design libre ce n'est pas ditribuer un binaire, le fameux « in either source or binary form » de la GPL), les autres constructeurs ne seront pas contraints de livrer les « sources » de leurs processeurs basés sur le design de Sun. De fait Sun aurait aussi bien pu licencer ses docs sous BSD, CDDL, MIT ou Choucroute Folle, ça n'aurait pas changé grand chose en pratique (sinon l'effet médiatique).
- Si Sun dispose de brevets pour protéger ses innovations matérielles, ils peuvent cependant empécher totalement la fabrication/vente de processeurs inspirés de leurs designs.
Donc en l'attente de précisions sur ces points (type: « Sun ouvre son portefolio de brevets » et « Ils utilisent une version modifiée de la GPL imposant la redistribution des schémas si distributions de procs » ) on sait seulement que les specs du processeur Niagara T1 sont dispos. Point barre. Le reste est exrapolation (ou j'ai fait une erreur dans mon raisonement).
Vu comme ça, ce n'est peut-être finalement pas un évenement extraordinaire :/
[^] # Re: C'est bien mais
Posté par M . Évalué à 5.
[^] # Re: C'est bien mais
Posté par Yth (Mastodon) . Évalué à 2.
Là tu pourrais reprendre des idées si tu ne reprends pas de bouts de circuit.
Après, dans le cas des Sparc, peut-être que Sun a des brevets sur certaines parties...
Yth.
[^] # Re: C'est bien mais
Posté par Jakie Kasperwsky . Évalué à 6.
Je ne suis pas tout à fait d'accord. La baisse des prix due à la concurrence est assez relative. La concurrence joue surtout sur les performances des processeurs. Pour les processeurs, les coûts de productions sont négligeables par rapport aux coût de lancement (R & D puce et machine + contruction de la ligne de fabrication se compte en effet en milliard de dollars).
En fait Intel pourrait pouduire des processeurs du genre pentium III à 1 GHz assez peu cher puisque qu'il ont les machines pour ça et qu'ils ont déjà amorti les dépense de R & D. Mais ce serait se tirer une balle dans le pied pour eux puisque beaucoup d'utilisateurs s'en contenterai (C'est la puissance de mon partable qui est tout à fait utilisable). Les fondeurs ont les moyens de le faire mais ils savent tous que leurs concurrents sont dans la même situation. C'est d'ailleurs là un des pbm du projet one Laptop Per Child, AMD fourni des processeurs pas cher pour ce projet mais prends aussi le risque de detruire ce model économique. Intel ne voulait pas prendre ce risque.
Au cours de mes quelques cours d'électronique, j'ai retenu que la révolution du domaine pouvait venir d'une architecture très standard bon marché avec Linux dessus et un ensemble de briques logiciel compatibles servant à créer tout un ensemble de services. Les livebox, freebox, ... sont peut-être des précurceurs. UltraSparc ou autre on y viendra de toute façon. Il suffit que quelqu'un commence.
[^] # Re: C'est bien mais
Posté par salvaire . Évalué à 8.
[^] # Re: C'est bien mais
Posté par Matthieu Moy (site web personnel) . Évalué à 9.
Les couts fixes pour la production des puces sont énormes. C'est pas pour rien qu'il y a peu de fabriquants de processeurs, et que dans l'embarqué, les entreprises concurrentes s'allient pour construire des usines (cf crolles 2 avec ST, philips et freescale).
Donc, pour la partie design, les universités pourront s'amuser avec, les particuliers et/ou petites entreprises pourront sans doute participer, mais pour la production des puces, ça restera entre les mains d'une poignée de grosses boites.
[^] # Re: C'est bien mais
Posté par spart . Évalué à 10.
mmh, a propos, ce n'est pas la Chine qui a péniblement développé son propre processeur pour ne pas dépendre des fondeurs américains ?
Revons deux minutes... ils reprennent le design du Sparc, l'améliorent, inondent le marché de CPU ultra puissants sous GPL, sur lesquels du reste n'ont été portés que des OS libres...
argh, vite ma pillule...
[^] # Re: C'est bien mais
Posté par GhZaaark3 . Évalué à 8.
Et les GPU libres... raghh, j'vais tombé dans les pommes.
C'est du pain béni pour les pays en voie de dev'
Bref c'est du très très fort.
Au moins ce qui est bien avec Sun, c'est que même si ils devaient sentir leur fin arrivé - ce qui n'est pas du tout le cas quand même - ils ne couleront pas avec leur navire.
Si il y a bien une entreprise qui peut prétendre la porteuse d'innovation, c'est bien SUN MicroSystem.
# Sympa pour les developpeurs
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 10.
Je veux la même dans ma machine pour mes compilations de moz !
mk_add_options MOZ_MAKE_FLAGS=-j32, ça le fait moi je dit :-) Parce que bon, du -j2, c'est bien beau, mais attendre 30 minutes pour avoir un binaire Gecko, c'est embétant à la longue :-)
Y a ceux aussi qui compilent à longueur de journée du KDE ou du gentoo qui pourraient être interressé :-)
# Tanenbaum était un visionnaire ...
Posté par Marc Poiroud (site web personnel) . Évalué à 9.
Fil complet : http://www.oreilly.com/catalog/opensources/book/appa.html
Enfin, bon faut encore faire les machines, faire des distrib compatibles (SparcDriva, Ultrabuntu, UltraOpenSuSe, ), ... on en a encore pour 15 ans ! :)
[^] # xSparcs
Posté par iOops (site web personnel) . Évalué à 1.
[^] # Re: xSparcs
Posté par Séverin Tagliante-Saracino . Évalué à -1.
[^] # Re: xSparcs
Posté par Arnaud (site web personnel) . Évalué à 3.
;-)
[^] # Re: xSparcs
Posté par B16F4RV4RD1N . Évalué à 2.
Je rigole, je rigole, cela dit, avec l'ouverture de l'architecture de certains systèmes (ppc, sparc etc.), on risque d'avoir la possibilité de pouvoir sortir des machines complètement libres, cela peut être un beau enjeu
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: Tanenbaum était un visionnaire ...
Posté par patrick_g (site web personnel) . Évalué à 8.
le machines existent : c'est SUN qui les vend pour l'instant mais cette annonce laisse présager d'autres vendeurs à moyen terme.
Quand aux distribs elles existent aussi ! (Debian Sarge est compatible Sparc...gentoo aussi je crois). Pareil pour NetBSD et OpenBSD.
Si l'union européenne etait visionnaire elle se lancerait à fond dans la production d'UltraSparc. Maintenant qu'ils sont GPL elle assurerait son indépendance technologique et elle aurait une chance de gagner des parts de marché dans un domaine (les CPU généralistes) ou elle n'existe pas.
[^] # Re: Tanenbaum était un visionnaire ...
Posté par GhZaaark3 . Évalué à 0.
[^] # Re: Tanenbaum était un visionnaire ...
Posté par gnumdk (site web personnel) . Évalué à 6.
C'est vrai qu'avec un noyau linux, tu vas aller super loin... Tu crois pas oublié une grosse partie du systeme?
Compiler une distrib GNU/Linux pour la faire fonctionner sur une autre archi, cela ne se fait pas en claquant des doigts... Je me souviens encore il y'a quelques années un membre du PLF qui faisait des builds de mandrake pour sparc, c'etait pas évident et je crois meme que le projet n'existe plus...
[^] # Re: Tanenbaum était un visionnaire ...
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Bref, il y a un grand pas entre avoir un noyau qui tourne et une distribution qui tourne sous une nouvelle architecture. C'est pas pour rien que les 3/4 des distributions se limite au x86.
[^] # Re: Tanenbaum était un visionnaire ...
Posté par mosfet . Évalué à 3.
[^] # Re: Tanenbaum était un visionnaire ...
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Les BSD ont leur système de port. Je parlais du système global : distribution. Pour une debian, c'est plus de 1000 paquetages.
Le portage d'une console texte sur une architecture exotique, c'est intéressant mais ce n'est pas tout à fait les mêmes objectifs.
[^] # Re: Tanenbaum était un visionnaire ...
Posté par agmk . Évalué à 4.
Je crois que tu voulais dire "plus de 10000 paquetages". Je me trompe ?
[^] # Re: Tanenbaum était un visionnaire ...
Posté par GCN (site web personnel) . Évalué à 3.
[^] # Re: Tanenbaum était un visionnaire ...
Posté par herodiade . Évalué à 5.
Par exemple un noyau ne supportant que IA32 peut tourner sur un x86_64 type AMD64 en mode 32 bits, mais dans ce cas c'est, en toute honneteté, un support partiel de l'architecture. À ce sujet, puisqu'on parlait de support SPARC et de Debian, il y a une seule archive Debian/sparc, pas une archive 32 bits et une archive 64 bits -genre Debian/sparc et Debian/sparc64, comme c'est le cas en testing pour i386 32 et 64-: peut-on en déduir que Debian n'utilise les processeurs UltraSPARC qu'en mode 32 bit ? (c'est une question hein, j'en sait rien).
Il en va de même des nombreuses extensions proposées par les processeurs modernes, type Intel/PAE, UltraSPARC/Stackghost, Intel/Silvervale, AMD/Pacifica etc. sans parler de la gestion (ou pas) du SMP et/ou du multihreading sur l'archi concernée ...
Donc dire qu'une distro ou un OS est "sparc-compatible", c'est trop peu dire.
Le Niagara (le proc dont il est question dans l'article) serait bien peu intéressant exploité par un OS tournant en 32 bits et ne sachant pas gérer le SMP SPARC, ni la virtualisation ...
Et puis comme le signalaient les posts parents, le kernel est une chose, le bootloader, la toolchain, les packages, ... en sont une autre: UltraSPARC est une archi délicate sur ce point, car grand boutiste, 64 bits, avec des contraintes d'alignement strictes, bref tout ce qu'il faut pour aimablement lever les bugs des applis développées sur pécé (petit boutiste, majoritairement 32 bits, faibles contraintes d'alignement). Du coup, le travail des packageurs/distributions n'est pas négligeable. Ce n'est pas du « tout cuit ».
[^] # Re: Tanenbaum était un visionnaire ...
Posté par Jimmy . Évalué à 3.
En tout cas, il n'est pas rare de voir un Solaris 32 bits tourner sur un UltraSparc ... cherchez l'erreur.
UltraSPARC est une archi délicate sur ce point, car grand boutiste, 64 bits, avec des contraintes d'alignement strictes, bref tout ce qu'il faut pour aimablement lever les bugs des applis développées sur pécé
C'est clair que le portage peut s'avérer pénible si le code n'est pas bien propre au départ. D'un autre côté, le Sparc a des caractéristiques assez sympa, comme la banque de registres "à glissière" qui permet des changements de contexte très rapides.
J'avais aussi entendu dire qu'un processeur grand-boutiste était un petit peu plus rapide, et que c'est pour ca que tous les CPU RISC utilisent cette orientation (ou sont configurables, comme le MIPS et le PowerPC). Quelqu'un en sait plus ?
[^] # Re: Tanenbaum était un visionnaire ...
Posté par lasher . Évalué à 3.
D'autre part, dans mes souvenirs, un de mes profs nous expliquait que d'un point de vue d'électronicien, faire du Big-Endian était plus simple, mais que d'un point de vue d'informaticien, le "penser" était plus difficile (ce qui se conçoit aisément). Bref, le design des puces devient plus complexe en Little-Endian, mais ne pose apparemment pas de problème de perfs significatif.
[^] # Re: Tanenbaum était un visionnaire ...
Posté par Jimmy . Évalué à 3.
Oui, c'est bien ce que je disais : les Mips, les PowerPC, les DSP TI, et sans doute bien d'autres. N'empêche que ces modes ne sont pas compatibles entre eux, et qu'il faut bien choisir lequel on utilise sur une carte donnée. Par exemple, il y a deux branches Mips dans Debian, l'une pour les stations Digital et l'autre pour SGI. http://www.debian.org/ports/mips/
Le standard PC est toujours little-endian, et les standards réseaux sont presque tous big-endian.
d'un point de vue d'électronicien, faire du Big-Endian était plus simple, mais que d'un point de vue d'informaticien, le "penser" était plus difficile (ce qui se conçoit aisément)
Je code quotidiennement pour des cibles embarquées qui utilisent les deux modes. La difficulté, c'est justement qu'on a une chance sur deux, quand on définit un champ de bits pour un registre, de se tromper de sens ... et que pour faire un code portable il faut tout faire en double, avec le risque d'erreur qui en découle.
Est-ce que tu te souviens de ce qui rend plus simple l'un ou l'autre sens selon le point de vue de l'utilisateur ? Parce que comme je suis à mi-chemin entre l'informaticien et l'électronicien, je n'ai pas un avis aussi tranché ;-)
[^] # Re: Tanenbaum était un visionnaire ...
Posté par lasher . Évalué à 3.
Mmmh.
Quels standards réseaux ? Pour moi, ils étaient TOUS en BIG-ENDIAN :-)
Est-ce que tu te souviens de ce qui rend plus simple l'un ou l'autre sens selon le point de vue de l'utilisateur ? Parce que comme je suis à mi-chemin entre l'informaticien et l'électronicien, je n'ai pas un avis aussi tranché ;-)
Honnêtement, ce n'est pas avec le peu d'électronique que j'ai fait que je pourrai te répondre pour le Big Endian. Pour le little endian, avoir les octets de poids fort dans le "bon sens", c'est quand même plus facile pour imaginer ce que va faire la machine.
Genre, si j'ai un mot de 4 octets (ABCD) à transmettre sur le réseau, et en supposant que ce dernier soit en Little Endian, ils vont partir "dans l'ordre". Alors qu'en Big Endian, j'aurais un mot ABCD, mais en pratique, si le réseau est en Big Endian lui aussi, ABCD deviendra CDAB (si je ne m'abuse - ou alors c'est carrément au niveau de l'octet, et à ce moment-là ce sera DCBA). Bref, ça ne respecte pas l'ordre des "humains".
[^] # Re: Tanenbaum était un visionnaire ...
Posté par darkleon (site web personnel) . Évalué à 3.
Ce n'est pas l'inverse plus tôt ? Je me rappelle des dumps hexa mémoires sur x86 des résultats d'une carte d'acquisition 32bits, c'est imbitable à lire pour un humain.
(H)=humain, (M)=machine
Sur 8 bits
BE (Big-Endian bit de poid plus fort en premier)
132 -> 10000100 -> 0x84
LE (bit de poid le plus faible en premier)
132 -> 00100001 -> 0x84
Sur 16 bits (2 adresses consécutives en mémoire )
BE : 32770 -> 10000000 00000010 -> 0x8402 -> AB (M) = AB (H)
LE : 32770 -> 01000000 00000001 -> 0x0284 -> BA (M) != AB (H)
Et en 32 bits
Big-endian : ABCD (M) = ABCD (H)
Little-endian : DCBA (M) = ABCD (H)
A priori LE est plus facile pour la machine, car pour augmenter la taille des mots, il ne faut pas lire la mémoire à rebours
Par contre ça oblige pour l'être humain de lire les chiffres de droite à gauche et non pas de gauche à droite
Le LE était un avantage sur les ordinateurs 16bits à bus 8 bits, ou il n'y avait pas à gérer le chargement de l'octet de poids fort avant l'octet de poids faible dans un registre (simplification du décodeur, pas besoin d'un registre tampon)
Maintenant que les bus mémoires font au minimum 64 bits et qu'il y a de toute manière un cache L1 entre la mémoire et le proc, cette limitation n'existe plus (présence automatique d'un "registre tampon")
Au niveau de l'électronique, avec la mémoire cache, ça doit être la même chose d'être en LE ou BE au niveau du nombre de portes. (par contre les schémas doivent être en mirrori)
Cette différenciation d'architecture vient plutôt de raisons historiques (comme le bios de 82)
Par contre au niveau logique le BE est plus facile a appréhender pour nous humains. C'est plus facile de debugger une série de mots 32 bits en BE qu'en LE (c'est peut être pour cette raison qu'à la base les protocoles réseaux sont en BE).
Mais je ne suis pas un spécialiste en conception de circuits éléctroniques, alors j'ai peut être dit une grosse connerie. Je serais ravis si c'est le cas, que l'on m'explique pour ne pas mourrir idiot :-)
[^] # Re: Tanenbaum était un visionnaire ...
Posté par Olivier Jeannet . Évalué à 3.
BE (Big-Endian bit de poid plus fort en premier)
132 -> 10000100 -> 0x84
LE (bit de poid le plus faible en premier)
132 -> 00100001 -> 0x84
Autant je suis bien d'accord avec toi sur le fait que le big-endian est plus lisible pour un humain, puisqu'il respecte l'ordre naturel d'écriture (cf mon autre commentaire pas loin), autant je ne pige pas pourquoi tu inverses les bits au sein d'un même octet, je n'ai jamais vu ça.
On récupère toujours chaque octet "normalement". Ce sont les octets entre eux qui peuvent être à l'envers, quand on les lit 1 par 1 à la suite en mémoire.
[^] # Re: Tanenbaum était un visionnaire ...
Posté par Jimmy . Évalué à 1.
Justement, c'est bien là la principale différence entre Big Endian et Little Endian. C'est l'ordre des bits du bus de données (physiquement, sur les broches de la puce) qui est inversé :
- en little endian, le bit 0 du bus est le bit de poids faible, le bit 31 est le bit le plus significatif (1),
- en big endian, c'est le bit 0 qui est le bit de poids fort.
Ainsi, on représente généralement les bus big-endian [0..31] et les bus little endian [31..0], en notant toujours le bit de poids fort à gauche, dans le sens naturel de lecture.
Mais du coup, l'ordre des octets dans la mémoire est également inversé, car on parcourt toujours les adresses dans le sens croissant : l'octet qui contient le bit 0 sera toujours placé à une adresse plus basse que celui qui contient le bit 31.
Voici une explication assez claire :
http://membres.lycos.fr/cgiguere/vdn/vdn71/vdn71.htm
notamment le passage sur UNIX, XINU et NUXI ...
(1) on utilise souvent les notations MSB (Most Significant Bit) et LSB (Least Significant Bit).
[^] # Re: Tanenbaum était un visionnaire ...
Posté par Olivier Jeannet . Évalué à 2.
C'est possible, mais ça ne change pas le fait que tu n'as aucun moyen de le savoir au niveau de la programmation.
Quand tu te retrouves sur une machine Little Endian (PC x86 dans mon cas), tu peux voir que l'ordre des octets est inversé en mémoire, quand tu stockes une valeur sur plus d'un octet (un entier 32 bits en particulier), par exemple en faisant "od -x fichier.bin" tu peux voir que les octets sont inversés 2 par 2 car les données sont lues par défaut sur 2 octets; pour avoir un affichage normal, il faut faire "od -t x1 fichier.bin" (casse-pieds quand on vient du monde 680x0 Big Endian). Les bits d'un octets apparaissent dans l'ordre normal (heureusement, sinon la machine serait difficilement utilisable !).
D'où ma surprise avec ton explication où tu inverses les bits au sein d'un octet; ça embrouille pour rien.
[^] # Re: Tanenbaum était un visionnaire ...
Posté par Olivier Jeannet . Évalué à 3.
Heu, pas du tout. C'est en big-endian que l'ordre est naturel : la valeur sur 32 bits 0x11223344 est stockée dans l'ordre en mémoire, l'octet 0x11 avant 0x22 et ainsi de suite. Un dump mémoire est parlant. La famille des Motorola 680x0 était big-endian et c'est agréable (j'y ai pratiqué pas mal d'assembleur).
Alors que sur x86 (little-endian, berk), quand tu fais un "od -x" d'un fichier, les octets sont inversés 2 à 2, c'est illisible. Il faut faire un "od -t x1" pour avoir les octets dans l'ordre.
[^] # Re: Tanenbaum était un visionnaire ...
Posté par encre (site web personnel) . Évalué à 1.
Moi j'ai (à contrecoeur, je dois avouer) choisi Linux dans ce cas. Donc NetBSD c'est très bien, mais surtout sur quelques archis avec beaucoup de développeurs. Et c'est compréhensible.
[^] # Re: Tanenbaum était un visionnaire ...
Posté par herodiade . Évalué à 10.
Hmm, je ne suis pas sûr qu'ils vendent déjà des serveurs sous Niagara.
Es-tu certains de cette info ?
> Quand aux distribs elles existent aussi ! (Debian Sarge est compatible Sparc...gentoo aussi je crois). Pareil pour NetBSD et OpenBSD.
Attention, le fait que certains processeurs UltraSparc|Sparc soient supportés ne signifie pas qu'ils le soient tous (en fait certains ne sont pas du tout supportés, au moins par les *BSD, faute d'ouverture des docs de la part de Sun -- c'est d'ailleur pour ça, obtenir cette ouverture, que je gueule un peu).
D'autre part - et à contrario des allégations marketing de J. Schwartz - la mise à disposition des schémas du processeur n'aidera (quasiment) pas le portage sur les serveurs de la vraie vie: encore faut-il que Sun mette à disposition, si possible sans NDA, les spécifications complétes de leurs serveurs: cablage du proc et de la mémoire, cartes scsi/raid etc. Ce qu'ils ont parfois, mais pas toujours, accépté de faire. J'avais déjà parlé de ça dans la précédente dépêche sur le sujet.
En fait l'intéret pratique de cette nouvelle n'est pas tant la portabilité que l'extention du libre au monde du matériel. Effectivement, de nombreux projets existent mais aucun d'une telle ampleur. Quelles seront les conséquences ? aura-t-on un jour une communauté du HL (hardware libre ;) vivante, riche, active et innovante comme la communauté du LL actuelle ? D'autres gros constructeurs emboiteront-ils le pas à Sun ? Quelles conséquences sur les prix des futurs procs ? Sur la qualité ? Quels vont être les modus operandi de ces communautés (cvs/svn + mailing-lists + wiki ... ?) et quels rétro-conséquence sur la communauté du LL ? Verra-t-on cette démarche reprise par des constructeurs sur d'autre types de matériels ? Les projets type Open Graphics y trouveront-ils le crédit / gage de sérieux nécéssaire à la levée de subvention ? ...
Cette dépêche n'a pas oublié que Schwartz s'adresse généralement aux developpeurs (car ce sont eux qui décide au bout du compte, dit-il dans l'article lié à la dépêche), moyennant des efforts de communication ciblée (sur nous !) et au prix de petites contre-vérités (paradoxalement, au prix de ne peut-être pas mettre assez en avant ce qu'il y a de réellement révolutionnaire dans la démarche de son entreprise !).
Donc mention spéciale à patrick_g qui nous a fait une excellente dépêche, distinguant le bon grain (l'extraordinaire potentiel d'un tel matériel libre) de l'ivraie (le marketing de Sun concernant sa position sur les LL, la GPL, la portabilité etc.). Un vrai boulot de journaliste ;) comparé à la précédente dépêche sur ce sujet. J'adorerai que toutes les dépêches relatant les coups de campagnes ciblées vers la communauté des LL émanant des gros industriels (Sun, IBM et Apple en particulier) soient rédigées avec autant de prudence.
Il reste juste un détail mineur qui m'interroge (enfin, peut-être que j'ai mal compris l'annonce de Sun): la dépêche semble indiquer que Sun compte libérer les designs de tout ses processeurs UltraSPARC (en précisant que le T1 était juste "les première spécification disponible ". Mais pour le moment je n'ai trouvé que des indications contraires, par exemple dans la FAQ du projet OpenSPARC : "OpenSPARC project is making the hardware source code of the recently announced UltraSPARC T1 processor available under an Open Source license. ".
J'ai l'impression que les communiquants de Sun entretiennent la confusion en parlant à l'occasion d'UltraSPARC (la famille de processeurs) de façon générique là où ils devraient préciser "UtraSPARC T1". Ou je me trompe et l'ensemble des designs UltraSPARC seront effectivement libérés ? Ou est-ce une mauvaise transcription des journalistes ?
Une dernière question: on-t-ils annoncé qu'ils donnaient gracieusement une licence d'utilisation de leurs (éventuels, mais probables) brevets concernants ce matériel à tous, sans discrimination, et royalty free ? Parceque la "gplisation" du design d'un proc vérouillé par des brevets serait complétement inutile. Bref, qu'en est-il de la question des brevets _matériels_ sur l'US ?
[^] # Re: Tanenbaum était un visionnaire ...
Posté par patrick_g (site web personnel) . Évalué à 5.
Es-tu certains de cette info ?
http://www.sun.com/servers/coolthreads/t1000/
http://www.sun.com/servers/coolthreads/t2000/
>> Il reste juste un détail mineur qui m'interroge [snip] J'ai l'impression que les communiquants de Sun entretiennent la confusion en parlant à l'occasion d'UltraSPARC (la famille de processeurs) de façon générique là où ils devraient préciser "UtraSPARC T1". Ou je me trompe et l'ensemble des designs UltraSPARC seront effectivement libérés ?
Dans le second lien (OpenSparc) on peut lire ceci :
The UltraSPARC Architecture 2005 is a complete specification of the instruction set architecture (ISA) common to Sun Microsystem's 64-bit SPARC implementations (beginning with UltraSPARC T1 in 2005). UltraSPARC Architecture 2005 complies with SPARC V9 Level 1, with many more details, plus includes numerous Sun extensions common to all UltraSPARC processors.
Donc a priori l'architecture libre est celle du T1 mais les futurs processeurs seront également libres (c'est comme ça que je comprends le beginning with UltraSPARC T1. De plus cette archi est compatible SPARC V9 (elle lui ajoute seulement des extensions).
>> aura-t-on un jour une communauté du HL (hardware libre ;) vivante, riche, active et innovante comme la communauté du LL actuelle ?
J'y crois pas trop car le hard reste un domaine matériel et donc il faut obligatoirement passer par le cycle très long de la conception/fabrication...rien a voir avec une chtite compilation de 15 mn !
>> D'autres gros constructeurs emboiteront-ils le pas à Sun ?
Pas tant qu'il pourront l'éviter et d'autant moins qu'ils voudront implanter des fonctions Trusted computing/DRM...etc.
Si SGI était malin ils libéreraient leurs MIPS mais bon.....
>> Verra-t-on cette démarche reprise par des constructeurs sur d'autre types de matériels ? Les projets type Open Graphics y trouveront-ils le crédit / gage de sérieux nécéssaire à la levée de subvention ? ...
J'ai un peu d'espoir pour les CGU. Après tout il y a bien des gens intelligents dans ces boites et ils vont bien finir par comprendre qu'ils ont tout a gagner à au moins ouvrir les specs (la mise sous GPL du design est encore un rêve). Ces types vendent du hardware alors pourquoi se faire chier à pondre des drivers ! Pourquoi un business model basé sur la vente de hard restreindrait l'usage de celui-ci par un manque de soft ? C'est vraiment très con.
Ils se privent de pleins d'OS et de pleins d'archi CPU sur lesquelles leur driver ne marche pas. La raison finira par leur souffler qu'il vaut bien mieux libérer les specs et sortir un driver libre : on a des retours de bugs par les utilisateurs; on a parfois même des patchs; on peut vendre sa carte a plus de gens et en plus les libristes sont fous de joie et vous font de la pub sur le net.
Si un décideur pressé d'ATI ou NVidia lit ceci il sait maintenant ce qu'il doit mettre dans son prochain Powerpoint exposant "une nouvelle stratégie révolutionnaire" !
[^] # Re: Tanenbaum était un visionnaire ...
Posté par herodiade . Évalué à 3.
> http://www.sun.com/servers/coolthreads/t2000/
Wow, c'est plutôt bon marché en plus: à peut près le prix d'un serveur x86 1U !
>> aura-t-on un jour une communauté du HL (hardware libre ;) vivante, riche, active et innovante comme la communauté du LL actuelle ?
> J'y crois pas trop car le hard reste un domaine matériel et donc il faut obligatoirement passer par le cycle très long de la conception/fabrication...rien a voir avec une chtite compilation de 15 mn !
Oui, là le "release early, release often" serait dévastateur !
Mais je pensait "vivante, riche, active et innovante" au sens d'une communauté large et créative, plutot que sur le plan du nombre de projets/releases.
> Pas tant qu'il pourront l'éviter et d'autant moins qu'ils voudront implanter des fonctions Trusted computing/DRM...etc.
Je ne suis pas certain d'y voir très clair sur ce point.
Est-ce que le fait que le design soit sous GPLv2 empêche les fondeurs (et même, les concepteurs/designers) d'implémenter des fonctionalités de type DRM ?
Je connais super mal le sujet des DRM, mais il me semble (me détromper si je dit une connerie) que:
1- un système de protection robuste ne devant pas reposer sur le secret de l'algorithme (security by obscurity), l'éventuelle protection DRM ne devrait pas être remise en cause par la publication des schémas (~= de l'algo), mais plutot de la clefs privée (par ex intégrée dans le firmware) qui l'utilise.
2- que le design du processeur soit GPL n'impose probablement pas que le contenu du firmware, dont la clef, le soit (ps: Sun a-t-il libéré le OpenBoot ?).
3- la GPLv2, même sur le plan logiciel, n'interdit pas l'implem de DRMs
Et puis Sun n'a pas l'air si farouchement anti DRM que ça ... : http://blogs.sun.com/roller/page/jonathan/20050826
Pour les GPUs, sans être aussi optimiste que toi, je crois me souvenir que le dev principal du projet Open Graphics peinait à trouver un support financier (d'ailleur ce projet avait été laché par son entreprise) parceque "le matériel libre, ce n'est pas une idée sérieuse". Maintenant que Sun fait des specs libres, son projet pourrait parraitre plus crédible aux yeux des décideux préssés !
[^] # A propos d'OpenGraphics
Posté par karteum59 . Évalué à 4.
Par contre, plutôt que de concevoir un ASIC en entier (ce qui pose de gros problèmes financiers), ne vaudrait-il pas mieux s'orienter vers une carte AGP avec des composants plus "génériques" et programmables, par exemple, un gros DSP / FPGA / processeur vectoriel ?
Par exemple, le processeur Cell d'IBM semble très prometteur. Je ne sais pas comment il pourrait se mesurer face aux processeurs dédiés comme ceux de NVidia mais si c'était comparable il me semble qu'on pourrait imaginer une carte (PCI/AGP) avec un processeur Cell qui fasse office de GPU (hébergeant un mini linux et une version de Mesa optimisée)... A mon avis, vu que les composants existent (sauf la carte PCI/AGP qui héberge le tout) ce serait bien plus réaliste que de concevoir un chip en entier et d'espérer que quelqu'un le produira... Comme c'est un processeur généraliste, il n'y aurait pas de problème pour les extensions OpenGL, les shaders, le décodage MPEG4 à la volée...
Sinon à part ça, qqun sait comment le Ultrasparc T1 se compare face aux Intel / PPC / Cell ?
[^] # Re: A propos d'OpenGraphics
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
Mais un FPGA est 4x plus lent et consomateur d'énergie (et chère) qu'un asic.
Sinon, on ne peut pas comparrer les perfs d'un DSP ou d'un cpu seul avec la puissance d'un gpu même simple comme l'OGP. Il y a un ordre de grandeur de différence (x10 donc...)
"La première sécurité est la liberté"
[^] # Re: A propos d'OpenGraphics
Posté par karteum59 . Évalué à 3.
Oui je sais, mais en fait de processeurs je ne parlais pas de x86 mais de processeurs vectoriels multicores comme le Cell (qui apparemment repend pas mal de techniques mises en oeuvre dans les GPUs).
[^] # Re: A propos d'OpenGraphics
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Il est à prioris in order, donc pas comparrable au athlon/pentium. Je dirais au pif, qu'un seul core à 1.2 Ghz doit être comparrable à un athlon à 800 mhz.
Pas d'out of order veut dire plein de gachis d'utilisation des unités de calculs. Mais il y a les threads pour ça, ce qui doit compenser.
Donc à 4 threads/core, tu dois avoir un trés bon taux d'utilisation.
Donc en gros, ton cpu en appli mutlithread doit être comparrable à un bi -athlon.
Donc avec 32 threads, on a une super machine faite pour les serveurs.
"La première sécurité est la liberté"
[^] # Re: Rapport Puissance/Conso
Posté par Mars . Évalué à 0.
>
pour 72 Watts ?
Ce proc est vraiment écolo ! Et donc à même de se positionner correctement face aux prochains Intel dans ce domaine ?!
Ca serait une TRES BONNE nouvelle à l'heure où les problèmes d'énergie se révèlent primordiaux.
Cependant j'ai un gros doute ....
[^] # Re: Rapport Puissance/Conso
Posté par patrick_g (site web personnel) . Évalué à 3.
Oui c'est d'ailleurs très marrant de voir que le marketing SUN lors du lancement de l'UltraSparc T1 se basait sur l'écologie et les économies d'énergie. Du style "si tous les CPU du monde étaient des T1 alors on pourrait économiser x milliards de tonnes de pétrole".
Pour la puissance il y a aussi une donnée à prendre en compte : le T1 est vraiment pensé comme un processeur pour serveurs web et donc ses performances en virgule flottante sont minables. il n'a qu'une seule unité FP en tout (par opposition aux 8 coeurs/32 threads).
La prochaine génération prévue en 2007 (l'an prochain quoi) aura les caractéristiques suivantes :
* gravure 65 nm
* 8 coeurs (ça change pas)
* une unité FP par coeur (soit 8 en tout)
* 8 threads par coeur (soit 64 en tout)
* fréquence 1.4 à 1.6 GHz
[^] # Re: A propos d'OpenGraphics
Posté par briaeros007 . Évalué à 4.
Tiens ca alors ca alors c'est tout d'abord ce vers quoi s'oriente ogp ...
Le problème avec un fpga c'est que
1°) c'est cher à l'unité.
2°) c'est moins performant qu'un asic (en perf pur , en rapport conso/perf etc...)
voila pourquoi ils vont normalement d'abord faire une carte avec fpga (qui sera aux alentours de 500 ¤ je crois), et une fois que la levée de fond sera suffisante (et le debug aussi) lancer la protection d'un asic.
Sur la ml il parlaient de 1 million de $ pour faire le masque.
Par exemple, le processeur Cell d'IBM semble très prometteur. Je ne sais pas comment il pourrait se mesurer face aux processeurs dédiés comme ceux de NVidia mais si c'était comparable il me semble qu'on pourrait imaginer une carte (PCI/AGP) avec un processeur Cell qui fasse office de GPU (hébergeant un mini linux et une version de Mesa optimisée)...
Cell et gpu n'ont pas vraiment le même but.
D'ailleur la ps3 aura un gpu en plus de son cell.
Sinon à part ça, qqun sait comment le Ultrasparc T1 se compare face aux Intel / PPC / Cell ?
Pour le cell ca va être dur vu qu'il n'y a rien qui est équipé avec pour l'instant.
Sinon regarde par la :
http://opensparc.sunsource.net/nonav/performance.html
et plus spécifiquement la :
http://www.sun.com/servers/coolthreads/t1000/benchmarks.jsp
Même si on peux faire dire ce qu'on veux avec des chiffres, ca devrait te donner une idée.
Oui, là le "release early, release often" serait dévastateur !
Avec un fpga et une image stable de base ca peut passer encore.
[^] # Re: A propos d'OpenGraphics
Posté par karteum59 . Évalué à 1.
Oui, mais est-ce que c'est pour des raisons techniques ou pour des raisons "pratiques" ? (une implémentation OpenGL optimisée pour le Cell pourrait prendre des mois à coder / débugger, alors que les processeurs NVidia et leur drivers sont disponibles tout de suite)
[^] # Re: A propos d'OpenGraphics
Posté par patrick_g (site web personnel) . Évalué à 2.
maintenant si : http://www.itjungle.com/tlb/tlb021406-story02.html
[^] # Re: A propos d'OpenGraphics
Posté par karteum59 . Évalué à 1.
[^] # Re: A propos d'OpenGraphics
Posté par patrick_g (site web personnel) . Évalué à 5.
je pense que les cell-blades d'IBM c'est plus pour les films 3D (pixar doit être content) ou pour des applications scientifiques spécifiques que comme substitut aux GPU.
# Améliorations ?
Posté par Poulpatine (site web personnel) . Évalué à 5.
# Les UltraSparc sous quelle GPL?
Posté par Guinns . Évalué à 1.
"si les utilisateurs voulaient préserver leurs libertés ..." alors il vaudrait mieux la v3, histoire de ne pas pouvoir mettre des DRM dedant.
en fait la réponse semble être GPLv2 ...
[^] # Re: Les UltraSparc sous quelle GPL?
Posté par herodiade . Évalué à 2.
Car enfin, il suffit qu'un contributeur au processeur (peut-etre meme Sun l'a déja fait ?) réussisse à faire accepter une modification couverte par un de ses brevets (hardwares, donc valable aussi en Europe) pour que le matériel soit vérouillé au point que plus personne ne puisse implémenter le design librement. C'est un danger très important pour ce genre de projets, et la GPLv3 devrait permettre de le désamorcer (si au final elle impose effectivement au contributeur de céder les droits d'exploitation de ses brevets, c'est dans le cahier des charges).
Sun semble être bien disposé envers la GPLv3, en tout cas suffisament pour (prétendre) envisager de re-licencer OpenSolaris sous double licence (CDDL + GPLv3). Mais il s'agit peut-être d'une promesse en l'air ... cf. le blog de Jonathan Schwartz: http://blogs.sun.com/roller/page/jonathan
[^] # Re: Les UltraSparc sous quelle GPL?
Posté par djano . Évalué à 2.
Meme si OpenOffice est GPL, il me semblait que Sun avait cree la CDDL expressement pour qu'OpenSolaris ne soit pas compatible avec Linux. Peut etre est ce parce que Linus Torvalds s'est declare contre la GPLv3 en l'etat, et que donc Sun ne craint plus que son code soit pris pour renforcer Linux.
En effet, si la licence choisie est CDDL+GPLv3, alors ce n'est pas compatible avec Linux qui est GPLv2.
Bref, moi plus comprendre la! :?
[^] # Re: Les UltraSparc sous quelle GPL?
Posté par patrick_g (site web personnel) . Évalué à 2.
La sauce OpenSolaris ne prenant pas il faut bien qu'ils imaginent des solutions. C'est vrai qu'ils peuvent pousser le machiavelisme jusqu'à choisir la GPLv3 pour éviter l'import de code dans Linux qui reste sous v2.
Ca n'empecherais sans doute pas d'importer des bouts interessants comme ZFS qui sont biens distincts du core kernel je pense.
[^] # Re: Les UltraSparc sous quelle GPL?
Posté par herodiade . Évalué à 4.
Non il est très improbable que ça soit leur motivation, car la remarque de Linus était un pur choix politique (une "police" le noyau mainstream, de kernel.org). Mais il n'y a pas un d'obstacle légal.
Moyennant quoi, si OpenSolaris est relicencé en GPLv3, et que par exemple ZFS ou DTrace intéressent suffisament les developpeurs (+ sont suffisament portables etc.) on verra certainement des projets adaptants ceux-ci à Linux, au moins come modules externes (ce qui de toute façon est assez bien admis et communs dans le monde Linux: p-o-m iptables, (anciennement) fuse, ...: autant de projets respectables mais pas immédiatement acceptés dans le kernel vanilla de Linus).
Même un fork n'est pas exclus: il en existe déjà, comme uclinux par exemple.
D'autre part Linus a mis de l'eau dans son vin en précisant qu'il pourrait y avoir des contributions v3 au noyau (simplement, que le noyau lui-même, dans son ensemble, serait considéré v2).
> En effet, si la licence choisie est CDDL+GPLv3, alors ce n'est pas compatible avec Linux qui est GPLv2.
Apparement Stallman tient à faire en sorte que la v3 finale soit compatible avec la v2.
http://gplv3.fsf.org/rationale#SECTION00380000000000000000
> Bref, moi plus comprendre la! :?
La GPLv3 n'empecherai pas Solaris de "renforcer Linux".
Ce qui est certain c'est qu'il ne s'agit pour le moment que de annonce d'une reflexion, meme pas d'un engagement. La GPLv3 n'est pas encore releasée.
Sun a déjà annoncé maintes fois "réfléchir à la libération de java", et on n'a encore rien vu venir.
(en clair: il s'agit peut-être d'une autre trouvaille de Schwartz en matière de marketing ciblé, ne tombons dedans: attendont plus de concret !).
[^] # Re: Les UltraSparc sous quelle GPL?
Posté par Anonyme . Évalué à 1.
C'est du FUD de GPL-istes barbus ça. Ils ont créé la CDDL, dérivée de la MPL (pour être réutilisable) car la MPL était ce qui collait le plus à leur vision. D'ailleurs la CDDL est bien antérieure à OpenSolaris. La CDDL est une licence très respectable.
# De L'autre côté SGI ...
Posté par GhZaaark3 . Évalué à 3.
Si on en croit cette article:
http://www.channelregister.co.uk/2006/02/08/sgi_warns/
Les risques d'une année 2006 fatale sont bien présent.
Si ils pouvaient libèrer leurs specs à leur tour, ça serait génial.
j'en ai presque des scrupules... :/
Enfin...
[^] # Re: De L'autre côté SGI ...
Posté par gnumdk (site web personnel) . Évalué à 4.
Si il pouvaient libérer leur code aussi, le OpenGL que Nvidia a porté pour eux sous GNU/Linux, ca serait pas mal déjà. Ca ferait déjà un truc de pas libre en moins dans les drivers de chez Nvidia.
# Sun et le libre
Posté par Wawet76 (site web personnel) . Évalué à 10.
Comme pour Solaris et Ultrasparc, ils attendent aussi que Java soit quasiment mort commercialement avant de libérer leur implémentation ?
[^] # Re: Sun et le libre
Posté par ufoot (site web personnel) . Évalué à 4.
Score 5: insightfull 8-)
Effectivement, il y a certainement un peu de ça. Mais bon ça reste une bonne nouvelle cette publication sous GPL. Cool!
[^] # Re: Sun et le libre
Posté par sylware . Évalué à 6.
[^] # Re: Sun et le libre
Posté par GuieA_7 (site web personnel) . Évalué à 4.
[^] # Re: Sun et le libre
Posté par Matthieu Moy (site web personnel) . Évalué à 5.
Ou l'inverse, peut-être ;-).
# Un vrai portable ou un gros pda
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Je te colle ça sur une carte mère avec 1 Go de RAM et 4 Go de FLASH. Je rajoute un écran 14" à éclairage LED et une grosse batterie Lithium-polymer de qq dizaines d'Ah.
Je mets le tout dans un package pour que cela face moins de 1 kg.
Et je te fais le portable/PDA tueur de blackberry et autre smartphone (avec clavier de m...) !
Un vrai ordinateur portable quoi...
"La première sécurité est la liberté"
[^] # Re: Un vrai portable ou un gros pda
Posté par GhZaaark3 . Évalué à 0.
Sinon, y a Nvidia qui vient de sortir un GPU pour l'embarqué.
http://www.dailytech.com/article.aspx?newsid=766
Oké c po libre...
[^] # Re: Un vrai portable ou un gros pda
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Le projet continue mais le core ne sera pas libre dans un premier temps, le temps de se faire une santé financière.
Il ne communique plus dessus tant que rien ne sort. J'espère un truc utilisable à la fin de l'année.
"La première sécurité est la liberté"
[^] # Re: Un vrai portable ou un gros pda
Posté par Mark Havel . Évalué à 2.
C'est bien beau de mettre un CPU sous GPL, mais je vois très très très mal en quoi cela pourrait être utile pour faire du matériel en l'absence des usines qui vont avec... Au mieux, cela peut permettre à quelques génies de se faire remarquer en proposant des améliorations de design...
[^] # Re: Un vrai portable ou un gros pda
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Si tu as déjà le code, tu gagnes un fric monstres.
Une puce comme ça, c'est un projet de ~10 Millions d'euro. Cela parrait énorme mais pas tellement pour un tel projet.
Si tu te payes un core genre PPC d'IBM, tu doubles le prix minimum voire plus. En gros, 10 M¤ par core (cpu, gpu,...).
"La première sécurité est la liberté"
[^] # Re: Un vrai portable ou un gros pda
Posté par Rémi Hérilier . Évalué à 0.
/me qui retourne rêver sur un pdf décrivant l'O2.
# Libriste
Posté par pleiades . Évalué à -2.
Je le trouve particulièrement horrible. De plus la communauté du logiciel libre présente, à mon avis, le gros avantage de parler correctement français par rapport aux autres communautés informatiques, je trouve donc ça dommage.
vw
[^] # Re: Libriste
Posté par zgnouf . Évalué à 5.
La formation de ce mot est tout à fait logique, répond à un besoin etc. il n'y a pas de raison de le rejeter ou sinon tu peux aussi rejeter les logiciels et autres qui ne te choquent déjà plus...
À ce propos je signale une ressource gratuite qui est parfois bien utile pour ceux qui traduisent :
http://www.olf.gouv.qc.ca/ressources/gdt.html
Tout n'est pas forcément bon mais c'est souvent très utile.
[^] # Re: Libriste
Posté par zgnouf . Évalué à -1.
La formation de ce mot est tout à fait logique, répond à un besoin etc. il n'y a pas de raison de le rejeter ou sinon tu peux aussi rejeter les logiciels et autres qui ne te choquent déjà plus...
À ce propos je signale une ressource gratuite qui est parfois bien utile pour ceux qui traduisent :
http://www.olf.gouv.qc.ca/ressources/gdt.html
Tout n'est pas forcément bon mais c'est souvent très utile.
[^] # Re: Libriste
Posté par Philip Marlowe . Évalué à 5.
~~~~~~> []
[^] # Re: Libriste
Posté par Frédéric Lopez . Évalué à 3.
[^] # Re: Libriste
Posté par Pierre Jarillon (site web personnel) . Évalué à 3.
[^] # Re: Libriste
Posté par FredCL . Évalué à 2.
c'est bon n'en jettez plus, j'ai vu la sortie -> [ ]
[^] # Re: Libriste
Posté par Séverin Tagliante-Saracino . Évalué à 2.
[^] # Re: Libriste
Posté par Jean-Philippe (site web personnel) . Évalué à 5.
[^] # Re: Libriste
Posté par GhZaaark3 . Évalué à 4.
libre à toi...
[^] # Re: Libriste
Posté par spart . Évalué à 3.
[^] # Re: Libriste
Posté par Mithfindel (site web personnel) . Évalué à 3.
# Aucun lien, mais pour info ....
Posté par GhostLine . Évalué à 2.
Cette machine uniquement connue des amigaistes, à base de PPC (G3 ou G4) est libre (depuis un petit moment maintenant). Elle contient (en vrai, je n'ai pas été voir si les plans concordaient) 2 ports Ethernet (100 et 1000 Mbps), un port IEEE1394, deux ports USB, une carte son integrée, un port AGP ... à voir donc.
http://www.amigaimpact.org/modules/news/article.php?storyid=(...)
# Spec != RTL
Posté par Xavier Caron . Évalué à 5.
Meme avec le RTL, ce n'est pas a la portee du premier venu. Il faut un outil de synthese (tres cher), d'analyse statique de timing (cher aussi) et de simulation (il y en a des gratos) pour synthetiser et valider ton processeur. Ca prend aussi beaucoup de temps pour developper les contraintes (dependantes du process de fabrication, donc des bibliotheques du fondeur). Les bibliotheques ne sont pas gratuites non plus. Pour les technos avancees, les memoires sont AMHA un point critique. Un processeur a pas mal de caches differents. Un generateur de memoires coute bombon (~ M$ "que" pour du 130 nm). Et quand on a fini tout ca, on n'a fait que la partie front-end du boulot ! Les outils back-end (P&R, LVS, etc.) coutent encore plus cher que leurs copains du front-end (et bouffent encore plus de CPU/memoire).
Xavier.
[^] # Re: Spec != RTL
Posté par Jimmy . Évalué à 3.
C'est à mon avis un domaine où les logiciels libres sont très peu présents, même si il y a des initiatives en cours, c'est encore un domaine où les softs propriétaires aux prix exorbitants sont incontournbles.
Par exemple, moins un simulateur VHDL est cher (version démo gratuite), plus il contient de boucles d'attente vides ... (les simulations durent des heures).
Sans aller jusqu'au développement d'ASIC, avec les coûts de production astronomiques des masques, déjà avoir des outils libres pour FPGA permettrait de faire plein de choses. On a beau dire que c'est moins performant et plus cher, ces puces reconfigurables évoluent très vite : les prix baissent et les perfos augmentent à un rythme soutenu. http://www.trenz-electronic.de/prod/proden21.htm
J'avais eu l'occasion, il y a 3 ou 4 ans, d'aborder le sujet avec RMS. Il avait tout de suite soulevé le pb des coûts de production, mais quand j'ai parlé de FPGA, il a dit "si ca se télécharge dans la puce, alors c'est du logiciel, et la FSF encourage le logiciel libre"
http://www.freehdl.seul.org/
http://www.opencores
http://www.geda.seul.org/index.html.org
http://qucs.sourceforge.net/index.html
[^] # Re: Spec != RTL
Posté par Xavier Caron . Évalué à 3.
Au sujet de ASIC / FPGA, il faut comprendre que l'on cherche a faire un micro-processeur. Les frequences max d'un ASIC sont entre 5 a 10 fois moindres que celles d'une puce Intel ou AMD. Quant aux FPGA ils se rapprochent seulement de la frequence de fonctionnement d'un ASIC. Un FPGA coute plus cher a l'unite mais si tu as besoin de grandes quantites les couts fixes lies a la fabrication d'un ASIC (dont les 1 a 2 annees de developpement) sont finalement ammortis. On s'en sert souvent pour prototyper un micro-controlleur genre ARM par exemple.
En bref, concevoir et fabriquer une puce reste un sport de riche...
[^] # Re: Spec != RTL
Posté par Jimmy . Évalué à 3.
J'avais bien compris. Mais tu sais sans doute qu'on peut mettre des microprocesseurs dans les FPGA ... soit en dur dans le silicium (comme les Virtex4FX de Xilinx équipés d'un ou deux PowerPC 405), soit sous la forme de netlist (Nios chez Altera, MicroBlaze chez Xilinx, et puis le LEON dont on parlait plus haut).
Tu sais aussi que Linux (ou µClinux) a été porté sur tous ces processeurs.
Evidemment, les fréquences de fonctionnement n'ont rien à voir avec les processeurs PC haut-de-gamme, on est aujourd'hui dans la gamme 100 à 200 MHz pour un soft-core, et le double pour un hard-core (le tout sans radiateur ni ventilo !). Mais le but est bien différent de celui d'un CPU généraliste, ca on est dans une puce programmable ! On peut donc implémenter plein de périphériques sur mesure, parallèliser des coprocesseurs hardware pour des applications particulières, profiter de la reconfigurabilité de la puce (même en cours de fonctionnement), explorer des topologies multiprocesseurs ... les performances (vitesse de calcul ET consommation) ne sont pas du tout ridicules pour une application embarquée spécifique.
Et la possibilité de modifier le design une fois le produit fini, pour corriger un bug ou ajouter une fonctionnalité, vaut de l'or !
Un FPGA coute plus cher a l'unite mais si tu as besoin de grandes quantites les couts fixes lies a la fabrication d'un ASIC (dont les 1 a 2 annees de developpement) sont finalement ammortis.
Effectivement, c'est valable sur une grande quantité. Plus performant, moins cher à l'unité, mais il faut être sûr de son marché.
Le point où il devient plus rentable d'engager des gros coûts fixes pour produire un ASIC pas cher, que de payer un FPGA tout fait, recule de plus en plus. Par exemple, il y a un FPGA (un Spartan2, je crois) dans la Freebox, et ce n'est plus un produit de petite série ...
On s'en sert souvent pour prototyper un micro-controlleur genre ARM par exemple.
Pour certaines applications de traitement d'image en temps réel, où les débits de données sont importants, il n'est pas question d'utiliser un processeur généraliste (soit il consomme trop, soit il n'est pas assez performant), les délais de mise sur le marché et les volumes ne sont pas compatibles avec un développement ASIC, alors le FPGA est la seule solution !
Il y a 4 ou 5 ans, les FPGA étaient sans doute principalement utilisés pour faire du prototypage, mais plus maintenant.
Pour revenir aux outils de CAO (électronique et autres), il y a des solutions propriétaires qui tournent sous Linux [*], certaines ont même des versions démo gratuites, mais malheureursement rien de libre. Dans le domaine mécanique, il y a des codes de calcul, comme CodeAster, mais pas d'outil de design comme Catia. Pour l'électronique analogique, il y a Spice. Pour l'électronique numérique, je crois qu'on les a presque tous cités. Et l'optique, l'acoustique, la thermique, l'aérodynamique, l'énergétique ?
Il est vraiment temps que les outils libres sortent du domaine quasi-exclusif de la programmation logicielle, et déferlent sur tous les domaines techniques !
[*] La migration station->PC a réduit les coûts, mais la migration UNIX->Windows associée n'a pas que des avantages quand on développe ... Alors le couple PC+Linux est un bon compromis pour la CAO, et de + en + d'entreprises vont dans cette direction. Les éditeurs commencent (timidement) à suivre.
[^] # Re: Spec != RTL
Posté par Xavier Caron . Évalué à 2.
Pour la CAD, nous n'avons quasiment plus que des Linux-box au boulot. Ca marche tres bien et tres vite. Les outils sont tous portes avec comme baseline la RHEL3. Les quelques autres stations vieilissantes sont des Sun Sparc, SunOS 9 (dont ma poubelle sans clavier "avé l'accent"). Mais les softs open-source ne sont pas legion et nous depensons des mega-brouzoufs par an pour tous les outils dont nous avons besoin (une license a l'annee peut faire de 50 K$ a 500 K$). Vu la complexite des softs je ne vois malheureusement pas trop venir d'equivalent libre. Par exemple, un coeur ARM necessite un outil de synthese physique. Ca coute un max mais ca nous permet de traquer les um^2 et les MHz (facteur de decision chez nos cients). C'est deja une gageure de trouver un outil de synthese classique en OSS.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.